如何使用障碍板克服软件障碍

本文要点

• 团队需要重新定义他们对软件障碍的看法，提前认识到他们会降低团队的速度，而不是等他们出现了再去干预。

• 障碍板为我们提供了一个活跃的障碍的视图，使团队可以共同努力来消除它们。

• 重点是，要对什么是障碍这一定义达成共识，而这一定义会随着团队的发展而演变。

• 障碍和故事可以在一块图板上和谐共存。

• 团队可以在工作协议中列出如何使用一块板的集体协议。

生活中充满了障碍。不管我们是在学校中、工作中还是在家庭生活中，但凡想要做点什么，过程中一定会遇到一些阻碍。如果每一个愿望或成就都来得太过容易，生活将变得相当枯燥乏味，无法给人带来满足感。虽然我们做不到想要什么就能得到什么，但能跨过几个障碍就应该去跨过几个，这总比把它们丢给别人去处理要好得多。

软件工程师经常要克服新产品开发中的障碍。软件开发和生活没有什么不同。不管使用什么过程和技术，团队都会遇到问题。我的个人观点是，解决障碍这件事使构建软件成为最具挑战性和最有成就感的追求之一。遇到阻碍你前进的问题就去解决它吧，没有什么比这更让人有满足感了。但是，要达到这个令人仰视的高度，我们首先要必须识别障碍，然后再清除它们。

回到 2019 年，新产品的开发需要我们在如何管理障碍方面进行一些实验。此时，团队正被未完成的工作搞得焦头烂额。我们正在将新产品与已有系统进行并行的比较，以验证其准确性。这个问题很明确，正是它激发了我们尝试使用障碍板来观察和跟踪问题。

虽然我发现这方面已经有了很多很有用的材料，它们描述了什么是障碍板，以及如何在特殊的工具中创建障碍板，但人们似乎不能那么直接地获得使用障碍板的体验。在这篇文章中，我思考了我们采用第一块障碍板的成功和挑战。我将讨论我们如何将障碍板投入实践的，并分享我们在这个过程中学到的经验以及如何应用到你们自己的实现中。

什么是障碍板?

你可能首先会问自己的第一个问题是：什么是障碍板？我发现几乎每个人对故事板都有或多或少的了解，知道它可以用来可视化开发中的条目状态。特别是如果你有 Scrum 或看板的背景，可能很熟悉下面的故事板示例。

我发现同一些敏捷社区，通常对障碍板不怎么熟悉，包括我自己。若想要入门，请查看下面列出的由其他人提供的一些资源。我发现其中每一份都对入门特别有帮助。

障碍,走开!——阿伦·桑德斯，一名搞敏捷的家伙

敏捷中的障碍板?——约迪卡尔·帕克特，我的敏捷合作伙伴

使用障碍板可视化问题——乔安娜·罗斯曼, 成功创建你自己的敏捷项目

很简单，这很像大多数 Scrum 和看板团队所用的常见的故事板。下面给出一个示例。

正如你所见，就像上面的故事板一样，我们以泳道来显示给定障碍的状态。我们的示例有一个简单的三阶段流程，但是如果你认为对工作帮助，当然有理由添加更多的状态迁移。板上条目的消除顺序为从左到右。在此也有所有权的概念，哪些团队成员拥有阻碍的解决方案，就可以将给定障碍分配给他们。如下所示，是我们使用的这块板的一个工作流示例，演示了这些泳道是如何与所有权一起工作的，以及如何与故事板集成在一起的。

上述机制并不局限于 Jira 或 Trello 等工作流管理工具。虽然我们在自己的案例中使用了 Jira，但如果你喜欢的话，也完全有理由在自己的办公环境中使用粘着便利贴的实物板，那同样有其独特的乐趣。不管它是实物的还是虚拟的，障碍板都能让你看到当前工作中任何障碍的状态。

什么是障碍？

接下来，大家常常挂在嘴边的下一个问题通常是“什么是障碍？”。这个想法本身就很有意思，因为工程师认为障碍就是指使他们在一件事上无法取得任何进展的问题。使他们慢下来的障碍不被认为是障碍，因为他们仍在向着他们的目标前进。事实上，本·林德斯在他的《障碍管理》一书中提到了这一点，他指出，让你减速的障碍比迫使你紧急停车的障碍更难识别。

在采用障碍板时，需要就什么是障碍达成共识。此外，它还需要能帮助你识别那些棘手的减缓你们速度的障碍，以免它们变得越来越严重，以至于最终迫使你完全停下脚步。

用例

现在，我来聊聊，我们是如何开始使用第一块障碍板的。我所在的团队负责构建一个新系统，以取代已经使用多年的系统。除了通常的 Scrummaster、产品负责人和开发人员角色以外，我们还得到了三位业务分析师的支持，他们会执行每日的验证检查，对新旧系统进行比较。鉴于这是一个金融产品，想必你可以想象得到，确保人数的准确性对产品得到客户群的成功采用是必要的。

团队遇到的具体问题是，在每个迭代的末期，他们都被未完成的工作项搞得焦头烂额。在回顾期间讨论这些问题已成为一种常态。而当进一步调查时，团队承认计划外的工作正在破坏我们在本迭代已承诺要交付的故事的开发工作。速度变慢的主要原因是新旧系统之间的那些检查。每次发现差异时，业务分析师就会向工程师们求助，以确定导致这个差异的原因。鉴于原有系统的年代和复杂性，再加上工程师们缺乏原有系统的使用经验，这通常需要相当长的时间。

考虑到系统准确性的重要性，很明显我们需要更有效地跟踪这些障碍。一开始，业务分析师尝试的跟踪措施包括 Excel 电子表格和以电子邮件为线索。然而，这些措施都失败了，其原因如下：

首先，多次调查可能会产生同一个问题，同步跟踪它们的状态很具挑战性。当遇到同样的问题时，每天发出的 Excel 表格修订导致增加了许多重复的条目。实践中发现，这些重复条目很相近，但同时又很难识别出来，特别是在不同的日期和不同的情况下暴露出的同一个根本原因。

第二，几乎看不到调查的进展，因为我们不知道什么时候在调查问题，谁在调查。工程师们不会经常关注他们的电子邮件以回复更新的请求。但反之如果他们这样做，我认为肯定会降低工作效率，因为他们扑到 IDE 上的时间会相应地减少，而把更多的时间用于更新这些电子邮件或 Excel 中的障碍。虽说我们可能做的是金融方面的工作，但软件工程师可不会整天泡在 Excel 上！

由于这些调查与涉众要求的新特性没有明确的关联性，开发人员在极力压缩后续调查的投入，同时，由于缺乏经验又浪费了不少时间，这些从定义上看更符合“阻碍因素”，而不是“故事”。这使他们成为团队进步的障碍。我们想要明确地跟踪准确性的状态，就像我们跟踪故事的状态一样。因此，我们决定尝试使用障碍板来观察这些障碍。经再三考虑，可以通过调整现有的故事板，加入障碍以进行跟踪，就像约迪卡尔·帕克特在《敏捷中的障碍板?》中所提出的建议。老实说，我们当时并没有考虑这种方法。我们没有考虑使用这种合并后的板，而考虑的是使用一个单独的板来解决一开始要在平台中跟踪精确性状态的问题。

在向流程中添加障碍板之前，很有必要先向开发人员、业务分析师和产品负责人进行相关的培训。不仅需要通过培训来解释这个概念，这还有助于证明为什么应该引入这个概念，并激发大家讨论是否使用以及如何使用这项技术。上面提供的那些资源不仅对我来说很重要，对其他小队成员和利益相关者来说也很重要。

有效性测量

这个小组同意使用障碍板来跟踪这些状态不明确的调查之后，我们设定了实验的界限。由于关键利益相关者对准确性的高度关注，我们对障碍的定义仅限定于这些调查。由于团队仍然在并行地处理故事，我们还定义了迭代中用于解决这些障碍的能力占比。我们的做法是为每个迭代分配一定的比重。随着时间的推移，我们会根据自己的节奏进行调整，但它通常不会超过我们所承诺的速度的 40%。

我们通过跟踪每周增加的障碍数量和解决的障碍数量来衡量效率。这些数据很容易就能从 Jira 中提取出来，因为该工具会跟踪每个条目的创建和解决日期。

我假设，随着时间的推移，提出的障碍的数量将会减少，团队将有能力解决提出的所有障碍。实际结果如下图所示，我们可以清楚地看到，随着时间的推移，我们增加的障碍的确变少了，部分原因是我们一开始在这块板上添加已知的障碍时，出现了较大的峰值。我很高兴地看到，近一个月来没有出现新的障碍。但是开发人员并没有在最初的高峰期解决所有的问题。但之后，他们确实解决了提出的其他问题。然而，由于最近这段时间没有继续调查问题，对解决率的计算产生了极大的影响。

从 Jira 中提取的数据也可以用于计算解决时间。我们在实验期间收集了一些关键统计数据，如下表所示。请注意，小障碍可以在不到几个小时的周期内解决，如表中的最短解决时间。但是，如果不是大家共同努力，它们会被一直放在那里待很长一段时间，如表中的其他统计数据。

另一个有待评估的指标是总体燃尽。由于障碍板的目标是可视化并消除那些阻碍故事发展的障碍，大家希望我们能够完成更多的故事点。正如下图示例所示，可以看出我们已经距离完成迭代中的所有故事更近了。

从较长的那条垂直线可以清楚地看出，故事进行到完成状态所花的时间较长。我认为，这很可能是由于我们采用了开发与障碍并行处理的工作形式。调查和故事开发之间的切换可能会中断开发人员在这两种工作类型上的流程。此外，尽管我们分配了一定的工作能力来帮助我们完成所承诺的故事，通过查看如上已创建和已解决的图表，但是我认为我们也许应该给障碍解决分配更高比重的工作能力。

从偏定性的角度来看，这块板已被证明是成功的了。产品负责人和业务分析师都评论说，调查的情况更加透明了。通过将调查明确地分配给自己，并将障碍切换到正处于什么状态，开发人员很容易就可以向所有涉众传达正在解决给定障碍的信息，就像那些开发任务一样。此外，如果需要澄清，可以将同一条目分配给业务分析师或产品所有者，以获得更进一步的详细信息。

我们发现的另一个额外好处是，阻碍因素很容易就能转换为需要开发的故事。如果障碍具有相同的根本原因，也可以将这些障碍关联起来。这是由于我们决定障碍板也使用与 Scrum 故事板一样的工具。如果同一个 Jira 条目中同时有障碍和故事这两类，我们可以将条目类型从障碍变为故事，这样就可以轻松将其置入到产品待办事项列表中。此外，由于调查的细节和开发人员的发现都记录在 ticket 上，所有的信息都附在故事上，所以有助于验收标准的编写，甚至计划的制定和任务的识别工作。

开发人员也能从中受益，因为他们能够更好地和其他任务一起管理这些调查。随着时间的推移，他们在旧系统的代码库上投入的时间越来越多，他们越来越了解旧系统是如何工作的。这帮助他们产生了一种肌肉式的记忆，使他们之后能够识别相同问题的复发，因此节约在解决这些阻碍因素上花费的时间。

反思

我们在使用第一块障碍板时取得了相当不错的开头。然而，随着时间的推移，我们发现一直保持相同的方法会遇到很多的挑战。实际上，该团队在实验开始三个半月后就停止使用这块板了。经过对此进行反思，我决定考虑在某些方面改变一下我们当时使用的这块板，以帮助它更好地与我们的实践长久地整合在一起，并能更好地培训其他那些希望追随我们脚步的人。

首先，虽然我们可以从之前的燃尽图中看到，完成的故事与承诺的故事的比例正在趋向于 100%，但我们并没有在实验的时间框架内做到这一点。原因大概率是因为我们一开始没有做好故事与障碍的平衡。就像团队使用他们之前的迭代速率一样，或者在他们制定迭代计划中使用的平均速率一样，我们也应该尝试更好地跟踪在障碍上花费的时间来调整这个比例。

其次，在这个实验中，我们将障碍的定义局限为这些数据验证问题，实践证明这影响了这块板的使用寿命。随着时间的推移，任何团队都在成长和发展，是什么导致他们放慢了发展速度？如果你不定期回顾导致你慢下来的原因，可能就不会把这些新的阻碍因素当成是障碍。当第一个小组不再需要针对新旧工具进行调查时，他们便不再使用这块板了，因为他们对障碍的定义只局限于此。就像团队可能用到的那些“准备就绪”或“已经完成”的定义一样，他们也应该定期重新审视他们对障碍的定义，以确保也能在这块障碍板上跟踪到那些新的事项。

当我们试图推广应用到同一领域的其他团队时，一些其他团队提出想用一块板承载更多的内容。一位 IT 经理表示，希望有一块板来管理所有公司。在我们的用例中，认为将障碍与故事分离开来是跟踪系统的准确状态的最好方法。我一开始收到这些反馈时，并不愿意尝试将障碍和故事合并在一起。我认为，就我们的经验来看，指望用这一块宝贵的板来包打天下有些贪心。不同的受众希望状态有不同的视图，无论是精确的开发步骤，还是更高层次的“它已经准备就绪了吗”。

对于只想要一个视图的观众来说，障碍和故事没有理由不能和谐共存。Judicael Paquet 之前在他的《敏捷中的障碍板?》中就已经讨论过了。虽然他的观点是针对于看板的，但我认为这个想法也适用于 Scrum 实践。从最初的实验之后，我已经转到了一个新的团队，他们发现在同一块板上跟踪主要障碍有助于让大家更能够关注到问题的存在。因此，我现在坚信，在某些情况下，由一块板来管理所有的问题可能是正确的解决方案。

我提出的另一个建议包括有障碍板的用法或团队规范的通用障碍策略。大家对团队规范有很多不同的叫法，我听说过的就有工作协议和团队章程之类的。我猜还有其他的名字。但如果你仍然觉得这个术语很陌生，那么它就是指团队达成共识的一组公共原则。无论你们是在同一间办公室一起工作，还是分散在世界各地，都应该概括一下你们希望如何在一起工作，这是很有必要的。声明你打算使用障碍板，以及你对不断发展着的障碍的定义是一个好的开始。我在这里概括了许多反思的内容，如果把这些加进去可能也会很受欢迎。

结语

我从未遇到过一个在开发新软件时从未遇到过任何问题的团队。障碍板是一种机制，它使团队可以在前进过程中可视化所面临问题。它们可以用来促进问题的开放交流，让大家能够坦诚、坦然地提出这些问题，并帮助团队一起协作消除障碍。

要注意，重点是不应该把推广所有团队全面执行作为目标。强制使用工具和技术，会降低采用敏捷方法本应为我们带来的灵活性和团队自主权。如果障碍板真能带来好处，那么就用。不要把它们当作解决所有问题的灵丹妙药。就像敏捷实践中使用的任何技术一样，它应该与团队的学习和成长一起有机地发展。

作者简介

Carly Richmond 是摩根士丹利(Morgan Stanley)的首席软件工程师和 Scrum master。她主要致力于构建金融系统，也在敏捷、UI、UX 和通用技术方面贡献了许多自己的想法。她还喜欢烹饪、摄影，而且，她是一个大茶缸。

原文链接：

Overcoming Software Impediments Using Obstacle Boards

译者简介：冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。