软件项目管理是软件工程学领域重要的组成部分。从过去借鉴工程项目管理的模型，到不断总结经验和，软件项目管理学形成了特有的理论和方式。一方面管理效率
有了很大的提高，另一方面软件项目管理已经从过去单一的针对项目本身，逐渐延伸和融入到企业的管理体系中。笔者结合一定的开发经验，对软件项目管理学的发
展有自己的一些体会，虽然不是创新性的概念和理论，但能从中反映出一些项目管理学在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》
总结
具体项目具体分析，项目管理是实践的理论，无论哪种方法论，对于项目本身而言都具有一定实践意义。软件项目的特殊性，绝对了它的管理方式逐渐走向轻型、灵
活和高度可操作性发展，软件项目管理也逐渐从过去“强”方法论，逐渐走向的“弱”方法论。但这并不意味着软件项目管理不容易控制，不意味着软件项目团队没
有纪律性，相反它发挥了团队的生产力和创造性，提高了软件项目的灵活性和适应性。运用软件开发设计领域的中的一种观点：“高内聚低耦合”，项目管理也类似
的需要“高宽容度低僵硬化”，以适应不断变化的项目环境。