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

ssdgh

提到敏捷开发，大家会不约而同的想到开发一个软件产品可以不需要文档、设计和计划；敏捷只是一些优秀实践，或者是优秀实践的结合；敏捷只适用于小项目开发；敏捷只会对研发产生改变；管理者不需要亲自了解敏捷，只需要管理上支持就可以了；引入敏捷只需要按照既定的步骤去做就可以了；敏捷是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以后活动不变。

关于工作说明：

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

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

liwenqi

软件的变更比硬件容易得多，变更的成本较低，因此在整个软件生命周期内变更是非常普遍的

xiaoming11

敏捷是来源于实践的思想和方法体系,特征很明显

MLXG

敏捷是一种思想

showmaker

敏捷更加注重沟通，强调拥抱变化，强调与客户的紧密合作