(项目管理)敏捷项目管理.docx
《(项目管理)敏捷项目管理.docx》由会员分享,可在线阅读,更多相关《(项目管理)敏捷项目管理.docx(14页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、1.敏捷项目管理1.1. 敏捷软件开发之项目管理1.1.1. 软件开发之项目管理项目管理是将知识、技能、工具与技术应用于项目活动,以满足项目的要求。软件开发项目的项目管理, 是为了确保软件开发项目顺利进行的各种管理活动的总和。PMBOK ( Project Management Book of Knowledge )中将项目管理分为9大知识领域整合管理范围管理(3).时间管理成本管理质量管理.人力资源管理沟通管理风险管理.采购管理设计流程时,一贯的指导思想是:提高作业透明度,早期发现异常,缩短迭代期间,早期得到反馈。早期发现问题,早期做出调整,在设计流程的过程中,要时时关注这一机制。1.5.
2、敏捷项目的交付1.5.1. 多次交付交付是指在软件开发中,核实可交付成果的行为。交付是指软件可以开始提供商业服务,或可在公司内 部使用,或可开始作为Package产品生产/销售。对外包公司来说,交付一般就是合同期满的时候,通常只有一次。但是,如果采用敏捷项目管理,假设 软件会随着环境变化和用户需求的变化而发生变化,将会有多次交付。1.5.2. 每个迭代做交付敏捷项目管理中,我们何时交付软件呢?你已经知道,我们是以迭代为单位进行软件开发的。我们需要 在每个迭代结束前,准备可以交付的软件。敏捷软件开发中,每个迭代的交付是必不可少的Practice。因为, 我们要和客户确认每个迭代的可交付成果,获得
3、客户的反馈,确保项目在正确的方向上运行。反过来说,正因为敏捷软件开发需要频繁地获取客户反馈,所以要求迭代的时间不能太长。有时候,一 个星期就是一个迭代,这时,我们需要每周交付一次。普通的开发人员会认为这是不可能的。因为,交付一般伴随着繁杂的手续,例如,压力测试,审计团队 的检查,文档的整备等。一般认为不满足公司内部的流程,或者不完全满足合同上的要求,就没有达到可以 交付的品质。敏捷项目管理中,每个迭代的交付,会让人想到交付所花费的时间和人力,因此感觉有点不实用。其实, 这只是表达的问题。敏捷项目管理中每个迭代的交付”是指使软件达到可交付的状态(而不是真正就一 次性交付了1.5.3. 每个迭代做
4、的简易交付交付有两种。一种是每个迭代结束时的简易交付,另一种是作为项目的一个里程碑,即End User可以 开始使用的正式交付。1.5.4. 简易交付的要求正式交付的流程和手续由合同和公司规定。敏捷项目管理中,关键是要定义简易交付的交付条件。即, 正式交付中的要求,有哪些在简易交付中必须满足。例如:单元测试在简易交付中必须满足(如果你使用测试驱动开发,必然会有自动化测试X那么,结合测试,和性能测试之类怎么办呢?每个项目的性质不同,团队的自动化工具的使用情况也不 同,有必要对每个项目具体问题具体分析具体判断:需要把结合测试和性能测试放到简易交付中吗?另外,简易交付的交付条件和迭代的长度也息息相关
5、。在设计流程时,需要重点讨论简易交付的交付条件。1.5.5. 敏捷软件的文档1.5.5.1. 文档最少化敏捷软件开发极力排除文档工作。因为充分交流和代码共享本身可以是项目团队用最少的文档实现仕样 传达(Transfer)和共享(Share 简单说来,就是不需要,所以不做。还有其他理由,例如文档的修改成本,例如文档有损圆滑的沟通之类。O O那么,敏捷软件开发中,真的不需要文档吗?如果我们正确实践各种Practice ,和利益相关者(包括客 户)沟通顺利,那么最大可能减少文档也没什么关系。但是,项目结束时,和利益相关者在默契基础上进行沟通的环境也没有了。为了和其他项目或者运营团 队Transfer
6、,有必要把信息书面化。除此之外,为了遵守现有的开发流程和公司内部规定,有时候并不特别 在意文档自身到底有没有用,也必须把文档准备好。(用PMBOK里的说法:更新组织过程资产)1.5.5.2. 在正式交付的迭代准备文档那么,如何准备文档呢?项目里,有一个迭代做正式交付,一般就在那个迭代整理文档。在正式交付的 迭代,团队的工作就是测试、准备文档和交付(not code correction X1.5.53.正式交付的迭代要做的工作正式交付的迭代中,团队实施本应在每次交付中实施的,但为了提高开发过程的效率没有实施的所有工 作。例如:文档、不能自动化的验收测试、内部审计团队的检查、在版本管理系统内做记
7、录等。1.5.6.敏捷项目管理的交付计划和流程设计1.5.6.1. 简易交付的条件要尽可能与正式交付相近如何把两种交付结合到一起呢?这是敏捷项目管理中,在设计流程时,必须重点考虑的另一个问题。如果每次简易交付都去满足正式交付所要求的严苛的交付条件,那简易交付的成本会增加,时间会延长, 每个迭代中简易交付的工时比例会增加。如此这般,迭代的时间会变长,反馈的次数就会相对减少了。如果简易交付只需满足较少的交付条件,我们就可以设计比较短的迭代。例如,在简易交付中,只包含 单体、结合的自动化测试,不包含验收测试。这样只需较短时间的准备即可完成交付。既可确保充分的作业 时间,也可减少因测试带来的各种修正工
8、作。因此,简易交付可以频繁地进行。但这种情况下,一些问题只有到验收测试阶段才能发现。带着隐藏的问题,做关于下个迭代的决策,风险很高。最终的交付可能瀑布化。敏捷项目管理建议简易交付的交付条件应尽可能贴近正式交付。提高开发工作的透明度,给顾客提供充 足的信息,提高获取客户反馈活动的质和量。1.5.6.2. 根据开发团队的技能、体制的完善程度以及顾客的体制做调整实际上,每个项目要根据开发团队的技能水平、各种体制的完善程度以及顾客的体制,做出必要的调整。 我们要注意平衡简易交付的频繁度和深度,推进自动化的探讨和实践,多下功夫,一点一点提高简易交付的 质量。至今为止,项目管理往往从这几个方面制定计划,在
9、实施中,检查计划和实施效果的偏差,监控项目的 健康状况。1.5.6.3. 软件开发之项目管理敏捷软件开发的项目管理,是指在敏捷软件开发中进行的项目管理活动。敏捷软件开发,如同第一章所 述,是一种积极拥抱变化的开发模式。敏捷软件开发认可并应对不确定性,换句话说,需要面对风险(根据 PMBOK的定义,风险就是不确定性X某种程度上,敏捷开发过程就是风险管理的过程。敏捷软件开发的各 种实践方法(Practice )就是为了应对各种风险而存在。敏捷软件开发的项目管理,其本质在于-平衡(Balance )为了提升透明度花费的成本和因为可能发生 变更而带来的风险。敏捷项目管理中,开发流程的概念轻量且抽象。在
10、日新月异的今天,开发流程本身的灵活性显得非常重 要。不是用一个固定的流程来应对变更,而是根据不同环境不同需要裁剪开发流程。从这个意义上来说,只 定义必不可少的管理内容的、轻量级的开发流程是顺应时代需要的。如果只在传统的Paradigm下解读和裁剪敏捷开发的流程,就很容易忘记敏捷开发的本来意义,这是造 成敏捷开发失败的一个主要原因。对流程的裁剪,一定要在正确理解敏捷项目管理的意义、不抹杀敏捷 特性的前提下进行。1.2.敏捷开发的可交付成果1.2.1. 不事先规定可交付成果的细节敏捷软件开发中,品质代表软件与用户需求的匹配程度。不事先规定可交付成果的细节是为了追求更高 品质。因为在开发过程中,需求
11、可能发生变更,可交付成果的内容也可能随之而改变。敏捷软件开发的特征不仅仅在于能以较低成本应对变更,而是使软件尽可能具有应对变更的能力。敏捷 项目管理的假设是,某个项目难以用传统的流程进行管理。即,Goal会随着时间的变化而变化。因此,重点 在于认识到可能发生变更的风险,提高应变能力。但是,通常情况下,人们认为如果可交付成果不断变化,开发可能无法收尾。因此,敏捷项目管理把开 发期间分解成几个短的区间,把每个短区间的可交付成果在一定程度上固定下来。在项目进展过程中,一边 听取客户反馈,一边调整可交付成果。可交付成果的灵活性要保持在多大程度?这个取决于流程的设计,是敏捷项目管理中非常重要的内容。1.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 管理 敏捷
限制150内