Scrum转型(四) Scrum会议 -- 结尾篇

1. 计划会议

1.1 工作量预估

我们会在Sprint开始之前预估工作量，并且绘制一个工作量估计表格。下图我举例一个工作量估计表格：

按照我计划的表格，我们的冲刺时长是两周，正常情况下是10个工作日。在冲刺1当中，正好有一天清明节的公共假期，所以公共假期那一列我填写了1，工作量那一列我填写了9. 研发A计划请假一天，所以计划休假那一列我也填写了1.有个比较有趣的地方不知道大家注意到每哟，有一列信息叫做“其他时间”，我在在这填写的是20%。而且在团队成员工作量估算表里面，每一个成员的总工作量都与另外三列的“研发”，“测试”，“UI”不相等（例如，研发A总的工作量是8天，但是他只有6.4天的研发工作量，你会不会问其他的1.6天哪里去了）。先来解释20%这个数字。大家都知道，Scrum有一些固定的会议需要团队成员参加，例如现在我们正在杂货召开的计划会议，这些会议会占用我们一部分时间。而且，处于组织中，我们还有其他的一些会议，工作必须完成，这些工作也会占用我们一部分时间。为这些工作预留时间是很多Scrum团队的做法。因此，我们为了大家预留了20%的时间来完成这些可以统称为“其他”的工作。这个20%是可变的，随着项目的进行，我们可以根据实际情况增减这个预留时间。

一般为了便于操作，我们一般会对这些小数取整数位。下表就是取整数后的工作量了。你有没有发现一个问题？主任工程师和UI设计的工作量本来是3.6天，我们这里却只保留了3天。这是因为，对于主任工程师和UI设计他们两个是跨多个团队工作，为了照顾到多个团队的工作，他们需要更多的时间来处理工作切换，因此我将他们的工作时间写成了3天。

现在大家应该都明白了工作量估算的意思了，就是了解一下团队单个冲刺的工作能力。大家注意到了吗？估算表里有一列是空着的“可完成用户故事的点数估计”。这个问题我会在接下来的会议当中为大家解答。

1.2 计划会议第一部分：做什么

计划议会分两步进行。第一步，我们要决定接下来的Sprint要做什么；第二步，我们要决定怎么做。 

计划会议的第一部分是梳理我们的任务板，把产品负责人的每个用户故事要做什么他讨论清楚，充分提问，发现问题，解决问题。 

1.3 计划会议第二部分：怎么做

经过充分的讨论，对于冲刺要做什么工作我们已经非常清楚了。现在需要团队讨论怎么做。大家根据对用户故事的理解，估算出完成任务需要的工作量，并且创建出具体的工作任务。

你还记得上面提到的什么是“可完成的用户故事点数估计”？我现在讲一讲如何估算工作量，然后解释这个概念。我相信大家都有过这样的经历，花费大量的时间和精力把模糊的需求分解成详细的任务，但是总却是不可避免的遇到范围变更，于是再调整计划，这种经历应该让大家很痛苦吧？Scrum团队广为使用的一种更有效的方法可以用来解决这个问题-----相对估算。这种方法独有的优雅简洁最终让大家相信：在又长又黑的估算隧道中，还是有些许亮光的。我要为大家介绍相对估算的方法，并且我们将用相对估算的方法来估算我们需要完成的任务的工作量。

目前，最常用的估算产品列表的单位故事点和理想天数。两者之间并不存在谁对谁错。但是，在实际项目中更多的团地会选者使用故事点技术进行项目估算。那么，到底什么是相对估算呢？相对估算使用‘比较’的原则，团队不是把需求拆分为一个个任务并估算任务大小，而是对完成一个新需求所需的相对工作和以前估算过的需求进行比较。例如，对一个苹果有多大，我可能没有概念。但是对于讨论一个苹果相对另一个苹果有多大就比较容易了。所谓故事点就是用于衡量产品列表条目的大小和数量。故事点的目标是比较各个故事。

为什么大家会更倾向于使用故事点数进行估算而不是理想天数呢？首先我们要明确一下什么是理想天数？理想天数代表完成一个故事需要多少的工作日或人天。之所以更喜欢以故事作为相对相对估算的一个重要因素，是因为理想人天可能会引发误解。在上面讲工作量预估时候，我希望尽量直观和介绍得简单一些，以便大家能够掌握最关键的一些概念。因此，我使用了“人-天”技术来估算工作量，现在不同了，我们要在实践中进行估算并且大家对基础知识已经更加熟练了，所以我要为大家介绍----这个在大部分组织中我们更加倾向使用的----故事点数技术来估算了。

 在上以节我有提到过 计划卡片（Planning Card）是用点数来代表故事大小的斐波那契数列： 1/2  1   2   3  5  8  13  20   40  100  无穷大（无限大的意思是说：这个功能太大了，没法估算，需要拆分）。

在评估过程中，大家要估算整个故事的工作量，而不只是你自己专长的那部分。也许你会问，怎样才能做到每个人都参与估算自己不熟悉的领域呢？请大家根据经验进行一个综合性的估算。像我们这样刚刚开始的，也许会有些难。但是，随着我们经验的积累，这种综合性的估算的准确度会越来越好的。在估算完全部任务后，我们要明确下冲刺目标，一般是以两类故事点数和最多任务，做为冲刺目标。

1.4 Sprint待办列表

 待办列表是计划会议结束的产物。

1.5 计划会议以后

在计划会议结束以后，团队成员立即开始按照计划会议上的讨论将用户故事分解成各个小的任务，在JIRA系统和物理任务板上按照既定的工作流程创建相应任务，并且标记任务完成所需要的时间。（这个工作也可以在计划会议上由指定的人员来完成；完成任务所需的时间并不是必填项，根据团队实际情况可以进行裁减。）

  

2. Scrum每日站会

站会是Scrum最有名的一项运动。每日站会就是团队的脉搏，健康的脉搏稳定，持续而又轻快。甚至很多不具备实践敏捷的组织和项目都会使用每日站会这个活动来促进沟通。 

每日在站会有五条规则需要遵守：

1.每次站会一开始，我们会先标记迟到的人
2.任何迟到的人，如果没有事先请假，没有正当的理由，就需要缴钱，做为团队的活动基金
3.请大家在开会时围绕者任务板站好
4.每日站会的发言顺序可以固定下来，也可以让发言顺序随机。
5.任务板上的信息要优化并且保持最新状态，以确保团队可以充分使用它。一些重要的信息，诸如Sprint目标，回顾会议的目标，团队的一些原则都可以放到任务板上。

Scrum每日站会小结：

每日Scrum站会是开发团队的一个时间盒子限定为15分钟的事件。在每日站会中，开发团队为接下来的24小时的工作制订计划。
通过检视上次每日站会以来的工作和预测即将到来的工作来优化团队的协作和效能。每日站会在同一时间同一地点举行，以便降低复杂性。
开发团队借由每日站会来检视完成目标的进度，并监视完成Sprint待办列表的工作进度趋势。每日站会优化了开发团队达成目标的可能性。

以下是一个可以使用的会议程示范。
1. 昨天，我为帮助开发团队达成Sprint目标做了什么？
2.今天，我为帮助开发团队达成Sprint目标准备了什么？
3. 是否有任何障碍在阻碍我或者开发团队达成Sprint目标？

每日站会是开发团队的内部会议。如果有开发团队之外的人出席会议，ScrumMaster必须确保他们不会干扰会议进行。

3. 评审会议

冲刺评审会议被有些人称为“Sprint演示”会议，因为在这个会议上团队可以炫耀他们的工作成果给项目干系人。炫耀也好，演示也罢，都说明这个会议是要展示工作成果，但你千万别被这个表面现象所迷惑，因为评审会议更重要的是为了收集项目干系人的各种反馈，达到检视和调整的目的。

在冲刺规划期间，我们要制订工作计划。在冲刺执行期间，我们在实际执行工作。在冲刺评审期间，我们检视并且调整工作成果。冲刺评审发生在每个冲刺迭代快要结束的时候，在冲刺执行之后，冲刺回顾之前。

评审会议是一个很特别的会议，Scrum里的其他会议都是团队内部会议，不邀请他人参与。但评审会议对项目外的人开发，包括Scrum团队，内部干系人，外部干系人的所有项目相关人员都可以与会。

 

 一般情况下，产品负责人都是最合适的进行演示的人。但是，我们也在实践中有过很多研发团队成员展示成果的经历。展示团队的成果对于团队成员是一个非常大的激励。所以，如果有机会，我建议大家以后都尝试做一下演示。冲刺评审常常被误认为是‘冲刺演示’或干脆被当作‘演示’。虽然演示在冲刺评审中很有帮助，但演示并不是冲刺评审会议的目的。评审会议的目的大家还记得吗？是参与者深入交谈，合作讨论出建设性的建议和意见。而演示实际上只是展示工作的一种途径。虽然我们刚才用演示的方式的对象来区分评审会议的各种表现形式，但我一定要强调，评审会议的目的并不是只是做演示。

当然除了上述目标外，评审会议的另外一个目的是要和与会项目干系人一起对一下个Sprint要做的产品列表达成共识。我所说的共识不是我们之前计划会议上所做的计划，而是对下个Sprint做什么事情的一个大致的，方向性的确定。

关于如何准备演示。演示稿本身不用很复杂，记住我们的并不需要做很炫的演示，只要能够介绍清楚我们实现的功能就足矣。花费额外的时间在做PPT和做动画上都是无意义的。通过演示，我们要达到的目的就是为深度的讨论提供足够的信息。记住积极鼓励参会者就产品和方向发表评论，进行合理的讨论是非常必要的。通过演示和讨论，团队应该能够梳理清楚以下几个问题。

1.与会者喜欢他们看到的东西吗？
2.他们希望看到什么变化？
3.产品在市场上或对内部客户来说仍然是一个好的想法吗？
4.我们是否遗漏了重要的特性?
5.我们是否在不必要的特性上过渡开发/投入？

  

评审会议小结：

Sprint评审会议用以检视所交付的产品增量并按需调整产品待办列表。在Sprint评审会议中，Scrum团队和项目干系人协同讨论在这次Sprint评审会议中，Scrum团队和项目干系人协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来的可能要做的事情来优化价值。这是一个非正式的会议，并不是一个进度汇报工作，演示增量的目的是为了获取反馈并促进合作。对于长度为一个月的Sprint来说，评审会议时间最长不超过4个小时。对于较短的Sprint来说，会议时间通常会缩短。

Sprint评审会议包含一下内容。

1.参会者包括Scrum团队和产品负责人邀请的主要利益者
2.产品负责人说明哪些产品待办列表已经“完成”和哪些没有“完成”
3.开发团队讨论在Sprint期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的。
4.开发团队演示“完成”的工作并解答关于所交付增量的问题
5.产品负责人讨论当前的产品待办列表的情况。根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）
6.参会的所有人就下一步的工作进行讨论，这样，Sprint评审会议就能够为接下来的Sprint计划会议提供有价值的输入信息。
7.评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变。
8.为下个预期产品功能或产品能力版本的发布评审时间表，预算，潜力和市场。

Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项。产品待办列表也可能为了迎接新的机会而进行全局性的调整。

4.  回顾会议

 Scrum鼓励变化，鼓励尝试；最终目的是找到适应环境的实践；当然如果环境变了，实践就要作出相应的调整。回顾会议是Scrum检视与调整的一个重要环节。在这个会议上，团队对自己的开发过程进行改进，并确定什么样的调整可以使下一个Sprint的效率更高，结果更令人满意和更易于工作。就像我们频繁地迭代和交付是为了快速的获得外部用户的反馈，进而帮助我们做产品需求的调整一样，每个迭代的回顾会议就是要更快地得到大家对团队工作的问题和改进点反馈，帮助团队内部的工作效能和能力成长不断改进。

如我之前介绍的，回顾会议的目的是检视和调整Scrum团队的流程。为此，会议组织者会组织大家使用各种技术来进行讨论。为此，会议组织者会组织大家使用各种技术来进行讨论，以挖掘出团队的问题以及讨论解决方案。必须指出的是，在之前我组织过的回顾会议中，我们经常遇到一下几个问题需要引起大家注意。

问题1：回顾会议被当成了吐槽大会。大家在会议上吐槽自己的各种不爽，宣泄情绪，但是吐槽完完毕后没有任何解决问题的方法提出，会后也不会有人跟进解决问题。
请注意，回顾会议绝不仅仅是一个让大家畅所欲言抱怨抱怨就了事的会议，畅所欲言结束后一定要讨论解决方案并跟踪。

问题2：回顾会议被当成鸡肋。很多Scrum团队会为了完成回顾会议而完成回顾会议，而无法从回顾会议当中收获到有用的交流和交流。
我之前有个切身的经历，在开了几场鸡肋一样的回顾会议以后，团队有成员提议干脆取消这个会议，至于老板要求的回顾会议要干脆就拿之前的纪要该一改就好了。。。
回顾会议的初衷是正确的，但是如果组织不当，或者团队成员不愿意讨论自己面临的各种问题，那么回顾会议就成了鸡肋。缺少了有价值的回顾会议的Scrum是不完整的，
团队很难对流程的自检和调整。

 

 回顾会议小结：

1.会议的目的---检查和调整Scrum团队的流程。
2.会议时间---每个SprintCycle的最后一个会议（推荐开会的时间是每个Sprint的最后一天的下午）。
3. 时间盒： <= 2小时（两周的Sprint）
4.会议讨论的问题：
4.1 检视前一个Sprint中关于人，关于，过程和工具的情况如何。
4.2 找出并加以排序做的好的和潜在需要改进的主要方面。
4.3 同时，制订改进Scrum团队工作方式的计划。

5. 实践类问题

5.1 冲刺目标是什么

在Sprint计划会议中，Scrum团队会草拟一个Sprint目标。Sprint目标是在这个Sprint通过实现产品待办列表要达到的目的，同时他也为开发团队提供指引，
使得开发团队明确开发增量的目的。Sprint目标为开发团队在Sprint中所实现的功能留有一定的弹性。所选定的产品待办列表会提供一个连贯一致的功能，也即是Sprint目标。
Sprint目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。
开发团队必须在工作中时刻谨记Sprint目标。为了达成Sprint目标，需要实现相应的功能和实施所需要的技术。如果所需工作和预期的不同，
开发团队需要与产品负责人和沟通协商Sprint待办列表范围。

5.2 Sprint应该多长

Sprint应该多长取决于团队和项目。当然，如果采访Scrum团队的话，你会发现团队都会把Sprint长度定在一周到四周之间，其中两周的长度是最常见的。

5.3 一个Sprint需要完成多少个故事点

故事点是一个相对的估计，除非刻意安排，每个公司的每一个团队都可以有自己的一套对于故事点大小的认知。因此，一个团队需要在一个冲刺中完成多少故事点这个问题是没有答案的。
但是，根据上一冲刺你的团队完成的故事点来估计下个冲刺你可以做多少个故事点是有意义而且可以找到答案。
团队速率是Scrum当中的一个重要指标。在每个冲刺的最后，团队会将完成的所有任务的故事点相加，最终得到的数字就是团队速率。
团队速率可以被用来预计下个冲刺团队可完成的工作。这样就可以帮助团队作出更长时间内可完成的工作的预估，并且帮助团队发现和确认问题。

5.4 如果评审会议没有可以演示的内容怎么办

如果团队什么工作也没有完成，肯定就没有任何东西可以演示，此时评审会议要讨论的重点就是为什么这个冲刺没有任何工作进展，这对今后的工作有什么影响。
当然，如果完成的工作难以演示则是另外一件事。例如，假设完成的工作是架构，那么可以展示代码（前提是产品负责人认可代码是可以验收的有价值的增量）。

5.5 Sprint评审会议有没有一些小技巧

在评审会议当中，你很有可能会遇到大家提出各种各样的问题和建议。我建议把问题限定在主题范围内。我的意思是说，团队应该回答与演示内容有关的问题。
但是如果问题跑题，就应该留到会后再处理最好由产品负责人和相关干系人召集单独的会议进行讨论。
另外，所有建议（不管听起来有多不靠谱）记在白板或者便签纸上，在会中就呈现给所有与会人。会后，任何有价值的建议都应该由产品负责人加入到产品列表中，以便进一步考虑。

5.6 回顾会议上的安全检查

在任何一个会议上，不同的与会者都有可能有完全不同感受。开会的时候有些人会觉得说话很安全很舒适，因此他们也会假设别人也会有同样的感觉。但是，另外一些人，他们也许就感觉很感觉很难受，甚至是恐惧，以至于他们很安静，甚至看起来很紧张。
回顾会议需要Scrum团队成员发表自己的观点，因此对于与会者在会议中的舒适度和喜好（喜欢当众发言或者在小组发言）对会议成功与否有很重要的影响。

安全检查是通过匿名调查来了解团队整体对会议安全感的情况。

 以下就是安全检查的步骤，以及发给与会者的调查表。

 

如果在安全检查中，发现大家对回忆的感觉更倾向于“危险”或者“恐惧”，那么ScrumMaster就需要尽量增加小组讨论的环节，让与会者在相对更加安全和舒适的小组里讨论问题。

===================================================================================

以上是全部的Scrum敏捷的全部内容，主要是在于多实践。