软件项目管理学(SPM)的发展

日期: 2010-08-23 作者:陈祖峰 来源:TechTarget中国 英文

  软件项目管理是软件工程学领域重要的组成部分。从过去借鉴工程项目管理的模型,到不断总结经验和,软件项目管理学形成了特有的理论和方式。一方面管理效率有了很大的提高,另一方面软件项目管理已经从过去单一的针对项目本身,逐渐延伸和融入到企业的管理体系中。笔者结合一定的开发经验,对软件项目管理学的发展有自己的一些体会,虽然不是创新性的概念和理论,但能从中反映出一些项目管理学在IT领域的发展趋势:轻量级,创新性,及充分发挥人的因素。

  传统软件项目管理的问题

  老的软件项目管理方式,是把一个项目拆分为截然不同的阶段,制定详细活动计划并跟踪其实施情况,然后调整计划与实际情况之间的偏差。典型的例子是瀑布模型,这是一种顺序、基于活动的思维定式,核心的行为是从需求收集,到设计编码,到单元测试、整合测试、系统集成,最后是验收,这样逐级的进行。后期工作开始的前提是前期工作的完成,以保证可追溯性。但软件项目实践毕竟与建筑设计不同,据统计,采用传统瀑布模型的软件项目,成功概率仅为10%(具体数据请参考Walker Rocye的《软件开发经济学》)。

  造成成功率的原因是,软件项目具有较大的不确定性和创新性。不确定性来自于客户变化的需求、各种不同利弊的解决方案和计划上的约束(时间、成本、团队和干系人的沟通、质量的主客观因素等等)。

  来看一下瀑布模型的问题。这种传统的项目管理方式,具有一些经典的法则:设计之前需冻结需求,概要设计和详细设计之前不能进行Code工作,编程语言和设计模式是事先确定的,单元测试完成之后才能进行系统集成,文档化设计,质量保证和质量控制团队是相对独立的,所有事情都必须基于计划,Source Code的baseline需要严格控制。

  上述法则中,无疑某些条款对于现在的软件项目管理都具有促进作用,比如源代码的baseline需要严格的审查和控制(事实上这也是每个正式的软件项目都需要版本控制和Code review机制原因)。不过,仔细考虑上述模型,僵硬、灵活性差、高度准确性等问题,都与真实软件项目的特性不默契。严格遵循计划和花大量时间建立精确需求,反而导致了构建系统时,对于系统架构的不全面的理解。其次,项目经理过度关注团队成员的活动,而往往忽视了结果,这容易造成我们花了一年甚至更长时间完成了一个庞大的系统,但最后产出的却是一个失败的产品。

  就如同瀑布模型的名字一样,水向低处流,是不可能回到上游的。

  迭代式开发

  解决传统软件项目管理缺陷的方式是利用用户需求说明书,和重点关注结果而不是团队的活动。这也是迭代软件开发的目标。User case往往来自于候选方案,比如demo。不断演示给客户看的同时,对于需求的明确有很大帮助,每一次增量的结果都是一个更匹配最终成品的需求实现;同时,关注结果的开发就是规模较小的团队在短期内完成一小部分代码,或者实现一部分功能。这就是“迭代”的思想,也是衍生“敏捷”的最初核心思想。

  迭代软件项目管理的优势是:架构优先,及早应对风险,变更控制的重视,各部分的协作增加灵活性,用演示的方式度量项目进度和质量,过程配置管理的伸缩性(因为软件项目的不确定性,任何一个过程都不可能做到适用于任何软件项目,迭代保证了合理配置实用的过程框架,这也容易得到最佳的投资回报)

  在软件项目管理中运用迭代,一个重要思想是尽可能降低软件项目规模和复杂度,虽然这部分依赖于客户需求,但从经济结果上考虑,降低人工编写Code量,提高抽象级别,对于软件项目质量提高、减少返工(rework)都有利。降低复杂度的典型做法是充分理解业务需求,仅交付必不可少的部分;采用代码服用;提高抽象和采用组件技术(这对于工程师的素质和业务能力有更高的要求,但在长期内,进行知识投资的回报率是最高的);缩短发布周期;有条件的采用SOA。等等。

  上述软件项目管理的思想,都比传统模型有了更高的要求,我们需要改进开发的过程,建立业务能力更强的团队和采用集成、自动化的方式提高生产力,并尽可能的采用SOA架构包装复杂性,以降低系统的运营维护成本。这已经超出了软件项目管理本身和业务的层面,对整个企业运营和发展都有很大帮助和提高。

  精益&敏捷

  精益生产(Lean Production)不是一个新名词,它来源于日本丰田公司JIT(Just In Time)生产方式。精益软件开发借鉴了传统工业的思想,从工作环境、团队建设到准时,零库存,再到任务分解,按时提交Code,持续集成,都是极具价值的管理模式。

  精益软件开发的原则是:消除浪费,不做任何无价值的工作,减少重复工作,仅做必须做的;尊重最基层的工作者,比如程序开发者,QC,Build Team等等;不断学习提高;不草率的下结论,任何决策都需要调研,比如需求不清晰时,不估计时间和成本;质量体现在每一个开发过程中,质量是过程的一部分;整体优化而不是局部优化(因为你仅仅优化一个软件Component,而不站在全局的高度去看,则对整体贡献微乎其微)。

  在软件项目管理学发展上,精益软件开发无疑是最大的贡献之一,它强调了项目过程质量,减少的成本浪费,体现了全面质量管理的思想;同时持续改进的原则对于团队建设的意义同样重要。

  其实严格意义上讲,精益软件开发也是敏捷软件开发模型的一种。敏捷(Agile)方法从诞生起就已经改变了整个IT行业,这种思维方式解放了生产力,改变了团队的交付能力,本质上它是迭代模型的深化和革新。在敏捷层面上,测试驱动开发(TDD)、重构(Refactor)、结对编程(Pairing)、持续集成(Continuous Integration)的概念已经逐渐深入人心,是目前最流行的软件项目开发方式。

由于传统软件项目管理的局限性,而迭代项目管理由于进度反馈性较差(某个功能点在一个迭代周期内反复进行,故进度反馈不明确),并且因为软件开发的方式逐渐从预见性(依赖于详细的计划推动)向适应性(不确定性)转变,所以敏捷项目管理逐渐走上前台,成为主流的项目管理方式。

  敏捷项目管理的核心是敏捷软件开发,侧重在实践而并非计划。这种管理模式强调软件产品而不是大量的文档;注重与客户的协作而不是针对合同的谈判;强调拥抱变化和快速响应变化,而不是严格遵守计划。敏捷项目管理对形成良好的团队文化和缩短项目周期有很大作用,更适合创新性的中小型项目(但并不意味着它只能运用在中小型项目中)。

  让敏捷项目管理走上主流地位的,是它新鲜的气息。事实上敏捷理论作用于不同的团队是完全风格迥异的,你可以有任意多种方法论的组合,这样是敏捷能够存在的最主要的原因之一:灵活性。你不会找到条条框框去束缚你的团队这样做那样做,要做的就是在敏捷体系下持续改进。

  Scrum的哲学

  Ken Schwaber首次提出Scrum方法,用橄榄球的名字或许是Mr Ken是个球迷,其实从名字也能多少反映这种项目管理方式的特点:迅速+冲刺。本质上,Scrum也是一种迭代式增量软件开发的过程,它同样是敏捷软件开发模型的一种,相对于大型业务来说,Scrum更适合中小型项目。个人认为,“拥抱变化”和“充分发挥灵活性”是Scrum的关键思想。相对于传统软件项目管理模型的预定义过程控制来说,Scrum是一种依赖于经验性过程控制的理论,强调“检查”和“调整”,强调“沟通”而尽量减少书面流程。

  Scrum周期相当短,一个Sprint也就是数周的时间(一般不超过30天)。这种方法很好的诠释了戴明环(PDCA)的循环,一次Sprint迭代包括计划会议 (Plan)、Sprint期(Do)、评审(Check)和总结(adjust)。在Scrum中,团队的能动性发挥到最大,能极大激发创造性从而提高生产力,项目管理是管理人的艺术,而并非限于项目本身。同时,Scrum中团队沟通通过Daily meeting进行,面对面的方式也减少了沟通途径中的“噪声”。

  Scrum的另一个特色是需求通过User Story体现,这是开发的基础,Team通过User Story拆分Task分配在Sprint中实现。由于User Story的特性体现了INVEST原则(独立、可协商、价值性、可估算、短小、可测试性),在加入到Backlog之后,从需求的理解上为今后的开发测试工作提供了更稳定的基础(应该注意的是User Story需要和需求文档应该达到良好的映射关系),这对于一个迭代乃至整个项目质量而言都具有很大意义。

  Scrum已经逐渐流行开来,虽然还有很多团队在实践中遇到很多困难,比如团队角色安排的问题,进度控制问题,需求文档与Backlog不统一等等。不过随着这种敏捷项目管理方法越来越成熟,相信它能够在中小型软件项目中占据主导地位。

  其它流派

  其实敏捷项目管理的门派还有不少,除了轻量级的Scrum之外,极限编程(XP)、Rational统一过程(RUP)都在有着具体的应用方式,RUP这种重量级的软件开发过程对于大型项目而言更具备稳定性的特点。由于笔者对RUP了解有限,故不作深入探讨。而对于XP,持续集成、结对编程、测试驱动开发的实践模式其实是这种敏捷方法论最早开始使用的,Crisp公司的Henrik Kniberg团队曾尝试过Scrum与XP的结合,更详细的信息可以看看他的那本小书:《硝烟中的Scrum和XP》

  总结

  具体项目具体分析,项目管理是实践的理论,无论哪种方法论,对于项目本身而言都具有一定实践意义。软件项目的特殊性,绝定了它的管理方式逐渐走向轻型、灵活和高度可操作性发展,软件项目管理也逐渐从过去“强”方法论,逐渐走向的“弱”方法论。但这并不意味着软件项目管理不容易控制,不意味着软件项目团队没有纪律性,相反它发挥了团队的生产力和创造性,提高了软件项目的灵活性和适应性。运用软件开发设计领域的中的一种观点:“高内聚低耦合”,项目管理也类似的需要“高宽容度低僵硬化”,以适应不断变化的项目环境。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐

  • 案例解析:变更管理中应用敏捷

    创业公司能从企业CIO那里学到一些东西 ——反过来也一样。Ken Accardi在SearchCIO最近的访谈中表达了这样的观点, 他从CIO转为CEO,有创业公司和企业的经验。

  • 灵活的ITSM平台如何让CIO受益?

    在之前的一篇文章里,TechTarget向大家介绍了CareWorks集团CTO&CIO Bart Murphy对IT服务管理(ITSM )平台的需求,以及他为了让IT团队兴奋起来所做的努力。在本文中,他谈及了如何使用该平台以及它给IT和业务带来的变化。

  • CIO如何协调遗留系统和云服务

    复杂性是敏捷性的敌人,而且还会导致风险。CIO要尽一切可能来避免复杂性,尽力将IT环境简化,以此降低意外发生的概率、提升透明性并促进流程的标准化和流水化。

  • 如果IT部门去制造赛车…….

    我们来假设一下,制造赛车这件事需要 4 个部门。设计团队(相当于 IT 架构师)、制造团队(研发)、安全团队(安全)以及机械师(运营)