一、  迭代计划会前准备

由于小组是第一次进行敏捷开发试点，小组成员对敏捷的概念、原则和方式等不是很了解，在会前准备阶段，首先对小组现有的问题进行了根因分析并提供了可行的方案进行参考，例如：

Ｑ： 开发人员参与会议较多？

Ａ ： 会议的类型进行确认，例如需求澄清会：首先负责人要对需求进行筛选，确认需求价值、可行性、是否合理、上线交付以后的业务价值等，在需求确认以后才能开始占用开发测试时间、减少研发资源的浪费和占用。在参加需求澄清会时，团队负责人需要过滤需求，让各角色在需要的阶段分批次参加，从而保护团队资源，减少浪费。

Ｑ： 生产问题太多占用太多时间？

Ａ： 由于生产问题的优先级较高，在阻塞严重时，需要调集研发资源协助处理生产问题。在事后对问题进行复盘，查找问题根源，为什么没有在需求、设计、开发、测试等阶段提前发现，提出、实施改进措施，保证生产问题不要重复发生。要将问题发现的时间迁移，问题越早发现，修复的成本越低，从而减少资源的占用。

Ｑ： 开发质量不高，反复修改次数多？

Ａ： 在迭代计划内任务完成以前，让研发资源专注完成迭代内工作，保证代码质量；在平时要对开发技能、代码规范等制定相关提升计划与规范；对各阶段的工作产出建立追踪机制与相应的责任机制。

Ｑ： 与外系统对接花费精力较多？

Ａ： 需要提前与外系统对相应的接口文档、联调时间、工作量等进行确认，当组员遇到阻塞无法按计划完成任务 ， 同时个人无法推进工作进度时，需要提前在小组内报告风险，并确认对应人员去协调处理，减少延误风险。

以上问题在很多小队都存在，对应的解决措施其他小队也可以用来参考，选择适合自己的方式，对现有的问题思考解决方式，在改进的过程中反馈的结果进行分析，通过不断的改进行动从而找到解决问题的方式。

其次对迭代计划会前的准备工作进行了介绍，并对各角色布置了相应的任务。例如：

需求就绪标准：

１、  建立对应系统任务

２、  各任务估算开发、测试工作量

３、  确认相应接口标准、文档

准备工作：

１、  所有未上线的需求和系统任务都在看板可见。

２、  估算系统任务的开发、测试人天：队长给出估算，填写开发估算、测试估算；每个小队成员创建个人任务并给出估算

３、  计算小队开发容量，确定迭代期内小队的工作量受理极限，在计算时需要对特定情况进行处理（例如休假、兼职、新员工等情况进行适当调整）

４、  需求优先级与业务确认

准备工作需要在会前准备就绪，这样在小队成员开会时可以减少开发资源的占用时间，节约研发资源，然后能将会议时间充分用于统一目标、确认价值、沟通协调等方面。

作为小队负责人，平时的工作不只是对小队成员进行工作任务的分配，监督工作进度情况，还需要保护小队成员免受不必要的干扰，做好相应的准备、协调工作，针对问题组织大家一起来思考原因和解决方式，注意团队成员的状态，建立多角色间、成员内部协作机制，规划小队成员的发展方向与技能提升计划。

二、  迭代计划会

１、  由于时第一次召开迭代计划会，首先对小队成员的角色类型、数量进行确认。

２、  确认迭代计划会目标：共同选择系统任务、承诺完成开发 +SIT ，可以展示 Demo 。

３、  确认系统任务概念： 1 、可独立开发、 SIT 的功能； 2 、规模 ( 开发 +SIT)<=10 天（迭代周期）

４、  确认 IT 价值：让业务尽快感知开发成果，加快反馈。

５、  具体流程 / 操作：        

      5.1  按价值优先顺序拍计划（常见价值类型：安全性、优化体验、监管要求、资源整合、技术优化），需要在迭代计划会前准备，分析需求实际价值、优先原因，做到优先顺序要提前知道。

     5.2  每人认领个人任务，不超出可用容量。在认领时如果发现风险或者阻塞点需要进行标记，同时指定求助对象协助解决该阻塞点。

     5.3  填写系统任务计划完成时间（ SIT 提测时间），需要注意倒排期需求、涉及外围系统接口需求。

     5.4  共同确认、填写迭代计划版本。

     5.5  梳理能展示 d emo 需求，并标记

６、  问题与改进、解答

针对会上发现的问题进行优化改进，例如：

Ｑ： 系统名称不规范，不能体现功能点或者业务价值

Ａ： 系统任务名称需要进行规范，例如体现功能点。

Ｑ： 系统任务不涉及开发测试

Ａ： 对还未涉及开发测试的任务，可以按照产出物进行划分，保证任务的价值和可度量性，例如：需求设计任务，可以拆分为系统设计与评审。

Ｑ： 迭代进行中发现新的工作内容

Ａ： 需要组长 / 项目经理新建系统任务。小队成员主要关注个人任务，需求、系统任务由组长、项目经理负责创建与管理。

Ｑ： 封板要求（ N-2 ）限定日期，由于开发延迟、问题修改、导致测试时间紧迫

Ａ： 做计划时需要考虑封板时间来制定计划，做好提前规划，中间遇到问题时各角色之间需要互相帮助。

Ｑ： 提测时间重叠，测试压力大

Ａ： 测试案例评审时多角色参与，在迭代周期的快要结束的积压时段，团队内的开发需要帮助测试进行交叉测试，减轻测试的负担。

三、  迭代计划会后

在迭代计划会结束后，团队成员需要对各自领取的个人任务补充计划完成时间，方便团队内部成员、也方便涉及外围系统时能够按照计划进行协作，确保迭代周期内的任务能够完成。

迭代周期内的每日站会前团队成员需要对各自的任务状态进行更新，遇到阻塞时要及时反馈给相应的人员，实现信息的透明化。

                       在使用电子看板前使用的物理看板

四、  感想

       第一次参与如此系统化的敏捷小队实践，感觉最后是否能够落地，是否能够真正的对小队有所提高，能够解决大家目前的问题、痛点，需要每一个团队人员的参与和思考。敏捷的实践不能只依靠老师的辅导，还需要各角色的参与，在实践过程中对遇到的问题进行思考，寻找解决方案进行实践，再通过反馈得到的结果不断修改之前的方案，在不断的目标 - > 实践 - > 反馈的迭代过程中提高团队，最终实现价值的快速交付。

此次迭代计划会的感想：

1. 业务价值：个人之前很少从这方面考虑问题，意识也不强。实现了业务价值才是根本目的，技术从业务价值方面与业务方对接，是一种很好的杠杆点。

2. 迭代：迭代是一种化繁为简的有效方法。持续不断地按优先级交付业务价值，能满足复杂多变的现实业务需求，又能不断提供一线业务反馈，不断在下一个迭代中调整。

3. 节奏：可预期，形成合作默契，减少协作摩擦力；并且可以让每个人从容不迫，发挥潜力，从而达到个人和整体的高效能。

4. 反馈：在实际反馈中调整，并且是要从最底层的反馈开始，也是最重要的。缺少反馈就是单相思，痴人说梦。晨会，周会，迭代后的复盘会，都是很好的反馈和反思总结方式。

5. 流动：我个人曾经提出过一个观点：信息流动的效率和质量可以作为判断一个项目组是否健康的标准。 敏捷中价值的流动，例如开发，测试，交付，反馈的流动及流动的效率和质量，是一种技术生命力。

6. 持续改进：改进需要在实践中从细微处开始，不断练习，不断发现，不断感悟，持续从细微处着手是很好的抓手。

7. 提正确的问题：是高效和深入沟通的有效方法。