产品开发机制-InfoQ

要点

降低管理损耗，放权予团队，并通过对简单机制的落实去提高生产能力和质量。

宗旨可用于表达团队价值并指引团队决策。

退出标准有助于团队避免返工，并将产品质量固化在解决方案中。

承担工作任务的人需自行去定义宗旨和退出标准。

一旦团队找到了更适合的工作方式，就可依此对机制进行持续精炼。

作为数字产品交付团队的负责人，我们时常设法对新产品特性的生产能力和质量进行改进。我们也常探寻降低管理过程中损耗量的方法，并放权给团队去自行做出最优的决策，这种放权无需的大量的表现为微管理及状态承担形态的无用管理开销（UMO），使得我们能侧重于高增值活动。本文中，我将论述两个简单但强大的机制，它们可在降低开发过程中损耗的同时，改进生产能力和质量。

机制

为帮助团队迁移到自授权的拉动式系统，一个基本步骤是将价值流映射到看板图上。此后最好是去添加 WIP 限制，这样可以平滑工作流并最大化生产能力。那么为了进一步消除软件交付过程中的损耗，我们还能去做什么？

“好的意图从不起作用，你需要好的机制使得凡事成为可能。” Jeff Bezos。

我在此使用了两个非常简单而有效的机制，用以改进团队纪律，并利于放权给团队去自行做出软件产品交付相关的更优决定。第一个机制是宗旨。宗旨是我们一致认可的言之有理的原则，并应能指导我们的行为。宗旨可用于开发过程中的多种场合。例如，一些宗旨有助于指导工作选取决策，例如做出是否采用某个首创或者特征的产品管理决策。还有一些宗旨可用于指导软件交付的方式，例如软件开发过程所采用的约束或指导原则。

第二个机制是退出标准，它规定了进入到价值流中下一个活动前所必须要达到的条件。退出标准起到了检查列表的作用，用于使团队真心实意地确保活动已被足够严谨地执行，以避免其后在价值流中出现返工或者其它所不期望的现象。

无论是宗旨还是退出标准，都应在某种程度上有助于使团队将软件交付工作的注意力集中于团队的任务上。

团队领导的职责包括，发起讨论并确保宗旨和退出标准得以定义。然而，具体承担工作的团队成员需要承担定义宗旨和退出标准的职责，并对它们的落实进行相互问责。为使讨论得以滚动开展，领导者可以推荐一些实例和候选的内容，然后退出一线以使团队自己去解决问题，仅在必要时提供便利。一旦领导者对任一机制存疑，或对其有效性或价值存在模糊不清的认识时，领导者也可去质疑团队。

一旦团队已定义了一套初步的宗旨和退出标准，团队成员就要同意去将它们付诸实施，并据此相互问责，进而通过持续地召集会议去评估它们的有效性，并进行必要地改进。对于会议召集的工作，一种好的组织形式是迭代回顾会，但这并非意味在团队在意识到机制需要即时更改时，仍必须等待至回顾会召开。

案例分析

近期，我帮助一个数字产品研发团队通过采用看板去提升他们软件交付的生产能力和质量。团队工作的故事包括了从代办列表到产品，使用了如下图所示的看板系统。我们在持续提交流水线（CDP）中使用了“接收测试驱动开发”（ATDD）的模型，自动化了软件构建活动，在测试环境中部署了软件构建，运行了测试环境，并将软件构建提交给开发环境以在生产系统部署之前做可视化审查。

(点击放大图像)

我们确立了如下文所列的宗旨和退出标准，并将这些内容贴在团队的房间中，以使每个人可参阅它们。

宗旨

被团队用于看板治理的宗旨包括：

产品负责人的职责在于确保代办列表优先级的顺序总是递减的；
任何价值流中的活动都必须被每个已被开发的故事所执行，不能跳过步骤；
我们不提前执行价值流内处于下游的活动。不按顺序地开展工作只能导致混乱和未完全完成的工作，进而导致不完整的价值；
就绪状态对团队意味着已对准备去执行价值流中的下一个活动；
如果某个团队成员已具备了一整套技能和能力，可为处于就绪状态的故事执行价值流中其后的活动，那么由该团队成员将故事从就绪状态拖出，置入其后的活动状态，并将自己的名字记录在看板上；
在选取从就绪状态拖出到活动状态的故事时，我们倾向于选取其中的最先被拖出到看板上的故事，以确保最高优先级的故事可最先交付；
当一个活动的退出标准得到了满足，由执行该活动的团队成员将故事拖动到其后的就绪状态；
我们从不违反在制品限制；
在某个时间上，一个团队成员只能活跃于一个故事上，因为专注可提高生产能力和质量；
每个团队成员负责去更新卡片以反映出他们所启动和完成的工作。经理不能代替团队成员做该事；
一旦故事正在进行就不能被中断。启动即要完成；
直到与故事相应的软件已被部署到生产系统并被可用户访问，该故事才被完成。我们不对未交付的价值邀功；

注意在大多数情况下，我们还需添加对遵循宗旨的原因的简要解释。这对于团队的新成员是十分有用的，并可提醒团队为何最初如此决策。

退出标准

除宗旨以外，团队对看板中活动的状态建立了如下退出标准:

活动

退出标准

定义验收测试 - 由产品负责人、商业分析师和质量分析员去审查并批准故事的所有验收测试场景；

验收测试场景应在大体上服务 /API 占比 80%，UI 占比 20% 的覆盖率间保持平衡；
包含故事场景的特征文件需提交源码控制。

正在开发 - 实现特征文件中所有场景自动化的代码，并提交源码控制；

实现使自动化测试通过的应用代码，并提交源码控制；
在 CDP 的协调指挥下，全套回归测试中 100% 的自动测试将传递进测试环境；
CDP 已将软件构建部署到开发环境。

正在验证 - 产品负责人已经目视检查了构建于开发环境中的应用；

产品负责人已目视检查了自动测试结果。

推广到生产环境 - CDP 已经在生产环境中部署了经验证的软件构建。该软件构建已可被用户使用，或者可通过开关一些特性而可用。

观察

为获得期望的结果，宗旨和退出标准是影响团队行为的强大工具。

在我们最初启动工作时，团队成员例行公事地将故事移动到看板上的状态中，这导致看板状态并非真实地反应了故事的实际状态。例如，在验收测试规程被产品负责人充分地审阅并核准之前，故事就被移动到了开发就绪状态。这导致了看板处于一种不可靠的状态，因为在开发仍在进行中时，团队成员就已致力于未完成的验收测试定义中。这使得无法得知在特定的时间点上，什么人真正地在进行什么工作，这违背了看板系统的透明度目标。

在我们制定了上述宗旨和退出标准后，看板的状态更加可信赖了。由于团队成员个体间彼此问责，这致使团队的项目交付经理可以大大降低团队成员微管理的时间，这种微管理是用于判断成员工作的完整性。如此做的一个重要影响是使得故事从左向右地穿越看板，其中因需要返工而退回到此前状态的故事实例更少了，这样消除了导致损耗的一个关键来源。我们也观察到，在具有需合作以达成退出标准的职责的团队成员间，他们的工作关系很好地得以改善。例如，在 PO、BA、QA 这三驾马车的成员间，他们已直接了当地用 10 到 15 分钟不拘泥于形式的快速讨论，就可以对验收测试规程达成一致。

在产品开发工作启动后，一些团队成员往往让他们的名字一次出现于多个处于活动状态的故事中。这意味着这些人意图在工作中多任务，而且我们也注意到这些人易于成为开发过程的瓶颈。考虑到这个问题，我们实施了每个团队成员只能同时活跃于一个故事中这条宗旨，以使团队成员只能一时聚焦于一事。对这些人而言，执行该宗旨起始是十分痛苦的，因为他们对保持忙碌等同于保持生产力存有幻想，已习惯于频繁的工作场景切换。事实证明，该活动状态的退出标准切实地降低了团队成员将他们的名字置于多个任务的倾向，因为他们不得不投入更多的、具有针对性的努力，已确保每个处于活动状态的故事已真正地完成且不会在看板上后移。

同样地，与将故事移出正在开发状态这条退出标准一起坚持在制品限制，这样起先对于团队而言是十分痛苦的。一个难以改掉的坏习惯是仅拖拽进来另外一个故事并工作于“我自己的部分”。曾一度，工程部副总不得不参与进来并告知团队，一旦发生潜在的在制品限制，为完成团队的工作，每个成员都需要去帮助工作于受阻故事的队友。如果做不到工作上的帮助，那么他们可试图去发现是否有其它能改进团队工作条件的事情可做，甚至可以是为每个人提供咖啡。一旦该副总澄清了他更愿意让人员保持闲置状态，而非用违反 WIP 去扰乱工作流，团队成员就可理解时常不在“看上去很忙碌”的状态也是没有问题的。

最初测试团队还在验证功能上花费了很多工夫，当使用更快速省事的服务测试就足以胜任时，他们还是使用了自动化 UI 测试。在我们添加了服务与 UI 测试分别占比 80% 与 20% 这条宗旨后，测试的开发和执行更加快速，而且团队还开发了聚焦于特定 UI 功能的 UI 测试方法。同样，该功能测试套件可更快地运行结束。

对于最初数个对产品负责人所做的演示，开发人员会在他们的开发工作站或测试环境中进行演示。这杨导致了一些痛苦的交流，因为此时软件相较于客户要求而言是不太稳定的。常见的借口是诸如“这在我的计算机是运行良好的”之类，这时产品负责人会开始失去耐心，团队也会对这样差强人意的展示感到十分尴尬。在我们添加了产品负责人在部署环境中检查软件这条退出标准后，使得演示更加地富有成效，更加专注于增值主题。因为部署环境仅比生产环境低一层级，因而是更加可靠和稳定的。

在团队更多地了解了如何共同工作之后，团结可继续对这些宗旨进行精炼。一旦团队在 CDP 中添加更多自动化，更多的退出标准将会被自动化工具所评估。例如，在团队对 CDP 足够信任之后，可能不再会有手工检查的需求，相关的退出标准或者将被清除，或酌情被移动到价值流的自动化部分。

总而言之，宗旨和退出标准机制有助于团队建立基本的“道路规则”。在其中，宗旨和退出标准机制中起到了道路护栏的作用，保证工作步入正轨。定义宗旨和退出标准的机制在项目中是一个小的投资，但是它们持续地避免了很多的工作损耗和质量问题。它们也在推进团队正规化为一个互相问责的集体中起到了关键作用。当前除采用自动化之外，我们也使用了上述技术，得以在 2 到 3 月的时间内完全转化原有的团队开发过程，改变了原有过程的产品发布工作流，即需 6 到 9 个月的时间持续地交付细微增量更新到软件的生产环境。