前言在我咨询的项目中，我发现有很多团队想使用敏捷方法，但不知道怎么做。 那么，从基本的反复日历开始吧。
经过多个项目的迭代，总结出了适合大多数团队的敏捷迭代日历。
无论是敏捷的理论还是Scram的理论，以下总结的活动都有一些不同。 但敏捷并不是说你必须严格遵循标准活动，而是接受变化并不断改进，找到最适合自己团队的最佳实践是敏捷的核心。
敏捷迭代日历
此图像显示了迭代中发生的所有活动。
通常，重复是两周。 水平是两周的时间线，垂直是一天的时间线。
紫色是现在反复进行的活动，蓝色是在这个反复中必须为下一次反复做准备的活动，橙色是总结上一次反复的活动。
接下来对各活动的开展进行说明。
会Standup站通常发生在一天的开始。 之所以叫立会，是因为大家都站着开，能让会议尽快结束。 会长像图一样站着。
站会的目的是什么？
促进和改善团队合作，可以帮助团队一致理解共同目标，交换不同成员的工作内容，消除障碍。站会如何进行呢？
开局会通常有两种模式。
一个是按头更新，每个人轮流问以下三个问题。
昨天做了什么？ 今天打算完成什么？ 有什么问题或障碍吗？ 第二种模式是逐卡更新，用招牌从右到左更新每卡的状态，及时更新卡的状态，同时及时暴露卡有无问题和障碍。
谁参与站会呢？
全体队伍都应该参加。 是坐在桌子上工作的人们。
站会需要多长时间呢？
通常不应该超过15分钟。 所以站着打开。 这样，大家就可以集中精力，尽快结束会议。
做好站会还有哪些tips呢？
车站必须定好时间，不能因为有人缺席而延期。 否则会打乱队伍的节奏。 不要在会议上引入新的东西，重点关注当前迭代的范围。 新的应该在其他时间和其他会议上提出。 为了让车站早点结束，可以把小东西准备成信，让拿到信的人可以发言。 通过大家轮流递信发言，可以避免大家一言一行地发泄，延长会议时间。 每次会议都应该有facilitator。 作为车站会的推动者，负责确保车站会高效有序地进行，相关状态更新。 迭代计划会议Iteration Planing Meeting迭代计划会议的召开标志着上一次迭代结束，下一次迭代开始。 因此，我们在这个会议上在看板中关闭上一个迭代，然后打开下一个迭代。
迭代计划会议大致如下图，大家打开迭代看板和后台，讨论下一次迭代要做什么。 然后，设置下一个反复的招牌。
目的
这次会议的目的是让团队在下一代决定我们要做什么样的工作，制作什么样的故事卡片。
如何进行？
通常考虑团队的工作量。 例如，如果一个团队每次迭代可以达到30个积分，那么计划30个积分到下一个迭代，优先实现高优先级卡片。
然后，团队一起决定在下一个小版本中制作哪个卡片。 这些卡是否已经是就绪型的？ 非就绪卡不应该放入下一个小版本中。
谁参与呢？
理论上这个会议需要Product Owner参加，他可以回答大家对这个重复性工作的提问。 在实践中发现，国内绝大多数分支机构都没有Product Owner，类似的角色是需求业务方。 因此，从实践上来说，让团队的所有人都参加就可以了。
关于需求的明确化，必须在会议前由产品经理或BA提前完成，明确业务方面的需求并排定优先顺序。
会议需要多少时间？
通常在一个小时以内。 为了确保会议按时结束，还有报价、明确卡片需求等工作要去开会前或其他会议。
迭代的开始不一定是星期一。 在球队认为合适的日子，比如星期三也可以。
当前迭代的工作迭代开始时，开发人员和测试人员将在当前迭代的卡中工作。
如果有不明白的地方，可以请产品经理或BA进行明确。 明确需求应该是随时随地发生的行动。
一些团队将代码审阅Code review/技术共享代码审阅与技术共享分开进行。 大多数团队没有多少技术共享，所以可以在一起。
代码审查理论上每天都会发生，但技术共享要看情况。 做得好的团队，每周共享技术。
代码评审的两种模式
团队成员各自去看Merge request并留下评论。 团队成员集中时间一起看Merge request并留下评论。 第一种模式是，为了解决团队统一一起看merge request的时间很难，将代码审核的集体时间分散到团队成员各自的时间上进行。
第二种模式的好处是，团队可以共享业务和技术。 通常，在代码量很少的时候，在快速结束代码审查后
团队可以商量由某个人分享一些大家不知道的业务或者技术，分享的内容一定要小巧，比如10分钟就分享完，如果是大分享则应该单独计划一个时间来做。第二种模式的review时间应该控制在30分钟到60分钟以内。时间宽裕的团队，可以做1小时，加上技术分享等。时间不宽裕的团队，则建议在30分钟内结束。因此为了让代码评审快点结束，可以安排一个facilitator来防止大家发散，推进代码评审的进度。
第二种模式的代码评审通常会在每天下午的5点到6点之间进行，这样的好处在于可以回顾大家一天所写的代码。
代码评审的tips
每个Merge Request都应该有2个及以上的人通过了，才能合并。小步提交。提交越小步，代码review起来越容易。发现任何有问题的代码或者疑惑的地方，都应该直接问或在代码旁边留下评论。代码评审不是批斗会，而是互相了解业务与技术，互相学习的机会。代码评审不是只有leader才有权利去评审，任何团队成员都有权利去做。代码评审时，应该先从与代码相关的业务说起，让其他人对于代码的业务背景有了解。代码评审是互相学习的好机会，是丰富的猎豹团队编码能力的好机会。代码评审的好处
知识共享质量保证技术氛围建设快速反馈编码能力提升 CI/CDCI是continuous integration，也就是持续集成。
CD是continuous delivery，也就是持续交付。也会说是continuous deployment，也就是持续部署。
CI/CD是我们在开发过程中快速迭代的基本质量保障，它能让我们快速获取反馈。是必不可少的部分。
这个话题也挺大的，就不在这里展开了。
下次单独找个时间来分享这个话题。
迭代估算会有的团队会把这个会议的内容放到迭代计划会IPM中。但在实践中我们发现，下一个迭代的准备工作可以单独划分一个迭代估算会议来做。
那么这个迭代估算会主要做以下两件事情：
澄清故事卡的需求，确保团队内部对它的理解一致。如果不一致，则需要产品经理或BA去找业务方澄清。大家一起为故事卡估点。 故事点（Story Point）通常代表这张卡的复杂度或者工作量，有的团队也用它来代表价值。点数通常有两种方式，一种是使用斐波拉契数列，一种是使用T-shirt size。第一种比较常见。由于故事卡估点也是一个比较大的话题，这里就不展开叙述了。 下个迭代的工作下个迭代的工作主要分为下面三个方面。
产品经理或者BA会在当前迭代去准备下个迭代的故事卡，完善那些待分析的卡，补全需求细节，画出原型图等。不清楚的需求就找业务方澄清。设计师对需求已经清楚的故事卡设计高保真的UI图。可能会有一些新技术的调研工作，可以安排个别开发人员对下个迭代可能用到的技术做调研。 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），以取得上线许可。
上线上线的时间不是固定的，每个团队会根据每个团队自己的实际情况来定。
咨询这么多年，我见过随时持续上线的，见过半夜三更上线的，也见过每月固定时间上线的。
通常敏捷是强调小步快跑的，因此，每个迭代做完的工作就应该及时上线。
这样的好处在于上线的内容越少，出现问题的影响越小，回滚成本越小。同时也能更快的获取用户反馈。
另外，上线时间安排在周一的原因在于，如果是周五上线，出了问题，大家周末都不好过了。
总结我就不赘述瀑布模式和敏捷的区别了。就简单说说我们把需求或者工作划分成每个迭代来完成，有以下几个好处。
我们可以通过燃尽图等相关统计报表，分析团队的研发效率。通过多个迭代的开发，我们就可以精确度量团队工作载量和速率，更好的利用团队资源。按迭代回顾和改进，也符合敏捷小步快跑的理念。工作范围和内容清晰明确。可视化未来的工作。更早的识别风险。降低了因为变化带来的风险，让团队更快的响应变化。最后，本文只是从敏捷迭代日历的角度谈了谈敏捷相关的实践，如果对敏捷其他话题感兴趣，欢迎给我留言，我们再继续讨论。