敏捷项目管理实战第三天组织、计划、执行与监控

最新推荐文章于 2024-05-26 21:49:58 发布

办公模板库素材蛙

最新推荐文章于 2024-05-26 21:49:58 发布

阅读量990

点赞数

分类专栏：教程技术管理文章标签： scrum 敏捷开发

本文链接：https://blog.csdn.net/fegus/article/details/124836411

版权

教程同时被 2 个专栏收录

1193 篇文章

订阅专栏

技术管理

102 篇文章

订阅专栏

06 自组织：敏捷团队如何开展自组织？

经过上一课时的学习，我们知道敏捷思维的培养要注重四个方面。本节课我们将学习敏捷实践中关键的一步——敏捷团队如何开展自组织。

敏捷宣言的原则中提到“最好的架构、需求和设计出于自组织团队”，所以在敏捷实践中需要构建自组织团队。

自组织团队

首先，我们要明确自组织是什么？

自组织团队也叫作自管理团队或者被授权的团队。管理层授权团队自己管理自己的工作过程和进度，并且团队通过自己的方式完成工作。也就是说，自组织团队并不是完全自组织的，自组织也是在一定的限制条件下的自组织，离开了这一限制，自组织也就无从谈起。

我举个例子，比如露营团队就是典型的自组织团队。大家一起去露营，需要有人搭灶生火、洗菜做饭及搭帐篷等，整个团队中每个人会的不尽相同，所以大家会根据自己的能力自发认领任务，或者帮忙打下手，这就是自组织的方式。在露营中，大家一般默认集体为重，每个人需要先完成集体的事情，再去做个人的，如果有人违反这个规定那么就自行退出，所以说自组织是有一定限制因素的。

自组织团队应该做什么

还记得我们前面提到的跨职能团队吗？自组织团队往往就是跨职能团队，由拥有不同职能专业、思考方式和行为模式的成员组成，就像一个游戏团队，通常会有策划、美术、开发、测试、运营等。

对于自组织团队来说，他们需要做的是：

自己分配任务，而不是等着管理层来给自己分配任务；
团队自行考虑用怎么样的产品方案和技术手段来实现目标；
团队自行制定需要遵循的行为准则。比如我们团队只有 3 条准则：开会自动交手机，迟到发红包，尽量不给别人“添麻烦”（即文档或代码自检）；
团队需要向管理层随时报告进展和问题；
团队成员自己管理自己工作内容，流转工作状态。

通常工具可以很好地帮助我们团队透明化，减少反馈的烦琐流程。比如在腾讯，通常使用敏捷项目管理工具 TAPD，它可以实时显示团队目前的工作状态，更方便自组织团队使用。

传统团队：无变化，高效率

为了帮助你感知自组织的优势，我们再来看一下传统团队，这种团队一般是由经理领导。对于经理领导的团队来说，经理需要为团队成员分配任务，要根据任务合理分配有限的资源。团队成员只要关注自己的任务，按部就班地执行就好。另外，经理除了要确定目标、方向和组织结构，还需要监督和管理团队的过程和进度，这就要求经理的专业能力非常高。

这种团队的优点是，对分配任务和执行任务进行了专业化分工，资源能被最大化地合理运用。如果一直没有出现变化，那么这样做效率是最高的。

但现实中项目的推进往往伴随着变化，这就暴露了其缺点——应对变化的能力非常弱。如果人员变动比较大，例如请假或调动出项目组，或者是有大的变更需要占用现有的资源，那所有的资源就得重新安排；如果变动进一步变得频繁，那么这种分配的弊端就被无限放大，这就更能看出自组织的优越性。

回到我们的敏捷实践当中，在一个自组织开发团队内，产品负责人和敏捷教练为团队明确当下的工作目标，让其他成员清楚此次迭代要完成什么功能，自己要做些什么。团队在明确的分工下，每个人对自己的职责更加清晰并需要对自己的工作负责，也能保证完成的任务经过自检，从而不把质量问题留给下游。

总而言之，自组织团队和传统团队最大区别是管理者，即自组织团队中不会依靠某一个人决定所有的事情，团队要自己决定如何达成目标，而管理层只看最终的情况，不会事无巨细得关心团队推进的过程。

管理层如何组建自组织团队

根据前面的叙述，我们知道了自组织以团队为重，那么自组织团队就意味着不需要管理层吗？当然不是这样的。自组织团队不代表彻底的自由，而是在管理层的战略下，有约束的自由。在组建自组织团队时，管理层主要需要做以下这些事情。

确定团队目标和愿景，让团队充分理解我们要做这件事情的目的和意义，比如我们斗地主项目就是让玩家畅快地对局游戏，所以我们需要让广大游戏玩家感受到这项游戏是好玩的，是畅快的，这是我们要做这个项目的意义。
确定团队上下文，即组织结构、团队结构、团队组成，组织结构是服务于业务的，只有好的组织架构和绩效方式，才能让自组织团队保持高效。在腾讯，只要你是属于业务部门的，不管是产品、开发、测试和运营，都需要背负部分业绩 KPI，这样做的好处是让团队能有共同的驱动力，激励他们为了同一个目标而努力。
提供环境和支持，主要是安全感、良好的团队空间、氛围和技能辅导等。我们给团队安排最近的位置，在晨会的地方竖立电子看板墙，必要的时候占会议室，把它改为“作战室”；不仅如此，我们从一开始就创建每个人都可以畅所欲言的开放氛围，并请外部教练帮助团队做敏捷转型。
适当放权，给予团队自治权，让团队自我管理，比如每个人确定个人的工作任务、团队商议迭代周期等。管理层一般不插手团队的执行过程，只有当团队成员需要帮助时，才需要反馈给管理层，让其提供帮助。
训练协作，管理层需要通过实操让团队“练兵”。给团队制造一些“意外”，让团队自行处理和总结经验，借此来锻炼团队应对“意外”的能力。阿里巴巴的 CTO，他会经常给系统来次“小惊喜”，比如叫人去机房拔网线，或制造大量的访问。通过这样不断地“练兵”，阿里团队面对各种突发情况也丝毫不慌。

自组织团队实践

通过上面的方式我们就能够建立起自组织团队，只有建立起自组织团队后才能够继续推进敏捷实践。那么基于自组织的前提下，我们接着需要做什么呢？那就是待办事项，也就是汇总未开始安排的任务，由自组织团队共同创建并维护。

创建待办事项列表

通常来说，待办事项列表可以让我们把控项目推进的过程。在创建时，我们应该从团队的角度出发，以团队为衡量。列表要详细得将任务展示出来，所以应该包括任务详情，它的价值以及所需要的预估工作量。除此之外，列表是用来帮助我们推进项目的，所以列表中要将具体的执行步骤写清楚。综合这些考量，一个待办事项列表应该包含 ID 、类型、名称、价值、优先级、工作量和执行计划这些内容。

其中类型是根据其来源来划分的，通常是这三种类型：

用户故事，即站在用户角度写的需求，通常由产品经理撰写；
外网 BUG，即外网曝出的 BUG，通常来自数据或用户反馈，需要测试人员确认；
开发任务，即开发人员撰写的任务，如数据库设计、系统重构任务等。

分类型可以帮助我们根据当前的主要任务，更快地选择相应的待办事项来完成迭代的目标。如我们这次迭代目标是解决大量外网用户的投诉问题，那么我们就在外网 BUG 类型里面选择待办事项。

欢乐斗地主项目待办事项列表

在实际的工作场景中，我们具体是这样来做的。

团队进行讨论，明确需求的背景、价值，以及是否有现成的解决方案，进而确定是否需要纳入待办事项列表。然后纳入待办事项，我们需要填写如上图的 ID 、Type 、Name 和 Value 。

根据优先级对待办事项排序，待办事项的提出者要给待办事项加入一个优先级，我们填写在 Priority 列中，通常为 high 、middle 或 low。

对需求通过增加、删除、分解或合并进行整合。如果需求较复杂，我们需要关注它的完整性，尽量用一个需求来覆盖多个用户场景。如果可以拆分，就把需求拆成更小的单元，以便于更灵活地进行排期处理。我们把这个细化结果添加在它的 How to demo 列下面。

自组织团队共同对需求所需要的工作量进行估算，也就是每个人都要进行估算并给出意见。敏捷一般按照估算扑克来估算，当给出的估算值之间差距大于可接受范围时，估算数值大的人和估算数值小的人要各自陈述自己的意见，说明是什么原因促使自己做了相应的估算。通过这种方法，可以让所有人都有机会发言，分享自己的想法，然后汇总得出大家都认可的结果，我们把结果填在 Initial Estimate 下面。

最后我们要发布这个列表，保证团队内外信息同步。这样，我们就完成了一个待办事项列表。

在做表的过程中我们需要注意以下几点：

Detailed Appropriate ，即适当的详细程度。待办事项的每一项描述清晰简洁，明确该事项是为解决哪类用户的问题、我们需要做什么以及做的价值即可。
Estimated ，即估算。待办事项要有一个大概的工作量估算值。值得注意的是，他与迭代计划的估算不同的是，这里的估算是只是负责人对工作的初步估算；
Emergent ，即涌现，指的是允许随时插入新需求，自组织团队可以积极应对变化；
Prioritized ，即考量优先级，指需要对每一个待办事项都排优先级，这样有新需求时，可以根据优先级进行比对，来确定放到表中哪个位置。

这个也叫做作 DEEP 模型，在完成列表后，我们还可以据此来衡量列出来的待办事项是不是合理。

维护待办事项列表

创建完待办事项列表之后，团队就可以高枕无忧了吗？当然不是。因为敏捷的拥抱变化，所以待办事项列表是动态更新的，这样可以随时让团队知道最优先的功能是什么，始终在推进开发优先级最高的需求，也就是对用户最有价值的需求，具体该怎么维护呢？

比如，我们要插入一个新的待办事项即微信支付。

分析：产品经理分析新的需求，确定是否放入待办事项列表中。如果确认可以则在表中新增一行，ID为 FE006 ，Type为 Feature（用户故事），Name 为微信支付；
排序：放入之后，产品经理需要评估需求的价值，并进行优先级排序，此时，我们评估此待办事项的 Value 为 75，Priority [praɪˈɔːrəti] 为 High；
理解：团队共同理解需求的描述。它的 How to demo 就是在用户选择支付时，可以选择微信支付来支付货款；
估算：团队估算该需求的工作量，微信支付的Initial Estimate [ɪˈnɪʃl ˈestɪmət] 为 2 。
更新发布计划：我们在待办事项列表中添加了微信支付，完成了列表的更新，我们就要向团队内外发布更新后的计划，做好信息同步。

每当我们遇到新的任务就可以按照上述例子来更新待办事项列表，在推进过程中，我们按照列表推进就会更加高效。

总结

本课时的内容就讲完了，这节课我们知道了什么是自组织团队，以及自组织团队的实践：创建并维护待办事项列表。下一课时我们将要学习如何建立一份好的迭代计划。如果你学习完本节课有什么问题，欢迎你在留言区留言与我一起讨论，我们下一课时见。

07 计划：如何制定一份好的迭代计划？

在上一课时，我们学习了如何建立自组织团队，本节课我们将学习如何制定一份好的迭代计划。

经常有人问我，敏捷核心是“拥抱变化”，那为什么要做计划呢？这是因为敏捷和所有项目管理都一样，我们需要行动方案来指导我们达成未来的目标，计划可以帮助我们有序地推进，但是敏捷的计划频度相较于传统开发更加高频，敏捷的计划更加灵活，我们称之为迭代计划。

在敏捷中，我们要将上一个迭代中用户的反馈加入本次迭代当中，也就是说敏捷落地是一个闭环，从最初的演进阶段，根据待办事项列表选择优先级最高的任务，接着实施阶段去完成该任务，然后反馈阶段收集用户体验得到他们最真实的想法，最后优化阶段根据之前的反馈进行优化，这四个阶段周而复始帮助我们的产品趋向最佳，不断提高用户的满意度。在整个过程中，迭代计划用来帮助我们更加高效地推进。

知道了这些，我们还要复习一下之前提到的“时间盒”概念，时间盒是一种管理方法，即在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。一个好的迭代计划应该是在时间盒内尽可能排进价值最高的代办事项。

制定迭代计划

具体制定迭代计划时，我必须要考虑到以下这些方面。

确定迭代周期，这通常由团队自行决定，一般在 1~4 周之间。迭代周期主要取决于两个因素：敏捷成熟度（指团队敏捷实践的能力）和自动化程度，这两种因素程度越高，迭代周期越短，反之越长。
**确定一个迭代内的关键工作项，**比如什么时间进行需求评审、什么时间测试。
固定关键工作项的发生时间，比如我们用两周迭代，然后在第二周的周一进行需求评审，周二开始测试。我们通常用表格将固定关键工作项的发生时间列出来，放在团队都能看到的位置，大家需要共同遵守。
培养团队的工作节奏感，大家根据上述表格来安排每周固定的会议，如需求评审会、迭代回顾会、迭代计划会，等等。
如果待办事项的紧急程度不一致，可以在一个时间盒中设置多个发布节点，但是一般不超过 2 个。如果有紧急需求，需要在迭代内进行发布，我们也可以灵活调整，让其发布，原则上不超过2个，因为迭代内太多次发布，整个节奏就会乱掉，那迭代节奏也就没有意义了。

迭代计划会议

既然迭代计划如此重要，我们在实际项目推进中就需要进行相应的迭代计划会议，与团队成员共同商议出一份大家都认可的迭代计划才可以事半功倍。那么我们该怎么举办一场迭代计划会议呢？

我们要考虑到这几点因素。首先是确定会议目的，即通过会议我们要明确即将要开展的工作内容，讨论明晰待办事项的相关信息；其次是确定会议参与人，一般 Scrum Master 是组织者，PO 和跨组织职能团队均要参与；接着是会议议程，这个过程比较相对复杂一些，我们稍后会详细说明；再次是通过会议确定迭代目标，我们可以把此目标放在团队显眼处同步；最后是**输出，**即将结果做成迭代代办事项列表，这其实是待办事项列表的子集，因为它是从待办事项中选出的优先级最高的事项。

会议议程

通常情况下，迭代计划会议的议程分为两个部分，What 和 How。

我们先来看第一部分，What 就是明确要做什么。在这个部分我们需要换位思考，站在用户的角度，作为用户去使用产品，设身处地地从场景中提炼用户的痛点，这个过程也叫作讲故事。

我们知道在待办事项列表中，PO 会使用 MoSCoW 法则对任务来进行基于客户价值的优先级排序。此时我们就要从待办事项列表中，选出既能满足用户痛点，同时优先级较高的用户故事，然后支持用户场景落地，也就是实现这个功能。

知识补充，MoSCoW 法则：
Must：必须要做的---功能集或Feature（特性）是系统的基础，没有了它们，系统将无法work或没有价值。
Should：应该做的---我们应该有的功能，这样子系统才可以正常使用，如果没有他们，系统将非常非常难用。
Could：可以做的---产品的附加值，加分亮点项。
Would not：不要做的--这个产品不需要的功能。
值得注意的是：待办事项中标为 Must、Should 的事情我们要保证完成，Could 优先级的我们争取未完成，在发生重要变更的时候，我们牺牲优先级为 Could 乃至 Should 的事情保证变更。

其次，How 就是明确我们怎么做，在这个部分我们需要先对选出来的用户故事进行工作量估算，我们可以采用故事点数和理想人天数来估算工作量；然后分解任务，遍历所有的用户故事，将其分解成团队成员可执行的任务，如分成前端任务、后端任务、联调任务、测试任务等，用户故事分解遵循谁认领谁分解的原则；最后团队承诺，任务分配到成员后，每次成员要承诺保质保量，尽可能做到不延期完成任务。

两种估算方式

理想人天数估算，这是一种个体估算。具体是指假设没有任何突发事件的理想情况下，一个开发人员完成该故事所需的工作量。这种方式实施起来比较简单，完成一轮估算所需时间较短，因为每个人都很熟悉自己的工作效率，所以这种估算方式比较主流。

但是这种方式没有考虑到差异化，就像小马过河一样，每个人的工作效率是不同的，一旦估算的成员与执行的成员不是同一个人，那执行时的工作量偏差可能很大。

敏捷更推荐使用故事点数估算，这是一种集体估算。具体是这样操作的：

建立团队共同认可的估算基准值，即团队对同一个需求要有一致的理解。这个基准值可以是完成一个需求的页面数，也可以是对数据库的增删改查次数，也可以是完成操作的步骤，一般完成单位功能基准值为 1；
对同一个需求，每位成员都要给出自己的评估值，然后通过估算扑克方法同时呈现，因为是相对估算，我们基于斐波那契数列，把故事点数设置为 0，1，2，3，5，8，13，20，40，60。
估算最低和最高的成员说明自己估算的理由。比如 A 认为这个需求点数是 60，因为需求里涉及很多算法，而团队之前没有做过任何算法的工作。而 B 认为需求点数是 5，因为他知道有第三方的算法工具可以直接引用。综合这些因素，团队考虑到 B 想法的可行性，最终决定对该需求评估是 5 个故事点；
对同一个需求进行 2 到 3 轮估算，通常用 5 分钟左右就可以最终确定该需求的估算；
重复第 2、 3 步，直到估算完本次迭代所有需求的工作量。

图片2.png

在这个过程中，大家都参与其中，所以最后的结果集合了各方视角，在团队建立了一致的理解，更重要的是增加了准确性。但是这种估算时间较长，两周迭代一般估算得花掉两个小时左右。

根据我的经验，对于刚接触敏捷的团队，可以使用理想人天进行估算。对于运用敏捷一年以上的团队，可以尝试着用故事点估算，这样团队更容易对需求达成一致。

案例应用

举个例子，我们现在在做一款商务酒店 APP，怎样制定一份好的迭代计划呢？

我们首先要清楚迭代计划会议的目标：

搞清楚我们为什么要做本次迭代的理由；
明确我们这次迭代要完成的内容；
每个人对彼此的工作内容都很清楚；
在什么时间点，完成什么工作内容，自己都很清楚；
团队彼此间认同、达成一致、心照不宣。

然后讲故事，也就是假设我们是用户要订房。如果是出差一族，平均报销房费是 500 元左右，用户使用 APP 时，能得到通过地理位置推荐附近价值合适的酒店列表，可以选择房型并发起预订，可以根据确切的酒店位置找到。

通过场景预设，我们考量到用户在完成整个酒店预订场景，从打开 APP 选房到完成入住，可以选出的我们的故事：房型清单、房型详情、下订、填写用户信息和确认房型信息。

知道了这些，接下来我们就要定目标。第一个迭代目标是让用户能够在线上选订我们的房间，具体包括：房间展示、预订、退订。

接下来对每个用户故事我们进行故事点数估算，假设工时如下：

用户故事标题	故事点数
房型清单	3
房型详情	2
下订	3
填写用户信息	1
确认房型信息	1

分解任务，对每个故事点进行拆解，分配负责人并让负责人评估自己任务的天数，结果如下：、

最后做出团队承诺，公开的承诺非常有效，在公开的环境中，大家会尽自己最大的努力去完成当初的承诺。这里团队承诺可以是：张三、李四、王五、赵一检查自己的任务是合理适度且自力可成的。并在迭代会议上是否能保质保量完成打上分数（满分 5 分）。

总结

本课时的内容就讲完了，我们主要学习了通过迭代会议的方式，如何制定好一份完整的迭代计划。下一课时我们将要学习敏捷的执行监控，使团队在敏捷过程中“透明化”。如果你学习完本节课有什么问题，欢迎你在留言区留言与我一起讨论，我们下一课时见。

08 执行和监控：如何使团队进展“透明化”？

在上一课时，我们知道了通过迭代会议可以制定合适的迭代计划。本课时我们将要学习敏捷的执行和监控，即如何在敏捷过程中使团队进展过程“透明化”。

透明化就是对团队完全公开化，团队所有成员接收的信息都是一致的，没有一点遮拦，它可以帮助我们的团队更好地对目标分解达成一致，更高效地协同，从而可以更快地完成既定任务。

清晰团队及团队外成员的职责

想要做到敏捷团队进展透明化，我们首先要做到使团队内外成员都清晰自己的职责。之前的课时中，我已经为你明确了敏捷团队主要成员 Product Owner、Scrum Master 和 Team 的职责，所以这里不再赘述。我想要提醒你的是，我们要分清团队内部人员和外部人员的职责。团队外部人员指的是，对团队没有直接产出的人员，比如管理层、投资人和客户。对于外部人员来说，我们只需要参考他们的意见，交付他们想要的价值即可，并不需要让他参与到整个事情当中。

每日站会

第二个帮助到我们的就是每日站会。在项目执行过程中，这是非常重要的一个工具。因为在每日站会上我们团队的信息得以流转，所以它可以帮助我们同步进展，同时及时暴露问题，并且能够及时纠正问题。

每日站会流程

每日站会一般是这样的流程，团队一起围着白板这样的信息发射源站成一圈，然后每个人轮流发言。这里有两种发言格式，主要取决于我们的团队使用哪种敏捷方式。

如果是基于迭代的敏捷，那么我们主要做的是同步进展和抛出问题，关注自组织团队的承诺。这时的发言格式是：昨天我做了什么？今天将要做什么？遇到了什么问题，谁来帮助我？

如果是基于流程的敏捷，那么我们关注团队的完成程度，主要做的是上下流的协同。这时的发言格式是：我们还需要做些什么来推进这⼀⼯作？有⼈在做看板上所没有的事情吗？作为⼀个团队，我们需要完成什么？⼯作流程是否存在瓶颈或阻碍？

每日站会的具体规则

遵循以下的规则来进行每日站会，就更容易成功：

团队人数不超过 10 名。因为沟通的路径是 N*(N-1)/2，这就意味着人数越多，沟通效率越低，所以我们应当尽量保持 10 人以内的小团队。
需每天进行。敏捷的核心是小步快跑，因此我们把任务粒度拆分到1天内，每个人每天至少可以完成1个任务，这样团队每天都有新的进展，但是也会遇到新的问题，所以需要每日开展站会同步信息。
固定的时间且每次不超过15分钟。我建议在每天上午上班15分钟后开始，团队成员可以用 15 分钟梳理昨天完成的工作。Scrum Master 要控制会议时间以保证效率。
固定的地点。团队在固定的时间就可以到指定地点集合，更加快速、直接。
需站立，这样容易集中注意力，大家在潜意识里容易想赶紧结束会议，所以就会提高效率。
不解决问题。如果站会过程中解决问题，会让这个会议主题发散，我们把问题抛出来，在站会之后 Scrum Master 可以安排专项会议解决问题。
相关人员都需出席，所有与项目相关的人员都需要出席会议。
团队以外的人不能发言，以免不熟悉团队的外人干扰团队正常工作流程。
可以使用“发言令牌”，如网球，毛绒玩具等，随机抛向团队成员，拿到“发言令牌”的成员才可发言。这样使得团队成员要随时准备下一个发言，大家会更专注。

斗地主团队案例

我们斗地主团队共 30 个人，我按斗地主的功能将团队分成 3 个小团队。每天早上10 点 15 分会在茶水间竖立一个团队白板，三个小团队先后过来开会，Scrum Master 会带着一个“地主” 小公仔，将其作为发言令牌。所有会议通常 11 点会全部过完，但是每个小团队实际占用时间只有 15 分钟。

另外，对于晨会提出的问题，Scrum Master 也会记录下来，并发到群里，中午和下午各跟进一次，直到问题得到闭环。有时我们也会开专项会议来解决某些问题。

（站会纪要示例）

擅用信息同步工具

敏捷注重高效，在团队中，信息快速同步对于提高效率非常重要，那么擅用信息同步工具就非常的重要，比如我们在每日站会中提到的白板。

白板

image (6).png

白板可以帮助我们可视化进展，它可以很好地帮助团队进展透明化。白板既可以是电子白板也可以是物理白板，通常都包含 3 个关键区域。

状态区，用来呈现待办事项当前进展。通常有未开始、进行中和已完成几个状态。如果是 IT 类研发项目，还可以细分为未开始、开发中、开发完成、测试中、测试完成、发布中和发布完成状态。
问题区：列出团队当前出现的问题，通常包括问题描述、负责人和解决时间。由负责人跟进并解决问题，完成之后该问题就可以从问题区删除。
燃尽图区：燃尽图以时间为横坐标，以工作量为纵坐标。通过燃尽图可以预测产品发布趋势、何时可以做完整个产品，而且如果是固定时间即时间盒开发，也可以预测能完成多少功能。除此之外，它还能提供关于项目进度和更新状态的最新报告，并对这些重要数据进行直观展示，这可以确保大家统一进度。

image (7).png
（燃尽图示例）

知识补充：
燃尽图中，虚线表示基准值，代表计划的完成趋势，实线表示实际值，代表实际的完成趋势。如果实线在虚线之上，代表低于预期即工作出现延误；如果在虚线之下，代表高于预期即工作提前完成。值得注意的是，燃尽图不是静态图，而是动态图，电子白板会自动更新，物理白板则需要 Scrum Master 每天晨会后手工更新。

迭代版本日历

团队进展透明化，意味着团队需要形成共同的迭代节奏，即团队要清楚哪天开周会、哪天是评审会，以及哪天需要需求评审。这就需要我们建立一个迭代版本日历。

image (8).png
（迭代版日历示例）

如图所示，这是两周一个迭代的迭代日历，纵坐标表示角色，横坐标表示时间。比如，在迭代 N-1 时，产品经理就要开始细化需求和产品体验，UI 设计师需要设计 UI，准备迭代 N 的资源，而研发人员要做的是 N-1 开发。并行开发需要产品经理和UI 工程师提前把下一个迭代的事情安排好，这样可以进一步提升团队的产能。

纵坐标在角色下面还有会议时间安排，团队成员能够明确时间，就可以提前预留时间做会议准备。

迭代版本日历完成后，我们还需要在团队工作日历上把关键活动标识出来，我们能够通过日历了解阶段性目标有哪些，需要在什么时间节点完成。

image (9).png