Bruce有话说
“每日Scrum”是Scrum 5个Events中的一个，也叫“站立会”或者“早会”。你有没有觉得身边的站立会越来越乏味？越来越形式化？变得可有可无？团队成员们每天花15分钟聚集在一起到底为了什么呢？为了向领导汇报工作进度？还是向团队伙伴同步自己的工作情况？遇到阻碍的时候个人和团队是什么关系？作为Scrum中团队反馈环的最小单元，每天团队可以根据实际情况对Sprint的后续进行调整吗？为什么Sprint计划会一结束计划就已经过时了？
今天翻译的这个Scrum Pattern就是说明每日站会的目标和意义。希望对你和你的团队理解他的真正用意有所帮助。
正文
Scrum团队已经聚集到一起了，可以开始或者已经开始Sprint了。因此，开发团队已经创建了一个Sprint Backlog，并正在努力实现Sprint目标。然而，用德国陆军元帅赫尔穆特·冯·莫特克(Helmuth von Moltke)的话来说，“除了首次与主要敌军部队接触外，没有任何行动计划可以是肯定可行的。”简而言之，在Sprint计划会期间创建的计划几乎马上就会过时。
✥ ✥ ✥
团队通过完成Sprint Backlog在Sprint中取得进展，但是考虑到工作的复杂性、任务的特征、大小和数量经常变化——有时每分钟都在变化。
例如，团队的日常工作中可能会出现替代解决方案，所需但未知的知识、隐藏的任务、误解的需求、需要进一步阐述的要求，开发人员之间的依赖关系，或者在团队日常工作中可能出现的阻塞形式的问题。 如何有效地应对这些情况成为了需要解决的问题。
有9× 10157 种方法来对100个任务进行排序，但只有少数几种方法会将团队置于“专注区”中，在该区域，工作变得毫不费力，速度显著提高（请参阅“速度注释”）。 由于工作性质的变化，团队每天至少需要采用一个新的排序方式才能超越平庸。
除工作外，团队成员的缺勤（例如病假）可能会迫使团队重新考虑其工作计划。
另一方面，太多的重新规划和重新评估浪费了时间，并让开发人员感到窒息。 而重新计划和重新评估的次数太少会导致阻塞，从而导致计划的延误或过时，这些计划不再能代表实际情况。
个人可以很快做出决定，但在团队环境中，个人不可能孤立地做出决定。你需要与每一个可能受到这个决定影响的人接触。要得到所有各方的同意需要时间。
个人可能需要向整个团队提出一个问题。但可能很难找到这样做的机会。在特殊情况下，问题会一直成为阻碍，直到团队解决它们为止。
因此:
每天都有一个简短的活动来重新规划Sprint，首先优化实现Sprint Goal的机会，其次优化完成所有Sprint待办事项的机会。严格限定会议时间，将重点放在日常计划上，避免占用开发时间。专注于第二天的工作，但要记着还有Sprint剩下的工作。
把会议时间控制在15分钟以内。团队可以按照自己的时间盒子来管理，如果有必要，ScrumMaster将强制执行这一方面的流程。许多团队站着开会，以控制短会议时长。之后，团队可以继续处理“每日Scrum”中未完成的业务，而每天花15分钟以上进行这种重新规划是团队需要进行持续改进(Kaizen)和突破性改善(Kaikaku)的一种信号。
开发团队的每个成员都要参加每日站会，这个是至关重要的。在很少的情况下，开发人员会因为疾病或冲突而需要缺席，所以会后发送会议纪要可能就没有意义了;因为团队将在下一次“每日Scrum”会议上向开发人员提供最新的信息。
为了制定计划，你必须知道你所处的位置，以及有什么问题在阻碍你。你需要一个完整的画面。一种流行的方法是让开发团队中的每个人回答以下三个问题:
- 我昨天做了什么帮助开发团队实现Sprint目标?
- 我今天要做什么来帮助开发团队实现Sprint的目标?
- 我是否看到任何阻碍我或开发团队实现Sprint目标的障碍?
请注意，当开发人员说出障碍时，有一种自然的趋势是深入研究它们并探索可能的解决方案。但这次会议是为了重新规划和决策，而不是解决问题。相反，开发团队的一些成员可能会同意在白天开会来制定解决方案——这样就不会浪费其他人的时间。他们将在第二天的“每日Scrum”中报告他们所做的事情。
当然，障碍往往会迫使计划发生改变。所以团队调整了当天的计划以避开障碍物。这是这次会议的重点之一。
这是开发团队的会议。开发团队之外的人员可以在开发团队的邀请下参加"每日Scrum"。开发团队可能希望Scrum中有一种透明的精神。但另一方面，局外人可能会通过他们的出席来影响会议。在任何情况下，只有开发团队才能在会议上积极参与，而其他人不行。这一规则适用于产品负责人以及非开发团队成员的任何其他人员。
ScrumMaster可以在任何时候参加这个会议，特别是在组织中使用Scrum的早期，主要是为了强制执行时间限制和流程的其他方面。但在这些会议上，开发团队经常会将ScrumMaster当作经理来看待。在这种情况下，最好让ScrumMaster给自己找个借口不参加这些会议，或者让他们在参加会议时以匿名ScrumMaster的身份出现。
“每日Scrum”会导致更新的Sprint待办事项列表，以及相关的信息辐射。 但是，更重要的是要理解“每日Scrum”是重新计划的会议，而不是状态会议。 辐射的信息是会议的副产品，而不是会议的目标。
✥ ✥ ✥
“每日Scrum”的精神是对现实的检验:我们能达到Sprint的目标吗？“每日Scrum”的结果是一个基于现实的新的每日计划，并促成了一个更易于合作的团队，对他们一起做的事情有更好的共同愿景和理解。团队变得更能适应其工作中的障碍环境。
“每日scrum”的习惯有助于在一群人中产生团队认同感。它将人们聚集在一起，重新关注他们的共同目标和共同身份。它可以增强团队士气(参见团队自豪感)。在某种程度上，它是一个早期发布模式(Earlier Published Pattern)的每日版本，该模式建议团队成员在深入到具体工作任务之前，首先协调任务列表中的广泛问题：请参阅远程工作之前的面对面。
诸如“应急程序”之类的特殊活动很可能出自于“每日Scrum”中的某个讨论。
“每日scrum”还有其他好处：
- 减少时间的浪费，因为团队每天都让障碍可见;
- 帮助找到协调的机会，因为每个人都知道其他人在做什么;
- 加强对Sprint目标的共同愿景；
- 通过确保每天至少一次全员互动来促进团队凝聚力;
- 促进知识共享和知识差距的识别;
- 增强整体紧迫感；
- 通过可验证的每日状态鼓励开发者之间的信任和诚实;而且,
- 通过分享仪式和鼓励积极参与来加强开发团队的文化。
站立会议(stand-up meeting)这个词有着悠久的传统，据说在英国维多利亚女王在场的场合会用到这个词:女王在场时必须站着。Scrum实践起源于Coplien对Borland Quattro Pro for Windows (QPW)项目([1])的分析，该项目在快速创造价值和质量方面有着卓越的记录。Bob Warfield当时是这个项目的负责人，他提出了以下看法:
它是我们生产力的重要组成部分，今天它是敏捷/Scrum的基石，它被称为“站立”会议或“站起来”会议。很明显，有些人只是从字面理解，开始在没有椅子的情况下开会。没关系，我想我会在会议中保留椅子，但它们的数量足够少，没有椅子应该不是问题。我曾经告诉人们要准时到会议现场，因为椅子数量会比参会者少两把，但那只是我蹩脚的玩笑，我不记得我真的这么做过。[2]
第一个Scrum团队在1994年2月基于QPW倡议实施了每日会议。Scrum团队得出结论，在Borland举行的每日会议有助于取得出色的表现。Scrum团队在其第二个月度Sprint中实施了每日会议。在1994年3月，团队在Sprint中加入了与前一个月相同数量的工作，并且在第一周就完成了。从那时起，有效的每日会议大大提高了世界范围内Scrum团队的速度
最后一点：外行通常将“做Scrum”等同于拥有“每日Scrum”。 尽管在Scrum 流程图上，“每日Scrum”是Scrum体系中最引人注目的事件之一，但是Scrum所能提供的功能远远超出了使用任何工具集所能体现的范围。 打个比方，在公园踢足球看起来很像踢足球，但不是足球。 这个模式引用了许多其他模式，“每日Scrum”模式代表了Scrum框架的关键组成部分，但这些模式也仅仅是一个起点。
“每日Scrum”模式是以前发表的站立会议的演变。
[1] James Coplien and Jon Erickson. “Examining the Software Development Process.” In Dr. Dobbs Journal of Software Tools 19(11), October, 1994, pp. 88–97.
[2] Bob Warfield. “How I Helped Start the Agile/Scrum Movement 20 Years Ago.” Smoothspan Blog, 2 October 2014, https://smoothspan.com/2014/10/02/how-i-helped-start-the-agilescrum-movement-20-years-ago/ (accessed 14 February 2019).
Picture credits: Photograph by Walker Lewis, 1944, Library of Congress, Prints & Photographs Division, FSA/OWI Collection, LC-USW3-055963-D.
