敏捷5.4敏捷计划与适应

Posted 2022-03-10 码农老张Zy

敏捷计划与适应

上篇文章用大量篇幅学习了敏捷中计划的概念以及用户故事的估算，毕竟都是新东西，所以大家还是要好好消化消化。今天我们主要学习的是敏捷计划的具体实施以及敏捷的适应问题。适应其实是针对于计划的变动、修改方面的相关内容。

敏捷计划的实施

在学习敏捷计划的实施前，我们先来再看看敏捷计划和传统项目管理计划的不同。

首先，敏捷计划是通过实验和示范的方式来发现真正的需求，然后对其进行重新规划。这个就是我们一直说的渐进明细与滚动式规划。重点在于尽早提交可以正式上线的高价值产品，用于帮助客户尽早发现他们的真实需求。

其次，敏捷计划前期投入少，并且计划是贯穿整个项目始终的。对于 PMP 来说，在前期有很重的规划和设计压力，十大知识领域的内容都要在一起形成项目管理计划。虽说事无巨细，但是后期变更的成本就会非常高，而敏捷就是为了解决这个问题。我们前期不用投入很多精力在规划设计中。

最后，计划在执行中间不断调整是经常的事。因为以上两点，再加上我们是拥抱变化的一种项目管理模式，因此，我们会做好迎接一些变更和调整的准备，比如通过迭代以及冲刺前的计划会议，让每冲刺都可以灵活调整。

接下来，我们就直接看看冲刺和发布计划。

冲刺和发布计划

一般来说，冲刺也就是指的迭代，是比发布计划要短一些的时间盒周期。而发布计划一般会是一个或多个冲刺之后才实施的计划。因此，它们两个之间是有一定的层级关系的。不过也有可能每一次冲刺都会有产品的发布，比如我们本身设定的迭代就是以四周为一个迭代周期的，然后在迭代完成时就必须发布可以上线的产品。其实在这种情况下，发布和迭代用一个计划就可以了。

当然，大部分开发情况下发布计划会是 3-6 个月，并且覆盖 2-12 次的冲刺。发布计划其实很像我们传统项目管理中的里程碑，但是和里程碑不同的是，在传统项目开发中，只有最后那一刻才是正式将产品发布上线的，里程碑时刻只是对项目完成情况进行检查，但不对产品是否真实可用可交付进行检查。

发布计划

发布计划制定的第一步就是要确定一次发布的总体时间，然后再看在这个规定的时间里可以完成多少用户故事。比如说我们规定下次发布的时间为 6 次迭代以后，而每次迭代的速率是 10 个故事点，因此，在这次发布中我们需要完成 60 个故事点的用户故事。接下来，我们就可以讨论用户故事，确定优先级，然后看看在本次发布中需要完成哪些用户故事。

发布计划的重要性不用多说大家也能想到，一是可以在前期让相关方和团队成员了解到发布产品所花费的时间以及我们下次发布的时间；二是帮助相关方了解这个阶段会发布哪些功能；三是作为项目小组前进的目标。

PO 在这个过程的作用不用多说，就是带领团队分析故事，完成优先级的确定，组织对用户故事的各项评估。而 Scrum Master 主要是要确定团队的迭代速率，也就是每次迭代所能完成的故事点数，然后准备好风险问题的追踪明确责任人，最后就是组织召开发布计划会议达成制订出一个可行的发布计划的目标。

冲刺计划

冲刺计划其实大部分情况下都是在 冲刺计划会议 上制定的。这个东西其实我们已经说过很多次了，在 冲刺计划会议 上，我们会更详细地拆解用户故事为任务，并让团队成员自发地承诺自己要完成的任务。这又是个什么新的概念，为啥要团队成员自己来决定自己做哪些任务呢？其实，这又是一种 自组织 的体现形式。敏捷团队期望的是在做出用户故事的估算之后，大家能够对任务也有了一些心理准备。这个时候，就可以根据自己的情况自发的选择一些任务来完成，并且承诺将会完成这些任务。如果有些任务没人愿意认领的话，那么我们后面要讲到 SM 在冲刺计划会议中的职责中会讲到这个问题。

冲刺计划会议一般会分为两个部分举行。第一部分是 PO 描述希望在冲刺中看到的待开发项，然后基于这个前提，团队选择一组他们认为可以实现的待开发项。第二部分是团队分解这些待开发项，也就是把用户故事给拆分成任务，并且将这些任务形成 冲刺开发列表 ，也就是 Sprint Backlog 。接着讨论如何完成这些工作，并承诺在冲刺的时间内完成。

在这个阶段，SM 主要是在会议前与各方沟通，明确当前冲刺需要完成的项目范围。然后与其它敏捷 Leader 沟通，落实冲刺目标，帮助团队提出项目风险并制订风险消解计划，最后就是引导团队成员自发地领取承诺任务，可以让新同事或者实习期的同事优先选择，也可以让有经验的老员工来提出无人认领的任务分配建议，并根据实际对方的认领情况进行分派。

每日计划

每日计划，有必要这么详细吗？不不不，你难道忘了 每日站会 吗？既然是一个敏捷团队，那么每日站会这么好的实践多少还是要尝试的。这个东西，就是每日的计划会议。关于每日站会说些什么，之前在 Scrum 相关的文章中已经详细说过了。而今天呢，我们来说说别的问题。

一是谁来组织这个每日站会，相关方能不能参与？这个每日站会一般是由 SM 来主持，但是在实际的项目团队中，大家轮流来主持会更好一些，能够大大地提升与会成员的参与度。而相关方当然可以参与，但是，之前的文章中也强调过，他们不要发言，只能倾听团队成员说的内容。

二是开会有人迟到怎么办？当然得罚啦，要么俯卧撑，要么仰卧起坐，要么真心话大冒险，这个还是让团队成员自己来定吧。并且，不管是 PO 还是 SM ，都是一视同仁的要接受惩罚。

敏捷监控

计划实施了，但是到位不到位呢？有没有完成我们既定的目标呢？这些就要靠监控来实现。在 PMP 中，监控过程组 是一个贯穿项目开发始终的，并且在十大知识领域中都有的一个过程组。可见其在项目管理中的重要性。在敏捷中的监控技术，其实我们也不陌生，也都是前面在 Scrum 框架中介绍过的。

冲刺评审

首先是 冲刺评审 ，它是干什么的想必不用多说了。由团队向 PO 和相关方展示已完成的产品功能。由团队主持并回答相关方的问题并记录所期望的更改意见。

在冲刺评审时，我们通常会将时间控制在 4 个小时，主要的议程包括如下方面的内容：

1. 确保所有人员都清楚目标，对产品有充分的了解。

2. 团队按照待开发项中的问题，逐个地介绍这次冲刺的结果和演示新功能。

3. 如果产品负责人想要改变功能，那么就要添加一个新问题到产品待开发列表中。

4. 如果小组报告项目遇到困难现在还没有解决，就要把这个问题加入到障碍待开发列表中。

5. 会议结束时，SM 向 PO 和全体利益相关方宣布下一次评审的地点和时间。

冲刺评审会通常是非正式的，所以尽量让相关方关注业务层次而不是技术细节，技术细节的评审应该是在内部解决的。在冲刺评审上更关心的应该是我们做了什么，而不是我们怎么做的。如果某些冲刺可能包含很多缺陷修复等功能，在评审会议中不要演示太多琐碎的 BUG 和修复，这点的原因前面说的不要关注技术细节是一致的。最后，如果有可能的话，最好让观众试一下产品，如果能够实现这个，那么对相关方来说会是相当震撼的感觉，而且也是最能体现我们敏捷原则的地方，持续可交付。

冲刺回顾

说完了冲刺评审会议，那么必然紧接着的就是冲刺回顾会议。作为敏捷计划的监督工具来说，回顾会议主要的目的在于展示及总结本轮冲刺的完成情况，根据一些实际数据及成员反馈的信息来分析本轮冲刺过程中的一些问题，制订在下轮冲刺中的改进计划。

一般来说，回顾会议是以 Scrum Master 为主导的，以过程和敏捷实践的执行为主要内容，以团队成员的成长和收获为核心方向。从 Keep（做得好的继续保持）、Change（做得不好的需要改进）、Try（可以尝试） 三方面进行总结。

首先回顾上次总结会议列出来的 Change 和 Try 事项，看看本轮冲刺做得怎么样；然后总结本轮冲刺的情况，让每个人将冲刺情况写到便签上进行汇总，并由大家投票列出哪些可以在下一个冲刺中改进以及尝试，列出具体的行动说明，但不要太多，三项即可，太多了反而可能哪个都做不好。

在回顾会议的最后，成员轮流总结自己在这一冲刺过程中的收获和遗憾，尽量具体，收获就是我们新学习到的内容，而遗憾则是之前制定了目标计划，但没有完成的内容。

信息发射源

最后一个监控工具就是我们的信息发射源。没错，估计不少同学马上就想到了，白板、任务板、燃尽图、燃起图等等。最直观的，最清晰的展示当前冲刺以及整个项目工作量和完成情况的就是它们。

敏捷适应

敏捷适应其实就是在敏捷计划的执行过程中如何解决出现的问题。所以，在适应模块中，其实包含的就是识别和解决问题两个方面的内容。

识别问题

我们上面讲的那些敏捷监控工具是为了识别问题的。通过 冲刺评审 我们发现的是产品方面的问题，通过 冲刺回顾 我们发现的是 Scrum 流程和团队方面的问题。而 信息发射源 配合 每日站会 则是非常重要的的一种即时发现问题的方式。别忘了，每日站会 第个人要说三件事，而第三件事 “有什么阻碍了我” 就是用来说出问题的。

解决问题

如果我们能够在早期就发现问题，并且能够在问题发生前就采取行动避免它们，那么这些问题其实也就不会构成问题了。而问题的出现一般都是事后才会发现，因此，如何解决问题也就成了非常重要的内容。在发现问题之后，通常我们会用下面的步骤来解决它。

1. 收集数据

没有数据，那么我们对于问题的原因、过程、结果也无法获得全面的了解。通过数据的收集，才能够了解需要解决的问题的方方面面，因此，我们会有很多问题收集的工具。

• 1）时间表：对于冲刺周期较长的项目，让大家回想起冲刺中发生的事情。并不是我们制定什么时间完成什么任务的那种时间表哦。而是在回顾会议的时候用于回想的。并且通过不同颜色的便签纸来分别代表好的事情、有问题的事情、重大的事情等，最后一起张贴在醒目的地方进行讨论。

• 2）三个5游戏：用于初步撰写行动计划，发掘项目的重要主题。每个人有5分钟时间进行头脑风暴，写下自己的想法，然后把纸条传递给右边的人，右边的人再基于这张纸条写下自己的想法，依次传递。

• 3）颜色代码圆点：这个活动需要和时间表活动结合使用，在完成活动时间表之后可以用它来表示团队成员的工作心情，就是我们前面说的不同颜色的便签。

• 4）愤怒——悲伤——高兴：与颜色代码和彩色便签的效果一样。

• 5）定位优势：通过团队成员之间的互相访谈，寻找最佳状态。

• 6）满意程度直方图：团队成员以直方图来个人与团队对现行制度和流程的满意程度。

• 7）团队雷达图：团队成员为个人和小组的表现打分。

• 8）挑选同义词：每名成员轮流做裁判，确定在他们的项目进行时，哪些事情或哪些因素最符合质量卡上的定义。通过对卡片的评定，成员们可以互相理解他们对同一事件的不同看法。

1. 激发灵感

在这里，我们会使用前面收集的数据，在团队解决问题之前，帮助团队解释并理解问题的含义。同样是几个活动工具：

• 1）头脑风暴：不用多说了吧，之间的文章已经详细解释过。

• 2）力场分析：通过找出各种有利于解决问题的力量和因素，加强积极因素，排除消极因素，以便解决问题、达到期望的目标的一种活动。

• 3）5Y 法：非常出名的 5 Why 法，就是针对同一个问题连续以 5 个“为什么”来发问，以追究其真正的原因。

• 4）鱼骨图：同样是探究问题的根本原因的方法，也叫做石川图或者因果图，也是 PMP 中的质量管理工具，大家可以自己查查这种图是长什么样子的。

• 5）圆点贴优先级排序：引导小组在一大堆变革、提议等方案中确定实施的优先级顺序。

• 6）寻找主题：从定位优势访谈活动中找出共同的线索思路，为实现、变革和建议寻找引人注目的创意。

1. 决定做什么

对于问题解决来说，最后一步就是要对于目前产生的问题如何进行一下步的操作。通过前面两个阶段，我们有了问题的数据，也了解到问题出现的原因，在这里我们需要一些去解决问题的工具。

• 1）回顾规划游戏：其实就是分级的针对需要完成的改进、建议等进行集体研讨，厘清任务。

• 2）SMART 目标：帮助团队创建“具体的、可量化的、可实现的、有相关性的、有时限的”目标。相信这个 SMART 还是非常出名的一种目标管理理论，如果有不清楚的同学自己查询了解一下吧。

• 3）问题圆圈：团队成员转坐成一个圈，然后指定一个人开始向他身边的人发问，当身边的成员尽其所能回答完问题后，继续由他开始向身边的人发问。如此反复直到每名小组成员都对他们的问题被听取和考虑而满意，并取得一致的行动意见为止。

• 4）持续改进：这个应该不用我多说了吧。

总结

感觉东西不多，但是随便一写又是一大堆的内容。而且很多东西都并没有讲得很详细。这个时候，还是发挥大家的力量，自己去查找一些相关知识的解释吧。有的时候，自己去努力寻找的结果反而会让自己印象更加地深刻。

关于敏捷规划设计方面的内容我们就学习完了。其实到这里为止，敏捷中最核心的一些内容就已经差不多了。后面我们还将要学习的是团队、风险管理和过程改进相关的内容。不能说不重要，但确实不会再有前面几章这些很长的文章了。大家总算可以松一口气咯。当然，学习的过程就是这样的，松紧相宜才能更好地吸收掌握。

参考文档：

《某培训机构教材》

《用户故事与敏捷方法》

《高效通过PMI-ACP考试（第2版）》

《敏捷项目管理与PMI-ACP应试指南》