敏捷项目管理.pdf

1. 敏捷项目管理 1.1. 敏捷软件开发之项目管理 1.1.1. 软件开发之项目管理 项目管理是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。软件开发项目的项目管理，是为了确 保软件开发项目顺利进行的各种管理活动的总和。 PMBOK （Project Management Book of Knowledge ）中将项 目管理分为 9 大知识领域 ① . 整合管理 ② . 范围管理 ③ . 时间管理 ④ . 成本管理 ⑤ . 质量管理 ⑥ . 人力资源管理 ⑦ . 沟通管理 ⑧ . 风险管理 ⑨ . 采购管理 至今为止，项目管理往往从这几个方面制定计划，在实施中，检查计划和实施效果的偏差，监控项目的健康状况。 1.1.2. 敏捷软件开发之项目管理 敏捷软件开发的项目管理，是指在敏捷软件开发中进行的项目管理活动。敏捷软件开发，如同第一章所述，是一种 积极拥抱变化的开发模式。敏捷软件开发认可并应对不确定性，换句话说，需要面对风险（根据 PMBOK 的定义， 风险就是不确定性） 。某种程度上，敏捷开发过程就是风险管理的过程。敏捷软件开发的各种实践方法（ Practice ） 就是为了应对各种风险而存在。 敏捷软件开发的项目管理， 其本质在于 - 平衡 （Balance ）为了提升透明度花费的 成本 和因为可能发生变更而带来 的风险 。 敏捷项目管理中，开发流程的概念轻量且抽象。在日新月异的今天，开发流程本身的灵活性显得非常重要。不是用 一个固定的流程来应对变更，而是根据不同环境不同需要裁剪开发流程。从这个意义上来说，只定义必不可少的管 理内容的、轻量级的开发流程是顺应时代需要的。 如果只在传统的 Paradigm 下解读和裁剪敏捷开发的流程，就很容易忘记敏捷开发的本来意义，这是造成敏捷开发 失败的一个主要原因。 对流程的裁剪， 一定要在正确理解敏捷项目管理的意义、 不抹杀 “敏捷”特性的前提下进行。 1.2. 敏捷开发的可交付成果 1.2.1. 不事先规定可交付成果的细节 敏捷软件开发中，品质代表软件与用户需求的匹配程度。不事先规定可交付成果的细节是为了追求更高品质。因为 在开发过程中，需求可能发生变更，可交付成果的内容也可能随之而改变。 敏捷软件开发的特征不仅仅在于能以较低成本应对变更，而是使软件尽可能具有应对变更的能力。敏捷项目管理的 假设是，某个项目难以用传统的流程进行管理。即， Goal 会随着时间的变化而变化。因此，重点在于认识到可能 发生变更的风险，提高应变能力。 但是，通常情况下，人们认为如果可交付成果不断变化，开发可能无法收尾。因此，敏捷项目管理把开发期间分解 成几个短的区间，把每个短区间的可交付成果在一定程度上固定下来。在项目进展过程中，一边听取客户反馈，一 边调整可交付成果。 可交付成果的灵活性要保持在多大程度？这个取决于流程的设计，是敏捷项目管理中非常重要的内容。 1.2.2. 可能发生变更，风险管理怎么办 1.2.2.1. What ’s Risk 有可能发生变更的地方，就存在着各种各样的风险。风险是因为可能发生变更而造成的，所以无论用不用敏捷项目 管理，风险都是存在的。 但是，采用敏捷软件开发和采用传统的瀑布式开发，客户和开发团队所承担的风险是不同的。 首先，传统的管理方法是制定计划，根据执行结果和计划之间的偏差来评估可交付成果。可是因为可能存在变更， 无法严密地定义可交付成果。因此，就出现了以下两种做法： a) 做各种假设，无论如何定义出可交付成果，决定金额和交货期 b) 虽然对可交付成果不是很清楚，但还是决定了金额和交货期 采用方法 a 的话，变更带来的风险由客户承担。即，如果假设和实际不相符，可交付成果和实际的业务需求就不一 致。采用方法 b 的话，开发团队承担仕样变更的风险，因为一边要遵守金额和交货期的约定，一边还要完成可交付 成果的变更。 一般来说，很难让某一方承担全部风险。通常的做法是采用折衷案。即，暂不考虑谁是谁非，客户和开发团队共同 承担上述风险进行项目活动。 敏捷软件开发中，客户和开发团队要一起承担变更可能性带来的风险。客户有责任解释说明并排序选择软件需求。 可是，如果客户不能从开发团队得到有关项目进度的反馈，就无法做合适的判断。这就是沟通上的风险。 另外，事先没有约定可交付成果的细节，因此