为什么有些公司敏捷实施不成功？

    介绍

    常听说有公司实施敏捷失败？本文研究探讨了那些经常被忽视，却导致敏捷实施失败的组织级原因，也讨论了为什么这些组织级原因并不是很容易能发现，并提出了一些处理此类组织障碍的潜在策略。本文的目标读者是负责预算的管理人员，尽管技术人员可能也会对此感兴趣。

    敏捷的历史观

    敏捷实践从哪里起源，因何而起源？这个问题将我们的注意力直接转向一些公司的大规模软件开发工作，这些公司要么开拓市场并以出售其软件作为主要收入来源， 要么将它们的定制软件视为其业务的主要竞争优势。我们将此类公司称为X。敏捷不是起源于从事固定报价软件开发工作的公司的IT部门的，而我们把这类公司成为Y。

    为何这个问题重要？

    答案在于X和Y公司是如何从财务角度看待开发工作的。在X公司，软件开发工作被视为一种投资，而且是为公司的未来所做出的首要投资。而在Y公司，开发工作 是小规模的，只是被看成是有时间界限的并需要去跟踪的一笔开销。X公司的经费是划拨给团队，Y公司的经费则是划拨给项目。请将最后这两句话再读一次。

    在X公司，敏捷方法能成功；在Y公司，敏捷方法则将失败。

    在固定报价软件开发中，软件开发工作是要在某个时间点结束的。为了获取项目经费，需要你预先定义范围，进行估算，分配资源，开发，测试，实施，然后将其交给支持部门。这是Y公司所采用的方法。

    而在时间和材料（time and materials）决定经费的情况下，公司做出决定，有必要组建软件开发团队，因为未来会有很多需要开发得很好的项目。他们会在预算期内（1年，2年） 估算可以承受的开发团队大小，并据此分配资源，然后决定项目范围和安排进度。这是X公司所采用的方法。

    发现区别了吗？在X公司，总是有软件在被开发。这一活动没有结束点，团队经费据此划拨。所以，在基于时间盒的迭代中，把任务放入backlog、按优先级排序、进行估算和评审才有意义的。

    而在Y公司中，他们通常只为某个预算期的一些子集（例如3个月）的工作划拨经费。在此之后，就没有更多的钱或者公司不愿再拨出额外款项了。他们不希望维持 一个长期的开发团队，因为他们负担不起，再说也不会有足够的开发工作使团队一直有事可做。因此，就必须通过严格控制和强有力的项目管理来确保3个月后项目能交付。

    从财务角度来看，敏捷是一种奢侈品。它假定你始终有一个软件开发团队，并且总有开发工作。它假定你的团队每年都能得到经费支持，并且你作为管理者，不必担 心需要按单个项目来划拨经费。作为敏捷管理者，你主要关注于日程安排、范围和团队能力。预算是每年或每两年才需要考虑的事情。你根据公司所面临的经济现状 向上或向下调整预算。成功的标准，则主要集中在一段时间内所交付的功能。

    在Y公司，你可能被分配了5万美元，要在3个月内完成项目。制定预算和控制费用至关重要，它们决定项目成功与否。管理者会在资本周期的不同时段得到按照项 目划拨的经费。你可能按时交付了所有功能，但如果超过了预算，也不会被视为一个成功的项目。作为这家公司的一名经理，你需要关注项目管理三角形的方方面面。你的团队可能是临时性的，并由合同工组成。在这种情况下实施敏捷是个错误...甚至可以说是个低级错误。为什么呢？

    估算

    关键在于估算。

    在敏捷软件团队中，只有当你开始工作的时候，你才对其进行估算。就Scrum来说，你仅仅估算下次迭代的工作。因此你怎么能知道产品需要多长时间完成呢？ 你不可能知道。而且，你确实不在乎这点。因为你将持续在每次迭代中交付功能。只要产品经理和QA说你有个足够好的产品，它就可以作为正式版本发布。你也许 有一个猜测值，但是直到团队对它进行估算….你真不知道它还需要多长时间。

    在固定报价项目中….你的估算需要在最开始就进行。公司会问你需要多少经费来构建此应用程序，因为他们不想无休止地资助它。他们希望它能结束….最好是早 一点而不是迟一点。资金是有限的，而且你的项目，虽然可能是必需的，但不会被看作对公司的未来至关重要。它的投资回报率甚至可能为负数。如果你回复公司的 领导者说；“我不知道此产品需要多长时间完成...请为团队提供一年的经费，然后我们看看每次迭代后会它会是什么样子”，那你可就犯错了，其结果很可能是你被解雇了。

    第二种情景中，如果我在取得经费并雇用团队成员后告诉他们：“我们将使用Scrum”。他们将会估算下次迭代的工作。他们会假定他们的估算被认真对待并且你会据此给予他们时间去完成工作，而不管他们的估算是否适合你初始的项目经费。这很公平的，只是不幸的是，你作为管理者将处于难受的位置，因为你需要提交 预算/日程变动，并且/或者要在初始估算被证明为不准确时削减项目范围。最终你无法管理项目还因此得出结论.......“敏捷这事儿行不通”。

    这里的错误在于假定公司的领导者了解并且从上至下地致力于实施Scrum和敏捷原则。从他们要求你估算完成项目所需的经费这一细节，可以察觉出实情与假定大有出入。如果他们问的是，“在后面三年需要多少经费来维持一个软件开发团队？”那么我们就会明智地从敏捷观点出发着手处理了。

    真正难题

    因此，什么才是公司实施敏捷的真正难题？这可以概括成以下几点：

    敏捷假定公司需要长期的软件开发工作而不是短期的项目。

    敏捷经常被公司管理层假定为是一种对预算没有影响的开发流程。但事实并非如此。

    开发团队假定领导者明白实施敏捷对于预算层面意味着什么。

    我们不应低估这些问题的复杂性。开发人员和团队往往对预算毫无概念，所以他们不知道从财务角度是怎么解读敏捷开发的。对于这一点，在网络上很多关于敏捷的 文章中体现得很明显。同样，管理人员往往对开发和特定的敏捷实践一无所知。实施敏捷需要通过培训来减少这两个世界之间的冲突和误解。

    所以，试图在一个固定报价项目中实施敏捷实践会有什么后果呢？本质上，这其实就是给瀑布项目批了层敏捷的“羊皮”。

    故事点

    敏捷团队经常使用故事点来衡量当前工作的复杂性。每次迭代中完成的点数确定了他们的速度（每次迭代点数），同时基于速度可以向管理层提供一个估算，用于表明某个给定的迭代能完成多少工作。

    如果你来自像Y那样的从事固定报价项目的公司，你的第一个问题就是：“这怎样和时间联系起来？又如何计划成本和投资回报率？”事实是：不能。并且也不打算能。重申一下，敏捷学家假定你正在为一个软件开发团队而不是一个软件开发项目提供经费。

    在X公司，你甚至可以用汉堡包或香烟作为参照，来估算每个迭代的工作。这没关系。你总会在某个时间点完成这个产品（根据要求增加/减少功能）。唯一真正的问题是：何时我们能称之为完成然后作为产品发布？团队经费并不取决于工作量的估算。

    而在Y公司，项目经费直接与工作量的估算相关。至关重要的是，我们将其与时间紧密联系起来。因为我们的成本动因往往是以小时来计算的。故事点在这里毫无意义。

    ScrumMaster vs 项目经理

    “敏捷不需要项目经理。”你曾听到过这种说法吗？这种不经意的吓唬会使传统型项目经理提心吊胆。然而，这一说法是对的。如果你假定团队每年都能得到 经费，并且经费不受项目工作量影响，那么组织和管理开发工作就的重点将是技术指导、任务和风险管理。这种情况下根本不需要时间表和预算，ScrumMaster就足够了，他能更好地完成任务。

    不过，如果你在像Y这样非敏捷的公司工作，那么传统的项目管理实践不仅有效，而且对于控制预算和工期偏差来说是必要的。这种情况下，就需要开发团队的领导去尽量节约公司的每一份宝贵资源，并且需要具备一个准CEO的技能。

    在有经费支持的开发团队中，项目经理的角色的确被改变了。而固定报价项目开发团队则没有。

    每日站立会议

    因为种种原因，敏捷使用每日站立会议。这其中包括：激励团队成员、缓解风险、汇报工作、问责、建设团队等。即使在固定报价瀑布式的项目中，这也是个好主 意，没有理由不继续使用这一实践。但从事固定报价项目的团队必须意识到：你并不是在真正地实施敏捷开发，最后期限正在悄悄地逐步逼近。你还可能需要权衡时 间需要。每日站立会议应该很短。但当你只有三个月的经费时，即使每天15分钟也得累计并考虑在总开销之内。

    迭代评审

    有充分经费的敏捷软件团队会渐进式地回答何时能完成产品这个问题。在每次迭代（例如30天）结束后，他们都会进行功能评审，并评估产品发布的准备情况。同 样，这也是个能被用于固定报价项目的好主意，但需要去引导业务负责人理解：迭代评审是一种缓解风险和问责的方法，而不是对已完成产品的演示。

    迭代规划

    迭代规划的确假定你是在一个有经费支持的团队中使用敏捷。它需要确保你的成本已知，预算周期固定，并且团队做出的任何估算都不会严重破坏你的预算。在固定报价项目中使用迭代规划基本上肯定会导致混乱、预算差异、和/或功能丢失。

    燃尽图

    燃尽图展示了一个特定迭代中完成功能的进度。它们是对一段时间内团队业绩的衡量，但并不能用于阐释离项目完成还有多远。如果我们将所有燃尽图都总结在一 起.....它们可能能够说明这一点。但鉴于燃尽图通常被严格地用于衡量项目开发工作量，所以即使这点也并不是总能被做到。

    在固定报价项目中，问题通常不是团队在一个时间段内完成多少功能，这真的不重要，重要的是在经费允许的时间段内所有的功能都必须完成。

    因此，在固定报价项目中使用燃尽图和迭代会向团队和客户传递错误信号。

    总结

    首先，我建议不要试图在固定报价或基于项目划拨经费的情况下尝试实施敏捷。取而代之，作为经理，你应该评估你的公司是否能够支持敏捷实践以及一支人员配备 齐全的开发团队。如果能，那么你应该实施敏捷...它能运作良好；如果不能....那么你最好明智地坚持使用传统项目管理实践。

    如果你确定你的公司有足够资源和工作负荷来支持软件开发工作，但没有使用敏捷，那么问题就涉及到如何使管理层相信敏捷对于开发工作是有意义的。戴顶变革管理和销售的帽子....你会需要它们的。

    其次，项目经理和ScrumMaster不是一成不变的角色和头衔。在一家公司，项目经理/ScrumMaster可能要负责预算；在另一家，他们可能不负责。有时候，在一个传统组织结构的公司 中，他们可能有直接下属；而在另一家，组织结构可能更偏向于矩阵式，项目经理/ScrumMaster没有直接下属。我提到这些差异，是因为有关敏捷的文 章，就像所有的著作，都是从作者的观点出发的来阐述。往往一些在某些情况下能起作用的过程或技术会被拔高说成万能的过程或者技术.......然而实际情 况是该组织和角色都能很好地适应这个过程和技术。如果角色和组织发生了变化，它可能就不会再起作用了。在敏捷vs瀑布开发的博客圈中，这种背景信息经常缺失。

    最后，有关敏捷的争论往往被比喻成一种哲学的战争。但是，从我的经验和角度来看，这种混乱很大程度上是误解的产物。很多时候，一个技术经理并未全面仔细考 虑实施敏捷的商业内涵。同样，业务人员则常将敏捷误解为与他们如何提供经费无关的“一些开发工作”。在我的职业生涯中，很幸运，这两类问题我都遇到过，并 且找到了解决之道。通过这些，我也才深刻地理解了有关预算的假定：这个导致敏捷实施失败却常常不被识别出来的原因。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14639675/viewspace-626036/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14639675/viewspace-626036/