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

1、-真理惟一可靠的标准就是永远自相符合浅谈敏捷项目管理在软件开发中的应用摘要：本文先介绍了使用传统项目管理技术管理软件开发项目的方法， 然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷 项目管理进行软件开发的方法。一、使用传统项目管理技术管理软件开发项目的方法按照人月神话的说法，软件开发是个焦油坑，书店里关于软件开发 管理的书籍林良满目，各个软件开发组织也在尝试和应用不同的软件开发管 理办法，希望寻找到 软件开发的银弹在软件开发管理中，引入项目管理的办法，已经得到广大软件开发管理 人员的一致认同，但对于具体实施何种项目管理办法，各个软件开发组织都 有不同的答案，更多的迷茫，因为

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

3、理问题。软件开 发项目管理涉及非常多的内容，从软件开发本身的业务出发，有需求管理、 变更控制、配置管理、测试管理、系统分析与设计等；从项目管理的知识领 域角度，有范围管理、时间管理、沟通管理、人力资源管理等内容。按照传统的经典项目管理方法， 通过一定的项目管理模板与IT工具，总 结多个项目的经验，笔者总结有如下经典步骤来完成项目管理的计划编制与 进度控制过程：计划编制的经典步骤：建立企业和项目资源库：这个是进行项目管理的基础工作。设置项目日历、资源日历。 设置项目的主要里程碑点。 在WBS (工作包)下列出工作清单(Task, Activity)。工作分解结构 (WBS)和作业是进行项目范围管

4、理的途径。对每个Task估计工期。连接每个Task间的逻辑关系(SS FS, FS FF,延时)。加载完成每个Task所需要的资源和资源数量。进度计算后，看开完工里程碑是否符合合同或业主要求，看资源负荷是否过大。看进度计划是否需要调整。调整的方法为：压缩关键路径上 Task的工期，多投入资源以缩短工 期，分解较长工期的作业。(11)看调整后的进度计划是否合适。合适的话，则把第一份计划，保存为 目标计划(Baseline)。张榜发布第一版本计划，通知项目干系人。进度控制的经典步骤：确定进度报告的周期，以周计还是以月计。下发第一个报告周期内所有成员的 Task清单(例如内容、质量要求、 时间要求)

5、。第一个报告周期结束时，各个成员反馈自己负责的Task实际进展(例 如实际开始时间、实际结束时间、完成百分比、尚需工期、本期的资源消耗 数量、工作结果的提交)汇总各个成员的进度报告，产生实际进度计划。 把实际进度计划与目标计划（Baseline）做对比，监控主要的里程碑 点是否还符合业主或合同的要求，周例会上针对每个员工的任务完成情况作 对比。如果不符合，则调整计划，并存储为新的目标计划。下发下一报告周期项目成员工作内容清单（Tas3循环往复，直到项目结束。计划编制的其他技巧：团队成员依据责任分工，协同完成计划编制工作。编制多层计划（适用于大型的项目，项目群管理）。编制滚动计划（适用于工期很长

6、的项目）。上述方法对于任何传统项目或IT实施服务项目，都是适用的，而且可以 达到很好的项目，也是实施项目管理的必由之路。笔者对于本事业部所有的 IT服务项目，都是使用这个方法进行管理，达到了项目进度控制的目的。但 对于软件开发活动，由于其与传统项目如工程建设项目的显著区别，在应用 上述方法与步骤时，往往达不到理想的效果，很多软件开发组织在推行这套 管理思路与方法的时候，也遇到了很多困难。主要表现在：1）传统项目的时间估算可能存在历史或经验数据，而软件开发的活动 工期估算却是因人而异；2）软件开发包含大量创新性活动，而这些创新性活动很难确定合适的 工期；3）经典的计划编制方法中，强调作业间的依赖

7、性（逻辑关系），以作 业间逻辑关系来推算和安排项目进度，而在实际的软件开发活动中，意义不 大；4）新型的软件开发方法，如迭代开发，很难就单个作业（功能点）反 馈进度，因为某个功能开发在周期内是反复进行的，进度反馈可操作性差。5）我们需要反思这样一个问题： 项目管理如何为一个项目增加价值 因为很多开发人员把项目管理活动如工时填报、进度反馈做为额外的负担， 认为项目管理师日常行政管理活动，不为项目增加价值；反思传统项目管理技术在软件开发活动中的应用，我们发现：这样的做 法过于强调计划管理和控制的自动调节模式，而对项目管理应该做的重点 实施一不够重视。针对软件开发活动，传统计划存在一定的问题：如计划

8、的动机通常来自 于项目之外，即制定计划的目的可能是为了满足管理的要求，而不是基于需 要完成的工作；制定计划的动机往往与控制欲望有关，而不是与实际工作的 实施需要有关；制定计划的人不参与实际工作，项目经理为了控制目的而制 定的、以任务为基础的计划与开发人员的实际工作几乎没有任何联系；站在 项目管理的角度，计划和控制成为了焦点，而具体做事被看作是最不重要的, 项目任务的合法化优先于产生的结果。If1-真理惟一可靠的标准就是永远自相符合上述问题导致项目管理活动与软件开发的具体活动存在脱节和两层皮 的问题，客观上导致了管理费的增加，而看不到项目管理对于项目的真实价 值。二、使用敏捷项目管理的初步实践在

9、当前的市场条件下，为商业竞争的需要，开发团队必须有以更快的速 度开发和交付质量更好、更具客户价值和创新性的产品。软件开发的方式须 由预见性（以计划为推动力）向适应性（对不确定性的探索）转变，以满足 客户对创新的不断需求。与此相适应，项目管理也需要强调速度、机动性和 质量，一种区别于传统结构化、改良或创新的项目方法，敏捷项目管理就诞 生了。敏捷项目管理的核心是敏捷软件开发，与传统软件开发模式相比，敏捷 软件开发突出如下四点：1）个体和交互胜过过程与工具；2）可以工作的软 件胜过面面俱到的文档；3）客户合作胜过合同谈判；4）响应变化胜过遵循 计划。敏捷项目管理是侧重于实施的模式，而不是侧重于计划和

10、控制的模式。 在敏捷项目管理中，项目经理的首要任务是促进产品构想的构思，并指导团 队去实现该构想，而不是制定计划和进度表、控制进度，保证计划”得以实行。当然敏捷项目管理不是反对计划的模式。计划 （和控制）是敏捷项目管理 的组成部分，只不过它不是重点。I1f-真理惟一可靠的标准就是永远自相符合在做好做实需求管理、变更管理、测试管理、配置管理、分析与设计管 理等业务的基础上，笔者在自己的团队中推行 以构架为中心、用例驱动、 迭代开发”的敏捷项目管理方法。试图在对传统项目管理方法反思的基础上, 提高项目管理活动对于项目成功的真正价值。以构架为中心、用例驱动、迭代开发”三句话来自旧M的RUP软件开发

11、过程，是一种重量级的软件开发过程指南。需要有明确的责任分工和大量的 过程文档，显然不适合中小型开发团队。但却道出了成功进行软件系统开发 的核心要素：缺乏良好的构架，软件可维护性差，质量不行；必须是用例（需 求）驱动；迭代开发又称增量开发，指构建软件的方式，整个生命周期依次 由几个迭代组成，每个迭代是自包含的迷你项目，他们由活动组成，例如， 需求分析、设计、编程和测试。每次迭代之后将产生一个迭代版本，这是一 个部分完成的系统，但它是稳定的、完整的和被测试过的。在流派上，敏捷包括Scrum、极限编程、统一过程（RUB、Evo等方法。 结合团队实际情况，综合各种方法，进行了如下一些尝试性实践：2）采

12、用迭代的开发方式：我们约定每次小版本的发布周期为1个月，每周进行一次迭代，经过4次迭代，小版本即可发布试用。每次小版本包括 若干需要实现的Feature,在每次迭代中，Feature细化为用户Story,而对于每 个Story的实现，则再细化为具体的任务（Task这样的划分，与 WBS的划 分基本一致，不同的是，传统项目管理的Task很重要的一个属性是时间，以 及作业之间的逻辑关系，而迭代开发中的这种划分，却是为了更好的完成任务，Task使用Size度量工作量的大小，并且使用看板管理每次迭代的总体进 度。3）变传统的计划编制与进度控制模式为直观的看板式管理办法：通过把Feature、Story、Task以看板的形式，直观的体现在团队成员面 前，团队成员可以更好的理解当前任务及进度，并且项目管理不自觉地已经 蕴含在日常活动中，项目管理这支手看不不见了，但仍旧在起作用，团队的 知识工作者则获得了更好地工作环境，公司获得了更高质量、更及时的的交 付产品。三、总结通过敏捷项目管理的初步实践，团队的产品交付有了固定的频率，每次 迭代出来的都是可以直接交付客户使用的版本，也防止了需求