定制你自己的敏捷方法：选择适合用于你的敏捷方法

本文要点

• 你的团队是独一无二的。你的敏捷方法应反映团队所处的环境。
• 在团队层，通常会以时间箱或计划、演示和反思的节奏来开展工作。
• 为治理流程，研究你的 WIP（在办任务）以搞明白你自己的 WIP 限制。
• 有些团队发现更频繁的演示和反思对产品和工作流程都有帮助。
• 基于你的环境决定适用于你的敏捷方法

我听到非常多的人说“Agile/Scrum”，好像 Scrum 是唯一的敏捷方法似的。Scrum 本身很好，但未必适合每支团队。实际上，迭代可能也不适用于你的团队，你可能需要交付、计划和反思的节奏，而不是时间箱。与其评估一个方法是否适用于你，不妨考虑一下各种敏捷方法的哪些部分能最适合于你的产品、项目和团队。

这是帮你思考《如何定制适合你自己环境的敏捷方法》系列文章的第一篇。如果你想知道如何使敏捷方法适用于你：你的工作、你的团队，以及你的组织，那么本篇文章就再合适也不过了。你可能是一名项目经理、Scrum Master、教练或者正在实验敏捷方法的其他领导。本篇文章所讲的是理解迭代、流程和节奏的不同，以及定制你的敏捷方法时在什么时机去考虑它们。

你可能认为敏捷方法是有效的。以我的经验来看，针对各类团队有许多不同的方法。其中一个大问题是，有人想着可以选择某一特定框架仅仅照猫画虎那样使用就可以了。

作为人类，我们理解其他人做了什么。我们觉得它可能适合我们的环境。然而，当它不能发挥作用时，我们又会对其全盘否定。

不应如此。某特定框架可能不适合你的团队或项目。我们做个假设，有 Bob 和 Sally 这么两个人，他们来自于不同的项目，处于不同的环境。

Bob 的团队都坐在一起工作，同时做一个项目，团队拥有所有所需的技术能力。Bob 的团队正在使用 Scrum，而且挺有效的。他们能够切实有效地使用各种仪式。此外，项目负责人是专职的，若有需要随时可以与项目在一起工作。

而 Sally 所处于的团队完全不同。她是研发经理，团队总部在波士顿。她和一名测试人员在印度工作，几名其他开发人员和测试人员分布在美国各地。他们的产品负责人在加利福尼亚，每周与团队一起工作的时间合计只有 1 个小时。此外，他们为一个新产品开发新的特性，并支持着四个其他产品的日常运维。

Sally 的公司想让每个团队使用 Scrum，但是 Scrum 并不适合她的团队。他们使用流程、计划及回顾的节奏使其敏捷方法可以适用于他们。

Bob 和 Sally 有着不同的项目环境。Bob 具备丰富的 Scrum 使用经验，但 Sally 的环境全然不同。Sally 的团队使用敏捷思想，可视化他们的工作，尽可能经常与产品负责人在最重要的事情上协作，以交付最具价值的东西。

想想你的项目。你的团队是同地办公吗？你的团队可以每次计划两周的工作吗？有需要时你们能找到产品负责人吗？你的团队具备所需的所有技术能力吗？从你的环境开始着手，思考哪些敏捷方法可以为你们所用。

每支团队都是独一无二的

每支团队都是独一无二的，所以每支团队都需要它自己的敏捷方法。有些团队可以使用现成的框架，比如 Scrum、极限编辑或看板法。然而，以我的经验来看，大多数团队需要针对自己的条件定制他们自己的敏捷方法。

在以下情况下，你应考虑定制你自己的敏捷方法：

• 你的敏捷团队分布在全球各地，跨至少四个不同时区。对于你们来说，召开日例会或同步的细化会、计划会和回顾会非常得困难。
• 你的组织对敏捷方法仍很陌生，你们拥有一支开发团队和一支测试团队。你的界面设计人员是一支“共享服务”团队。在这种情况下，你可以使用看板去演示工作流程，使每个人了解工作到什么地步了、什么工作延期了。你可以用这块板及其数据把界面设计人员融入到团队中来。
• 你们以工作组的形式开展工作，而不是团队。你们的工作是独立的，没有互相依赖。软件团队有相互依赖的工作，比如，需要开发人员和测试人员协同完成的工作。想象一下客户支持“团队”。公司称这个团队为一支团队，但他们并没有相互依赖的工作。每个人都单独作战。在某些情况下，大家可能会协作处理难题，但大多数时间都是每个人单独完成他们的工作。当大家独立工作时，其实只是个工作组。
• 你的团队需要提供支持或维护，这些工作的优先级高于项目工作。它们会打断你的项目工作。
• 你的团队同时要应付多个项目。

在这些情况中每一个都需要一个计划、演示和发布的节奏。然而，你的团队可能会发现，同一节奏不适用于所有的工作。

你们的计划、演示和反思节奏是什么？

一般敏捷图是思考敏捷方法如何运转的一种方法：

图1：常规敏捷图，© Johanna Rothman

负责人（通常称之为产品负责人，PO）从客户和/ 或组织那里了解到他们的想法，然后创建一个排好优先级的待办事项列表。跨职能团队从这份列表中领取任务，频繁定期地交付小的可运行的产品。在某个时间点，团队演示他们的工作并进行总结回顾。

如果你使用迭代，就要制定时间计划，因为迭代是个时间箱。按照定义，团队在时间结束时完成相应的工作。产品负责人决定未完成的工作移至下个迭代还是移到更往后的产品路线图。

一般认为，如果团队使用像Scrum 中的迭代，那么就是以有优先级的待办事项为始，以演示和总结回顾为终。如果团队使用工作流，就可以随时演示和回顾。

坦白讲，基于迭代的敏捷方法并未限制你随时演示或回顾。只是许多团队都是等到迭代结束了才演示和反思。

有些团队已经发现更频繁的演示和反思对产品和工作流程都有帮助。Ben 的团队一完成特性就进行演示。因为产品负责人大多数时间都有空，所以他们很方便演示。他们面对一些复杂特性时，想得到更多的反馈，不仅限于每迭代一次，所以开始尝试一边做一边演示的实践。结果这个实践效果很好，他们就延续了下来。

Ben 知道组织中另一支团队有个叫做“持续反思”的实践。那支团队每天站立会之后进行五分钟的反思，为接下来的工作做准备。他们在午餐之前召开站立会。因为他们全都取在快餐厅用午餐，所以他们经常在午餐时间优化流程或做些讨论。

如果你使用工作流，就会为工作范围制定计划，因为工作流不关注你有多少工作，而是完成一件后，再做下一件。在某一时刻，你们会进行演示和回顾。团队决定何时演示和回顾对于他们来说是有意义的。使用工作流的团队没必要在每个特性完成后就进行演示，尽管我遇到过的大多数是这么安排演示的。

Sally 的团队演示每个特性，尽管他们演示的方式与 Ben 的团队有所不同。Sally 向产品负责人发电子邮件解释新的特性。Sally 请产品负责人次日试试这个特性，然后反馈给团队。这名产品负责人经常用一两天时间给出反馈。

如果这名产品负责人对这个特性感到满意，那还好。但如果产品负责人对这个特性不怎么感冒，Sally 会先请产品负责人阐明他的关注点。然后，基于这些关注点，再来推进团队工作，或者请产品负责人把故事或接下来的工作讲清楚。

因为产品负责人没有足够的时间，所以 Sally 的团队的工作延期了。

Sally 的团队按节奏反思。他们每周进行异步的回顾，因为得考虑那么多不同的时区。另外，他们会每季度每个人都亲自出面聚到一起，开始亲自参与的包含回顾的会议。

理解时间箱和节奏的差异

我发现区分时间箱和节奏的差异很有用。

通过定义，时间箱可以帮助你划个期限说，“放下笔吧，时间到了！”节奏则说，“是时间再做这项活动了。”

可能团队在一个时间箱或迭代内完成故事有困难，这可能有这样那样的很多原因。我见过的三个共性原因是：故事太大了；人同时在处理多个故事，甚至更糟的是同时应付多个项目；以及团队没有像一支团队一样去完成故事。如果团队因为多重任务无法完成，节奏可能会使其更加糟糕。然而，把工作可视化可能会带来不同的影响。

Sally 的团队在一个迭代内完成他们的故事有困难。他们出现了这些状况：

Sally 的团队从未完成一个迭代的承诺。一部分原因是因为产品负责人在迭代期改变了他的想法，把讨论过的故事换成了没讨论过的。

Sally 决定是时间做些改变了。她建议团队限制故事的数量，接下来要做的、要讨论的不要太多。团队决定限制为三个故事。然后，她要求产品负责人不要改变这些故事或把它们换出去。产品负责人同意了。团队同意每周在做好支持工作的情况下努力完成这三个故事。这意味着团队和产品负责人可以每周规划好三个故事了。而灵活性是产品负责人可以每周改变或增加一次故事。

Sally 团队的节奏是每周计划和切换一批工作。随着特性的完成，团队演示了这些特性。他们所有人都很高兴。

Sally 的团队以一周的节奏去计划和演示。他们经常使用短时间箱进行冲刺，或者一个早上，或者一个下午，但他们不再使用迭代了，因为对于他们来说有些东西变得太快了。

Sally 的团队还以一周的节奏来开展回顾。他们检查已经完成的工作怎么样了，管理他们的风险和障碍，然后决定接下来做什么。

确定什么适合你的环境

你们可以使用时间箱还是迭代来管理团队承诺完成的工作？或者，你觉得用工作流有更多的灵活性？或许你可以同时使用这两种思想：时间箱让你有明确的节奏，让你清楚可以承诺完成什么，而工作流让你能看到在办任务做到什么地步了。

在办任务是所有团队正在进行中的工作。如果你使用 Scrum 板，那么它们就在“正在进行”栏。如图 2 所示：

图2：常规 Scrum 板

如果你使用看板，所有这些都会在准备栏和完成栏之间。

图3：看板可能是这样的© Johanna Rothman

使用看板的团队，其准备栏中有八项。介于准备到完成之间的所有任务是：讨论故事、开发和单元测试、系统测试，也就是他们的在办任务。

这个特殊的团队有个完整的看板。在办任务的限制防止团队把太多的任务放到准备栏，直到他们真的有时间去处理它们了。

该团队将重心转至最右边的栏，当团队把工作移到完成栏，就表示工作彻底完成了。自从团队限制了系统测试，无论谁在做系统测试，都会有人去协助他完成了。然后，谁也就都可以把已经开发完成的工作提交到系统测试了。

当一支团队加了在办任务限制时，他们就可以控制自己工作流转和生产力了。有些团队发现创建不同的栏目并限制在办任务能帮助他们发现应在自己的敏捷方法中做些什么尝试。

Sally 的团队已经转变了工作的方式。他们刻意限制了每种状态在办任务的数量。使用经典 Scrum 板时，他们不清楚每种状态下实际有多少工作。他们可以建个看板在迭代内使用，但是他们没有。

考虑你的团队的选择

尤其是，如果团队使用一个工具，最大的决策是如何管理工作流程。是使用迭代，还是应该使用工作流？我的参考意见是：如果团队能有相对稳定的故事集，在一或两周内不会被打断，就用迭代。如果团队需要快速响应一或两周内的变更，就使用工作流。

接下来，请团队考虑他们想要多长时间演示和反思一次。团队可以使用计划、演示和反思的节奏，也可以使用工作流。或者，团队可能使用迭代和有时间箱的迭代驱动他们的计划、演示和回顾。

我喜欢使用一周时间箱内的工作流。我制定一周内可以完成的计划。我可以调整这些工作的顺序，有时我还会在本周内因为中断或机会改变它本身。我一周反思一次，然后做下一周的计划，根据的是已经完成了的内容。因为我在周末中止工作，确定针对尚未完成或者仍未开始的工作再做些什么，所以我采用时间箱。

如何使用敏捷方法并没有所谓正确的方式。结合你的环境、团队和项目，才能定制出你自己的敏捷方法，使项目取得成功。

关于作者

Johanna Rothman, 以 “实用主义管理者”而著称，为你遇到的问题给出坦诚的建议。她帮助领导和团队理解问题、处理风险，以及管理他们的产品开发。Rothman 有着十多本的著作，包括：《打造成功的敏捷项目：协作、度量、评估与交付》、《敏捷和精益项目管理：跨组织的大规模协作》、《管理你的项目组合：提升能力完成更多项目》第二版，等等。请在 jrothman.com 了解她的更多著作。

查看英文原文： Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context