Scrum Meetings

    环境（源自：Backlog）

　　你是一名软件开发人员或者一名管理软件开发团队的教练，在此团队中发现、创造或者实验创新占有很高比例。一个例子就是首次交付，在这里必须详细说明问题、必须创建对象模型等。

    在诸如科学研究、创新、发明、体系结构、工程以及其他的活动中同样可以展示这种行为。

    问题

    什么是用来控制一个不可预知过程的非常好的方法，例如软件开发、科学研究、艺术项目或创新设计，在这里很难定义所产生的产品和获得它们的过程？

    作用力

    估计
    对于包括发现、创造或者实验性活动的精确估计是困难的。一般来说，它们包括大量的变化。这些不确定因素至少来自5个特性：

    1. 需求未被很好地理解。
    2. 体系结构方面的依赖关系不容易理解，并且持续变化。
    3. 技术上可能有不可预知的挑战。即使事先知道这些挑战，他们的解决方案和相关的工作量也是不可知的。
    4. 在软件中可能存在难以解决的Bug。因此，可能会看到对于项目的估计相差了几个数量级。
    5. 另一方面，估计是重要的。必须能够确定在将来某个时间范围内的任务是什么，并且事先准备好资源。

    规划

  • 规划和重新确定优先级需要时间。工作人员参加时间计划会议降低了生产力。而且，如果系统是混乱的，没有什么能够减少不确定性因素。例子：因计划而导致瘫痪。某些项目把个人的时间浪费在计划每件事情到极端详细的程度上，但是永远也不能实现这些计划。

  • 然而，一个过于详细的计划将变得庞大而且很难去遵循。计划越庞大，它所包含的错误越多（或者至少是证实其正确的成本将增大）。例子：总体规划是一个极大的谎言。很多项目试图遵循一个总体规划，实际上，却落入了相信他们的不准确的陷阱里，通常在他们的期望落空时感到失望。

  • 没有任何规划增加了团队成员间的不确定性，最终损害士气。例子：愿景迷失。没有任何安排的项目往往失去对它们期望的控制。没有一点进度压力，将没有人去做任何事情，更糟糕的是，将很难把独立开发的不同部分集成在一起。

    跟踪

  • 过多的监视浪费时间，使开发人员感到压抑。例子：度量致死。项目把每个人的时间浪费在跟踪每件事情的极端细节上，但是永远也不能实现计划。

  • 由于系统混沌的本质，跟踪并不能增加指示器的确定性。

  • 过多的数据毫无意义。

  • 不足的监视导致障碍及任务之间可能的停顿时间。例子：这里发生了什么？没有跟踪任何事情的项目往往失去对正在进行工作的控制。最终，没有人真正知道完成了什么。

    解决方案

    为正确地估计、计划和适当地跟踪做好准备。在每天例行的Scrum Meeting上花费短暂的时间（大约15分钟）与团队成员见面，唯一的活动是询问每个参与者下面三个问题：

    （1） 自从上次Scrum Meeting以来，你都做了哪些工作？Scrum Master将已知完成的任务和那些还未完成的任务记入日志。
    （2） 在刚刚过去的24小时中，你在执行任务中发现了什么障碍，如果有的话？Scrum Master将所有的障碍记入日志，过后寻找解决这些障碍的方法。
    （3） 在未来24小时中，你将做什么工作？在架构师的帮助下，Scrum Master帮助团队成员选择合适的任务。因为任务的安排是以24小时为基础的，任务一般都是小规模的。

　　译注：Craig Larrman在此基础上增加了2个有用的问题。（4）有没有任务添加到Sprint Backlog中？注意是指遗漏的任务，不是新的需求。（5）相对于其他团队成员，你是否学到了一些东西或者做出了一些新的决定？（技术方面、需求方面）最后一个问题为持续进步和学习的团队提供了一个有效的讨论会，这对于敏捷开发是相当重要的。

　　这将提供给你更准确的估计、短期计划、适当的跟踪和纠错机制，来对变化做出反应，每24小时做出适应性改变。

　　每天的Scrum Meeting一般在相同时间和地点举行，所以它也可以达到创造浓厚文化的目的。同样，Scrum Meeting也是为团队增强社会化状态、问题和计划的仪式。Scrum Master主持会议，把来自每个团队成员的所有任务记入日志，作为全局的项目Backlog；他还将每个障碍记入日志，并在开发人员从事其他任务时解决这个障碍。

    Scrum Board已经成为管理任务的非常好的实践。团队在多栏Scrum Board前碰面讨论。第一栏为以大卡片形式的选自Product Backlog的按业务价值排序的用户故事（User Story）。在Sprint开始时，把从用户故事扩展而来的任务以小卡片的形式放在左栏中。每天软件开发人员将任务移至“处理中”（In Progress）一栏，然后是“验证”栏（Validation），之后是“已完成”（done）栏。每天更新任务的估计和Burndown Chart，容易计算，并在板上公布。

    需要优先予以考虑的由Scrum Master记录的障碍日志，现在被称为障碍清单（Impediment Lis或Impediment Backlog）。 阻塞（block）是制约系统吞吐量的关键因素，应是Scrum Master优先关注的工作。校正开发项目类似于微调计算机系统。关键约束可能并不会明显存在，可能需要仔细分析才能得出。主要的瓶颈必须发现并第一时间修复它。开发系统作为整体应该允许稳定和可度量。

    重新稳定后下一个关键阻塞可能在意想不到的地方出现。非瓶颈活动中的人员工作效率即使不高，也不会影响整体项目，使用关键资源来加速瓶颈活动中的工作。

　　Scrum Meeting不仅为开发人员安排任务，还可以并且应该为所有参与项目的人安排活动，比如从事配置管理的集成人员、架构师、Scrum Master或者QA团队。

　　Scrum Meeting也可以由自引导的团队举行。在这种情况下，需要指定一个人作为记录员，将Backlog中已经完成的和计划的活动以及现有的障碍记入日志。来自Backlog的所有活动以及障碍都将分发给团队成员来解决。

    Backlog和障碍的格式可以有所差别，从写在纸上的项目清单到通过Internet/Interanet的软件表示法[Schwaber 1997]。Scrum Meeting的频率可以调整，一般可以定在2～48小时之间的任何位置。

    Scrum Meeting通常站着举行会议，这确保了会议简短而且切中要害。

    基本原理

    由于非常容易产生高估或低估，这会导致闲置开发人员的时间，或者延误任务的完成。因此，最好经常对小规模的任务状态进行取样。具有高度不确定性的过程不可能仅用像甘特图（Gantt）或者计划评价与审查技术（PERT）图这样的传统项目计划技术，因为正在进行分析、实现或者创造的变化速率是非常高的。相反，对任务的持续重新确定优先级提供了一种适应性机制，这种机制提供了在短时间内对系统知识的采样。

    同样，Scrum Meeting也能够帮助创造一种“参与的文化”（anticipating Culture）[Weinberg1997]，因为他们促进这些建设性的价值：

  • 他们增强了全面的紧迫感。

  • 他们促进了知识的共享。

  • 他们鼓励了密集的交流。

  • 他们促进了开发人员之间的诚实，因为每个人不得不汇报每天的状况。

    这一机制鼓励了团队成员在发展的基础上社会化（Socialize）、外表化（Externalize）、内化(Internalization)并整合(Combine)技术知识，因而使技术的专业知识成为实践团体的共同财产[Nonaka1995]。因此，Scrum Meeting是具有深厚文化超越性的仪式。在相同地点、相同时间与相同的人会面增强了归属感，培养了共享知识的习惯。

    已知应用

    Mike Breedle，在位于芝加哥的Nike证券工作。自从1997年2月开始使用Scrum Meeting来运作我们所有的项目，包括企业过程重组（BPR）和软件开发。参与这些项目的每个人会接受为期一周的Scrum技术培训。

    Yonat Sharon，在Elementrix Technologies工作。有一个项目在开发大约5个月后延期。它只完成了一小部分（大约20%），即使这部分也存在特别多的Bug。项目经理开始每2天举行一次短暂的状况会议（当时我们中没人知道Scrum这个词）。在接下来的一个月里，整个项目都完成，并且质量急剧上升。2周后，beta版发布。会议就此中止，之后这个项目就几乎没有什么进展。我不认为这个项目的成功应该全部归功于Scrum Meeting，但是它们在取得的这一成就中发挥了重要的作用。

    在RAFEAL，软件团队中的一名团队领导实施了Scrum Meeting的一种变体。他每天都去每个开发人员那里，问那三个问题；同时他也管理Backlog。这没有团队建设的效果，但它的确提供了经常的采样。

    C3和VCaps项目也做了这些工作。他们称之为“站立会议”（Standup Meeting）。实际上，极限编程XP（Extreme Programming）的站立会议正是Kent Beck从Scrum得到的启发。

    应用结果

    这个模式的应用导致：

  • 高度可视的项目状态

  • 高度可视的个人生产力

  • 浪费在障碍上的时间减少

  • 浪费在等待其他人上的时间更少

 • 增强的团队社会化