每日scrum与看板
“在拥挤的人群中也有同志情谊。他们重整旗鼓，集中精力，保持前进的势头。”——埃弗茨，戈登和肖普“打破拥挤”。
Scrum为团队提供了大量检查和调整进度的机会，包括每日检查。抽出15分钟的时间盒——从一天繁忙的协作和完成工作中抽出——让团队聚在一起，重新将全部注意力集中在Sprint目标上。所谓的“每日例会”是每个成员反思的机会:
我昨天做了什么来帮助实现这一目标——团队同意——我个人已经承诺要实现这一目标?
我今天要做些什么来让我们更接近目标，以及我打算在下一个每日Scrum中完成的目标?
有什么障碍可能会阻碍我们的成功吗?
Sprint目标经常使Sprint Backlog中工作的选择保持一致。它给予团队一个共同的关注点和一起工作的理由。没有合作，就没有团队精神，而且很难在一开始就证明真的有一个团队。因此，如果您将每天的“聚会”作为快速的“健康检查”来衡量Scrum开发团队的健康状况，您可能会发现某些问题很明显。记住，每日Scrum的基本标准是与会者离开时要有一个计划，即他们在未来24小时内作为一个团队要做什么，以使他们更接近Sprint目标。
例如，这可能会变得很明显，每日Scrum将是团队成员相互之间有任何联系的唯一场合。你可能会看到他们使用上述“三个问题”格式的怪诞近似来报告他们一直在独立处理的任何工作的状态，也许还会在其他人都不关心的细节上发表意见。在白天，为了完成手头的各种任务而进行的合作似乎是不存在的。事实上，冲刺目标可能在任何人的独白中都没有得到任何参考，因此在15分钟的时间框结束之前，没有任何实现它的计划。实际上，很明显，团队成员不承诺以任何形式实现团队目标，或者不理解这样做的任何事情。与此同时，Scrum指南中描述的价值观阐明了每个人都应该提交就我个人而言为了团队的目标。
经常承诺而且目标只要它们首先得到团队的承认，就会被每个成员承担为其他人的责任。如果在Sprint计划中讨论了它们，那么在会议结束时它们可能很快就会被遗忘。对Sprint目标的承诺就会变得毫无意义和无关紧要。任何这样的雄心都不太可能经过深思熟虑，因为它在实践中几乎没有什么意义。该送的就送。冲刺目标就像给送奶工的醉酒便条一样被丢在了冲刺计划的门口。随着每天的Scrum，它被风吹得更远。
看板爱好者对这个问题相当沾沾自喜。因为他们主要是在持续流的基础上工作，他们通常不会观察Sprint，所以在Sprint计划中没有Sprint目标，随后也就忘记了。这意味着他们对承诺的理解可能会截然不同。例如，他们可以选择观察承诺点.．.一个节点，在这个节点上，他们将项目纳入他们的工作流，并承诺完成它们，以满足服务水平协议。看板团队成员的协作程度更有可能由任何相关的工作流策略和流畅的流程管理决定，而不是在给定的时间框内满足Sprint目标的需要。
这就形成了看板团队通常进行“日常会议”的方式，这种做法起源于质量管理。“每日Scrum”和“每日会议”之间的等价性可能并不像看起来那么直接。与Scrum不同的是，在看板中，团队成员没有责任解释他们已经做了什么，或者希望做什么，从而实现某种目标。相反，团队可能会一个项目一个项目地“走董事会”。从右到左阅读看板，团队成员可能会集体问自己:
当前被阻止的是什么?
我们如何才能消除障碍，使工作不会继续老化并招致进一步的流量债务?
还有什么正在进行中，我们如何完成每个项目?
根据我们建立的工作流程政策，我们当中谁可以帮助完成这项工作?
在采取了所有步骤以确保完成正在进行的工作之后，我们可能开始哪些新项目?
除了团队行为和预期结果的差异外，Daily Scrum和“聚在一起”之间也可能存在更明显的差异。例如，一个Scrum开发团队被限制在3到9名成员之间，所有成员都应该是同行，并且很可能重视泛化专家。超过9个人将增加网络开销，并可能阻碍这些同伴之间相互协作的能力。另一方面，看板团队并不一定由同行组成。相反，每个成员带来的技能和能力应该支持团队的工作流策略，无论它们是什么。例如，每个团队成员可能只希望与那些在工作流中与其位置直接相邻的人合作。这可能足以使生产流程更加顺畅和积极地管理。随着网络开销的相应减少，看板团队可以自由地扩大规模，而不必受到惩罚。每天的会议有时可能有几十个人参加，每个人都是纪律严明的团队成员，专注于特定的领域。当然，著名的“两个披萨规则”适用于任何会议，包括秘密会议。 If the rule is being observed, then it should be borne in mind that those attending a huddle might not constitute the whole Kanban team. They might be representing others as well as themselves.
对于Scrum开发团队来说，这一切意味着什么?它是否应该尝试将看板作为一种策略来实现?他们的每日Scrum是什么样的?
首先要承认的是，它仍然必须是一个Daily Scrum。每个Scrum角色、事件、工件和规则仍然有效，因此团队将继续拥有3到9名成员。这些团队成员可能非常具有专业技能，但他们将作为政策问题进行合作，因为他们必须展示出对明确且一致的Sprint目标的共同关注。在每次每日Scrum中，他们仍然会重新规划如何在接下来的24小时内更接近目标。
重要的区别在于，当看板策略被实现时，Scrum Sprint目标的性质可能会发生变化。它可能不再是在Sprint Backlog中为工作选择提供一致性的特性。团队可能会转而致力于完成改进的流程。例如，团队可能致力于减少周期时间，或提高吞吐量，或改善涉众所期望的服务水平。任何这些都可以是有效的Sprint目标，如果它们代表了一个连贯的功能结果，并给予团队共同工作的理由。
因此，实现看板的开发团队可以相当合理地以看板的方式“走板子”。他们可以问自己:“当前有什么东西被屏蔽了吗?”我们如何才能移除我们基于流的Sprint目标的任何障碍?我们怎样才能完成目前正在进行的工作?团队中是否有人需要帮助，如果需要，谁能提供帮助?一旦这些项目完成，我们可能会开始什么新的工作?”
看板策略要求团队主动管理其工作流。度量标准的评估有了新的意义。例如，在每日Scrum期间，开发团队应该对工作项老化特别感兴趣，因为它是一个主要指标，并且成员可以对其施加即时控制。通常情况下，一个项目在进展中停滞的时间越长，它在Sprint中完成的可能性就越小。我曾经在Sprint回顾中使用了以下测量方法来解释这一现象:
Sprint结束时项目年龄(天):>未完成的概率:23%
Sprint结束时的项目年龄(天):>未完成的概率:67%
临界点:7天或7天以上的项目根本不可能完成。
这种性质的信息在工作流的主动管理中是至关重要的，因为团队可以选择专注于那些明显处于风险中的有价值的项目。此外，他们可能会参考时间和空间图，或累积流程图，以检查流量。这样他们就能适应，从而更顺利地进行管理。进入和离开工作流程的工作量的任何差异都将引起人们的兴趣，因为正在进行的工作的积累将损害可预测性。
请记住，Scrum指南并没有规定团队在进行每日Scrum时应该使用哪些技术。经典的“三个问题”只是一个建议。如果一个团队认真地实施Scrum框架，并把他们的注意力完全放在改进流程上，那么他们的每日Scrum可能确实会采取与看板实践相关的“聚在一起”的形式。