发表于： 2017-12-03 23:31:31
1 780
今天完成的事情：
1. 小课堂准备完成70%
2. 敏捷开发live的整理完50%
3 .完成了复盘申请PPT
明天计划的事情
1. 讲小课堂
2. 敏捷开发live的整理完成
遇到的问题：
无
收获：
1. 敏捷开发（未完待续）
敏捷开发：
一、为什么需要敏捷开发
解决的问题：
- 需求在变化
- 定义清楚团队里每个人的职责
- 客户不知道自己到底想要什么，做出来的东西和其心中不服
- 最后得到的东西不符合现在的要求
结论：在需求不断变化的情况下，保证软件开发的质量存在
二、敏捷开发流程中有哪些工具可以使用
- 禅道
控制项目进度
- wiki（confluence）
汇总信息
- 邮件(企业邮箱)
汇报东西
三、敏捷开发中的角色
- 产品经理
- UI设计师
- 前端/后端
- APP有IOS/安卓
- 运维
- 测试
可以把敏捷开发大致分为三个阶段：
- 产品设计阶段
产品经理设计产品，拆解stroy ,PPT,验收标准
设计阶段，PM内部需求评审，确定风格等
内部评审注意： 所有细节考虑到，细节都讲清楚了
需求评审：
所有利益相关的部门参加：产品/开发/运营 （这些部门leader）、技术总监（或者旗下部门leader）、UE、UI（CTO、产品总监）,需要估计出多长时间做出，有没有未接触过的技术。
会议要求得出结论：
- 需求花多长时间完成
- 需求给那些团队、人员来做
- 下次需求讲解时间在什么时候开始
- 各个部门leader职责保证产品经理的需求合理，没有问题，可以交给开发人员实现
- 当需求评审会议过后，原则上不允许对需求做出更改。
需求讲解：
- 给负责开发项目的成员将需求怎么做，做的什么东西
- 开发人员确认自己理解的需求没有偏差，细节考虑清楚无遗漏，判断出这个需求能不能做的到，那些事不确定的地方，有没有需求不合理逻辑混乱
- 的等等（有的话提出给产品经理或 自己部门leader 但不能当场讨论）
方案评审：
- 每一个参与的人主动独立做方案(分模块，能力强多分，最后整个方案满足需求 )（然后架构师/项目leader 拿所有的方案做方案评审）
- 架构师/项目leader需要理解清楚需求和方案，指出方案中的问题，拿出方案的开发人员重新修改
- 开发阶段
2.1 定义接口前后端一起
2.2 拆解stroy,变成task，每一个参见项目开发的人都是项目负责人，需要主动推动项目进度，解决项目问题
2.3 项目有延期风险或项目有问题的时候的时候项目leader , 开始干涉
- 测试阶段
3.1 cordrove ， 性能测试
3.2 dome 环节，开发团队把产品经理交的成品功能需求完全做完，交付给公司，验收通过（由产品经理/项目leader/(技术总监/测试人员)），由开发人员发起
3.3 验收，由PM，UI，测试，技术骨干（不能出现一个问题）
3.4 运维把开发人员代码部署到开发环境，开发环境要求稳定。测试人员（QA）在测试环境所有测试用例跑一遍，找出BUG,记录BUG优先级，追踪BUG的解决进度，推动BUG解决
3.5 上线，所有参与上线的人员都要参与
注： 拥抱需求的变动指在一定时间了需求不变
四、开发流程
- 产品经理不只要讲怎么做，还要将他的来龙去脉
PPT:
- 我们要解决的问题是什么
- 当前行业内解决的问题是什么
- 这些解决方案有哪些好处和坏处
- 期待的解决方案是什么
- 方案有了具体，怎么做，做到什么程度，方法有哪些，思路怎样
- 价值在什么地方（忽悠让公司的开发团队让其跟着他的节奏走）
story:
- 当前stroy的用户角色（什么场景下）
- 给这个用户角色提供什么样的服务
- 给当前用户角色能带来什么价值
注册为例;
stroy： 想要加入注册官网使用其服务的用户，在官网完成注册以便使用只有注册用户才能使用的功能
注意：
- 一个story不应超过一个星期的工作量
- 一个迭代中不应该超过15个stroy或10个
- story的拆解一定要独立, 不要太大，尽量一个story满足一个功能 ？？？？（例如两个story,一个手机号注册，一个邮箱，应该合并为一个注册
- story）
关键点在于：什么样的功能是一个story，story的拆解对于产品经理，是帮助他思考到底要什么东西
进度：
无法关联
禅道：http://task.ptteng.com/zentao/project-task-264.htm
返回列表
评论