敏捷实践：如何让团队的迭代效率更高.pdf

敏捷实践 ：如何让团队的迭代效率更高 在互联网行业 ，敏捷应该不是陌生的名 了。互联网产品快速发展的特性 ，决定了“小步快跑”的管理 思想 ，持续迭代 ，不断的改进产品。而应用敏捷基本上可以让迭代周期减少一半 ，在追求效率和产 出的互联网 ，这确实是一剂良方。 在产品研发过程中 ，从需求管理到最终的产品运营 ，全过程应用敏捷的思想 ，让产品团队成为产品 的主人和管理创新的驱动者。当产品团队自发的去持续优化产品 ，不断提升产品质量和研发效率时 ，整个团队的工作效率就提升了 ，产品的迭代周期自然会缩短 ，他们会树立更高的目标去挑战 ，当 他们持续地周而复始时 ，卓越就成为了团队的习惯。 在敏捷实施的过程中 ，从产品经理的角度来说 ，更应该关心需求是否也可以迭代的方式去产出 ，合 理的按照价值和优先级去安排每个迭代需求 ，是产品经理需要关注的。这会保证每个迭代开发人员 在实现的都是优先级最高的需求。从开发人员角度来讲 ，对每个迭代的任务的需求理解和工作量安 排是他们所要关心的 ，要合理的分配每个人的任务 ，以达到最大化的效率利用 ，进而保证每个迭代 的高效产出。 1号店目前已全面实施敏捷开发 ，结合自己对敏捷需求管理的理解 ，分享在1号店工作期间实施敏捷 项目管理的实践经验、失败教训。主要从以下几个环节提高团队效率 ，最终成功地让4-6周的交付 周期缩减到了2周左右。 迭代需求集中评审和评估工作量 在每个迭代开始之前 ，产品经理就需要把下一个迭代要做的需求安排好 ，待到迭代开始之前 ，对所 安排的需求进行集中讲解评审 ，参与的对象是整个团队。这样做的好处是 ：研发、测试团队 和Scrum Mast er一起深入理解需求 ，测试团队也因此能够更早地开始编写测试脚本 ，这样需求、 开发、测试都是敏捷的 ，否则只有开发是敏捷的 ，两头就会都跟不上。 很多人觉得每个迭代开始之前 ，花上一整天的时间去理解需求和评估工作量是很浪费的 ，但是磨刀 不误砍柴工 ，在工作开展之前把一切不确定性的东西都确认好 ，这样后续的开发效率就会高很多。 另外对产品经理的要求就是提前梳理需求 ，这个不是简单的梳理 ，而是要充分评估手头所有需求功 能点的价值和优先级 ，先做优先级高的。 站会 ：随时把控进度、解决问题 站着开会带来的紧张感和疲劳感可以有效地避免过于冗长的会议 ，且可以保持清醒的状态 ，一般都 在早上上班的时候开 ，也叫“晨会”。可以尝试让发言者站在中间 ，这种做法更能增强其自信心和责 任感。站会的议题是每人说一下自己昨天做了什么 ，今天要做什么 ，有没有遇到问题。产品经理可 以参与站会听取一下团队成员的进度 ，对各个需求的进展了然于胸 ，对发生的问题需要介入协助的 ，可以在会后就协助处理。 团队自我 动 在迭代开始之前要做好任务的认领和分配 ，可以培养团队主动工作的积极性。在迭代开始后 ，要明 确只有开发出可用的功能才算完成 ；明确迭代目标 ，并把目标分配给明确的负责人 ；严格要求代码 提交环节 ，确保提交后测试即可介入 ；明确每个人的工作职责 ，优化团队协作机制 ，中间出现某个 成员进度弱后的情况 ，可以调配进度快的成员帮忙。同时要避免整体重构 ，尽可能局部重构。产品 经理更需要确定迭代目标能否完成而不仅是关注迭代进度。 持续集成和产品演示环境 迭代任务陆续完成过程中 ，要能自动化集成到演示环境 ，这样就可以边开发边验证 ，测试也就可以 边开发边测试 ，省去了很多重复的工作。并且可以尽早的发现问题或bug ，及时修复。产品演示环 境能够尽早Ready是很重要的 ，这样可以提前看到产品的最终形态。 迭代总结会 在每个迭代结束的时候 ，要召开迭代总结会 ，团队成员都需要完成自评和他评 ，分析和总结上一个 迭代中遇到的问题 ，大家讨论改进的方法 ，比如说到需求变更太多之类的 ，就需要产品经理更好的 去把控和分析需求 ，尽量在开发过程当中不变更。绩效与任务难度挂钩的方式也激励成员做有挑战 的项目/功能开发。同时 ，严格的得失分析让团队更好地吸取经验和教训。 保证质量 虽然研发速度很重要 ，但是没有质量保证的快速开发非常危险 ，质量保证是一项需要高度重视的 标准。需要制定严格的bug控制标准 ，开发自测和测试人员测试的标准不一致 ，这样可以激励不同 角色人员的工作积极性。 敏捷开发对于产品经理来说是一个挑战 ，迭代周期越短 ，对产品经理的要求越高。比如迭代周期为 两个星期 ，那就需要产品经理在两周内把自身对产品的想法 ，或者业务部门的需求转化成可供开发 的需求 ，这样才能保证迭代的顺利进行。这对产品经理的能力要求还是很高的 ，假如一个迭代要完 成