从管理人员了解敏捷项目管理（一）
前言：
敏捷项目管理在软件刚热门起来的时候就存在了，但一直发展平平，在最近几年开始流行，最终的原因还是因为敏捷项目管理适应了当下社会对于软件快速完成的需求，敏捷最主要的两个特点便是灵活和快速。本文将先从管理人员的角度去阐述为何敏捷项目管理如此受欢迎，同时也是对所读文章进行一个总结。文中若有总结不当的地方，也希望大家批评指正，一起讨论。
目录
1、管理期望
从管理期望来说明其重要性。其实这里的期望也就是说需求，但这里的期望包含了需求之外的无法表达的一部分。以下的几个观点我觉得一个都不能少，每一个都有其独特的说服力。
-
迟到的变更
传统的管理方式的特征是：各个阶段都是由里程碑隔开，阶段与阶段之间通常需要有一个完成信号。这个信号完成标志着进入了下一个阶段，该阶段就算彻底完成了（当然这里所说彻底，大家可以从管理者角度来进行理解下，不要钻牛角尖）。下图就是传统软件的开发方式，诸如需求、分析和设计、编码、测试、部署这样的工程活动分成的各个阶段。
按照这种方式开发，若一个周期为3年的项目，2年后到了测试阶段才发现之前未发现的需求，这岂不要撞墙了，按这种方式我们又得重新设计重新考虑，这是非常困难的。这有两个原因：一个是经济原因，到目前为止这个项目已经花费了所分配的资源中的大部分；另外一个是结构和设计上的原因，它们在构建的时候根本就没有考虑这些需求。
传统模型是在 20 世纪 60 年代开发的，在那个时候统治 IT 王国的是大型计算机。在那个时代所使用的技术并不欢迎变更的到来。那时候编程是过程化的、自上而下的。如果需要变更，就需要重新编译并重新组装整个程序或系统。为了安全起见，每一次编译的成品都需要新的完全测试。这个模型为其特定的技术服务，人们英雄般地尝试一次性地把工作做好。相比之下，现代软件开发通常使用面向对象的技术。这些面向对象的系统是由更小的高度聚合、松散耦合的分块和元素组装起来的。这使开发团队能够以更小的步骤和单元进行开发、测试并集成。由于新的可用技术的存在，我们现在处于一个可以关注现代开发过程及其管理方法的位置上。结果就是，敏捷开发和敏捷项目管理方法更早、更频繁地把变更带入，而且这些方法以小的、循序渐进的步骤来构建软件。
-
需求瘫痪
相比于上面迟到的变更，有些需求由于过于动态或存在矛盾而根本无法解决。在需求总是变化，大家疲于对大的技术规格达成一致的情况下，项目团队将根本无法找到需求阶段的出口在哪儿。让受困于这种事件圈子中的人感到灰心的是，除了文档以外项目团队无法达成任何明确的进展。同时，在你解决歧义问题并完成一个足够稳定的需求范围以便完成这一阶段的过程中，珍贵的时间和资源白白浪费了。这种现象在动态行业中尤其常见，这些行业的变更速率非常高；另外在革新项目中也很常见，这种项目的需求起伏无常。比如传媒业和广告业以及金融业就属于这种动态业务领域。对于这样的情况，需求可谓朝令夕改。基本上，需求瘫痪的问题归根结底只有一个原因：想让需求“确定下来”。
-
二义性
二义性主要是说对文件说明的理解会有不同，不同的人看到或听到一句话，会产生不同的理解。比如说“玛丽有了只小羊羔。”这里的“有了”有可能以许多不同的方式错误地进行解释。她可能怀了只羊羔，拥有一只羊羔或者实际上吃了一只羊羔都是可能的解释。所以消除二义性就必须是*的优先性。二义性代价高昂。比如，Barry Boehm 就有这样的评估：如果在需求阶段所修正的二义性的成本比率为 1，那么在测试阶段发现二义性所造成的修正成本将是这个值的 15～40 倍；如果在部署阶段之后应用程序或系统开始运行时发现二义性，则成本将高达 40～1000 倍。而敏捷开发将保持用户的参与，经常要求涉众按他们的记忆图像对成果进行确认。于是，敏捷开发消除了二义性及其价格标签上的巨大数字。
-
需求太多
在项目确定需求的前期阶段，涉众们需求很多，但他们实际需要的是什么？当对所谓的需求规格按优先级排序时，我们将发现，许多需求可有可无，或者完全超出范围之外。如果给这些功能进行评估，就会发现这个情况特别真实。要记住，需求必须是涉众们的公同需要。而有些需求可能只来自一位涉众，这样的需求必须和其他涉众进行协商，得到他们的接受和确认。对功能的开发要耗费时间和金钱。不仅如此，有些功能根本不值得开发—它们只会占用更重要功能的宝贵时间。许多传统项目会完成对需求的优先级排序和过滤这一步骤。遗憾的是，这一步骤只执行一次。一旦某些需求被认为超过项目的范围，以后要想把它们加入到范围内将会相当费劲。此后，你将看到开放范围的需求管理在敏捷项目管理中的强大之处。你也将看到，真正的需要总能在最终系统中找到自己的位置。
-
需求太少
在项目中，要么有太多需求，需要应付二义性，需要集成并解决迟到的变更，要么需要应付需求瘫痪。接下来我们要讨论的场景可能是传统项目面对的最糟糕的情况：需求太少。具有讽刺意味的是，需求太少是敏捷开发非常善于对付的问题。需求的缺乏对传统项目有巨大的影响。首先，最初的项目范围不能反映涉众真正的需要。其次，评估出来的范围会导致内部的变更控制搅动，因为涉众最终会表达出他们的需要。我们将变更控制搅动看成是在低质量需求基础上的大量变更。许多新发现的需求都是为实际项目之后的所谓改进项目而收集的。这些改进项目对于一个机构而言非常重要，经常是没有它们就无利可图。换言之，改进项目包含“真正的”需求，释放了真实的潜能。我可以想象得出有多少业务潜能隐藏在那些位于“待命”列表的项目中。
如果需求太少，那么要想获得早期或初始的评估，或者对计划进行迭代，都将会是个挑战。然而，事实是，需求终究会出现。在项目要结束的时候需求才出现，这会是传统项目面对的最糟糕的情况。这种情况经常发生在虽然刚刚交付了第一个或主要的版本，而项目团队却得继续为新版本工作时。最可能的情况是，团队所做的、所修补的是一开始没想到的事情。
敏捷项目不追求建立一个完美的需求集合，但你将看到这个模型在开发生命周期的初期动态地吸纳新发现的重要需求的方法。作为结果，敏捷项目的计划将在项目的早期就能够包含新识别的重要需求。
-
变更控制委员会
委员会通常由几个战略项目团队成员组成（比如，项目经理、架构师、主任业务分析师等），它按不同案例决定每个变更请求。CCB 讨论变更请求，提出行动计划并进行投票表决。对于大公司来说，变更控制委员会是必不可少的部门，对于承认变更控制委员会的必要性的机构而言，这是其朝向采用更现代的工程过程所迈出的第一步。这表明机构正在开始接受改变。不过，要决定变更控制委员会是应该每周开一次还是每两周开一次会就能适应动态的要求，对开发人员和业务分析师来说都很难，而敏捷项目管理就能很好的处理变更。
2、上市时间
我们假设有一家公司宣布了一种可以治疗特定病毒感染的药物。由于其市场价值的提升，该公司的股价也许会飞涨。华尔街的银行家们买入的是未来，因为驱动股票价值的是这家公司的潜力。现在，证明自己并把许诺的产品推向市场就是这家公司的责任了。随着项目一天天延期，就可能被其他机构先拔头筹。赛跑从此开始了。
让我们想象一下这种场景。一家机构通过让销售代表直接与客户一起工作的方式提供特定服务与产品。然后，有位业务分析师发现顾客 80%的订单是周期性的并且是相同的。于是就启动了一个 IT 项目，旨在将这个订购过程自动化并对其加速。实现现有业务过程的自动化是软件项目的典型场景。做好了决定并分配了资金之后，就要为开发人员计时了。这些类型的项目的问题在于，IT 项目一直都在追随业务的愿景而很少领先于业务。随着 IT 项目的时间流逝，业务也在演化。最终所交付的完成的系统可能再也无法为业务需要服务。比如，竞争对手也有相似的想法并且在项目开始之后不久就发布了一个相似的系统。于是项目团队就不能忽略这样一个事实：这个项目在内部可能按照正确路线进行，但却落后于市场时间表。
3、革新
这里我用一个简单的话来概述革新对于传统管理和敏捷项目管理的不同：每个公司都知道要创新，但却很难实现创新。
2006 年，在线电影租赁公司 Netfix 在 NPR 宣布，只要有人能将他们的电影推荐系统改进至少 10%就给予 100 万美元的奖金。一年以后，到了 2007 年 11 月，仍旧没有人赢取这项现金大奖。首先，这家公司承认公众在为 Netfix 的顾客推荐电影这项工作上可以做得更好。Netfix也承认它自己无法解决这个问题，这是一个巨大的心理因素。这个例子所涉及的问题要比仅仅从顾客那里收集反馈和想法多得多。这一比赛是要求提供解决某特定问题的聪明的方案。所以计划革新非常困难，但为革新作计划则要简单一些。机构必须创建一个接纳并鼓励创新的环境。传统的描述性的过程模型，其事件流是死板、强制的，不如那些能适应经验的方法易于接纳改变。敏捷方法就是适应性的、接纳革新的方法。
4、资金供给
机构内的资金流的组织一般也是按照传统方式管理项目为目标。当未来的 IT 预算在财务年度的末尾进行计划与协商时，可以对将来项目的投资组合进行估算与评估。其结果将是一个非常静态并且不灵活的财务模型，无法适应新的额外的项目。这种预算过程在财务年度中途非常难以变更，因为最初预算的美元数已经定了下来。而后这些美元将用于所选的项目。毋庸置疑，新的革新的项目必须推迟，因为预算有限。
管理层通常要求有预测和估算的硬数据，而不是按比例增加或减少去年的预算。要满足这种要求就变成和传统需求相似的情况。机构不能确切知道新项目需要什么、什么时候需要、需要多少预算和资源。项目的定义很模糊，而情况总是会变。艾森豪威尔将军曾经说过：“计划毫无价值，但计划的制定则是一切。”这个说法也适用于为项目制定财务计划。
在传统的资金供给过程存在的情况下，出了问题的项目（项目 A）将继续消耗越来越多的资源，因为它一直在推迟。而后续的项目却因为前面项目占用了其所依赖的资源而必须等待。这种问题的原因是，项目处于机构的监控下而且投资了可观的金钱。从组织上说，将项目移开并将资源释放给其他更加有希望的项目将是非常困难的。而敏捷项目允许一个处于动态的项目选择和资金供给过程。