敏捷开发模式中的需求实现

浪子行

需求规划完成了之后，我们要确保这些需求能在敏捷开发的过程当中实现。相比较与瀑布模式，需求规划完成了之后，提供一份完整的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、  每个拆分出来的条目都是可单独验证并上线的；

2、  每个拆分出来的条目都是可以在单个迭代内完成的；

这就涉及到工时估算的问题，一般的估算方法都是让团队中不同级别的成员对某个Backlog进行估时，并取某个中间值或者团队都可并接受的值为最终的估算工时；

每日站会确保需求实现的进度

检查每天的工作进展是否按照迭代计划在进行，永远确保资源投入在高优先级的Backlog上；

该完成而未完成的任务有哪些以及是什么原因？及时识别出对迭代中后续问题的影响，并根据风险和应急方案努力规避；

遇到的问题应该由谁来负责解决以及何时必须解决，否则会影响后续计划中哪些条目？尤其是那些有前后依赖关系的条目；

开发过程中会出现对原有需求的进一步细化，可能会和迭代计划时讨论的结论有一些差异，那么变更的内容是否会对既定的业务需求产生调整？

需求变更的原则是在计划会议之后，既定的Backlog尽可能保持稳定；但是需求变更是很难避免的，若业务或者技术发生变化时，敏捷团队该如何响应呢？

1、如果有紧急插入的需求，但不影响既定Backlog需求进度的，可以在迭代当中安排插入开发；如果会影响原有Backlog需求进度的，此时需召集PO开会讨论，以决定将哪个Backlog移出本次迭代的开发计划；

2、如果没有插入需求，但既定Backlog需求完不成，如果通过加班能解决的，尽量安排加班来完成，实在不行的将剩余部分安排进下一个迭代，原则 就是“今日事今日毕”；如果既定Backlog需求不饱和，可以适当将未安排的需求移到本迭代内开发，也可以安排一些内部的技术分享或者培训，以提高团队 的整体实力；

3、如果遇到一些特殊的情况，比如因为一些不可抗的因素导致既定的迭代计划无法继续完成，则应该提前终止；并总结出现类似问题的原因，尽量避免此类 问题再次出现。最常见的就是和第三方的合作项目，有的时候因为赶进度，合同还没谈好就要开始开发，到最后合同没谈成，就白干了，这种情况要和业务部门协 商，尽量避免；

敏捷测试保证需求实现的准确率

敏捷测试是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。

1、持续测试、持续反馈，阶段性比较模糊，强调测试的速度和适应性；

2、扮演“用户代表”角色，确保产品满足既定的需求；

3、强调直接的沟通、协作以及团队责任，不太关注对缺陷的记录与跟踪；

4、敏捷功能测试 = 新特性的手工测试+ 原有功能的自动化测试

5、敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试；

一个好的计划会议可以将需求拆分成可在一个迭代内实现的几个部分，再加上每日站会的过程跟踪，发现问题及时解决，最后通过敏捷测试及时验证已开发完成的条目，这样的过程基本可以保证每个需求的实现都是按照原先的需求规划来的。

上一篇：敏捷开发模式中的需求规划
下一篇：想报考个敏捷教练培训班，那个好？

月光色

学习下我只是路过，不发表意见……

枫叶112

好帖是需要鼓励的~

玉米小王子

我是个凑数的。。。

外挂滤镜

打酱油的人拉，顺便赚点金币

寂寞、变堕落

路过 帮顶 嘿嘿

风继续吹

没人回帖。。。我来个吧！

微亮的光芒

学习下我只是路过，不发表意见……

多喜欢张杰吖！

好帖是需要鼓励的~

在终点前，

支持，赞一个

笑笑吧

还不错哦，如果再能多分享一些就perfect了！

笑很甜

very good.

赫尔墨斯!

很有借鉴意义，先收藏了，谢谢楼主。

废话多了没有味i

很有借鉴意义，先收藏了，谢谢楼主。

箛獨

其实，很多情况下都是这样的，习惯就好。