浅谈IPD模式下的敏捷软件项目管理

  浅谈IPD模式下的敏捷软件项目管理

 

                                                   汉捷咨询/杨学明

 

 

           华为无线的ROSA-RB项目引进敏捷后：

TR5后遗留问题缺陷率降低了30%

TTM（Time To Market）改进了30%

平均生产率提升了49.6%   

 

-----数据来自华为官网

http://www.huawei.com/cn/publications/view.do?id=3269&cid=5764&pid=87

     汉捷案例：A公司是汉捷的一个客户，成立于1998年，是国内建设领域信息化服务产业的领军软件企业。公司立足工程建设领域，围绕工程项目的全生命周期，为客户提供以工程造价为核心，以工程项目（综合）管理为主体的软件产品和企业信息化整体解决方案。

      2007年，由于产品的BUG比较多，稳定周期相当长，一般正式发布的产品的稳定周期为两到三个月。产品开发完了，测试人员却不敢懈怠，得不断测试，不然不敢交付用户。而且，需求变化快，产品发布后，马上面临修改。答应客户的产品交付时间一推再推。在此形式下，公司高层推动IPD（集成产品开发）体系，但没有收明显的效果，根据汉捷咨询的观察，主要是市场及客户的需求变化太快，难以把握一些新的市场机会点，大家对开发方法不再有信心，研发能力已经无法支撑公司去把握新的市场机会。程序员和测试人员很难有休息的时候，加班强度非常大，产品的发布质量非常糟糕。这让分管研发的副总裁王强压力非常大。

     2008年初，A公司研发副总裁王强意识到问题的严重性，在汉捷咨询的帮助下，推动了IPD加敏捷的项目管理模式，持续关注客户价值，并对研发团队辅以有效的激励措施，内部客户的概念，按照价值链排序，公司内部在自己后面的那个人就是自己的客户，因为他更靠近外部客户，那个人满意是自己重要的考核指标，所以这就使得所有人都主动去想客户为什么不满意。在外部目标统一的情况下，很容易形成一个很好的自适应团队。例如，开发人员为让自己的客户——测试人员满意，就会提前不断与做测试人员和做需求人沟通，提前进行很多开发阶段的质量风险控制活动，如此一来，很多BUG在开发阶段被修正，提高了整个开发过程的效率和质量，让产品开发更敏捷。

    经过两年多的努力，到了2010年，A公司的这种情况却发生了翻天覆地的变化：公司5月在深交所成功上市，预计年产值4亿多元，主要有四条产品线、7个主要产品，种类涵盖管理类、工具类、互联网类，有33万使用者、280个研发人员，产品的发布周期稳定，能全面满足市场营销计划。“从2009年开始，我们全面按100%计划交付，并且有的工具类产品甚至做到了提前交付，甚至还有27个研究、孵化类产品项目积极探寻市场机会。”王强自豪的说。

        提到敏捷开发，大家会不约而同的想到开发一个软件产品可以不需要文档、设计和计划；敏捷只是一些优秀实践，或者是优秀实践的结合；敏捷只适用于小项目开发；敏捷只会对研发产生改变；管理者不需要亲自了解敏捷，只需要管理上支持就可以了；引入敏捷只需要按照既定的步骤去做就可以了；敏捷是CMMI的替代品，是另一种流程……其实，这些观点都是错误的。从上面的案例不难看出，敏捷并不是一种开发流程，汉捷咨询认为，敏捷是一种思想，它是集理念、优秀实践、具体应用于一体的代名词。

        目前，国内很多企业都在推行IPD，IPD更加注重流程，在概念、计划、开发、验证、发布、维护阶段设置阶段性决策点，通过决策点对产品开发做出调整、保证投资收益比和产品的质量。而敏捷开发更加关注在软件研发领域，IPD的思想则是产品运营领域，视角不同，着重点就不同，如果把敏捷比喻成导弹，那么IPD就是原子弹，如果把敏捷比喻为战斗机，那么IPD就是航空母舰。敏捷更加注重沟通，强调拥抱变化，强调与客户的紧密合作。那么，如何在IPD模式下实施敏开发模式呢？

       笔者先后经历过华为和阿里巴巴公司两家大型企业的研发模式，在华为，IPD早已在2001开始推广并使用，到今天走过10个年头，已经根深蒂固, 牢记在每个研发人员心中的就是IPD的六个过程、六个技术评审点（TR）和四个决策评审点（DCP），但对于敏捷开发，早在2006就开始应用，2009才大规模推广，也走过了一段不寻常的历程；在阿里巴巴，作为中国最大的互联网公司之一，大部分的项目采用敏捷开发模式，以客户价值为中心的交付模式早已深入人心。对于IPD与敏捷的结合，许多人仍持质疑的态度，主要表现在：

1）      如何管理企业级敏捷项目，因为几个人的小项目开发好管理，但是要做到多个团队、多个项目、多条产品线敏捷开发的整合管理就不那么容易了；但IPD体系往往是跨团队的，是涉及到多个项目的流程体系，并且涉及到人员较多；

2）      开发人员离职带来的风险很大，因为敏捷的很多信息留在开发者的头脑里，并没有形成像IPD和CMMI要求的那样大量、细致的开发文档，一旦开发人员离职，项目进度以及产品开发和维护的可继承性都将受到很大程度的影响。

      软件开发和硬件开发不一样，软件的变更比硬件容易得多，变更的成本较低，因此在整个软件生命周期内变更是非常普遍的。如果采用原始的瀑布模型，等到所有变更完成测试后，再交付给客户，那么很有可能项目会延期；同时，有很多的潜在需求是在客户看完DEMO后进行明确的，甚至客户提出新的需求，都是基于研发输出的原始版本，在这种背景下，就产生敏捷的最佳实践之一迭代开发。敏捷/迭代开发的核心思想是：聚集客户价值，以客户为中心，交付刚刚好的系统，随时构建立品质量。

华为公司从2009开始，产品研发部正式推行敏捷/迭代开发模式，对于IPD模式下的部分软件项目进行敏捷转型，通过“三步走”的策略，实现人员技能、工程 能力、流程、工具等方面的积累，在风险可控的情况下逐步达到全面敏捷的目标。三步走的内容如下：

1）项目级敏捷：实施的范围限定在TR2—TR4A,聚焦单个项目组或多个项目组或多个项目组协同的开发过程和能力改进；对IPD流程的对外交付点及非研发领域（用服、Marketing等）没影响。

2）版本级敏捷：版本级敏捷实施的范围将扩展到TR1—TR6,对架构、设计、非研发领域协同（用服，Marketing等）等多个方面能力提出了更的要求；版本具备按特性向最终客户分批交付的能力，加快对用户响应速度

    3）产品级敏捷：实施范围扩展到产品的全生命周期（含所有版本），以更小的需求包接纳客户需求，给用户提供更快的市场响应速度，将在规划、组织结构、主流程、市场、财务、供应链、商务等方面带来巨大挑战。

路线图如下：

   

 对上图的说明：

①项目级敏捷：聚集在TR2～TR4A的单个项目组或多个项目组协同的开发过程和能力改进。要求实践：持续集成、开发测试拉通、迭代、回顾会议、自动化测试、站立会议、用户代表参加与现场迭代性验收。建议有如下实践活动：建议实践：引入敏捷团队的PO和Scrum Master角色、结对编程、TDD、特性团队、重构。

好处：1.培养人员，储备敏捷实践技能、带来质量和效率的提升2.激发团队士气，逐步掌握敏捷思想。

②版本级敏捷：1.范围扩展到TR1-TR6；2.具备按特性向用户分批交付的能力，保持一个主干；3.要求系统设计、开发和测试、资料、硬件的协同；4.迭代交付模式的改变带来资料、市场、用服等相应的改变。

要求实践：系统Anatomy、需求管理。

好处：缩短交付周期；降低版本维护成本；提高需求命中率；整个版本的质量和效率提升。

③产品级敏捷：1. 聚焦产品全生命周期；2. 将敏捷精益思想（降低批量、减少任务等待时间）融入到产品端到端流程中；从一个R版本中多个小版本的串行开发转变到基于小需求包的并行开发，并且始终保持一个主干3. 交付周期进一步缩短对组织、流程、财务、供应链、商务等带来影响。

要求实践：可能包含的实践：产品需求管理、版本规划和策略、多个并行需求包开发团队的协同和管理。

好处：全流程角度减少需求等待时间，最限度的缩短TTM，更聚焦客户价值。

      总之，敏捷是来源于实践的思想和方法体系，具备鲜明的实践特征，真正要应用好敏捷开发方法，需要每个人在领会敏捷精髓的基础上，投入到敏捷实践中，在实践中领悟，在实践中升华。敏捷变革过程中必然伴随着困难、彷徨和阵痛，只要秉持开放进取的心态和坚定不移的决心，持续关注人员培养，加强经验交流，精心准备，耐心实施，敏捷就一定能够成功！从敏捷思想起源至今，不论是新兴的互联网公司，软件开发公司，还是以传统IPD流程为主轴的创新型企业，如华为，腾讯，阿里巴巴等，都在推动中国敏捷项目管理前进的步伐，可以预见，在未来的一段时间，敏捷项目管理将是众多管理者必须迈过的一道槛！

 

附件：A公司项目级敏捷过程样例：

   

 

说明：

首轮迭代启动前：

•              需求分析将原始需求细化成Story，并形成产品Backlog；

•              TR1前增加Anatomy活动，将用户需求映射到系统Anatomy图；

•              系统架构设计，输出系统架构，系统设计活动输出DS和模块AR；

•              对于复杂和新增的模块，建议TR2后先完成模块架构设计，再启动迭代开发；

•              版本迭代计划会议输出版本迭代计划和迭代完成标准；

•              无统一TR3点和TR4点，在PDC前增加迭代启动评估活动，评估迭代启动入口条件是否具备。

 

每轮迭代中：

•              项目组迭代计划会议输出迭代Backlog和Story完成标准；

•              迭代0可选，做为特殊迭代，实现代码框架/公用机制部分，验证系统架构和模块架构的可行性；

•              多项目组在版本迭代计划协同下进行迭代开发（周期2-4周），分批实现产品Story；

•              每轮迭代包括Story开发和验证的小循环、迭代内部验收，用户代表现场验收和迭代回顾会议，达到迭代完成标准后再启动下一轮迭代。

所有迭代完成后：

•              TR4A前要进行全系统的功能回归验证；

•              TR4A以后活动不变。

关于工作说明：

•              工作件主要目的是：促进当前项目高效地、准确地沟通；用于智力资产传承，便于后续产品开发和维护；

•              本样例中工作件是推荐的最基础的交付文档。