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

敏捷开发模式中的需求实现 需求规划完成了之后，我们要确保这些需求能在敏捷开发的过程当中实现。相比较与瀑布模式，需 求规划完成了之后，提供一份完整的 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 需求不 饱和，可以适当将未安排的需求移到本迭代内开发，也可以安排一些内部的技术分享或者培训，以