迭代任务是一种任务管理方式，它使用分步骤的方式完成一项复杂的任务。在每一个步骤中，都会有一个反馈机制，以便根据结果进行调剂和改进。这类方式可以有效地提高工作效力，并且可使任务变得更加可控和可预测。
如何让团队的迭代效率更高
在互联网行业，敏捷应该不是陌生的名词了。互联网产品快速发展的特性，决定了“小步快跑”的管理思想，持续迭代，不断的改进产品。而应用敏捷基本上可以让迭代周期减少一半，在追求效率和产出的互联网，这确实是一剂良方。
在产品研发过程中，从需求管理到最终的产品运营，全过程应用敏捷的思想，让产品团队成为产品的主人和管理创新的驱动者。当产品团队自发的去持续优化产品，不断提升产品质量和研发效率时，整个团队的工作效率就提升了，产品的迭代周期自然会缩短，他们会树立更高的目标去挑战，当他们持续地周而复始时，卓越就成为了团队的习惯。
在敏捷实施的过程中，从产品经理的角度来说，更应该关心需求是否也可以迭代的方式去产出，合理的按照价值和优先级去安排每个迭代需求，是产品经理需要关注的。这会保证每个迭代开发人员在实现的都是优先级最高的需求。从开发人员角度来讲，对每个迭代的任务的需求理解和工作量安排是他们所要关心的，要合理的分配每个人的任务，以达到最大化的效率利用，进而保证每个迭代的高效产出。
1号店目前已全面实施敏捷开发，结合自己对敏捷需求管理的理解，分享在1号店工作期间实施敏捷项目管理的实践经验、失败教训。主要从以下几个环节提高团队效率，最终成功地让4-6周的交付周期缩减到了2周左右。
迭代需求集中评审和评估工作量
在每个迭代开始之前，产品经理就需要把下一个迭代要做的需求安排好，待到迭代开始之前，对所安排的需求进行集中讲解评审，参与的对象是整个团队。这样做的好处是研发、测试团队和Scrum Master一起深入理解需求，测试团队也因此能够更早地开始编写测试脚本，这样需求、开发、测试都是敏捷的，否则只有开发是敏捷的，两头就会都跟不上。
很多人觉得每个迭代开始之前，花上一整天的时间去理解需求和评估工作量是很浪费的，但是磨刀不误砍柴工，在工作开展之前把一切不确定性的东西都确认好，这样后续的开发效率就会高很多。另外对产品经理的要求就是提前梳理需求，这个不是简单的梳理，而是要充分评估手头所有需求功能点的价值和优先级，先做优先级高的。
站会随时把控进度、解决问题
站着开会带来的紧张感和疲劳感可以有效地避免过于冗长的会议，且可以保持清醒的状态，一般都在早上上班的时候开，也叫“晨会”。可以尝试让发言者站在中间，这种做法更能增强其自信心和责任感。站会的议题是每人说一下自己昨天做了什么，今天要做什么，有没有遇到问题。产品经理可以参与站会听取一下团队成员的进度，对各个需求的进展了然于胸，对发生的问题需要介入协助的，可以在会后就协助处理。
团队自我驱动
在迭代开始之前要做好任务的认领和分配，可以培养团队主动工作的积极性。在迭代开始后，要明确只有开发出可用的功能才算完成；明确迭代目标，并把目标分配给明确的负责人；严格要求代码提交环节，确保提交后测试即可介入；明确每个人的工作职责，优化团队协作机制，中间出现某个成员进度弱后的情况，可以调配进度快的成员帮忙。同时要避免整体重构，尽可能局部重构。产品经理更需要确定迭代目标能否完成而不仅是关注迭代进度。
持续集成和产品演示环境
迭代任务陆续完成过程中，要能自动化集成到演示环境，这样就可以边开发边验证，测试也就可以边开发边测试，省去了很多重复的工作。并且可以尽早的发现问题或bug，及时修复。产品演示环境能够尽早Ready是很重要的，这样可以提前看到产品的最终形态。
迭代会
在每个迭代结束的时候，要召开迭代会，团队成员都需要完成自评和他评，分析和上一个迭代中遇到的问题，大家讨论改进的方法，比如说到需求变更太多之类的，就需要产品经理更好的去把控和分析需求，尽量在开发过程当中不变更。绩效与任务难度挂钩的方式也激励成员做有挑战的项目/功能开发。同时，严格的得失分析让团队更好地吸取经验和教训。
保证质量
虽然研发速度很重要，但是没有质量保证的快速开发非常危险，质量保证是一项需要高度重视的标准。需要制定严格的bug控制标准，开发自测和测试人员测试的标准不一致，这样可以激励不同角色人员的工作积极性。
敏捷开发对于产品经理来说是一个挑战，迭代周期越短，对产品经理的要求越高。比如迭代周期为两个星期，那就需要产品经理在两周内把自身对产品的想法，或者业务部门的需求转化成可供开发的需求，这样才能保证迭代的顺利进行。这对产品经理的能力要求还是很高的，假如一个迭代要完成五个需求，那就要在两周内完成这五个需求的分析和设计，这中间包括了竞品分析、数据分析、调研等等环节，工作节奏会很紧凑。
迭代的成功需要正确的产品方向+正确的需求构建方法，因此在开发前弄清楚产品方向和构建方法至关重要，这也就是迭代开始前的主要任务。
产品经理的基本任务应该是将业务需求分解为产品需求，再将产品需求分解为可实现的功能需求，其目标在于转化和细化原始需求，制定下一个迭代的需求列表和发布计划，以及明确随后1-2个迭代的开发需求。
因此前期需求管理的主要工作在于拆分——从角色的角度拆分、从实体的角度拆分、从目的的角度拆分、从解决方案的角度拆分！分解目的再拆分解决方案，通过拆分明了产品的业务流程，将需求分解为具体的任务和业务操作，最后制定可行的开发流程和迭代计划。
敏捷开发在互联网行业中的应用是大势所趋，个人觉得会深刻影响到传统的瀑布式项目流程。从实际经验来看，敏捷开发也确实有很大的优越性，能够更快的适应需求变更，灵活的安排资源的投入，每个迭代的产出都是产品的阶段性目标，也有可能就是一个小版本的发布，对于崇尚“持续迭代、小步快跑”的互联网产品来说，非常适合。微信在一开始的时候能迅速抢占市场，和其快速的版本发布有很大关系，而现在微信已经进入稳定发展期，版本发布缓和很多。从产品发展的生命周期角度看，新生的产品最容易成功也最容易失败，成功是因为其市场的新鲜感和功能的新增可以俘获用户的关注度，失败是由市场竞争导致的。在互联网行业，产品层出不穷，新出的产品很多时候大家也都愿意尝鲜，但一段时间后发现无趣就会卸载，这段安装到卸载的时间理论上可以发布好几个迭代，而这就是“快”和“慢”的体现。
如何带领开发团队做好迭代计划的心得
迭代是指重复反馈过程的活动，其目的通常是为了逼近所需目标或结果。
迭代的过程
迭代是重复进行某一过程或一系列步骤的行动，每一次迭代都会产生一些结果，这些结果会作为下一次迭代的输入。迭代过程中，每一步都会利用上一步的结果进行调整和改进，不断逼近最终目标或结果。
迭代过程中需要注意收敛性，即次数的增加，结果的差异应逐渐减小，最终达到预期的目标。
迭代的原理
迭代法的基本原理是从初始值开始，通过迭代过程逐步逼近目标或结果。每一次迭代都由一系列步骤组成，每一步都会利用上一步的结果进行调整和改进，以逐步缩小误差或接近最优解。
迭代的重要性
1、逼近目标
通过迭代，可以逐步逼近所需的目标或结果。在每次迭代中，都会根据上一次的结果进行一定的调整和改进，从而更加接近所要实现的目标。
2、优化结果
迭代过程中，可以逐步优化结果。每一步迭代都可以看作是对结果的优化过程，通过不断的迭代，逐步完善结果，使其更加符合预期。
3、适应变化
迭代过程中，可以根据实际情况进行灵活的调整和改变。这样使得其能够更好地适应各种变化和需求，从而更好地解决问题或完成任务。
4、提高效率
迭代过程中，可以及时发现和纠正错误或问题，避免浪费时间和资源。同时，通过不断的迭代和改进，提高工作效率，从而更快地完成任务或达到目标。
5、适应性和鲁棒性
迭代过程中，可以通过根据上一次的结果反馈，对算法、方案或模型进行微调，使其更具适应性和鲁棒性。
作为一名QA，之前有过一些非系统、打游击式的敏捷工作经验。一直随波逐流跟随公司的文化和管理者对敏捷转型的支持程度去推广敏捷实践。终于，在长行敏捷转型的背景下，专业敏捷老师的带领下，感觉找到了组织，有了一场专业的敏捷实践经历。这篇文章就谈谈我在开发团队如何开展迭代计划的一些经验和心得。
一、会前准备
1、规划好本迭代开发需求；
2、拆分好创建的系统任务；
3、各小队成员都已完成各自个人任务的创建；
4、创建好本次迭代版本；
二、迭代计划会步骤
迭代计划会why、目标（计划好、承诺好、交付好） （交付有业务价值、可感知） 2周一个迭代1、做什么明确当前手头需求，对需求进行任务拆分。在本迭代开展前，需要完成需求澄清的工作。即迭代第一天开始就能够进入编码。所以每一个迭代都要预留一定的时间来作为下一个迭代的需求澄清和评审，且大家对需求的理解都能达成一致。
2、确定任务优先顺序根据业务提供的需求优先级，对本次迭代的系统任务进行排序。
3、我的可用开发容量我们团队的迭代周期为2周一个迭代。因此每人的一个迭代的工作容量为10人天。但为了应对风险和一些日常事务，以及紧急事务，还有前面提到的需求澄清、会议及一些管理工作，每个人的工作容量都要有所预留。除非是可以全心投入开发的人员，或通过一些加班补充工作量。
如团队人数为10天，一个迭代为10天，则团队的开发容量为10X10=100人天
4、我们一起排任务 （紧密协作、team work）谁有意外一起帮助、达成交付目标
各自认领任务。将任务分配到每个人的名字，并估算出每个任务所需的工作量。当 某人的工作容量超过10人天时，需要其他容量不足的人员进行任务认领，协助完成整个团队的工作任务。
5、这个迭代的交付目标
大家都制定一个共同的迭代交付目标，可交付到下游的交付物。一般为可演示的工作产品/程序。
对于交付物，大家也要有共同的质量认识。我们团队达成共识可交付下游的工作产品即通过了SIT测试的程序。
6、大家的信心指数投票 （识别风险，外部依赖）
最后大家通过一个手势来表示对本次迭代能完成的信心。
1表示信心指数最低，5表示信心指数最高。同时举手表示。当出现差异时，大家再各自说明理由，进行调整。挖掘团队计划中的风险。
以上，为个人在带领和辅导团队开展迭代计划的一些和心得，希望看到这篇文章的敏捷同行能够指导及点评，让我知道有那么一批敏捷的志同道合者也在互相鼓励、努力。谢谢！
评论(0)