敏捷项目管理（基于敏捷项目管理方法的实施方案）

本文目录

• 基于敏捷项目管理方法的实施方案
• 敏捷项目管理是什么
• 一、敏捷价值观和敏捷原则

基于敏捷项目管理方法的实施方案

随着信息技术应用的快速发展，企业信息化面临着前所未有的机遇和挑战。很多IT企业持续致力于信息化产品的特性创新与改进，正在广泛应用敏捷项目管理方法，加速新产品及新功能的开发与上线时间，力求尽快赢得用户市场。根据Gartner 2010年对全球主要软件企业的调查，敏捷项目管理理念已被更多企业所接受，逐渐成为主流的发展趋势。国内外大型企业在信息化建设中也在引入这种方法，但由于各企业信息化建设目标和发展阶段不同，敏捷项目管理实践也呈现定制化的特点。 中国石油信息化建设经历多年发展，积累了丰富的项目管理经验，项目管理方法也在不断优化与提升，但信息化管理也遇到一些共性问题和挑战，比如信息系统通常建设周期较长，投资见效较慢；难以及时响应业务需求的变化，可能影响系统上线后的应用效果，而敏捷项目管理方法正是针对这些共性问题进行较大的改变和提升。中国石油结合自身信息化建设特点，也在逐步探索如何应用这种方法加快信息系统的交付周期，进一步提升信息系统的应用效果。 敏捷项目管理的目标是用最短的时间交付最大的业务价值。它是一种迭代和增量的方法，以小步快跑、高度灵活、与客户频繁互动的方式来管理信息化项目。它通常把一个信息化项目分为多个相互联系，也可独立运行交付的小项目，并按照业务需求优先级，分阶段迭代交付，在此过程中软件一直处于可运行的状态。这种方法具备两大优势：一是通过迭代的方式，分批次发布系统功能，大幅缩减了信息系统交付周期，使信息化投资见效更快；二是本轮迭代发生的需求变更最快能够在下一轮迭代中予以满足，更及时的响应业务需求变化，强化信息系统的上线应用效果。 敏捷项目管理方法迄今已发展为多种具体的实践方式，其中Scrum是目前最主流的指导性与结构性较强的方法框架之一，中国石油信息化项目初步考虑也是基于这种方法框架进行探索和应用。 从角色划分上，Scrum设定了产品负责人、敏捷教练和项目团队三种项目角色，其中由产品负责人确定和澄清需求，控制需求范围和优先级，确保最终交付能够满足需求的产品，这一角色也可由客户或客户代表担任；由敏捷教练指导项目团队进行敏捷实践，协助项目团队解决遇到的问题与障碍；由项目团队负责实现需求，输出可运行的产品增量。 从需求管理上，敏捷项目管理的需求分析是从粗到细、逐步细化的过程，并不是一步到位确定全部需求。产品负责人通过产品列表维护和管理需求，并制定发布计划，明确发布节点和交付功能。虽然产品列表是一个动态的需求列表，但并不意味着需求范围是开口的。敏捷项目管理强调以MVP（Minimum Viable Product）最小化产品范围为中心，MVP是满足用户核心功能需求的最小集合，敏捷项目范围至少应该覆盖MVP的功能范围，在MVP的基本功能被优先满足后，其他功能才被继续考虑，所以需要事先定义MVP，围绕MVP制定计划，以保证按期且在投资预算内快速交付产品，实现预期的投资回报。定义MVP一般将需求划分为四个层次，一是必须完成的功能，否则会影响业务目标实现；二是应该完成的功能，否则会影响业务效率；三是可以完成的功能，主要提升系统功能体验；四是不会完成的功能，不在项目范围之内。因此所谓动态的产品列表只是针对需求细化的过程，新增或变更需求都要经过产品负责人的评审。 从迭代过程上，为快速实现业务需求，Scrum将项目划分为一系列迭代过程，每轮迭代都产生可交付的产品增量。在迭代初期，项目团队召开迭代计划会，从产品列表中挑选优先级最高的需求，共同制定迭代计划，并进行设计、配置开发、测试和集成等工作；在迭代过程中，每日通过站立会议、可视化管理等手段监控项目进度；在迭代后期，项目团队召开迭代评审会和迭代回顾会，分别对产品增量和管理过程进行评审和改进。Scrum方法框架的管理流程如下图1- 12所示：图1- 12 Scrum全视图 从技术架构上，敏捷项目技术架构的形成不同于传统瀑布模式，通常分为顶层概要设计和迭代详细设计两个层面，一方面要保证顶层概要设计的灵活性和可扩展性，另一方面迭代详细设计可适时优化完善顶层概要设计。一般情况下，敏捷项目管理将技术架构设计（顶层概要设计）放在第一轮迭代中完成；详细设计分散到后续每轮迭代过程中完成。总体上，敏捷项目管理并非轻架构设计，而是依然注重架构设计，只是产生架构的方式发生变化。 目前中国石油的信息化项目管理主要是基于传统瀑布模式，通常按阶段以过程为中心控制软件开发过程，项目建设过程一般分为项目启动、需求分析、详细方案设计、系统配置开发与测试、数据准备与用户培训、系统上线、验收等阶段。从项目管理的角度，这种方法有利于大型软件开发过程中人员的组织和管理，为项目设置了清晰的按阶段划分的检查点，严格控制各阶段的评审和交付物，可控性强，但传统瀑布模式的不足主要体现在难以获得用户的即时反馈，在需求分析阶段完成后，对需求变化的响应需依托于详细方案设计、数据准备与用户培训等里程碑节点的意见反馈，从需求调研到系统上线的时间较长，系统上线效果可能受到一定影响。因此，中国石油信息化项目也在探索基于Scrum方法框架的敏捷项目管理方案，但由于中国石油信息化项目规模较大，各领域业务需求复杂，各地区公司需求差异化明显，涉及用户较多，所以敏捷项目管理的应用方案也要结合中国石油信息化的特点和实际情况。      3.1 适用范围分析 敏捷项目管理的优势毋庸置疑，但它并不适用于所有的信息化项目。如果将中国石油信息化项目划分为三类： （1）新建项目； （2）运维项目； （3）功能提升项目，即在运维阶段形成的功能提升或新增资产类项目。 对于功能提升项目，具备前期系统建设的良好基础，用户对已有的系统功能和期望的系统功能均有一定的认识，而且功能提升通常是从业务角度触发的需求，用户的参与程度和配合程度都有较好的应用敏捷项目管理的前提条件，所以初步考虑功能提升项目可应用Scrum方法框架。 对于新建项目，由于中国石油的信息化项目规模较大，在项目初期需求不明确的情况下，对软硬件选型的可扩展性和灵活性都提出了很高的要求和挑战，而且现阶段中国石油敏捷项目管理实践仍处于探索阶段，所以初步考虑新建项目仅在开发阶段引入迭代方式，实现快速交付。 对于运维项目，以日常运维和技术支持为主，系统功能变更较小，所以初步考虑运维项目应用Scrum方法框架的优势并不明显。      3.2 应用方案探讨 结合敏捷项目管理适用范围的分析，在敏捷转型过程中，不同项目不同阶段适合采用不同的敏捷项目管理方案。 方案一： 从需求分析阶段开始的完全敏捷项目管理方案，适合功能提升项目或敏捷应用推广阶段。这种方式与中国石油现行瀑布项目管理的关系和差异，如下图1- 13 所示：图1- 13 完全敏捷项目管理方案 在项目启动阶段，制定项目总体计划，参考Scrum方法框架明确项目人员的角色，开展敏捷项目管理的培训，进行项目准备。 完成项目准备工作后，在具体应用Scrum方法框架时，与瀑布模式不同，不会严格划分项目的各个阶段。由于需求分析是逐步细化的过程，所以在项目初期并不确定所有需求的细节，而是进行总体的需求分析和初步方案设计。后续在每轮迭代过程中，针对本轮迭代计划，需进一步细化需求，开展详细方案设计。因此，需求分析过程分为两个层面，一是明确总体需求范围和优先级，形成以产品列表为主要形式的需求分析报告，制定发布计划；二是进行需求细化，一般率先明确最重要最紧迫的需求，后续根据发布计划在每轮迭代过程中再逐步细化其它需求，补充完善产品列表。方案设计过程也分为两个层面，根据总体的需求分析，进行初步方案设计，主要针对总体技术架构进行设计，后续在每轮迭代过程中进行详细方案设计。在迭代交付过程中，基于本轮迭代详细方案设计的内容，进行配置开发、数据准备、用户培训等工作，实现阶段交付。阶段交付后通过用户反馈还可进一步优化和调整已交付的功能，并在下一轮迭代过程中予以实现。 在验收阶段，由于每轮迭代可能对上一轮迭代的功能进行调整和改进，建议采用最后统一验收的形式。 方案一的优势在于实现快速交付；关键用户全程参与，即时给予反馈，能够紧跟业务需求的变化；相当于对关键用户进行彻底全面的培训，通过关键用户一带多的优势，促进在最终用户端建立自主进行系统运维的团队，降低系统运维的成本。方案一的挑战在于需要关键用户的全程参与和配合，投入较多的时间和精力；对于中国石油目前的信息化内部支持队伍的要求较高，主要体现在需建立跨多功能领域、熟悉敏捷项目管理实践的项目团队；与现行项目管理方式差别最大，存在管理理念的一定冲击。 方案二： 从详细方案设计阶段开始的过渡敏捷项目管理方案，适合功能提升项目或敏捷应用过渡阶段。 在项目启动和需求分析阶段，基本沿用瀑布项目管理方式；在详细方案设计阶段开始应用敏捷项目管理，即按照发布计划，针对每轮发布内容先后进行详细方案设计和迭代交付。这两个阶段结合紧密，循环往复直至迭代交付全部功能，再统一进行验收。这种方式与中国石油现行瀑布项目管理的关系和差异，如下图1- 14 所示：图1- 14 过渡敏捷项目管理方案 方案二旨在进行敏捷项目管理转型的过渡方案，它的优势在于实现快速交付；关键用户过程性参与，及时给予反馈，能够反映业务需求的变化；从项目初期就明确需求，项目可控性加强。方案二的挑战在于对中国石油目前的信息化内部支持队伍的要求仍然较高，主要体现在设计和开发并行，详细方案设计颗粒度要更细；详细方案设计分多次进行，和现行瀑布项目管理方式仍有冲突。 方案三： 从实施阶段开始的试点敏捷项目管理方案，适合新建项目、功能提升项目或敏捷应用试点阶段。在项目启动、需求分析、详细方案设计阶段，基本沿用瀑布项目管理方式；在迭代交付阶段开始应用敏捷项目管理，针对每轮发布内容进行迭代交付，最后进行统一验收。这种方式与中国石油现行瀑布项目管理的关系和差异，如下图1- 15所示：图1- 15 试点敏捷项目管理方案 方案三旨在进行最小化的敏捷项目管理，它的优势在于实现快速交付，同时项目可控性明显加强，是和瀑布项目管理最有效的结合方案，适合敏捷转型初期。方案三的挑战主要体现在由于关键用户前期参与程度不高，用户培训、数据采集分多次进行，需赢得用户对迭代交付的支持和理解。 以上三种方案，在中国石油敏捷转型过程中，都可以根据项目和人员情况灵活选择。从敏捷项目管理的核心价值观上，方案一是最能体现敏捷核心思想的方案，也是应用难度最大的方案，需在具备熟悉敏捷项目管理实践和快速迭代交付能力的项目团队等保障因素的前提下应用；从实际可操作性上，方案三是在现行项目管理模式下，充分实现瀑布和敏捷优势互补、相互促进的最佳方案。因此，初步考虑按以下三个阶段逐步实现过渡和推广，如下图1- 16所示，现阶段按照方案三进行项目试点，应用成熟后，再逐步将方案一或方案二推广到功能提升项目中。 图1- 16 敏捷项目管理转型过程 应用敏捷项目管理的难点主要集中在两方面：一是项目的重要干系人，是否接纳敏捷项目管理理念与实践，是否愿意从时间、精力上配合参与项目，并及时给予反馈意见和建议；二是项目的内部成员，是否熟练掌握敏捷项目管理实践，是否具备积极性与自主性，应对快速交付的压力，能否有效控制项目进度、迭代时间和成本。中国石油大规模敏捷项目团队的管理会更为复杂，针对以上的难点和挑战，获得信息化管理模式的支持、提供人力资源的保障和加强敏捷项目管理培训是促进敏捷项目管理方法落地最核心的三个因素，建议从这三个方面着手保障敏捷转型的成功。 4.1 获得信息化管理模式的支持 敏捷项目管理是一个不断探索直至发现客户真正需要的价值的过程。在敏捷转型过程中，最大的难点通常来源于企业的组织文化和管理要求，并非实际推行的敏捷项目管理实践。大多数企业的敏捷转型是增量和渐进的，尤其是对于中国石油信息化项目规模较大的企业，更是需要循序渐进的完成转变，而且也并不是所有的项目都适用敏捷项目管理方法。建立鼓励快速交付、积极响应需求变化的组织氛围是保证敏捷项目管理方法落地实施的前提保障。从信息化整体的管理模式至项目各阶段的管理模式都要相应调整，从企业层面形成敏捷项目管理的指导意见，甚至给予相关政策鼓励，逐步将敏捷快速交付作为信息化项目的考核评价指标，以获得信息化整体管理模式的支持，这是敏捷项目管理落地实施最重要的保障。      4.2 提供人力资源的保障 从外部资源上，需尽量协调项目的重要干系人深度参与系统建设过程，能够对软件的问题和缺陷进行及时反馈，保证系统设计和开发方向与需求不偏离。从内部资源上，需改变传统的人力资源管理理念，以往倾向于同时赋予员工多项任务，以便获得最大的人力资源价值，但是由于敏捷项目管理的特点，需尽量保证员工在某一个时间段内专注于一个主要信息系统的相关工作。由于敏捷项目管理团队要自组织开展工作，并快速交付可运行的软件，这对项目成员的工作态度、技术能力和团队协作均提出了较高的要求，甚至项目成员可能会不断变换角色，需同时具备设计、开发和测试的能力。最关键的是需具备熟悉敏捷项目管理实践、善于引导项目团队的敏捷教练，对于企业内部的信息化队伍，应逐步培养经过认证的有资质的敏捷教练。      4.3 加强敏捷项目管理培训 在敏捷转型过程中，培训是必不可少的环节，从试点到推广要逐步扩大培训范围，培训内容包括敏捷项目管理理念的培训、Scrum方法框架的培训、产品负责人和敏捷教练的认证培训、敏捷项目管理工具的培训以及与相关项目管理体系的融合培训等。通过培训，有助于项目干系人和项目团队达成共识，提高项目团队敏捷项目管理实践的应用水平，缓解推广敏捷项目管理方法时面临的各种困扰和误解，循序渐进的引导敏捷转型。 如果觉得本篇文章不错就快快分享一下吧

敏捷项目管理是什么

狭义地讲，敏捷企业就是将柔性的先进制造技术、熟练掌握生产技能、有知识的劳动力以及促进企业内部和企业之间的灵活管理三者集成在一起，对千变万化 的市场机会做出快速、有效的响应。敏捷企业强调人、组织和技术的有机结合。通过这三者的紧密结合，敏捷企业可以发挥最佳的整体效益。评价一个企业敏捷性的 具体指标是时间、成本、稳健性（Robustness）和适应范围。对敏捷企业的广义理解，可以认为敏捷企业是一个CIMS（计算机集成制造系统）、动态 联盟、并行工程、仿真制造、高素质员工等多方面的系统集成，是一个基于CIMS、在CMS基础上发展起来的一个更高层次的集成大系统。

一、敏捷价值观和敏捷原则

敏捷价值观有四项内容，即： 1、个人与互动胜过过程与工具 （Individuals and interactions over processes and tools） 在项目管理过程中，过程和工具是比较重要的。在过程、工具和个人、互动相比较，过程、工具就显得没那么重要。这也就是我们常说的：成也萧何，败也萧何。事在人为。天下事，重在商榷。 2、可用的软件胜过复杂的文件 (Working software over comprehensive documentation) 在互联网plus、大数据时代下，通过收集有效数据、信息，再进行汇总、分析、挖掘，项目干系人通过移动端即可实时监控项目进展和状况，这远比复杂的文件更高效。那么，要想实现这一功能，就离不开可用的软件平台。 3、与客户合作胜过合同谈判 (Customer collaboration over contract negotiation) 甲乙双方，在平等互利的基础上，签署合同。换句话说：签订合同，就是在平等的基础上，为了实现双赢。只有彼此合作，才能追求双赢。这也正是项目管理之所以重视沟通的原因所在。 4、响应变更胜过遵循计划 (Responding to change over following a plan) 项目的特征之一就是渐进明细。人们常说：计划赶不上变化快。在规划阶段，不论我们的计划做得多么详细，在实施阶段，总会有意想不到的问题发生。在项目管理过程中，变更在所难免。正确面对变更，是每个项目管理者最睿智的抉择。 敏捷原则共12条，为了更好地理解和掌握敏捷原则，我们把它重新排列归为两类，即成果交付原则（6条）和人员交互原则（6条）。 1、成果交付原则 价值排序，尽早交付 敏捷原则第1条：我们第一优先的任务是，通过尽早且持续交付有价值的软件（系统）来满足客户（Our highest priority is to satisfy the customer through early and continuous delivery of valuable software）。 项目之所以被立项，是因为它有存在的价值。既然项目是有价值的，那么它越早交付，价值呈现越明显。在安排交付顺序（里程碑）时，把握客户的痛点和敏感点，优先交付客户关注的内容，可以尽早、持续地让客户满意，有效降低项目收尾时，客户不满意的风险。 拥抱变化，提高优势 敏捷原则第2条：即使在最后开发阶段，也要竭诚欢迎改变需求，敏捷过程掌控变更，以维护客户的竞争优势（Welcome changing requirement , even late in development . Agile processes harness change for the customer’s competitive advantage）。 在项目管理过程中，既然无法回避变更，那么就该正确面对变更。发生变更，分析变更，做出正确判断，最后执行变更计划。敏捷团队不能坐视问题不管，要敢于迎接改变，尽早修正，让价值最大化、伤害最小化。 持续交付，小步快跑 敏捷原则第3条：经常交付可用的软件（系统），频率可以从数周到数月，以较短的时间间隔为佳（Deliver working software frequently , from a couple of weeks to a couple of months , with a preference to the shorter timescale）。 在项目管理过程，我们与客户沟通，往往出于两种原因：第一种原因是遇到问题，需要沟通、协商、解决，第二种原因是有成果产出，需要用户确认。如果能持续、快速地交付成果给用户，无疑会博得用户的青睐、支持和认可，利于项目工作推进。 成果达成，衡量进度 敏捷原则第7条：可用的软件（系统）是进度的主要测量标准（Working software is the primary measure of progress）。 现在，一些企业实行项目管理考核制，旨在提高项目管理效益，可是人为衡量、鉴定项目的进度，相对困难（延误的借口总会有的），甚至产生意见和分歧。如果能借助相应的管理软件（平台），可以让干系人直观地查看项目进度，回避意见和分歧。 追求卓越，强化敏捷 敏捷原则第9条：持续专注于追求卓越的技术与优良的设计以强化敏捷力（Continuous attention to technical excellence and good design enhances agility）。 精益求精，让敏捷更加敏捷。在发布、迭代的过程中，不断精益设计，卓越产品或成果，产出令用户满意的产品或成果。返工少了，变更少了，项目更敏捷了。 精简产品，杜绝浪费 敏捷原则第10条：精简——精髓是要尽最大的可能，排除不需要做的工作（Simplicity-the art of maximizing the amount of work not done-is essential）。 敏捷管理，虽然以客户为导向，拥抱变更，但是同样要控制范围，尽最大可能排除不需要做的工作。坚决杜绝需求范围蔓延现象。 2、人员交互原则 团队合作，每日互动 敏捷原则第4条：业务人员与开发者在项目进行中，必须每天一起工作（Business people and developers must work together daily throughout the project）。 不论是传统项目管理，还是现代项目管理，甚至敏捷项目管理，都提倡集中办公。不过敏捷管理，要求更加苛刻。敏捷团队成员，必须在一起工作，每天组织15分钟立会。 信任成员，给予支援 敏捷原则第5条：项目靠积极的个人来完成，给予他们所需的环境与支持，并相信他们可以完成工作（Build projects around motivated individuals . Give them the environment and support they need , and trust them to get the job done）。 无数条河流，汇聚成大海。来自不同岗位、技能的成员，组成敏捷团队，共同完成项目工作。相互信任、支持和配合，积极、主动完成工作，加强团队凝聚力，工作就会无坚不摧。领导再像仆人一样提供服务，为团队创造环境，给予支持，项目不敏捷都没人信。 当 面沟通，高效明了 敏捷原则第6条：在开发团队与团队成员之间，面对面的沟通是传播信息最有效率与效能的方式（The most efficient and effective method of conveying information to and within a development team is face-to-face conversation）。 影响沟通效果的因素之一就是距离。如果项目团队成员能面对面沟通，是最高效的沟通方式。 各方成员，稳定节奏 敏捷原则第8条：敏捷过程提倡稳定持续的开发，发起人、开发者及用户都应该能不断地维持稳定的步调（Agile processes promote sustainable development .The sponsors , developers , and users should be able to maintain a constant pace indefinitely）。 敏捷管理，是在愿景、资源和时间明确的条件下，采取的一种高效管理方式。这也就意味着资源不会改变，保证项目时间进度。持续稳定的工作节奏，有利于控制项目的时间进度。项目干系人应该维持稳定的步调，在适当的时机做适当精度的规划、设计，才能按时持续输出可用的阶段成果。 同心协力，自我组织 敏捷原则第11条：最佳的架构、需求及设计皆来自于能自我组织的团队（The best architectures , requirement , and designs emerge from self-organizing teams）。 团结就是力量，这力量能克服各种困难。敏捷团队是自我组织、管理的团队。敏捷项目管理没有明确的架构、需求及设计时间。团队成员同心协力，一起规划、设计，一起完成任务，一起克服困难，一起分享胜利的喜悦。 团队自省，持续改进 敏捷原则第12条：团队定期自省应如何更有效率，并据以调整与修正行为（At regular intervals , the team reflects on how to become more effective , then tunes and adjusts its behavior accordingly）。 笔者提倡精益敏捷管理，也就是说敏捷要建立在精益的基础之上，脱离精益，盲目敏捷，必将造成返工，或者更多的变更。 敏捷团队成员，在追求卓越的同时，要加强学习，定期反省。在提升自己技能的过程中，及时调整与修正自己的行为，才能成为真正的敏捷成员。 以上敏捷价值观和原则，摘自《敏捷项目管理——基础知识与应用实务》。 参考文章:http://blog.sina.com.cn/s/blog_53e932a10102wusx.html