超越Scrum，实现企业级敏捷

敏捷给企业带来了快速提升商业价值、帮助客户明确需求、以产品为中心等六大益处。然而，人们往往会集中在团队层面上去介绍敏捷方法。这确实是最容易开始实施敏捷的方法，但团队敏捷不是成熟及发展中企业面临的主要问题，它也不是敏捷的最终目标。

敏捷的真正目标应该是达到企业级敏捷，也就是说，在整个企业实施敏捷。企业级敏捷使企业能够以比竞争对手更快的速度为客户提供质量更高的产品服务，这在任何行业中都是一种强大的竞争优势。

企业级敏捷要求着眼于整个组织的价值流，从最初的概念开始，到客户可以使用该产品为止。为实现企业级敏捷，必须做到以下几点：
•确保将要开发或升级的产品是对公司的盈亏影响最大的产品
•管理组织资源，使资源与升级产品（项目）要相互匹配
•管理项目，以最高的质量和最快的速度去开发产品增强功能
•组织开发团队，使其以最有效的方式协同工作
•使用适当的软件工程方法，该方法既能支持项目管理，又能确保项目的长期可行性，并维持较低的开发成本
•营造学习氛围，使过程不断改进

Scrum是敏捷开发项目中广泛使用的一种方法，能在团队层级有效实施，帮助团队找出项目中存在的障碍并消除它们，但将它作为一种主要方法去指导企业级敏捷实践的时候，却因为远离管理层、无法协同多团队等原因，面临严峻的挑战。精益-敏捷具备更广阔的视角，能助我们逐步实现企业级敏捷，具体可参考我们的电子书：精益数字化转型。

这篇文章中，我重点分享两种相比Scrum更有效的方法，它们源于精益思想和精益生产方法，分别是Scrum#和看板软件工程。

Scrum#（嵌入精益思想的Scrum）

Scrum#是精益背景和观念体系下的Scrum实践。在敏捷转型之初，Scrum#从业者通过遵循以下4项简单实践，可以达到改进团队工作质量、缩短迭代循环实践的效果。

1.及时构建，使用集群
许多团队被及时构建时产生的困难所困扰。所有的编译或链接都可能因为未知的依赖关系而让代码失效，例如，某些团队采用的是旧的API，他们没有发现API已经被修改了。这种情况往往发生在多个团队工作于公益素材，但是彼此之间不同步。一个补救措施是使用团队集群来处理素材。获得有品质的开发的困难通常是集群不够造成的。集群的做法是将所有需要的成员汇集在一起，在同一时间工作在同一素材上，最大可能缩短完成该素材的总体时间。精益方法重视项目总体周期时间，而非个人生产力。

2.定义验收测试优于编写代码
这种做法增强了客户、分析人员、测试人员之间的交流，也有助于测试人员与开发人员之间保持同步。如果开发人员不能在测试人员制定测试方法之前编写代码，那么就需要开发人员在后期帮助测试人员，防止测试过程落后于进度。

3.迭代结束时，所有已启动的素材都要完成
要避免启动新的素材，只是因为这会给开发人员带来障碍。需要新实施敏捷的团队没有意识到，大量存在的WIP对它们本身就是一种障碍。少量、完全完成的素材要好过大量、90%完成的素材——在迭代结束的时候，你无法将一个只完成90%的素材演示给客户。

4.询问好的、可靠的问题
这激发了团队成员去思考关于他们正在做的工作，并且有助于他们学会识别正在做的工作与期望完成的任务之间的差别。

看板软件工程（直接针对工作流）

看板软件工程（简称看板）是一种新的根植于精益思想的软件开发方法。它以长期经验和良好的原则为基础，旨在通过直接管理在制品的价值流来改善产品的流通。比起试图通过短迭代管理价值流的方法，这是一个比较好的方法。

看板软件工程基于下列观点：
•软件开发有关创建和管理知识
•软件开发过程可以用队列和控制回路及相应的管理来描述
•通过系统的信息流必须有一定的代表性

看板软件工作流具体见下图：

多数敏捷团队花费10%~12%的时间将素材分解到功能中并进行评估。看板则通过管理流程来消除这类浪费——仅评估少量素材的成本、整个项目的花费和没有特别价值的工作等。看板从组合团队确定的功能列表中拉出功能，如果你对评估的功能相当确定，那么你可以发现，其实细分素材评估根本没有必要。

看板的真正价值在于，它要求团队创建一个定义明确的规划和有限制的工作流程。这使团队成员能够客观讨论哪些功能应该付出努力，哪些不应该付出努力。也就是说，它有助于团队重视过程，而不是将责任归咎于个人。

看板兼具以下两个工作流：
•基于队列和可控制的回路来定义的工作流
•在工作流的每个步骤中通过限制在制品数量来管理工作流

证据表明，团队不断学看板加快了工作过程的改进，原因如下：
•看板减少了评估每个素材时的恐惧感，这对某些团队来说是一种风险，恐惧总是妨碍学习
•看板明确了一个团队过程而非一个个人过程，突出的是团队的表现而非个人的表现，可以减少遇到困难时的恐惧感。
•看板注重的是工作流过程如何被改进，而非责备某个个人。
•看板能够反映具体措施的实施情况，例如，在制品应该是4个还是5个？在开始时利用看板去反映这种具体的问题相比那些抽象的问题更容易。
•一个开放透明的过程使管理者能够参与其中，并有机会去改进这一过程。

---