敏捷管理思考研究报告论文

在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 解决 敏捷管理痛点二：难以处理单个迭代期间的需求变化 - 通过引入拉动式计划解决 精益管理痛点一：难以估算项目预算 - 通过引入敏捷开发的经典估算方式解决 精益管理痛点二：进度不知道，报告很难写，经理很着急 - 通过引入敏捷开发的燃尽图、燃耗图等传统报告方式解决。 总而言之，敏捷-精益的混合管理方式有着更广泛的适用范围，更少的失败成本，并且提供了更大的效率，是大家都值得在自己项目去尝试的管理方式，快去试试吧！ 更多有趣的文章，欢迎来小马哥的 个人网站 ：