敏捷墙

在敏捷的世界里，BVCs、TOWs 和 POWs 都是非常重要的工具。那么它们都是什么东西呢？BVCs（Big Visible Charts）指大型可视化图表，TOWs 代表着墙面展示（在墙上展示各项事项，Things on Walls），而 POWs（Plain Old Whiteboards）则意味着简单且古老的白板——它们都属于不同类型的信息辐射器。进一步来说，为什么这些工具都有非常宝贵的价值？因为在理想情况下，每个人都可以看到、研究并且理解它们。通过把各类事项放大并进行可视化展示，我们将让整个团队都能够接触到这些信息，而不再将其仅仅局限在部分特定的团队成员中。

在墙上展示这些信息，意味着我们会把它公之于众，以便获得来自整个团队的反馈。为了尽可能让工作中 “不存在浪费”，我们需要使这些信息具有轻量级、易于访问、低技术门槛的特点，从而让每个人都能够看到并且能够无限地变更。就此而言，POW 是一项理想的工具，团队中的每个人都应该能够根据需要使用它，或是对它进行更新。

当我们谈论起这件事时——把团队需要的事项内容放到公开的、易于接触的区域——听起来它并不复杂。我们将做好足够的准备以促进人们理解信息，并消除实际上并不怎么好看的 Visio 图以从而避免浪费。同时，我们也要保持信息公开，从而以评论、更新和重要的关键指标为中心，提供良好和开放的透明度。我们应该确保团队中的每个人，自始至终都能够接触到全部信息，因为这非常有助于培养整支团队中的沟通、协作和共享的理解。此外，通过使用活动挂图、标签、卡片、便利贴以及手绘图形，我们可以非常快速、高效地传达许多信息。我们也能够捕捉并记录历史、发展趋势、以往的决定，以及工作进展或团队内部的变更。

展现什么类型的信息？选用什么类型的墙？由谁负责管理它们？谁去更新它们？在实际工作中，面对这些问题有许多种不同的方法和信息，因此作者的答案是“视情况而定”。不过本文将介绍一些（不分先后顺序）作者曾经见过、听过或想到过的一些非常好的理念、一些标准的墙，以及一些精彩的、富有创造性的墙。

计划墙

计划墙负责呈现有关工作、团队和产品等方面的计划信息。这些信息可能是一些类似于发布计划、产品路线图或是迭代计划，甚至是故事墙之类的东西。在理想情况下，计划墙应该被安置在团队中的每位成员都能够看到并对其进行更新的地方。

图 1- 最初的发布计划

发布计划——这类墙上包含了工作中的待办事项列表，其右侧是基于速度或团队结构，将已规划的工作流分解成的各个迭代。待办事项列表包含了从项目最初阶段开始，为了完成项目所规划的工作。速度是指预估的团队工作能力。基于风险、依赖、大小和团队能力，我们把工作单元或故事分布到各个迭代和严格控制时间的工作片段之中。这样，计划墙就能够展现整体工作的全局视图、对依赖和团队工作能力的理解，以及对项目工期的清晰描述。应该由团队负责构建计划墙，并且依据每次迭代过程中的工作进展，以及待办事项列表或正在进行的工作发生的变更情况，进行更新。

图 2- 动态（更新的）发布计划

当某次迭代结束后，可以捕捉到额外的工作并将其添加到计划中，例如缺陷（红色）或变更（绿色）。在添加了所有的缺陷和变更后，代办列表将显示出无法在计划时间内完成的工作，或是已经识别出的额外工作。这将帮助团队清晰地看到接下来需要做哪些工作，以及它们将在何时完成。如果项目中有多支团队，那么可以把发布计划按团队以及每个团队分配的工作水平分割，以便与团队资源、技能配置和工作能力相对应。

图 3- 多团队发布计划

在项目工作推进的过程中，这些发布计划也将同步更新。从发布计划中，我们还可以看出是否达到了预估的速度。如果没有，还需要多少个额外的迭代来完成待办事项列表。此外，我们将对新增卡片按不同颜色或日期排序，以便跟踪注入到待办事项列表中变更的总量。我们可以将代码卡片着色，来突出显示任何专家工作区域；我们可以为缺陷配上不同的颜色，并查看墙上添加了多少此类卡片，从而评估已完成工作的质量；我们可以在卡片之间划上线，以跟踪和管理依赖。计划墙还能够跟踪其他事项，包括故事、任务，甚至是产品的特性或组件——如果画出了产品生命周期的话。若是将计划墙用在持续不断的工作流，而不是不是单一项目，那么可以采用发布而不是迭代，来衡量工作和速度。如果在众多迭代的上方添加一个日历，那么管理者就可以看到交付日期、工作流，并且还能够评估其他一些事情，例如：资源限制，或是用来管理其他关键团队行为（如休假或培训）的计划等等。

我们可以从发布计划外推，得到投资组合计划和治理层面的业务单元工作计划；或者向下推算到团队层次：每个人对工作的贡献被映射到每一天的层面（一次迭代计划）或是工作流层面（故事墙）。

在每次迭代结束后，应该由整个团队更新发布计划：反馈并通过发布计划反映出从这次已完成迭代中学到的东西、向待办事项列表增加事项、更新能力并重新评估风险。团队将通过管理规划墙享有额外的好处：在构建对项目整体的理解的同时，也培养了交付完整产品所需工作的产品所有者制度。团队中的非技术成员可以查看并理解需要交付完整产品所需完成的工作范围，并且也能够评估并理解对计划所做变更的分支、不断提高的速度（会带来缺陷的增加）以及故事之间的依赖。

计划墙还可以展示迭代计划，并且（在理想情况下）迭代计划应该展示在紧邻发布计划的区域中。迭代计划详细展示了完成迭代中规划的工作所需要的活动。此外它还会捕捉关键团队事件（例如站立会议、作品展示和回顾），并将这些现实情况应用于更大范围的发布计划。迭代计划应该从团队的必要流程开始，首先识别出所有已知的团队活动，然后是迭代周期中规划的工作，以及用天数和工作小时数表示的迭代长度。

图 4- 迭代计划启用时的样子

接下来的事情，就像是做大型拼图游戏一样：试着让所有已规划工作与个体和团队承诺——例如核心工作小时、培训、休假、其他项目工作等等——相互匹配。其关键在于，首先填充必须进行的活动，然后在间隙中填入已规划工作和一般性团队活动（例如精化或用户接受测试），最后则是分配团队成员个人的工作时间。这让每个人都能够了解自己什么时候需要参加团体活动（高依赖），以及什么时候有时间来完成各自部分的工作。

当制订完迭代计划后，我们应该已登记了所有强制性团队活动，为迭代过程中所有已规划工作指派了所有者，并规划了关键交付活动。另外，在对可并发进行的工作进行规划的同时，也规划了每个已规划工作单元的关键交接节点。理想情况下，已规划的工作将与迭代相匹配，否则将会有一些工作遗留在已规划工作区域，这样就必须在迭代结束时反馈给发布计划。迭代计划非常适合与立会配合，因为它能够让团队中的每个人指出自己当前工作和进展，而且还能够让整个团队都理解、规划和管理延误的影响。如果某份计划过于乐观，不能接受某些现实情况例如病假、节日、休假或培训，那么这所引发的问题会变得非常明显。而如果某份计划过于天真地期望团队成员能够在桌子前面“工作”8-10 小时，那么它所引发的问题也将非常明显，而团队可以基于这份迭代计划，快速标识出问题和风险。这种做法确实严重依赖于对预估的所有制，因为团队基于自己的预估制定了这份计划。指定迭代计划将促使团队逐步成长，使其认识到其预估对其他团队成员有多么重要，以及一个故事中的延误将如何影响另一个故事的交付。

图 5- 完成后的迭代计划

在细节层面，比计划墙更进一步的是故事墙。故事墙展示了某个工作单元或故事的生命周期，并跟踪了贯穿这些活动之间的故事的进展。故事墙是很常见的敏捷墙，而且如果使用看板风格方法（例如限定当前正在进行的工作的数量，并使用头像来表明个体能力，以及为完成整个工作单元所需的详细的活动）的话，它将变得极为高效。

图 6- 标准故事墙

图 7- 看板工作流

架构墙

与计划墙相比，架构墙是大相径庭的东西，然而二者之间非常奇妙地又有着颇多相似之处。它们分别涵盖不同的题材并专注于不同的信息，但是都可以用于“宏观”讨论中，记录解决方案的端到端架构；也可用于“微观”讨论中，深入到当前正在交付的故事或工作单元中的某些细节层面。我最欣赏的方式，是随着迭代过程中提出并解决问题，详细地更新整个项目的架构墙，接下来在架构墙中分配一个区域用于标准，另一个区域用于问题和讨论交流。

图 8- 基础的架构墙

当信息填充到墙上后，就可以针对开发和交付解决方案所需的中间成果，组织全体成员来讨论关系、依赖、可测试性，以及用来开发和管理这些中间成果的环境。对墙上内容作任何变更，都可以快速完成并公之于众（因为墙本身就处于公共区域，每个人都能看到它！），随后整个团队都能看到变化，并就任何内容及其分支进行提问和理解。团队还可以在架构或屏幕或上下文关系图中覆盖上自己的工作卡片，以查看是否存在间隙或过度交付。

理想情况下，架构墙应该位于正在进行其上所列工作的团队的附近。对团队来说，它应该起到 wiki 或“待办事项”参考的作用，并且理想情况下附近还应该有一个 POW，以便团队参考整体解决方案来讨论并研究解决细节问题。为了保证定期记录架构墙的变化，可以使用数码相机或智能手机进行拍照，以支持进行变更并对其版本控制进行管理。

测试墙

测试墙与架构墙大体类似，但关注的维度不同。在测试墙上，用不同的颜色（测试的类型或级别）和状态（通过或失败）区分测试覆盖。作者最喜欢的方法之一是使用一份高级别架构图，然后用代表着测试在哪些级别上被规划为手动或自动的卡片，来覆盖该架构图。随着测试的进度，卡片也将被标注或着色为红色或绿色（代表失败或通过）。如果团队希望跟踪缺陷密度，那么每次测试失败的时候就增加一张红色卡片，这样卡片堆的厚度就反映了下面覆盖的代码 / 解决方案的风险程度。针对某次迭代或发布，这将有助于选择期间适合使用的回归测试。

图 9- 测试覆盖计划

图 10- 测试结果映射

该方法可以用来跟踪测试覆盖中的自动化、回归、非功能属性或任何团队需要了解的其他方面。它是非常强大的工具，能够发现缺陷簇和系统中脆弱或容易产生向下兼容问题的区域。

报告墙

上面介绍的各种墙，都可以被归类为报告墙，因为它们都可以用于衡量或评估进度、覆盖、风险或缺陷。然而一些团队更愿意为管理层或团队提供专用的墙，用来评估特定的指标。最常见的指标之一是“燃烧速度”。燃烧可以是以天、工作投入、美元或故事点为单位，其评估结果可能是增多（燃起）或减少（燃尽）。燃烧速度是非常强大的工具，它有助于团队保持专注。

墙上跟踪的其他指标包括资金花费、故事交付（通过发布计划）、发现和解决的缺陷（通过测试结果墙）、测试覆盖（通过测试计划墙）。另外，还可以跟踪团队在社会契约方面的行为和变更方面的趋势——在考虑是否乐于跟进敏捷变革时，这是非常有用的指标。

图 11- 团队行为

作者也曾听说过其他一些有趣的指标，例如：在一次迭代中分布的故事的大小。使用该指标，将非常有助于查看速度、了解完成了多少迭代，以及它与故事大小的关系。

图 12- 故事大小

总结

团队要想良好地完成工作，需要掌握太多的信息。而且，我们需要真正理解并展现这些信息，以最大限度发挥团队的优势。这些信息应该不仅可用，而且应该易于理解。为达到这一目的，各种类型的墙提供了最佳的可能途径。理解可供使用的各种类型的墙，有助于团队理解自己需要看到哪些信息，以及如何展现它们。其关键并不在于遵循严格的模式，而是展现并使用那些对于团队整体来说至关重要的信息。

关于作者

**Sharon Robson是Software Education**的软件测试实践领袖。自 2008 年起，她就担负起这一角色的工作。作为一位满心激情的测试工作者，以及一位天生的培训导师，Sharon 提供和开发了软件测试中各个层次的课程，从入门到精通。Sharon 还专注于敏捷，并针对许多团队（培训和辅导）身上投入了大量的时间，来帮助他们完成敏捷转型。在 2010 年，Sharon 被《Software Test and Performance》杂志提名为软件测试领域 13 位最有影响力女性之一。在诸多论坛（包括敏捷 2010 大会）中，Sharon 都接受了采访，并留下了敏捷和测试方面演讲的记录。

查看英文原文： Agile Walls