组合拳的力量 - 敏捷精益的混合管理

Posted 2023-04-13

参考技术A 在IT圈有三个最主流的项目管理方式：瀑布管理、敏捷管理和精益管理。一般来讲，三种方式都能找到适应的项目类型，比如：

瀑布管理一般使用于需求明确，预算严格的大型IT项目

敏捷管理一般使用于需求和预算变数较大的中小型IT项目

精益管理一般使用于团队、需求、预算都处于变动中的创业项目，或者成熟产品的运维项目。

看起来似乎是一个一片和谐的情况，但在实际操作中，特别是市场需求瞬息万变，竞争良莠不齐的当下，我们所接手的项目往往都无法套用到某一个类型。面对这些一直处于高度混沌和变化状态的项目的时候，单一的管理方式开始慢慢变得有心无力起来。这个时候，我们便需要引入混合管理的方法。

今天小马哥会讲一讲单纯的敏捷和精益开发的痛点，并介绍一种敏捷精益的混合管理模式。

敏捷管理的痛点

敏捷开发是一套具有高适应性的软件开发模式，它通过把单个项目拆分成迭代的持续交付方式，达到渐进明细的管理手段，从而增加自己对于未知的掌控和缓冲能力。但是，敏捷开发也有自身的一些限制和瓶颈，比如：

痛点一：没有在制品限制（WIP）

敏捷开发提倡建立全功能团队 (cross functional team)，也就是说一个标准敏捷团队里需要有完成软件开发所需的开发、测试、业务分析师、服务设计师等所有角色，并且这些角色在某种程度上可以去承担其他角色的职责。 这样一个团队拥有非常大的优势，它可以给予团队更多的灵活度与韧性，也保证了不同职能之间沟通交流的最大效率化。

然而 最大限度的灵活在另一方面也意味着最大可能性的失控 。举个例子，或许大家在平时的工作中都会有这样的经历：迭代刚开始的时候业务分析师准备了一大堆故事卡，开发们迫不及待的捡了很多卡做，测试们通常无事可做。结果在迭代中后期，大量的故事卡都开发完毕，这时候却发现测试根本忙不过来，闲下来的开发只好临时充当起了测试的职责，帮忙测卡。用户故事墙往往会像这样发展：

这样的开发方式往往会有以下一些缺点：

测试在迭代前中期的 资源无法有效利用

将所有测试 压力都集中在了迭代中后期 ，大大增加了交付的风险，减少了应变的空间。

开发承担测试任务往往会同时 降低开发和测试的效率。

而导致这一痛点的原因非常简单，就是缺乏一个在制品限制去控制在每个开发流程中的带宽，导致团队资源在某一个时间段过度的集中在了单一流程上。

痛点二：难以处理单个迭代期间的需求变化

标准的敏捷开发是以迭代作为最小交付单位的，也就意味着在每一个迭代交付中理论上是不允许需求的增加和改变的，任何的需求变更和蔓延都需要在下一个迭代计划会议（IPM）进行讨论。然而在当下的软件市场环境，想要实现这一点是不可能的。通常在做一些持续时间只有数月的项目的时候，客户的需求几乎随时都在改变，“这个新需求明天要上线，怎么实现我不管”的惨案随时都在发生。

迭代式开发是敏捷管理的底线，如果不跳出盒子思考，在满足客户需求的同时处理紧急的需求变更似乎只剩一个解决方案：妥协。

精益管理的痛点

精益开发的核心工具便是 “看板系统”。 看板系统看似和故事墙很像，但却有以下的一些不同点：

有在制品（WIP）限制；

没有制定任何估算方式，任何一张故事卡都被看做一个可以交付的价值流；

没有迭代的概念，采用拉动式的需求管理方式。也就是说需求的拉入取决于市场或者客户的及时需要。

这样的一种开发方式比起敏捷有着更大的机动和灵活性，可以实时实现高优先级需求的持续交付，但同时它也有着非常明显，甚至致命的痛点：

痛点一：难以估算项目预算

因为没有制定任何的估算方式，所以对于精益开发来讲，估算整个项目的预算几乎是一个不可能完成的任务。通常境况下，我们只能通过专家意见的方式给出一个”最晚交付时间“ 或者 ”大约生产周期“ （lead time） ，并在先设立deadline的情况倒逼项目的交付。在绝大多数项目里这样的方式都是不推荐的，只有一些信仰开发的创业型项目和需求相对简单的运维项目能够稍微较好的实施这种估算方式。

痛点二：进度不知道，报告很难写，经理很着急

这个几乎是所有从事精益开发的项目经理都头痛不已的”无解题“。因为看板系统没有使用任何估算方式，同时也没有迭代的概念，所以项目经理通常只能使用累积流图（CFD）这样的相对工具来展示项目进度：

然而，对于当下众多把ROI，NPV等财务数据挂在嘴边的管理层来说，这种 ”我们一共有X张故事卡，已经做完了X张故事卡“ 的报告方式显然是非常不具备说服力的。 当我们尝试着去量化开发进度，并与财务挂钩的时候，又发现精益开发所收集的数据远远达不到我们的期望。

所以，敏捷和精益开发都不是万能的，它们都会遇到自己的限制和痛点。这个时候，一套组合拳天时地利人和的问世了：

敏捷-精益混合管理

顾名思义，敏捷-精益混合管理便是吸取并结合了敏捷和精益管理的特点，尝试去解决各自痛点的混合式管理形式。概念很简单，让我们 以敏捷管理为基准， 来看看精益原则是如何融入其中的吧。

传统的敏捷开发流程大概是这样的：（再一次，请原谅我拙劣的画工）

在加入了精益管理的概念后，流程大概变成了这样：

具体来讲，针对 传统敏捷管理 来讲，敏捷-精益混合管理大概有这么几个大的改变：

改变一：引入在制品限制 （WIP）

如果你有仔细看小马哥上面叨叨了半天的内容的话，便能理解这个改变是一个理所当然的决定。事实上很多项目经理早就在项目中引入了WIP的概念，去平衡团队的开发资源。一般情况下 WIP的数量应该等同于开发的pair数量，等于测试或者业务分析师的数量。 如果你的团队有4对开发，1对测试和1对业务分析师的话，那拥有WIP的故事墙就应该长这样：

在引入了在制品限制之后，我们便可以去限制资源的过度集中，从而在项目的任何阶段都释放出更多的产能去支持整个故事卡生命周期的交付流程，也为持续改进提供了物质基础，从而大大的降低交付风险。

改变二：弱化迭代概念，重视拉动式计划

在这里需要强调的点是，弱化迭代概念并不是抛弃迭代概念，在敏捷-精益混合开发中，迭代依旧是最小的开发管理周期。那如何理解这个”弱化“呢，主要体现在两点：

允许迭代内的需求改变

引入拉动式计划带来的最大改变便是对于客户需求的及时反馈。在敏捷-精益管理模式中，对于高优先级的需求我们允许直接从backlog拉入迭代，并进入优先交付通道 （快速通道）。进入快速通道的故事卡将会被第一时间处理，它大概长这样：

需要提醒的是，虽然我们允许迭代内的需求改变，但是它必须遵守如下原则：

在快速通道里的故事卡依然要受到WIP的限制，通常我们会block住低优先级的卡转而先完成快速通道里的卡

在迭代内加入的需求必须满足如下两个特点中任意一个 ：1. 高优先级需求； 2. 在当前迭代需求全部提前完成情况下的次优先级需求。

允许一定程度的故事卡滞留（carry over）

很多聪明的小伙伴肯定会问，如果我们允许在迭代内拉入新的需求，那不就造成了需求的蔓延了吗？如何确保团队能够交付本来承诺的故事卡呢？答案便是：我们不强制要求故事卡在每个迭代的交付。这也就意味着，敏捷-精益混合管理允许一定程度的故事卡滞留，通常在20%以下。 当前迭代没有完成的故事卡，在完成基本的记录后，可以滚动到下一个迭代的计划当中。

那聪明的小伙伴又会问了：那这样一来，迭代燃尽图不是就很难看了吗? 我们又怎么确保能够按时完成交付呢？关于这个问题，小马哥的答案是：弱化迭代概念，强调项目的整体交付速率和质量。最直接的办法便是使用燃耗图（burn up chart）而不是燃尽图 （burn down chart）:

燃耗图可以通过对于每个迭代的速率收集对比项目整体的故事点数，进行三点估算（PERT），并预测出可能，乐观和悲观的交付时间。通过对交付时间的预测，项目经理可以一目了然的了解项目当前的健康情况，这种方式比燃尽图更加的全面，并且达到了弱化迭代概念的作用。

最后，我们再来总结一下，看敏捷-精益管理方式是否解决了我们之前的痛点：

敏捷管理痛点一：没有在制品限制（WIP）- 通过引入WIP 解决

敏捷管理痛点二：难以处理单个迭代期间的需求变化 - 通过引入拉动式计划解决

精益管理痛点一：难以估算项目预算 - 通过引入敏捷开发的经典估算方式解决

精益管理痛点二：进度不知道，报告很难写，经理很着急 - 通过引入敏捷开发的燃尽图、燃耗图等传统报告方式解决。

总而言之，敏捷-精益的混合管理方式有着更广泛的适用范围，更少的失败成本，并且提供了更大的效率，是大家都值得在自己项目去尝试的管理方式，快去试试吧！

更多有趣的文章，欢迎来小马哥的 个人网站 ：www.himateng.com

项目管理Scrum vs 瀑布 vs 敏捷 vs 精益 vs看板

软件开发行业有很多不同的方法–一些是旧方法的新方法，另一些方法采用了相对较新的方法。该领域中最常用的两种方法是敏捷，如Scrum，看板和精益等，以及传统的瀑布模型，如结构化方法或更新的RUP。

大多数常规这两种模式的软件公司都认为他们选择的方法在方面是优越的，所以在我们回答这个问题之前，“哪一个更成功？我们应该看看它们的主要区别。

瀑布方法

瀑布是软件开发过程的线性方法。这些都代表了软件开发的一个独特阶段，每个阶段通常在下一个阶段开始之前完成。每个开发阶段之间通常也有一个逐步。

• 结构化为顺序过程中的一个大项目

• 适合变化不常见的情况

• 一个需要预先明确定义的需求的流程

因此，瀑布模型保持只有在检查并验证其前一阶段时才应移动到阶段，如下图所示：

瀑布方法

例如：

在Royce的原始瀑布模型中，按顺序进行以下阶段：

• 系统和软件要求：在产品需求文档中捕获

• 分析：产生模型，架构和业务规则

• 设计：产生软件架构

• 编码：软件的开发，证明和集成

• 测试：缺陷的系统发现和调试

• 操作：完整系统的安装，迁移，支持和维护

敏捷方法

敏捷使用精益思想衍生出来，在信息技术环境中应用“精益”概念。精益方法的关键重点是：

• 消除流程中的浪费

• 开拓地减少业务非增值活动

• 从消费者的角度最大化附加值

敏捷方法

敏捷方法是经过验证的项目管理方法，它鼓励以下关键概念：

• 经常检查和调整

• 鼓励团队合作，自我组织和问责制的领导哲学

• 一套工程最佳实践，可以快速交付纳入的项目

• 一种将开发与客户需求和公司目标相结合的业务方法

敏捷开发–回归生命周期

敏捷开发阶段包括传统规划，分析需求，设计，编码，测试和部署，但它们形成一个循环而不是一条线。这意味着流程灵活，可重复，可以按任何顺序和并行发生。这允许收集用户反馈，针对不同环境的连续测试以及在运行时更改项目的范围。

敏捷方法的基础

• 经验主义–能够在逐步提高发展的过程中执行，停止，反思，改进和继续

• 确定优先级–根据业务价值提供工作

• 自组织–团队最了解如何根据资源和约束提供工作

• 时间拳击 –团队需要在规定的时间内完成指定的任务。

• 协作–团队承诺在给定的交付最终产品，这将鼓励跨团队协作和完成任务的独创性。

敏捷与瀑布–范围，时间和成本三角

瀑布方法的最大优势是固定成本和可预测性。你知道价格，什么时候交付。其最重要的弱点是其缺乏抵抗。敏捷方法非常灵活，可以演变成与最初尝试的产品截然不同的产品。

敏捷与瀑布

传统的瀑布方法建立在时间，成本和范围三重约束的基础上。调整这些变量中的任何一个都会强制改变至少其中一个变量。交付成功的项目改变平衡这三个竞争变量。，实际上，如果在软件项目的后期添加资源，它实际上会产生不利影响。

敏捷方法不是将范围视为一开始就是固定的，而是将时间（转化）和成本（团队成员）设置为固定；敏捷方法采用不同的方法，将三重约束颠倒过来。然后调整范围以关注最高优先级。建立敏捷是因为期望范围会随着时间的推移而发展。目标是在预算成本和及时满足客户最重要的要求。通过项目的进展，敏捷允许新的需求或重新确定优先级。

敏捷与瀑布质量

敏捷还是瀑布？

Standish Group的最新报告涵盖了他们在2013年至2017年间研究的项目。在这段时间内，敏捷和瀑布的成功，挑战和失败的整体突破如下所示，敏捷项目成功的大概是大约的2倍，失败的可能性降低1/3。

（来源：vitalitychicago.com  – 比较瀑布和敏捷项目成功率）

敏捷与瀑布–项目成功率

敏捷方法伞

实际上，敏捷方法只是一种思维方式，可以使团队和组织进行创新，快速响应不断变化的需求，同时降低风险。组织可以灵活地使用多个可用的框架，如Scrum，看板，精益，XP等。

Scrum敏捷伞

精益方法

精益组织了解客户价值，并关注其关键流程以不断提高客户价值。最终目标是通过一个零浪费的完美价值创造过程为客户提供完美的价值。

5步精益方法

指导精益方法实施的五步思考过程很容易记住，但并不总是很容易实现：

1. 从最终客户的角度按产品系列指定值。

2. 确定每个产品系列的价值流中的所有步骤，消除那些无法创造价值的步骤。

3. 使价值创造步骤按顺序进行，使产品顺利流向客户。

4. 随着流量的约会，让客户从下一个上游活动中获取价值。

5. 在指定值时，识别值流，删除浪费的步骤，约会流和拉，再次开始流程并继续，直到达到完美状态，其中创建完美值而没有浪费。

5步精益方法

Scrum方法

使用Scrum进行敏捷软件开发通常被视为一种方法论；但不是将Scrum考虑方法论，还是将其视为管理流程的框架。

Scrum过程画布

看板方法

看板是日本的“视觉信号”或“卡片”。丰田线路工人使用看板来表示制造过程中的步骤。作为精益的一部分，该系统的高度视觉性操纵团队可以更轻松地沟通需要完成的工作和何与scrum sprint board类似地，看板跟踪“做–做–完成”活动，但它限制了“必须的”活动的数量（该数量由团队经理定义，不能超过）。

看板方法

有四个基本的看板原则：

• 可视化工作以增加沟通和协作。

• 限制限制的工作，骨折无限的非优先打开任务链。

• 预期和优化流量，收集指标，预测未来问题。

• 初步通过分析获得持续改进。