敏捷迭代日历

前言

我咨询过的项目中，发现很多团队想用敏捷，但是不知道如何做。那我们就从最基础的一个迭代日历开始吧。

经过多个项目的迭代，总结了一个适合于大部分团队的敏捷迭代日历。

不管是在敏捷的理论里面，还是scrum的理论里面，下面总结的活动都多少有一些差异。但敏捷不是说一定要严格按照标准的活动来进行，而是拥抱变化持续改进，找到最适合于自己团队的最佳实践，才是敏捷的核心。

敏捷迭代日历

图中所展示的是一个迭代内发生的所有活动。

通常一个迭代是2周。横向是两周的时间线，纵向是一天的时间线。

紫色的是当前迭代会进行的活动，蓝色的是需要在本迭代为下个迭代做准备的活动，橙色是总结上一个迭代的活动。

接下来我们就每个活动展开来讲解。

站会Standup

站会通常发生在一天的开始。之所以叫站会，是因为大家站着开，才能让会议尽快结束。站会长如图的样子。

站会的目的是什么？

• 促进和改善团队协作

• 让团队达成一致

  • 理解共同的目标
  • 互通不同成员的工作内容
• 消除障碍

站会如何进行呢？

开站会通常有两种模式。

一种是按人头更新，每个人轮流说下面三个问题：

1. 昨天做了什么？
2. 今天准备完成什么？
3. 有没有任何问题或阻碍？

第二种模式是按卡更新，在看板上从右至左的更新每一张卡的状态，及时更新卡的状态，同时也要及时暴露该卡有没有任何问题或阻碍。

谁参与站会呢？

整个团队的人都应该参与。也是那些坐在一张桌子上工作的人。

站会需要多长时间呢？

通常不应该超过15分钟，这也是为什么要站着开的原因，这样才能让大家保持专注，尽快结束会议。

做好站会还有哪些tips呢？

• 站会要固定时间，不能因为某人缺席而推迟。不然会打乱团队的节奏。
• 不要在站会上引入新东西，只聚焦在当前迭代的范围中。新东西应该在其他时间或其他会议中提出来。
• 为了让站会尽快结束，可以准备一个小物件作为信物，拿到信物的人才能发言。大家轮流传递信物进行发言，这样可以避免大家你一言我一句的发散导致会议时间过长。
• 每次站会都应该有一个facilitator。作为站会的推动者负责保证站会高效有序的进行，并更新相关的状态。

迭代计划会议Iteration Planing Meeting

迭代计划会议的举行就标志着上个迭代结束了，下个迭代开始了。因此，我们会在这个会议上在看板中关闭上个迭代，然后开启下个迭代。

迭代计划会议大概长下图的样子，大家打开迭代看板和backlog，然后讨论下一个迭代要做什么。并设置好下一个迭代的看板。

目的

这个会议的目的就是让团队决定接下来这个迭代中，我们要做哪些工作（哪些故事卡）。

如何进行？

通常会考虑团队工作载量，比如一个团队每个迭代能完成30个点，那么就会计划30个点到下一个迭代中，同时会选择优先级高的卡优先完成。

然后团队一起决定下个迭代做哪些卡，这些卡是否都已经是ready的，如果不ready的卡不应该放到下个迭代中。

谁参与呢？

理论上这个会议需要Product Owner参加，他可以回答大家对于这个迭代的工作的问题。实践中发现国内大部分公司没有Product Owner，而类似的角色是提出需求的业务方。因此实践中只需要让团队所有成员参与就可以了。

而对于需求的澄清，会议前应该让产品经理或BA提前完成和业务方的需求澄清和优先级排序。

会议需要多少时间？

通常在一个小时以内。为了保证会议能按时结束，有些工作会放到会前或者其他会去做，比如估点、卡的需求澄清等。

迭代的开始不一定是周一。可以是团队觉得合适的任何一天，比如周三。

当前迭代的工作

迭代开始后，开发和测试人员会工作在当前迭代的卡片中。

如果遇到不清楚的细节，就可以找产品经理或BA澄清。需求澄清应该是一个随时随地发生的动作。

代码评审Code review/技术分享

有的团队会把代码评审和技术分享分开来做。大部分团队没有太多技术分享，因此可以放到一起。

代码评审理论上每天都会发生，而技术分享则看情况。做得好的团队，每周都会有技术分享。

代码评审的两种模式

1. 团队成员各自去查看Merge request并留下评论。
2. 团队成员集中时间一起看Merge request并留下评论。

第一种模式是为了解决团队很难有统一的时间来一起看merge request，则把代码评审的集体时间分散到团队成员各自的零散时间中去做。

第二种模式的好处是，团队可以一起分享业务和分享技术，通常在代码量比较小的时候，快速做完代码评审之后，团队可以商量由某个人分享一些大家不知道的业务或者技术，分享的内容一定要小巧，比如10分钟就分享完，如果是大分享则应该单独计划一个时间来做。

第二种模式的review时间应该控制在30分钟到60分钟以内。时间宽裕的团队，可以做1小时，加上技术分享等。时间不宽裕的团队，则建议在30分钟内结束。因此为了让代码评审快点结束，可以安排一个facilitator来防止大家发散，推进代码评审的进度。

第二种模式的代码评审通常会在每天下午的5点到6点之间进行，这样的好处在于可以回顾大家一天所写的代码。

代码评审的tips

• 每个Merge Request都应该有2个及以上的人通过了，才能合并。
• 小步提交。提交越小步，代码review起来越容易。
• 发现任何有问题的代码或者疑惑的地方，都应该直接问或在代码旁边留下评论。
• 代码评审不是批斗会，而是互相了解业务与技术，互相学习的机会。
• 代码评审不是只有leader才有权利去评审，任何团队成员都有权利去做。
• 代码评审时，应该先从与代码相关的业务说起，让其他人对于代码的业务背景有了解。
• 代码评审是互相学习的好机会，是拉齐团队编码能力的好机会。

代码评审的好处

1. 知识共享
2. 质量保证
3. 技术氛围建设
4. 快速反馈
5. 编码能力提升

CI/CD

CI是continuous integration，也就是持续集成。

CD是continuous delivery，也就是持续交付。也会说是continuous deployment，也就是持续部署。

CI/CD是我们在开发过程中快速迭代的基本质量保障，它能让我们快速获取反馈。是必不可少的部分。

这个话题也挺大的，就不在这里展开了。

下次单独找个时间来分享这个话题。

迭代估算会

有的团队会把这个会议的内容放到迭代计划会IPM中。但在实践中我们发现，下一个迭代的准备工作可以单独划分一个迭代估算会议来做。

那么这个迭代估算会主要做以下两件事情：

1. 澄清故事卡的需求，确保团队内部对它的理解一致。如果不一致，则需要产品经理或BA去找业务方澄清。

2. 大家一起为故事卡估点。

   1. 故事点（Story Point）通常代表这张卡的复杂度或者工作量，有的团队也用它来代表价值。
   2. 点数通常有两种方式，一种是使用斐波拉契数列，一种是使用T-shirt size。第一种比较常见。
   3. 由于故事卡估点也是一个比较大的话题，这里就不展开叙述了。

下个迭代的工作

下个迭代的工作主要分为下面三个方面。

1. 产品经理或者BA会在当前迭代去准备下个迭代的故事卡，完善那些待分析的卡，补全需求细节，画出原型图等。不清楚的需求就找业务方澄清。
2. 设计师对需求已经清楚的故事卡设计高保真的UI图。
3. 可能会有一些新技术的调研工作，可以安排个别开发人员对下个迭代可能用到的技术做调研。

Retro回顾会

回顾会的英文是Retrospectives，俗称retro。

每个迭代结束之后都会进行Retro回顾会，目的是为了回顾过去展望未来。总结上个迭代中做得好的，可以继续保持，然后看看哪些地方可以改进。

安全检查

在有必要的团队，回顾会可以有一个安全检查，安全检查就是让大家投票觉得现在这个回顾会可以安全进行吗，如果大家的投票是NO，则把参会人员中职位最高的人请出去，再进行投票，直到大家都认为安全后，再进行回顾会。

实践中，大部分团队都不需要安全检查。如果需要，可以反思一下，为什么大家的团队安全感很低。

最高指导原则

回顾会不是批斗会，因此回顾会有一个最高指导原则，目的是为了创造一个安全的环境，在这个环境中，团队成员可以自由检查他们的流程和工具，而且不必担心别人的指责。

最高指导原则就是：

无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。

最高指导原则的好处在于为了最大化知识的产出而将思考的重点暂时从“人”移开。

回顾会经过这么多年的发展，已经有非常成熟丰富的模版来做了。下图就是一些常见的retro模版。

模版来自：https://metroretro.io/templates

回顾会的几个小tips

• 大家讨论出来的改进项可能会很多。大家可以投票选出优先级最高的前几个action来执行。
• Action必须有owner，没有owner的action就意味着没有人会去做。
• 每次回顾会开始的时候，应该先回顾一下上次回顾的action是否都完成了。
• 回顾会不一定是迭代结束就马上做，这样会让当天同时有迭代计划会和回顾会，占用团队太多时间。实践中发现，如果IPM在周一，则retro可以在周三比较合适。

Showcase

每个迭代结束后，需要向PO或者业务方做showcase，展示工作成果，同时获取业务方反馈或批复，以持续改进。

Showcase通常需要团队中的开发、测试、产品经理/BA出席，同时需要业务方或者PO出席。

实践过程中，很多团队会通过showcase会来获得业务方的批复（Sign off），以取得上线许可。

上线

上线的时间不是固定的，每个团队会根据每个团队自己的实际情况来定。

咨询这么多年，我见过随时持续上线的，见过半夜三更上线的，也见过每月固定时间上线的。

通常敏捷是强调小步快跑的，因此，每个迭代做完的工作就应该及时上线。

这样的好处在于上线的内容越少，出现问题的影响越小，回滚成本越小。同时也能更快的获取用户反馈。

另外，上线时间安排在周一的原因在于，如果是周五上线，出了问题，大家周末都不好过了。

总结

我就不赘述瀑布模式和敏捷的区别了。就简单说说我们把需求或者工作划分成每个迭代来完成，有以下几个好处。

1. 我们可以通过燃尽图等相关统计报表，分析团队的研发效率。
2. 通过多个迭代的开发，我们就可以精确度量团队工作载量和速率，更好的利用团队资源。
3. 按迭代回顾和改进，也符合敏捷小步快跑的理念。
4. 工作范围和内容清晰明确。
5. 可视化未来的工作。
6. 更早的识别风险。
7. 降低了因为变化带来的风险，让团队更快的响应变化。

最后，本文只是从敏捷迭代日历的角度谈了谈敏捷相关的实践，如果对敏捷其他话题感兴趣，欢迎给我留言，我们再继续讨论。