敏捷项目管理.docx

敏捷项目管理.docx

《敏捷项目管理.docx》由会员分享，可在线阅读，更多相关《敏捷项目管理.docx（11页珍藏版）》请在冰点文库上搜索。

敏捷项目管理

Companynumber：

【0089WT-8898YT-W8CCB-BUUT-202108】

敏捷项目管理

1.敏捷项目管理

1.1.敏捷软件开发之项目管理

1.1.1.软件开发之项目管理

项目管理是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。

软件开发项目的项目管理，是为了确保软件开发项目顺利进行的各种管理活动的总和。

PMBOK（ProjectManagementBookofKnowledge）中将项目管理分为9大知识领域

1.整合管理

2.范围管理

3.时间管理

4.成本管理

5.质量管理

6.人力资源管理

7.沟通管理

8.风险管理

9.采购管理

至今为止，项目管理往往从这几个方面制定计划，在实施中，检查计划和实施效果的偏差，监控项目的健康状况。

1.1.2.敏捷软件开发之项目管理

敏捷软件开发的项目管理，是指在敏捷软件开发中进行的项目管理活动。

敏捷软件开发，如同第一章所述，是一种积极拥抱变化的开发模式。

敏捷软件开发认可并应对不确定性，换句话说，需要面对风险（根据PMBOK的定义，风险就是不确定性）。

某种程度上，敏捷开发过程就是风险管理的过程。

敏捷软件开发的各种实践方法（Practice）就是为了应对各种风险而存在。

敏捷软件开发的项目管理，其本质在于-平衡（Balance）为了提升透明度花费的成本和因为可能发生变更而带来的风险。

敏捷项目管理中，开发流程的概念轻量且抽象。

在日新月异的今天，开发流程本身的灵活性显得非常重要。

不是用一个固定的流程来应对变更，而是根据不同环境不同需要裁剪开发流程。

从这个意义上来说，只定义必不可少的管理内容的、轻量级的开发流程是顺应时代需要的。

如果只在传统的Paradigm下解读和裁剪敏捷开发的流程，就很容易忘记敏捷开发的本来意义，这是造成敏捷开发失败的一个主要原因。

对流程的裁剪，一定要在正确理解敏捷项目管理的意义、不抹杀“敏捷”特性的前提下进行。

1.2.敏捷开发的可交付成果

1.2.1.不事先规定可交付成果的细节

敏捷软件开发中，品质代表软件与用户需求的匹配程度。

不事先规定可交付成果的细节是为了追求更高品质。

因为在开发过程中，需求可能发生变更，可交付成果的内容也可能随之而改变。

敏捷软件开发的特征不仅仅在于能以较低成本应对变更，而是使软件尽可能具有应对变更的能力。

敏捷项目管理的假设是，某个项目难以用传统的流程进行管理。

即，Goal会随着时间的变化而变化。

因此，重点在于认识到可能发生变更的风险，提高应变能力。

但是，通常情况下，人们认为如果可交付成果不断变化，开发可能无法收尾。

因此，敏捷项目管理把开发期间分解成几个短的区间，把每个短区间的可交付成果在一定程度上固定下来。

在项目进展过程中，一边听取客户反馈，一边调整可交付成果。

可交付成果的灵活性要保持在多大程度这个取决于流程的设计，是敏捷项目管理中非常重要的内容。

1.2.2.可能发生变更，风险管理怎么办

1.2.2.1.What’sRisk

有可能发生变更的地方，就存在着各种各样的风险。

风险是因为可能发生变更而造成的，所以无论用不用敏捷项目管理，风险都是存在的。

但是，采用敏捷软件开发和采用传统的瀑布式开发，客户和开发团队所承担的风险是不同的。

首先，传统的管理方法是制定计划，根据执行结果和计划之间的偏差来评估可交付成果。

可是因为可能存在变更，无法严密地定义可交付成果。

因此，就出现了以下两种做法：

a）做各种假设，无论如何定义出可交付成果，决定金额和交货期

b）虽然对可交付成果不是很清楚，但还是决定了金额和交货期

采用方法a的话，变更带来的风险由客户承担。

即，如果假设和实际不相符，可交付成果和实际的业务需求就不一致。

采用方法b的话，开发团队承担仕样变更的风险，因为一边要遵守金额和交货期的约定，一边还要完成可交付成果的变更。

一般来说，很难让某一方承担全部风险。

通常的做法是采用折衷案。

即，暂不考虑谁是谁非，客户和开发团队共同承担上述风险进行项目活动。

敏捷软件开发中，客户和开发团队要一起承担变更可能性带来的风险。

客户有责任解释说明并排序选择软件需求。

可是，如果客户不能从开发团队得到有关项目进度的反馈，就无法做合适的判断。

这就是沟通上的风险。

另外，事先没有约定可交付成果的细节，因此，项目能够在预算和进度要求内完成的保证就没有了。

开发团队也要充分了解这一风险，并作出应对。

外包公司可能会尽可能降低成本，既满足事先决定的交付期和可交付成果，又使计划和执行之间的Gap转向有利于开发商一方，从而实现利益最大化。

但是，敏捷软件开发中，没有事先约定可交付成果的细节，所以，很可能不存在如上所述的提高利润的空间。

开发商如果采用敏捷软件开发，就要认识到这样的风险，同时最大限度地满足客户需求。

1.2.2.2.怎么降低风险

因为可能存在变更，所以无论采用哪种项目管理方法，都必须承担变更可能性带来的风险。

那么，敏捷项目管理的优点在哪里呢

就在于敏捷项目管理能够应对更多的、可能发生的变更。

因为敏捷软件开发本来就假设软件开发项目中有可能发生变更。

因此，越是深刻理解敏捷软件开发的本质，正确实践，就越能以较少的成本应对可能发生的变更。

与此相对的，瀑布式项目管理没有做这种假设。

从这一点来看，熟练使用敏捷软件开发，可以更迅速更安全地应对变更可能性带来的风险。

更重要的是，当使用敏捷项目管理时，顾客和开发团队之间的风险平衡（RiskBalance）是Win-Win的合作关系。

即，适应变更，拥抱变更的开发使客户得到想要的功能，另一方面，开发团队因客户满意而获得更大收益。

与此相对，瀑布式项目管理在制定计划时，顾客和开发团队之间就形成了一种风险的交易（Tradeoff）。

一旦发生变更，顾客和开发团队在谁承担风险上很容易形成对立关系。

这种对立关系潜在地增加了项目管理的难度。

变更越可能发生，项目管理就越难做。

敏捷项目管理的Point在于顾客和开发团队一起向一个目标奋斗，即提供更能满足用户需要的可交付成果。

消解了对立关系，构筑了一种积极应对变更的合作关系。

这一点，相对于传统的项目管理来说，无论在合同方式，还是在顾客和开发团队间的角色扮演（责任分担）上，都是一种激变吧！

1.3.敏捷项目管理之估算

敏捷项目管理中，计划（Planning）非常重要。

计划之前，开发团队要估算出任务的大小（size）。

这和传统的瀑布式项目管理究竟有何不同呢敏捷软件开发中，估算有两个特征：

一是以顾客能够管理的需求为单位进行估算，另一个是只需估算出需求的相对大小。

关于这两个特征，解说如下。

1.3.1.以客户能够管理的需求为单位进行估算

第一个特征是要义客户能够管理的需求为单位进行估算。

虽然这并非是敏捷项目管理固有的东西，但对于敏捷项目管理来说，至关重要。

因为采用这样的管理方法，顾客可以自主排序选择需求。

首先，敏捷软件开发前，客户有责任准备需求列表。

当然啦，大多数情况下，由开发团队帮客户制作需求列表。

但开发团队要认识到需求列表的制作和管理是顾客的责任。

关于这种需求列表，每种开发方式都有自己的叫法，其中需求的粒度和表现形式也不同。

例如，XP中，有Story。

Scrum中有ProductBacklog。

无论哪种，都是利害关系者期待的软件功能（Feature）。

以客户能够管理的需求为单位进行估算，其本质在于使客户能够判断功能的优先度，以决定每次交付时，软件需要具有什么功能。

1.3.2.只需估算出需求的相对大小

这里的估算并不是项目所需时间（人月）的估算。

因为估算出来的累计时间，很可能因为人力资源等限制，会与实际需要的时间大相径庭。

第二点，需求的相对大小是由经验和感觉得来的，客户比较容易理解，也比较容易操作。

敏捷项目管理的前提是项目的不可预测性。

因此，精细估算得来的计划和概算估算得来的计划，其精度差别不大-都是不确实的计划。

因此，与其在估算上花费成本，倒不如把侧重点放在体制的整备上，以应对意外事态。

敏捷项目管理中，以需求的相对大小为单位进行估算。

这个单位在XP中称作StoryPoint。

1.3.3.也有不能对应的不确定性

敏捷项目管理接受不确定性，需要时，可以调整估算值。

但是，有时，估算阶段的前提条件中，也有一些不得不确定的要素。

这些要素一旦变更，其变更成本往往不可接受。

比较极端的例子，比如，一旦选定某种开发语言，就几乎不可能再变了。

还有，架构的再构也是这样。

因此，事先必须详细调查这些不可更改的因素。

例如，多数情况下，开发团队根据经验定义非功能需求，整理出架构的优缺点，明确其适用范围和潜在风险。

1.4.敏捷项目管理之流程设计

1.4.1.迭代（Iteration）

敏捷项目管理的要点在于能够设计出一个流程以平衡为获取反馈所花费的成本和获得反馈给项目带来的好处。

客户从开发人员那儿得到关于可交付成果的报告，并进行决策。

该决策作为仕样反馈给开发人员。

然后，开发人员基于该仕样改进开发，并继续向客户报告结果。

如此这般，客户和开发人员一边切磋琢磨，一边做出更好的软件。

敏捷软件开发采用迭代（Iteration）管理开发项目工作。

一个迭代，一般持续一周或一个月。

迭代是分配任务和制作可交付成果的管理单位。

迭代的长度一旦决定了，就不再更改。

即，迭代的长度是固定的，不是由分配的任务大小决定的。

Scrum使用Rugby中的术语，每个迭代被称作一个Sprint。

1.4.2.Time-box

Time-box被称作迭代背后的手。

重视人与人之间互动的流程，往往会有规则不够用的缺陷。

这是因为，这种流程的重点在于协调以完成实际的工作，而不是遵守严密的规章制度。

这种流程更接近于管理的本质，但是更难掌控。

激发创造力的交流是必不可少的，但有时候，用于调整的时间无限膨胀，甚至压缩了做实际工作的时间。

例如，长时间的会议和辩论。

的确，各种Session会给参加者带来一定的满足感，但也容易流于为会议而会议的形式主义，或者带来“开会就是完成工作”的虚假的成就感。

更坏的情况时，如果掌控不好，会造成进度迟延、品质低下、以及成本和回报的不平衡。

那么，该如何解决这些问题呢

有一种方法，对各项活动设定了时间，并要求严守结束时间。

即，终了时间必须结束，即使会议的预期可交付成果还处于Inprogress的状态，也要结束，这个预期的可交付成果会成为下一道工序的输入。

这种时间管理方法就叫做Time-box。

Time-box的Point在于并不仓促得出可交付成果。

而是按时间进入下一道工序，得到客户反馈，再返回来，更好地完成可交付成果（由此可见，项目真的是一种目标导向、结果导向的东西）。

重视客户反馈的敏捷项目管理就采用了Time-box，按照定义好的时间，进入下个Step。

1.4.3.任务管理

1.4.3.1.把需求分配到各个迭代

需求是在迭代中实现的。

在哪个迭代中分配哪些需求，一般是按照客户设定的优先度，从高到低地实施。

实际操作时，因为需求的大小不同，而迭代的长度是固定的，所以无法完全按照优先级实施。

另外，客户也不一定会主动设置需求的优先级。

开发团队要在每个迭代开始前，与客户密切交流，让客户发挥主动性选择需求。

1.4.3.2.需求分解成作业项目

敏捷软件开发中，将开发工作细分为任务，每个人自发地选择任务，一项任务完成后，自己再给自己分配下一项任务。

把工作分解到可以分配给个人的程度，叫任务（Task）。

迭代中，要把需求进一步分解为任务，并制成一览表。

然后，通过管理任务的分配，每个人所做的工作都明了可见。

虽然任务需要分配给Team中的某一人，但Team全体对任务负有管理责任。

不依赖于个人能力。

而是通过Team一起管理剩余的任务，以判断迭代内是否能完成计划的可交付成果。

两一方面，通过观察剩余的任务，可以早点发现异常。

设计流程时，一贯的指导思想是：

提高作业透明度，早期发现异常，缩短迭代期间，早期得到反馈。

早期发现问题，早期做出调整，在设计流程的过程中，要时时关注这一机制。

1.5.敏捷项目的交付

1.5.1.多次交付

交付是指在软件开发中，核实可交付成果的行为。

交付是指软件可以开始提供商业服务，或可在公司内部使用，或可开始作为Package产品生产/销售。

对外包公司来说，交付一般就是合同期满的时候，通常只有一次。

但是，如果采用敏捷项目管理，假设软件会随着环境变化和用户需求的变化而发生变化，将会有多次交付。

1.5.2.每个迭代做交付

敏捷项目管理中，我们何时交付软件呢你已经知道，我们是以迭代为单位进行软件开发的。

我们需要在每个迭代结束前，准备可以交付的软件。

敏捷软件开发中，每个迭代的交付是必不可少的Practice。

因为，我们要和客户确认每个迭代的可交付成果，获得客户的反馈，确保项目在正确的方向上运行。

反过来说，正因为敏捷软件开发需要频繁地获取客户反馈，所以要求迭代的时间不能太长。

有时候，一个星期就是一个迭代，这时，我们需要每周交付一次。

普通的开发人员会认为这是不可能的。

因为，交付一般伴随着繁杂的手续，例如，压力测试，审计团队的检查，文档的整备等。

一般认为不满足公司内部的流程，或者不完全满足合同上的要求，就没有达到可以交付的品质。

敏捷项目管理中，每个迭代的交付，会让人想到交付所花费的时间和人力，因此感觉有点不实用。

其实，这只是表达的问题。

敏捷项目管理中“每个迭代的交付”是指使软件达到“可交付的状态”（而不是真正就一次性交付了）。

1.5.3.每个迭代做的简易交付

交付有两种。

一种是每个迭代结束时的简易交付，另一种是作为项目的一个里程碑，即EndUser可以开始使用的正式交付。

1.5.4.简易交付的要求

正式交付的流程和手续由合同和公司规定。

敏捷项目管理中，关键是要定义简易交付的交付条件。

即，正式交付中的要求，有哪些在简易交付中必须满足。

例如：

单元测试在简易交付中必须满足（如果你使用测试驱动开发，必然会有自动化测试）。

那么，结合测试，和性能测试之类怎么办呢每个项目的性质不同，团队的自动化工具的使用情况也不同，有必要对每个项目具体问题具体分析具体判断：

需要把结合测试和性能测试放到简易交付中吗

另外，简易交付的交付条件和迭代的长度也息息相关。

在设计流程时，需要重点讨论简易交付的交付条件。

1.5.5.敏捷软件的文档

1.5.5.1.文档最少化

敏捷软件开发极力排除文档工作。

因为充分交流和代码共享本身可以是项目团队用最少的文档实现仕样传达（Transfer）和共享（Share）。

简单说来，就是不需要，所以不做。

还有其他理由，例如文档的修改成本，例如文档有损圆滑的沟通之类。

。

。

那么，敏捷软件开发中，真的不需要文档吗如果我们正确实践各种Practice，和利益相关者（包括客户）沟通顺利，那么最大可能减少文档也没什么关系。

但是，项目结束时，和利益相关者在默契基础上进行沟通的环境也没有了。

为了和其他项目或者运营团队Transfer，有必要把信息书面化。

除此之外，为了遵守现有的开发流程和公司内部规定，有时候并不特别在意文档自身到底有没有用，也必须把文档准备好。

（用PMBOK里的说法：

更新组织过程资产）

1.5.5.2.在正式交付的迭代准备文档

那么，如何准备文档呢项目里，有一个迭代做正式交付，一般就在那个迭代整理文档。

在正式交付的迭代，团队的工作就是测试、准备文档和交付（notcodecorrection）。

1.5.5.3.正式交付的迭代要做的工作

正式交付的迭代中，团队实施本应在每次交付中实施的，但为了提高开发过程的效率没有实施的所有工作。

例如：

文档、不能自动化的验收测试、内部审计团队的检查、在版本管理系统内做记录等。

1.5.6.敏捷项目管理的交付计划和流程设计

1.5.6.1.简易交付的条件要尽可能与正式交付相近

如何把两种交付结合到一起呢这是敏捷项目管理中，在设计流程时，必须重点考虑的另一个问题。

如果每次简易交付都去满足正式交付所要求的严苛的交付条件，那简易交付的成本会增加，时间会延长，每个迭代中简易交付的工时比例会增加。

如此这般，迭代的时间会变长，反馈的次数就会相对减少了。

如果简易交付只需满足较少的交付条件，我们就可以设计比较短的迭代。

例如，在简易交付中，只包含单体、结合的自动化测试，不包含验收测试。

这样只需较短时间的准备即可完成交付。

既可确保充分的作业时间，也可减少因测试带来的各种修正工作。

因此，简易交付可以频繁地进行。

但这种情况下，一些问题只有到验收测试阶段才能发现。

带着隐藏的问题，做关于下个迭代的决策，风险很高。

最终的交付可能瀑布化。

敏捷项目管理建议简易交付的交付条件应尽可能贴近正式交付。

提高开发工作的透明度，给顾客提供充足的信息，提高获取客户反馈活动的质和量。

1.5.6.2.根据开发团队的技能、体制的完善程度以及顾客的体制做调整

实际上，每个项目要根据开发团队的技能水平、各种体制的完善程度以及顾客的体制，做出必要的调整。

我们要注意平衡简易交付的频繁度和深度，推进自动化的探讨和实践，多下功夫，一点一点提高简易交付的质量。