浅谈敏捷项目管理在软件开发中的应用

浅谈敏捷项目管理在软件开发中的应用
摘要：本文先介绍了使用传统项目管理技术管理软件开发项目的方法，然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷项目管理进行软件开发的方法。

一、使用传统项目管理技术管理软件开发项目的方法
按照《人月神话》的说法，软件开发是个焦油坑，书店里关于软件开发管理的书籍林良满目，各个软件开发组织也在尝试和应用不同的软件开发管理办法，希望寻找到“软件开发的银弹”。

在软件开发管理中，引入项目管理的办法，已经得到广大软件开发管理人员的一致认同，但对于具体实施何种项目管理办法，各个软件开发组织都有不同的答案，更多的迷茫，因为引入的项目管理办法不能从根本上解决软件开发项目面临的进度拖后、费用超支等问题，软件开发的银弹到底在哪里？
以下是笔者对国内软件开发组织不同项目管理成熟度的归纳和总结，大概可以分如下几类;1)小作坊、混沌形的，这样的组织还处在接单求生存的阶段，管理者还根本没有项目的意识，以满足客户需求、定制开发和回款为第一要务；2）尝试按照项目管理的思路与方法管理软件开发项目，但
发现推行困难，不得要领，目前很多中小型的软件开发组织都处于这个阶段；3）大型的软件企业，已经通过CMM|ISO认证、有足够的资源做保障，实行规范的项目管理做法，如一些软件外包工厂。

本文主要讲述处于第二个层次的软件开发组织的项目管理问题。

软件开发项目管理涉及非常多的内容，从软件开发本身的业务出发，有需求管理、变更控制、配置管理、测试管理、系统分析与设计等；从项目管理的知识领域角度，有范围管理、时间管理、沟通管理、人力资源管理等内容。

按照传统的经典项目管理方法，通过一定的项目管理模板与IT工具，总结多个项目的经验，笔者总结有如下经典步骤来完成项目管理的计划编制与进度控制过程：
计划编制的经典步骤：
①建立企业和项目资源库：这个是进行项目管理的基础工作。

②设置项目日历、资源日历。

③设置项目的主要里程碑点。

④在WBS（工作包）下列出工作清单（Task，Activity）。

工作分解结构（WBS）和作业是进行项目范围管理的途径。

⑤对每个Task估计工期。

⑥连接每个Task间的逻辑关系（SS，FS，FS，FF，延时）。

⑦加载完成每个Task所需要的资源和资源数量。

⑧进度计算后，看开完工里程碑是否符合合同或业主要求，看资源负荷是否过大。

⑨看进度计划是否需要调整。

⑩调整的方法为：压缩关键路径上Task的工期，多投入资源以缩短工期，分解较长工期的作业。

⑾看调整后的进度计划是否合适。

合适的话，则把第一份计划，保存为目标计划（Baseline）。

⑿张榜发布第一版本计划，通知项目干系人。

进度控制的经典步骤：
①确定进度报告的周期，以周计还是以月计。

②下发第一个报告周期内所有成员的Task清单（例如内容、质量要求、时间要求）。

③第一个报告周期结束时，各个成员反馈自己负责的Task实际进展（例如实际开始时间、实际结束时间、完成百分比、尚需工期、本期的资源消耗数量、工作结果的提交）
④汇总各个成员的进度报告，产生实际进度计划。

⑤把实际进度计划与目标计划（Baseline）做对比，监控主要的里程碑点是否还符合业主或合同的要求，周例会上针对每个员工的任务完成情况作对比。

⑥如果不符合，则调整计划，并存储为新的目标计划。

⑦下发下一报告周期项目成员工作内容清单（Task）。

⑧……循环往复，直到项目结束。

计划编制的其他技巧：
①团队成员依据责任分工，协同完成计划编制工作。

②编制多层计划（适用于大型的项目，项目群管理）。

③编制滚动计划（适用于工期很长的项目）。

上述方法对于任何传统项目或IT实施服务项目，都是适用的，而且可以达到很好的项目，也是实施项目管理的必由之路。

笔者对于本事业部所有的IT服务项目，都是使用这个方法进行管理，达到了项目进度控制的目的。

但对于软件开发活动，由于其与传统项目如工程建设项目的显著区别，在应用上述方法与步骤时，往往达不到理想的效果，很多软件开发组织在推行这套管理思路与方法的时候，也遇到了很多困难。

主要表现在：
1）传统项目的时间估算可能存在历史或经验数据，而软件开发的活动工期估算却是因人而异；
2）软件开发包含大量创新性活动，而这些创新性活动很难确定合适的工期；
3）经典的计划编制方法中，强调作业间的依赖性（逻辑关系），以作业间逻辑关系来推算和安排项目进度，而在实际的软件开发活动中，意义不大；
4）新型的软件开发方法，如迭代开发，很难就单个作业（功能点）反馈进度，因为某个功能开发在周期内是反复进行的，进度反馈可操作性差。

5）我们需要反思这样一个问题：“项目管理如何为一个项目增加价值”，因为很多开发人员把项目管理活动如工时填报、进度反馈做为额外的负担，认为项目管理师日常行政管理活动，不为项目增加价值；
反思传统项目管理技术在软件开发活动中的应用，我们发现：这样的做法过于强调计划管理和控制的自动调节模式，而对项目管理应该做的重点―实施―不够重视。

针对软件开发活动，传统计划存在一定的问题：如计划的动机通常来自于项目之外，即制定计划的目的可能是为了满足管理的要求，而不是基于需要完成的工作；制定计划的动机往往与控制欲望有关，而不是与实际工作的实施需要有关；制定计划的人不参与实际工作，项目经理为了控制
目的而制定的、以任务为基础的计划与开发人员的实际工作几乎没有任何联系；站在项目管理的角度，计划和控制成为了焦点，而具体做事被看作是最不重要的，项目任务的合法化优先于产生的结果。

上述问题导致项目管理活动与软件开发的具体活动存在脱节和两层皮的问题，客观上导致了管理费的增加，而看不到项目管理对于项目的真实价值。

二、使用敏捷项目管理的初步实践
在当前的市场条件下，为商业竞争的需要，开发团队必须有以更快的速度开发和交付质量更好、更具客户价值和创新性的产品。

软件开发的方式须由预见性（以计划为推动力）向适应性（对不确定性的探索）转变，以满足客户对创新的不断需求。

与此相适应，项目管理也需要强调速度、机动性和质量，一种区别于传统结构化、改良或创新的项目方法，敏捷项目管理就诞生了。

敏捷项目管理的核心是敏捷软件开发，与传统软件开发模式相比，敏捷软件开发突出如下四点：1）个体和交互胜过过程与工具；2）可以工作的软件胜过面面俱到的文档；3）客户合作胜过合同谈判；4）响应变化胜过遵循计划。

敏捷项目管理是侧重于实施的模式，而不是侧重于计划和控制的模式。

在敏捷项目管理中，项目经理的首要任务是促进产品构想的构思，并指导团队去实现该构想，而不是制定计划和进度表、控制进度，保证“计划”
得以实行。

当然敏捷项目管理不是反对计划的模式。

计划(和控制)是敏捷项目管理的组成部分，只不过它不是重点。

在做好做实需求管理、变更管理、测试管理、配置管理、分析与设计管理等业务的基础上，笔者在自己的团队中推行“以构架为中心、用例驱动、迭代开发”的敏捷项目管理方法。

试图在对传统项目管理方法反思的基础上，提高项目管理活动对于项目成功的真正价值。

“以构架为中心、用例驱动、迭代开发”三句话来自IBM的RUP软件开发过程，是一种重量级的软件开发过程指南。

需要有明确的责任分工和大量的过程文档，显然不适合中小型开发团队。

但却道出了成功进行软件系统开发的核心要素：缺乏良好的构架，软件可维护性差，质量不行；必须是用例（需求）驱动；迭代开发又称增量开发，指构建软件的方式，整个生命周期依次由几个迭代组成，每个迭代是自包含的迷你项目，他们由活动组成，例如，需求分析、设计、编程和测试。

每次迭代之后将产生一个迭代版本，这是一个部分完成的系统，但它是稳定的、完整的和被测试过的。

在流派上，敏捷包括Scrum、极限编程、统一过程（RUP）、Evo等方法。

结合团队实际情况，综合各种方法，进行了如下一些尝试性实践：2）采用迭代的开发方式：我们约定每次小版本的发布周期为1个月，每周进行一次迭代，经过4次迭代，小版本即可发布试用。

每次小版本包括若干需要实现的Feature,在每次迭代中，Feature细化为用户Story,而对于每个Story的实现，则再细化为具体的任务(Task)。

这样的划分，与WBS的
划分基本一致，不同的是，传统项目管理的Task很重要的一个属性是时间，以及作业之间的逻辑关系，而迭代开发中的这种划分，却是为了更好的完成任务，Task使用Size度量工作量的大小，并且使用看板管理每次迭代的总体进度。

3）变传统的计划编制与进度控制模式为直观的看板式管理办法：
通过把Feature、Story、Task以看板的形式，直观的体现在团队成员面前，团队成员可以更好的理解当前任务及进度，并且项目管理不自觉地已经蕴含在日常活动中，项目管理这支手看不不见了，但仍旧在起作用，团队的知识工作者则获得了更好地工作环境，公司获得了更高质量、更及时的的交付产品。

三、总结
通过敏捷项目管理的初步实践，团队的产品交付有了固定的频率，每次迭代出来的都是可以直接交付客户使用的版本，也防止了需求蔓延导致项目进度拖后挫伤成员积极性等事情的发生，极大的提高了团队成员的积极性和生产效率。

PowerOn各个小版本的交付周期平均缩短1.5个月，保证了公司为应对市场变化而提高产品研发效率的战略要求。

敏捷项目管理在传统项目管理的基础上，把项目管理的职能化“有形”为“无形”，适合知识型员工的、带有创新性质的中小型项目，为我们缩短产品交付周期、提高员工积极性，营造良好的团队文化提供了一条新的途径。