成功的解决方案源于敏捷的项目管理

作者：ESI国际公司

欢迎访问e展厅 展厅 3 管理咨询与服务展厅 企业文化, 战略管理, 生产管理/工业工程, 营销管理, 知识管理, ... 摘要：当今，商业环境充满了活力，却又错综复杂，我们的管理工作也因此而面临一系列的挑战—管理的要求在改变、需求在增高、预算在缩减，需求也快速转变。许多企业正力图实现低投入与高产出—利用更少的资源（包括减少资金，某些情况下还涉及降低劳动力投入）达成同等或更高的目标，因此，对商业运作中的各个环节进行优化（尤其是项目管理）就变得更加重要。对于企业而言，业绩和成果无疑是最终目标—这一点对于国有企业、私营企业，或是非赢利性机构都是不争的事实。 传统的项目管理是可以预测的，且属于任务驱使型。换言之，它将影响项目的环境因素假定为可以预测的。然而敏捷的项目管理则在更多充满不确定性及适应性的项目环境中如鱼得水。它是一个高度迭代和增量的管理过程。在此过程中，客户（最终用户）和项目团队（开展项目管理和商业分析）之间的持续沟通是成功管理的两个内在关键因素。 本文重点讲述了敏捷项目管理框架的使用方法，阐明了此方法实施过程中的主要挑战，并展示了在敏捷环境下项目管理和商业分析所扮演的重要角色。 引言 传统项目交付和敏捷项目交付的原则和方法有本质的相似点—其目标都是交付可衡量的成果。传统项目交付属于“瀑布式”。它假定项目的要求、期望值、周期、活动以及结果等都在实际开展项目活动之前可被准确预测，并有序计划。然而，在实际操作中，下列因素往往会成为传统项目交付的重大限制： 1) 项目早期，客户通常难以清楚地介绍所有关于项目的具体要求。 2) 在项目开展之前的最终目标是制定一份全面的客户要求文档供客户签核。 桑吉夫•奥古斯丁（Sanjiv Augustine）认为，敏捷项目交付“是一种通过适应性计划、快速反馈、不断改进以及紧密的互动和合作来管理项目的方式”。（16）。交付“客户价值”是敏捷式项目交付的关键。协同实施敏捷项目的团队规模较小，通常由客户/最终用户、一名项目经理、一名商业分析师（或担任此角色的其他人员）和专家组成，其中专家可能包括系统开发人员，行业专家，IT建构师以及具备整合项目能力的特殊专才。 什么是敏捷项目管理？ 吉姆•海斯密斯是《敏捷宣言》的创始者之一，也是公认的敏捷方法领域的专家。他将项目管理中的敏捷定义为 “敏捷是为了在多变的商业环境中获益而需具备的一种创造能力和应变能力”、“敏捷是一种平衡灵活与稳定的能力”（16）。 相比传统的项目管理方法，敏捷方法强调的是渐增式交付工作产品或原型，以供客户进行适时评估和优化。所谓的“预测型”项目管理方法认为，所有的要求和活动在项目开始时就能够被加以预测，而敏捷方法则包含了产品开发过程中的所有要素，例如要求、分析、设计、开发以及测试—简而言之，它是一个有规律的重覆工作。每次重覆提交出一个工作产品或原型，并且对这些工作产品或原型的反馈都是对下次交付产品进行改进的重要信息。 敏捷理论认为，改变、改善和附加特征将贯穿整个产品的研发过程，同时理论还认为，每次对产品的修改都不是程序的缺陷，而是一次改进产品的机会，使之更符合其用途和商业目的。 敏捷宣言 二十世纪50年代，传统的项目管理在建筑、工程和国防工业中逐渐浮现。2001年，在一次软件开发先锋和IT产业精英们汇集的会议中，与会者们十分关注怎样为客户创造一个更好的项目管理方法，敏捷项目管理应运而生，成为了21世纪新兴的管理方法。2001年的专家会议上《敏捷宣言》面世，它由一群迭代增量法的倡导者们编撰而成，是敏捷运动的奠基性文件，它与12条敏捷原则一起共同阐述了敏捷项目管理的基础概念，值得一提的是，敏捷项目管理中不仅囊括了项目管理实践的功能，还将项目交付问题上的方方面面也纳入其中，它还包含了所有的商业分析，系统分析和开发工作，以及所有级别的质量保证和测试工作。 在此列出宣言是为了让读者理解“敏捷转型”服务的目标是为了帮助一个组织从现有的项目交付方式过渡至一个与宣言中提到的原则相一致的交付方式（敏捷宣言）。1 敏捷（产品）开发宣言 “通过敏捷管理和帮助他人进行敏捷管理，我们发现了更好的产品开发方式。通过此项工作我们认识到— • 人员和互动比流程和工具更重要。 • 工作产品比详尽的文件更重要。 • 与客户合作比合同磋商更重要。 • 应变能力比遵循计划更重要。 也就是说，虽然右项是有价值的，但相比之下我们认为左项更为重要。” 《敏捷宣言》的原则 • “我们的最高宗旨是通过较早的和不断的交付有价值的[产品]使客户满意。 • 即使是在开发的最后阶段我们也同样欢迎客户对要求的改变。敏捷管理利用其可应变性使客户更具竞争力。 • 应该频繁交付工作产品，时间从两周到两个月不等，越短越好。 • 项目进程中业务人员和开发人员必须每天一起工作。 • 项目应该由积极的人员完成。给予他们所需要的工作环境与支持，相信他们能成功完成工作。 • 面对面的交流，是给开发团队传递信息，也是在团队中传递信息的最有效方式。 • 工作[产品]是项目进展的根本标尺。 • 敏捷管理过程促成了可持续发展。赞助商、研发者和用户间应永远保持步调一致。 • 不断关注能够提高产品质量的优秀技术和设计。 • 简单化处理—最大可能地估算未完成的工作量—这一点十分必要。 • 最好的架构，要求和设计源自於自组的组织团队。 • 团队定期反思如何使自身更具效率，并进行相应的调整。 假定你的项目涉及创新，需要独特的专业知识，以及及时调整的要求，那么敏捷管理方法可以为您提供所需的解决方案。 1 正如海斯密斯在他的《敏捷软件开发》一书中所述，我们在《敏捷宣言》中把“软件”一词替换成了“产品”，使之更大众化。 实施敏捷项目开发和管理框架所面对的关键问题 从传统的产品开发和项目管理方式过渡到敏捷管理方法需要经历实质性的改变。 一些职能工作需要预先安排，例如收集客户需求，制定项目时间表，管理团队和测量进度。敏捷管理方法相对传统方法的不同之处详见表1，它显示 “组织必须重新思考目标，重新配置他们的人员、管理机制及技术组件，以便成功运用敏捷法。”（Nerur等，75） 希望采用敏捷开发和项目管理框架的公司必须克服以下主要挑战： 对敏捷项目管理方法的误解 在关于传统和敏捷方式的驳辩中，两方倡导者都存在许多对对方理论的误解，包括： • 敏捷方法仅仅是稍加伪饰的剽窃 • 运用敏捷方式者关注那些须规避的、不会增加客户价值的要求和设计 • 运用敏捷方式者不做计划 • 敏捷方式与PMI®的《项目管理知识体系指南》(PMBOK® Guide)以及传统的项目管理方式相矛盾 • 敏捷项目管理可以用更少的资源更快完成工作，而且不需要项目经理 项目组合管理 敏捷方式最适合创新性、探索性/实验性、“前所未见”的项目，例如在研发过程中不断出现新要求的新型软件系统，或为适应快速市场变化而进行的新品研发，如消费性电子产品。敏捷方式并不适合于高重复性、有详细文档记录、低变化性及不确定因素少的项目。项目组合管理（PPM）是一种基于标准的决策模型，将稀缺的组织资源分配到最关键的项目集和项目中。公司在其项目组合中必须从不同角度审视传统型和敏捷型项目。传统项目管理依靠陈旧的预测程序、公司年度计划（例如财政季度报表或年度报表）或项目里程碑来提供项目经费，而敏捷项目则根据交付成果以及要求更改逐步提供经费。许多公司在分叉型项目组合上存在管理困难。 组织结构和文化 应该意识到的是，向敏捷框架转型的过程同时也意味着公司文化的转变。由于地理位置、业务类型（产品和服务交付）、组织结构与文化的不同，一些公司能够满腔热情、完美地从传统管理方式顺利过渡到敏捷管理，而也有一些公司则会在这一过程中遇到巨大阻力，还有一些公司甚至根本不适合采用敏捷法。比如说，制度严格、官僚气息浓郁、办事过程繁复且文件要求死板庞杂的机构就容不下敏捷式管理方法，在一个要从传统方式过渡到敏捷方式的公司内部，所要面临的挑战将存在于三个层面： 1. 管理层面 行政和高级管理层的支持对采用敏捷管理至关重要。必须应对的管理问题包括： • 可预测性—传统项目管理经理喜欢在可预见性的环境内工作，这使他们能够罗列具体的要求，制定完整的项目计划，做好预算以及管理资源。敏捷管理则着重于交付客户所需价值，而不是严格遵从程序。相比可预测性和一成不变的程序，它更看重创造力和创新性。 • 充分的时间保证—敏捷方法要求经理们接受并且参与到频繁的协作中，他们可以不用写书面报告，但随时随地都可能需要开会。 • 资源管理—与任务负责人不同，他们必须相信项目团队能够自我指导，当某个团队成员准备好采用敏捷管理时，应该对资源风险具备更大的承受力。 • 风险管理—经理们要接受项目中的不确定性、风险以及成本，摒弃死板的进度表和预算表，避免自我欺骗的盲目乐观或不切实际的管理风格。 • 衡量标尺—经理们应接受这一点，传统方式中对成功或失败的认定在敏捷管理中将会转变，对成功的衡量标准不再是依从计划或严格的变更控制，而是项目团队所交付的成果。对于价值管理，应根据所交付的产品、特征以及功能来衡量，而并非项目团队所完成的任务。 2. 团队层面 有些团队对敏捷管理存在误解，认为敏捷管理团队不做计划、无法估计、不写文件、没有标准，这都是向敏捷管理过渡的主要障碍。 敏捷管理的中心原则是需要高技能的研发者。鉴于敏捷管理团队通常规模较小，能够自我管理和自我约束，因此对团队成员的个人品质有很高的要求。团队成员应喜欢在敏捷环境下工作的各种特殊挑战，摒弃自我中心，应围绕团队成功来考虑问题，乐于在高度透明的环境下工作，让团队其他成员和客户可以看到他们的产品、创造力和勤奋。 3. 干系人/客户层面 客户和干系人会担忧局面会失去控制。他们将失去在传统管理中赖以认定项目进展的标尺。缺乏对时间和成本的估计，使他们无法进行预算和人员分配。对敏捷管理所要求的频繁协作和资源持续可用性，以及这些要求对他们自己工作量的影响，他们心存担忧。而当让客户代表加入敏捷管理后，销售和管理团队也会对“财务管理”有所顾虑。 除了以上三个层面的阻力之外，传统项目管理和传统项目团队在向敏捷管理的转型时也有困难。 项目经理VS项目领导人 传统的项目经理大都利用项目计划来管理三重约束条件（范围、时间和资源），这种方法在敏捷管理团队中需要改变。成功的敏捷项目经理的角色必须从管理者转变为领导人，从监督服从性转变为促进自我指导，从领班转型为创造力和创新精神的助推剂。 分散式资源和虚拟团队 希望采用敏捷管理的组织最为关注的问题是这种管理方式下分散的虚拟团队。交流、协作以及与客户间互动是敏捷管理的重要原则，许多敏捷管理方法中都会要求每日例会，因此，能否通过视频、协作工具以及其他虚拟技术组建起一支跨地区和时区的团队对敏捷管理项目成功至关重要。另外，如果团队中的项目经理和研发者同时从事于多个项目，此方面问题更为堪忧。 运用敏捷项目管理框架的高级方法 为运用敏捷项目管理，企业们必须采取迭代式（或敏捷式）的方式，从而把这种框架引入到其组织机制中。他们必须熟悉敏捷项目管理框架，对自身目前接受敏捷项目管理方法的能力进行评估，进行短期和长期的倡导，并在一段时间内逐步运用这种框架。 了解敏捷项目管理 在实施“敏捷管理转型”前，了解敏捷管理框架、领悟敏捷宣言、并学习敏捷管理相关术语，对于主要行政人员、企业高管及项目经理/领导人至关重要，参加相关课程培训，阅读相关书籍及出版物，以及参阅相应网站资讯（例如，敏捷联盟及项目管理协会PMI®的网站）都是良好的学习途径。 评估组织机制的准备度 对于“我们做好实施敏捷管理项目的准备了么？”这一问题，我们可以通过进行“优劣势”及“组织准备度”评估来找到答案。组织需要对有助或有碍于其转型到敏捷管理模式的各种组织机构因素进行鉴别及评估，高级管理人员需要确定： • 本组织重视创新与创造性胜于组织机制稳定性的程度。 • 就产品相关问题能做出独立决策、而不咨询其他机构。 • 本组织面对不确定性情况时的积极性。 • 本组织能随时为一个项目而非多个项目进行资源分配。 • 能够理解并包容使用多套方法来对项目进展情况进行记录和衡量。 • 与客户间协作性的程度。 评估项目组合 如先前所述，敏捷方法最适合创新型、探索/实验型及“前所未见”型的项目，而不适合重复性、详细记录的、变化性及不定性较低的生产性项目。企业高管及项目经理/领头人应对项目组合进行详细了解，将项目组合一分为二，确定哪些项目适合采用敏捷项目管理，哪些更适合于传统的项目管理框架。 评估项目经理（PM）的准备度 对于“项目经理们是否已对进行敏捷项目做好了准备？”这一问题，答案可通过进行“项目经理准备度”评估得到。高级管理人员、业务经理及所有项目经理都需要确定： • 相比遵从标准项目管理程序，项目经理更加重视客户的程度。 • 相比坚持计划，项目经理更加重视创新及实际操作性的程度。 • 项目经理对充满不确定和变化的环境的适应性。 • 项目经理与所有干系人分享所需信息的技能和承诺。 • 项目经理对团队的投入度，以及促进团队合作的意愿程度。 • 项目经理激励团队，因材委任和充份授权的能力。 评估项目团队的准备度 对于“项目团队是否准备好了在敏捷项目管理中工作？”这一问题，可以通过对各团队成员进行“团队准备度”评估来得到答案。高级管理人员、业务经理及项目经理们需要确定： • 团队成员独立决策的能力。 • 团队成员协作共进，团队合作的能力。 • 团队成员间面对面沟通的程度。 • 干系人乐意并能够成为团队成员的程度。 • 团队成员解决问题及敏捷出新的能力。 • 团队成员在创造项目成果的过程中在应用及工具使用方面的知识和经验。 对现有的产品研发及项目管理方法进行分析 组织的文化、体制及所采用的工作方法都将决定其转型采用敏捷项目管理时所需做出的努力，因此，高级管理人员、业务经理及项目经理必须清楚地认识以下问题： • 正在实施的项目中，哪些现有的程序、工具及模板可运用到敏捷项目管理框架当中？ • 摒弃某些程序及结构将在业务上带来何种影响？ • 将需要投入多少时间和经历来开发新的工具、模板及程序？ • 是否需要对现有用于确定项目成功（或失败）与否的尺度及测算技术做出改变？ • 敏捷项目与传统项目间的报告方法有何不同？ • 干系人及客户会对此项目改变将做出何等反应？ • 敏捷项目管理会为现有的企业文化及组织结构带来怎样的冲击？ 有机的落实：一个小项目，一个团队 一旦企业决定尝试敏捷项目管理，千万不要将这一举措马上转化成大刀阔斧的大规模转型，相反，企业应首先从其“创新型项目组合”中正选出一个小项目来操作（且相对简单的项目），并相应组建一支团队来执行这一项目，在这一举措中将需要为该项目指派出恰当的项目经理（见上文“评估项目经理的准备度”一节）及最有经验的团队成员（见上文“评估项目团队的准备度“一节），一旦组建起团队，首先需要进行正式培训，了解敏捷项目管理的内容定义，然后在赞助者的帮助下，由项目经理领导，采用敏捷法，以一种迭代式方法来操作该项目。 随着项目不断发展，团队及组织应适时召开“总结研讨会”，以提高其在执行敏捷项目管理时的能力，使之更加成熟。随着时间推移，组织可利用其所积累的经验组建起更多此类项目团队使用敏捷项目管理框架来执行更多的项目。 就您的组织而言，您可以自己进行一次内部评估，或者您也可以寻求一些外界帮助来帮您判断出您的组织在实施敏捷项目管理方面的准备度。 为确定敏捷项目管理是否适合您及您的组织，您的准备度评估中还需包括对于“何时会（将要）完成”的理解。“什么样的‘完成’叫完成？”，怎样的特征意味着项目已经完成？正如前文所述，敏捷项目管理注重的是迭代增量式的程序—在项目发起及项目进展过程中贯穿其间的“用户故事”（稍后有更多介绍），如果整个项目过程中所进行的转变、提升及其他特性研发达到了客户的预期愿景，并解决了团队迫切需要解决的问题，则算是成功的达成了目标。敏捷项目管理下的最终产品正是因为一路不断的提升和向其商业目标靠拢才会得以成功。 敏捷项目管理背景下的商业分析和项目管理职能—两方面你是否都需要？ 现在您已经确定敏捷项目管理适合您的项目和需求，让我们来考察下采用敏捷项目管理法的项目中商业分析与项目管理的作用。为分析两者所扮演的不同角色和职能，我们可通过下表回顾敏捷项目管理特征与传统项目管理特征的比较： 记住表中左右两栏所列的特征后，我们需要分析三个词汇—“愿景”、“需求”及“用户故事”，这些是敏捷项目管理的三大组成要素。简而言之，“愿景”所关注的是项目的内容（“视野”），包括项目的目的及预期达成的目标。“需求”则着眼于在理解客户需求的基础上解决问题，达成解决方案或目标。重视需求通常属于商业分析的职能范围。诚如 IIBA® 《商业分析知识体系》® (BABOK® 指南)中所描绘的一样，就“需求”问题，可分为4个大类别和2个子类别： • 业务需求—企业/组织的需求、目的与目标 • 干系人的需求—那些在业务要求与其他类别解决达成条件之间起到连接作用的因素，以及让特定干系人能与解决方案或最终成品间形成互动的因素。 • 解决方案达成条件—达成业务及干系人要求的解决方案的特征或标志，包括： - 功能需求—解决方案所管理的行为及信息 - 非功能需求*—解决方案或最终成品一定能运转的环境条件 • 转变需求—从当前状况转变至将来状态的临时性能力，通常通过解决方案评估及验证来达成 *在传统项目管理中，这一项目通常称作“服务质量”需求 商业分析关注各个级别上需求的搜集、研发及管理等所有方面的问题。如果敏捷项目管理团队具备丰富的经验和积极性来熟练且恰当地履行商业分析职能的话，您就不需要再腾出单独的资源来进行商业分析了，然而，在这之前，对于项目团队专业技术及经验方面的评估（特别是项目管理方面的背景）就变得尤为重要，通过评估，可以确保他们具备对于需求获取、分析及评估方面的技能（构成商业分析人员角色任务的几大关键性因素），所有这些因素在理解用户描述的需求特征时都十分重要。 这就为我们带来了所谓“用户故事”的概念。在采用敏捷项目管理的情况中，“用户故事”一般通过客户叙述，而用户情况搜集会议则由具备商业分析“需求搜集”技能的团队成员负责，此会议可作为项目管理的职能，也可认作是商业分析的职能。“用户故事”重点叙述客户（用户）期望最终产品或解决方案所能达到的或内在具备的特征。这些特征作为产品性能要求（由最终用户或消费者进行评估）包含有一项或多项功能，并同时包括有解决方案的典型特质。客户（用户）首先用简单朴素的方式叙述其期望及需求—“用户故事”，然后通过与客户进行的交流与沟通，团队随即综合用户情况制订出产品或解决方案需要具备的特征。 在用户情况的搜集工作中商业分析起到了什么样的作用呢？在许多案例中，商业分析都作为连接用户需求（也就是干系人的需求）与解决方案提供的性能之间的枢纽，它将用户要求的特征转变为相应的功能需求，此外，就商业术语而言，商业分析还通过在“用户故事”中编入详尽的最终产品或最终可交付条件的功能及特征款项，保证客户能够详细说明他们的需求以及他们所希望达成的业务目标或需求。 正如前文所述，为确保成功，在施行敏捷项目管理前对项目管理团队进行准备度评估是十分重要的，敏捷管理在需求制定与管理问题上充分利用了“用户情况信息”。采用此项团队准备度评估可确保项目团队在敏捷项目管理环境下具备有恰当的经验、领导力及能力。之后，您可以再来确定 “您目前项目中的项目管理和商业分析需要分开成单独的职能来运转，还是将两者结合起来？”，当然这两者在成功的敏捷项目管理中都扮演着不可或缺的角色。 未来就在于此 虽然敏捷项目管理只是软件开发及IT世界的“产物”，但在过去的数年中它已日渐成长，不断进化，毫无疑问，今日的敏捷项目管理法已经在广泛的项目中得以成功应用，用户及干系人早已从中获益良多。敏捷项目管理法是一项最终用户与项目团队共同协作，着眼于项目远景及最终成果的项目管理技术。 参考文献 海史密斯，詹姆士 A.《敏捷项目管理：创建创新性产品》.波士顿：爱迪生-韦斯利出版社，2004年印 《敏捷宣言》.www.agilemanifesto.org.沃德 坎宁安，2001年网络发表 Nerur、 Sridhar、Radhakanta Mahapatra以及George Mangalaraj.《敏捷项目管理方法转变上的挑战》.《美国计算机学会通讯》2005年，第48卷，第5号：75 奥古斯丁，桑吉夫.《掌控敏捷项目》.普伦蒂斯▪霍尔出版社.2005 《商业分析知识体系指南》(BABOK®).2.0版本.国际商业分析协会(IIBA®).2009 Nee，Nancy Y.《确保敏捷项目管理环境下需求汇总成功》 ESI地平线..2009年7月. 网络发表2010年3月15日(end)

文章内容仅供参考 (投稿) (3/14/2011)