根据发布目标分析需求把需求分析成独立故事初步分析可以是粗略随着需求不断深入刻意对故事进行整合或者切割
要注意是分析出来需求尽量在发布目标范围的内超出发布目标需求应该尽量避免过深分析
所谓发布目标是确定了这个版本可以让用户满意条件
故事模式:做为(用户角色)我可以(做什么)以便(业务价值)后面业务价值在比较简单或者大家都比较明确时候刻意不需要注明
当前团队(Team)实战推行思路方法:
第阶段这个分析工作开始由PM进行收集、整理和分析
第 2阶段当大家都为用户故事方式接受以后采用需求讨论方式来明确和分析用户故事
2、对分析故事进行相对估计估计出来故事点是对用户故事和复杂度无单位估计值使用数值大小本身没有绝对意义只有相对于其他故事规模相对意义
比如用户登录这个用户故事估计值是2那么做为同等开发规模用户推出这个用户故事估计只也应该是2
当前团队(Team)实战推行思路方法:
第阶段这个估计工作暂时由PM来负责完成但是由于个人估计肯定会有偏差所以在估计完成的后需要进行调查来进行修正
第 2阶段用估计扑克会议来统对用户故事进行估计当主持人拿出个新用户故事的后大家给出自己对这个故事使用扑克打分然后取出平均值对差异较大估计值要给出解释来消除对用户故事理解估计扑克会议实战不超过１个小时
3、准备产品调查对用户故事进行功能存在和功能缺失性产品调查然后根据调查结果对用户故事进行划分划分成3类:基本需求线性需求非线性需求
此外还有反对需求、存在疑问需求、无所谓需求3种类型需求这些需求将根据进步发展进行确认
当前团队(Team)实战推行办法:
第阶段由PM发出调查问卷在参和到项目开发团队(Team)、测试团队(Team)、技术支持团队(Team)来进行调查然后汇总答案根据存在问题和缺失问题答案对用户故事进行定性
第 2阶段由PM发出调查问卷扩展到相关用户群体中进行调查然后汇总答案根据存在问题和缺失问题答案对用户故事进行定性
4、确定发布规划首先要确定是迭代周期长度以周为单位然后估计出每个迭代周期团队(Team)速度然后可以从用户故事池中选择出合适用户故事来填充到第次和第 2次迭代周期中其余暂时可以先不用填充随着每次迭代周期完成来对发布计划进行更新最后根据估计速度和需要开发故事来确定需要几个迭代周期并最终有几个迭代周期来确定需要开发时间周期发布计划可以以功能来驱动进行也可以以日期来驱动进行 [Page]
发布规划特点以月做为时间范围规划对象是用户故事估计单位是故事点
当前团队(Team)实战推行办法:
第阶段使用1周做为迭代周期开始时团队(Team)速度使用估计方式做出简单估计根据每个周期结束后团队(Team)速度再进行发布计划调成迭代周期内用户故事完成暂时以开发完成做为标准
第 2阶段使用2周做为迭代周期可以使用原有历史速度做为团队(Team)速度多出周时间做为测试修复时间迭代周期内用户故事完成以测试完成完整功能提交做为标准并在开发过程中熟练使用单元测试来进行确保功能完整完成
5、确定迭代规划根据填充到迭代周期内用户故事来分解成工作任务工作任务包括设计工作区别层次开发工作调试工作和测试工作等等具体任务然后对任务进行估计这时候估计单位以理想工作小时做为单位比如设计需要两个人小时开发持久层需要1个人小时调试持久层需要半个人小时开发业务层需要2个人小时调试中间层需要1个小时等
然后根据每个故事人小时和这个迭代周期内参和人数以及每个人所能参和实际有效时间(注意有效时间约为每天6小时需要考虑到会议讨论头脑休息等非理想工作时间)来判断这个迭代周期填充是否足够如果不够则再加入个用户故事如果超出则移出个用户故事到下个迭代周期中
迭代规划特点以周做为时间范围规划对象是工作任务估计单位是理想小时
当前团队(Team)实战推行办法:
第阶段使用速度驱动思路方法来进行迭代规划即确定了本次迭代速度然后选择用户故事扩展成任务对任务进行估计
第 2阶段使用承诺驱动思路方法来进行迭代规划即提出个故事把故事扩展成任务对任务进行估计让小组承诺是否可以完成这个故事如果可以在迭代周期内完成则加入这个故事如果不能完成则推迟到下个迭代走起
6、迭代开始在迭代开始时召开迭代启动会分配迭代周期内用户故事和工作任务到个人每个工作任务必须精确到个人同个用户故事区别工作任务可以根据情况适当分配给区别人来完成
当前团队(Team)实战推行办法:
第阶段任务分配给个人通常个故事任务分配给同个人
第 2阶段任务分配给结对通常个故事任务分配给同个结对 [Page]
7、迭代进行每日早对昨日完成工作任务和问题进行汇报并且同时计划今天需要完成工作任务对于迭代过程中进度和问题进行及时观察和调整要求每个人完成某个任务的后要及时告知整个小组知道(qq群方式最为快捷)
当前团队(Team)实战推行办法:
第阶段由PM及时地对当日工作进行询问并负责把遇到问题跑出来进行解决
第 2阶段小组成员主动地对已经完成任务进行汇报并及时把自己遇到问题抛出来
8、迭代结束确认本次迭代完成用户故事对于完成部分用户故事计算到下次迭代中并对本次迭代过程资产进行整理总结形成FAQ方式文档进行规整
同时根据新需求情况资源情况已完成功能回馈以及开发中遭遇不确定性问题对发布规划和迭代规划作出调整
当前团队(Team)实战推行办法:
第阶段使用学习网站WebSite或者博客等方式对经验进行记录
第 2阶段使用完善skills对经验进行记录可以方便组织成培训文档并方便进行搜索查找
9、迭代测试为了保证用户功能完整提交每个用户故事开发完成的后都要对该用户故事进行测试然后在针对开发中出现问题进行修复以便完整完成个用户故事
第阶段:测试迭代周期和开发迭代周期分开
每次迭代开始阶段由PM告知开发组需要开发和修复用户故事同时告知测试组本次迭代需要测试故事需要准备故事需要复测故事
并在分配任务时把修复故事工作规划到本次迭代中来
每次开发完成用户故事点算作本次迭代速度
迭代1 迭代2 迭代3 迭代4 迭代5
测试 准备故事12 测试故事12
准备故事34 测试故事34
准备故事56 复测故事12
测试故事56
准备故事78 复测故事34
测试故事78
准备故事910
开发 开发故事12 开发故事34 修复故事12
开发故事56 修复故事34
开发故事78 修复故事56
开发故事910
第 2阶段:测试迭代周期和开发迭代周期合并
每次迭代开始阶段由PM告知开发组需要开发故事同时这些故事也是测试组需要准备测试故事要求这些故事分解工作任务中要包括测试工作和修复工作
每次测试完成用户故事点算作本次迭代速度
迭代X
测试 准备故事1234 测试故事1234 复测故事1234
开发 开发故事1234 修复故事1234 完成故事1234
十、发布结束对本次发布中完成用户故事进行会议整理总结:
1 确定最终完成用户故事以及花费迭代周期
2 通过计算得到个团队(Team)人平均速度这个速度做为下次发布规划参考
3 分析哪些用户故事估计出现了失误以及出现失误原因是什么
4 最初发布版本在市场上有了初步反馈信息的后可以延长1个迭代周期用来做为发布版本反馈收尾
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
