|
需求规划完成了之后，我们要确保这些需求能在敏捷开发的过程当中实现。相比较与瀑布模式，需求规划完成了之后，提供一份完整的PRD就可以逐项开始 开发了，敏捷模式下需求规划中的功能清单首先有可能不是一次实现，会分多次，可能中间还穿插了别的项目，其次是每个功能清单还是再拆分成开发任务去分别实 现，再加上中间的需求变更，所以在需求实现的过程当中是要采取一些措施去避免实现中的困难的，比如需求实现的连续性问题，需求拆分的方式方法，需求变更的 处理，敏捷开发过程当中问题的解决等。项目管理者联盟
 项目管理者联盟
在敏捷开发模式当中，需求实现的过程有以下几个方面需要注意：项目管理者联盟
计划会议如何分解Backlog项目管理者联盟
需求规划完成后就形成了确定的需求，体现在敏捷流程当中，就是一条产品需求Product Backlog，我们要实现它，就要开启一个新的敏捷迭代，通常一个迭代的开始都是通过计划会议来开始的。项目管理者联盟
开计划会议的前提是需求规划已经完成，Product Backlog必须已经存在;通常，对单个产品或者项目而言，只能有一个Product Backlog和Product Owner;每个Product Backlog的描述都是完整的，包括主题、描述、优先级和验收标准等;Product Owner应当理解每个Product Backlog的含义;敏捷团队成员根据Product Backlog优先级，已经预先了解即将开始的迭代大致会涉及的Product Backlog，并能列出相应的问题;项目管理者联盟
注意：Product Owner之外的人也可以添加Product Backlog，但是他们不能说这个Backlog有多重要，也不能定优先级，这是Product Owner独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。项目管理者联盟
首先就是确认Product Backlog的开发顺序，如果有多条的话，基本都是按照需求的优先级的来确定的;项目管理者联盟
其次是确定Product Backlog是否需要拆分，即判定是否可以在一个迭代内完成，或者是否整体需求的优先级都是一样高的;项目管理者联盟
最后就是按照拆分好的条目重新排定开发顺序;拆分的依据如下：项目管理者联盟
1、 每个拆分出来的条目都是可单独验证并上线的;club.mypm.net
2、 每个拆分出来的条目都是可以在单个迭代内完成的;项目经理圈子
这就涉及到工时估算的问题，一般的估算方法都是让团队中不同级别的成员对某个Backlog进行估时，并取某个中间值或者团队都可并接受的值为最终的估算工时;项目管理者联盟
 bbs.mypm.net
每日站会确保需求实现的进度项目管理者联盟
检查每天的工作进展是否按照迭代计划在进行，永远确保资源投入在高优先级的Backlog上;项目管理者联盟
该完成而未完成的任务有哪些以及是什么原因?及时识别出对迭代中后续问题的影响，并根据风险和应急方案努力规避;项目管理者联盟文章
遇到的问题应该由谁来负责解决以及何时必须解决，否则会影响后续计划中哪些条目?尤其是那些有前后依赖关系的条目;项目管理者联盟
开发过程中会出现对原有需求的进一步细化，可能会和迭代计划时讨论的结论有一些差异，那么变更的内容是否会对既定的业务需求产生调整?PgMp.mypm.net
需求变更的原则是在计划会议之后，既定的Backlog尽可能保持稳定;但是需求变更是很难避免的，若业务或者技术发生变化时，敏捷团队该如何响应呢?club.mypm.net
1、如果有紧急插入的需求，但不影响既定Backlog需求进度的，可以在迭代当中安排插入开发;如果会影响原有Backlog需求进度的，此时需召集PO开会讨论，以决定将哪个Backlog移出本次迭代的开发计划;项目管理者联盟
2、如果没有插入需求，但既定Backlog需求完不成，如果通过加班能解决的，尽量安排加班来完成，实在不行的将剩余部分安排进下一个迭代，原则 就是“今日事今日毕”;如果既定Backlog需求不饱和，可以适当将未安排的需求移到本迭代内开发，也可以安排一些内部的技术分享或者培训，以提高团队 的整体实力;项目管理者联盟
3、如果遇到一些特殊的情况，比如因为一些不可抗的因素导致既定的迭代计划无法继续完成，则应该提前终止;并总结出现类似问题的原因，尽量避免此类 问题再次出现。最常见的就是和第三方的合作项目，有的时候因为赶进度，合同还没谈好就要开始开发，到最后合同没谈成，就白干了，这种情况要和业务部门协 商，尽量避免;项目管理者联盟
敏捷测试保证需求实现的准确率项目管理者联盟
敏捷测试是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。项目管理者联盟
|
