具有可操作性的敏捷工具

摘要：
很多人都知道，在敏捷领域充斥着各种内容空洞、不具可操作性的建议。当你在为一个简单的问题寻找答案时，这种状况真是令人沮丧。当然，不会有人告诉你应该按照A、B、C这样的步骤进行，不过在这篇文章里，Jeff会告诉我们如何使用一些具有可操作性的工具来解决问题。

正文：

要点：

• 让晨会变得有趣又高效
• 让团队成员集中在重要的事情上
• 在团队里使用看板
• 在当天完成知识分享
• 建议组织为知识分享投入更多资源

以敏捷为主题的书和博客有很多，我听到人们对它们抱怨最多的一个问题是，它们的内容太过空洞，而且让人不知该从何处着手：

它们看起来都很好，但如何在现实中应用它们呢？

面对这样的抱怨，我会为人们提供一些工具，帮助他们开始着手解决问题。敏捷更偏向于理论，而非具体的工具或实践，不过当我们需要去解决一些实际问题时，如果能够知道该从何处着手，对问题的解决会有所帮助。

现在，我会介绍一些工具，或许可以借助这些工具来解决一些常见的问题。这些工具很简单，实践它们所需要的时间可能比了解它们所需要的时间更短，不过它们真的会为我们带来实质性的改变。

晨会协议

你们的晨会是否散漫且无聊？人们是否要等到Scrum Master对他们指名道姓才会开始发言？是不是每个人都像在念台本一样告诉大家昨天发生的事情？

如果你经常经历这样的事情，那么你可能需要考虑实现一个晨会协议。

晨会协议的内容主要包含会议需要涉及的几个重要事项，它不再是一个仪式，而是一个可以帮助团队解决实际问题的强有力工具。

下面的例子可以作为参考：

这个做起来很简单，只要在晨会上系统地过一下所有的事项即可。这些事项可以写出来或者打印出来，并放在团队成员可以看到的地方，或者把它们做成幻灯片。我个人喜欢使用幻灯片，因为这样可以让大家精神更集中，防止他们走神。另外，幻灯片也比较方便，因为如果晨会需要用到网页（比如查看构建系统、监控台、收件箱等），可以直接把幻灯片作为网页的一部分。

要在协议里包含哪些事项完全取决于你自己，不过我建议不要把一般晨会里都会有的标准报告放在里面。另外要多想想你们每天要做的那些重要的但可能经常被忘记的事情，并提醒自己要及时完成。如果有些事情经常因为变更导致无法完成，那么这个时候正是把它们列入协议事项的最佳时机。

晨会协议为我们带来了新的框架和节奏，让晨会变得更加高效。这个框架是构建肌肉记忆的第一步，我们的目标是最终可以完全不依赖协议。

WIP协议

我看到很多团队在使用看板时存在的一个最大的问题，是他们总是被自己设定的未完成任务所牵绊。看板没有太多的规则，不遵循少数几个它所没有的规则就不会达成我们所期望的目标。

不过人们很自然地遐想到：

当我们达成白板上的一个虚拟数字，是否就该撒手，然后什么事都不做？
这听起来有点疯狂……

这确实有点疯狂，不过这并非看板存在的意义。在我看来，看板存在的目的不是为了让我们不经思索地盲目行动，相反，使用看板是为了确保我们在往已经饱和的工作队列里添加新任务时能够停下来想一想。

看板的准则是：

在完成旧任务之前不要开始新任务。

那么在这种情况下，我们该做点什么？这个时候该考虑使用WIP协议了。WIP协议包含的内容很简单，不过这些内容应该要在新任务开始之前完成。
请看下面的例子：

你可以把任何你喜欢的东西放进这个列表，只要记住，开始新任务总是要放到最后才考虑。完成已经开始的任务，防止出现可能会发生的阻碍进度的突发事件，这些才是要优先考虑的。

病假日

你的团队里是经常出现互相推诿的现象？你是否经常听到一些类似“这是（谁）的事情”，或者“只有（谁）知道（这个系统或组件）”这样的话？

这在IT公司里是个司空见惯的事情，而且发生这种状况是很危险的。在现今社会，大多数人不会在一个公司呆很长时间。公司方面也意识到这点，都在讨论该如何解决这个问题。不过大多数公司还是会在雇员宣布要离职的时候才开始采取行动，他们经过简单的交接，在下一个可以接手的人成为这个领域的专家之前，会经历一个混乱不堪的过渡期，然后这样的过程会循环往复。

这向我们揭示了两个问题：
1）如果有其他人能做这个事情，你就不会去接手。
像快速解决燃眉之急这样的事情极具诱惑性。在面临压力的情况下，如果要在一个老手和新手之间做一个选择，我们总是倾向于选择能更快解决问题的那个。
2）如果有必要，你总是能把事情完成。
如果他人的离职已成事实，团队里总是会出现能够接手任务的人。离职人员不见得能够在他提出离职后的两个星期内完成交接，一般情况下，接手的人只能得到基本的框架，然后在此基础上继续摸索。

如果你愿意，你可以继续这样做，不过这真不是个有效的方式……

实行病假日

解决这个问题的一个低风险低成本的方法是实行病假日。

过程很简单，就是让团队成员在不同的工作日轮流“生病”。当一个成员“生病”时，他会离开日常的工作环境，其他成员被委派去做他们力所能及的事情，尽量不要去打扰“病员”，除非真的有必要。

如果有人在没有“病员”的帮助下无法顺利完成任务，那么首先要打电话给“病员”请求支援，他不可以直接过去跟“病员”对话，而只能通过电话讨论。

如果通过电话无法解决问题，那么就直接去“家里”找“病员”当面讨论。

如果情况还是很糟糕，那么就要让“病员”亲自“带病”来解决问题。

最后，我们要跟踪每个人的行动事项，包括事项的执行者和事项的内容。

下面是一个简单的例子：

这个跟直接让成员们分享知识有什么区别呢？

首先，这对每个人来说都是一个很重要的思维转变，因为当原先经常出现的那个人不在场的时候，无法跟他直接面对面沟通，这意味着我们要在没有他人介入的情况下努力尝试解决问题。

通过轮流的方式把“病员”的工作分摊出去，这样会减少因“病员”缺席造成的进度滞后，每次只有一件事情滞后一天，总的来说前期成本不会很高。

我们知道该聚焦在哪些事情上，在做交接或知识分享的时候，我们自然会把注意力放在我们认为重要的事情上，不过在实际应用中还是会遇到一些问题。

我们开始着手解决这个问题！这个时候去鼓动组织投入更多资源来解决这个问题要容易得多。要说服他们，可以这么跟他们说“我们每天需要Patrik来救场4次，如果他离开公司对我们来说损失很大”，而不是仅仅告诉他们“不做知识分享会有很高风险”。

这样我们就可以远离因缺乏必要知识所带来的风险，而且在紧急事件出现的时候我们就可以进行灵活处理。

结论

事情就是这样的，用实际的建议解决实际的问题。这些工具不会一下子就能解决所有问题，不过还是希望它们能为你们带来一些价值，让你们知道该从何处着手。这些工具一直在变化，所以这不是它们的最终形式。我建议你们去找出更适合你们自己的版本。

如果你想要更多的灵感，可以看看这本书。

关于作者

Jeff Campbell是一个敏捷教练，他把敏捷和精益（Lean）融入自己的生活，认为帮助他人改进工作质量是一个社会责任。作为一个敏捷教练，他努力地促进大大小小的组织向敏捷转型。他在工作之余热衷于敏捷社区的活动，他是Gothenburg Sweden最大敏捷社区的发起人之一，这个社区拥有700多个会员，运营着一个在3个国家都具有一定影响力的敏捷论坛。他还是酝酿敏捷年度大会的组织者。

查看英文原文：Actionable Agile Tools