敏捷项目管理.docx
- 文档编号:4747480
- 上传时间:2022-12-08
- 格式:DOCX
- 页数:8
- 大小:21.76KB
敏捷项目管理.docx
《敏捷项目管理.docx》由会员分享,可在线阅读,更多相关《敏捷项目管理.docx(8页珍藏版)》请在冰豆网上搜索。
敏捷项目管理
1.敏捷项目管理之巴公井开创作
1.1.
时间:
二O二一年七月二十九日
1.2.敏捷软件开发之项目管理
1.2.1.软件开发之项目管理
项目管理是将知识、技能、工具与技术应用于项目活动,以满足项目的要求.软件开发项目的项目管理,是为了确保软件开发项目顺利进行的各种管理活动的总和.PMBOK(ProjectManagementBookofKnowledge)中将项目管理分为9年夜知识领域
1.整合管理
2.范围管理
3.时间管理
4.本钱管理
5.质量管理
6.人力资源管理
7.沟通管理
8.风险管理
9.推销管理
至今为止,项目管理往往从这几个方面制定计划,在实施中,检查计划和实施效果的偏差,监控项目的健康状况.
1.2.2.敏捷软件开发之项目管理
敏捷软件开发的项目管理,是指在敏捷软件开发中进行的项目管理活动.敏捷软件开发,如同第一章所述,是一种积极拥抱变动的开发模式.敏捷软件开发认可并应对不确定性,换句话说,需要面对风险(根据PMBOK的界说,风险就是不确定性).某种水平上,敏捷开发过程就是风险管理的过程.敏捷软件开发的各种实践方法(Practice)就是为了应对各种风险而存在.
敏捷软件开发的项目管理,其实质在于-平衡(Balance)为了提升透明度花费的本钱和因为可能发生变动而带来的风险.
敏捷项目管理中,开发流程的概念轻量且笼统.在日新月异的今天,开发流程自己的灵活性显得非常重要.不是用一个固定的流程来应对变动,而是根据分歧环境分歧需要裁剪开发流程.从这个意义上来说,只界说必不成少的管理内容的、轻量级的开发流程是顺应时代需要的.
如果只在传统的Paradigm下解读和裁剪敏捷开发的流程,就很容易忘记敏捷开发的原本意义,这是造成敏捷开发失败的一个主要原因.对流程的裁剪,一定要在正确理解敏捷项目管理的意义、不抹杀“敏捷”特性的前提下进行.
1.3.敏捷开发的可交付功效
1.3.1.不事先规定可交付功效的细节
敏捷软件开发中,品质代表软件与用户需求的匹配水平.不事先规定可交付功效的细节是为了追求更高品质.因为在开发过程中,需求可能发生变动,可交付功效的内容也可能随之而改变.
敏捷软件开发的特征不单仅在于能以较低本钱应对变动,而是使软件尽可能具有应对变动的能力.敏捷项目管理的假设是,某个项目难以用传统的流程进行管理.即,Goal会随着时间的变动而变动.因此,重点在于认识到可能发生变动的风险,提高应变能力.
可是,通常情况下,人们认为如果可交付功效不竭变动,开发可能无法收尾.因此,敏捷项目管理把开发期间分解成几个短的区间,把每个短区间的可交付功效在一定水平上固定下来.在项目进展过程中,一边听取客户反馈,一边调整可交付功效.
可交付功效的灵活性要坚持在多年夜水平?
这个取决于流程的设计,是敏捷项目管理中非常重要的内容.
1.3.2.可能发生变动,风险管理怎么办
1.3.2.1.What’sRisk
有可能发生变动的处所,就存在着各种各样的风险.风险是因为可能发生变动而造成的,所以无论用不用敏捷项目管理,风险都是存在的.
可是,采纳敏捷软件开发和采纳传统的瀑布式开发,客户和开发团队所承当的风险是分歧的.
首先,传统的管理方法是制定计划,根据执行结果和计划之间的偏差来评估可交付功效.可是因为可能存在变动,无法严密地界说可交付功效.因此,就呈现了以下两种做法:
a)做各种假设,无论如何界说出可交付功效,决定金额和交货期
b)虽然对可交付功效不是很清楚,但还是决定了金额和交货期
采纳方法a的话,变动带来的风险由客户承当.即,如果假设和实际不相符,可交付功效和实际的业务需求就纷歧致.采纳方法b的话,开发团队承当仕样变动的风险,因为一边要遵守金额和交货期的约定,一边还要完成可交付功效的变动.
一般来说,很难让某一方承当全部风险.通常的做法是采纳折衷案.即,暂不考虑谁是谁非,客户和开发团队共同承当上述风险进行项目活动.
敏捷软件开发中,客户和开发团队要一起承当变动可能性带来的风险.客户有责任解释说明并排序选择软件需求.可是,如果客户不能从开发团队获得有关项目进度的反馈,就无法做合适的判断.这就是沟通上的风险.
另外,事先没有约定可交付功效的细节,因此,项目能够在预算和进度要求内完成的保证就没有了.开发团队也要充沛了解这一风险,并作出应对.
外包公司可能会尽可能降低本钱,既满足事先决定的交付期和可交付功效,又使计划和执行之间的Gap转向有利于开发商一方,从而实现利益最年夜化.可是,敏捷软件开发中,没有事先约定可交付功效的细节,所以,很可能不存在如上所述的提高利润的空间.
开发商如果采纳敏捷软件开发,就要认识到这样的风险,同时最年夜限度地满足客户需求.
1.3.2.2.怎么降低风险
因为可能存在变动,所以无论采纳哪种项目管理方法,都必需承当变动可能性带来的风险.
那么,敏捷项目管理的优点在哪里呢?
就在于敏捷项目管理能够应对更多的、可能发生的变动.因为敏捷软件开发原本就假设软件开发项目中有可能发生变动.因此,越是深刻理解敏捷软件开发的实质,正确实践,就越能以较少的本钱应对可能发生的变动.
与此相对的,瀑布式项目管理没有做这种假设.
从这一点来看,熟练使用敏捷软件开发,可以更迅速更平安地应对变动可能性带来的风险.
更重要的是,当使用敏捷项目管理时,顾客和开发团队之间的风险平衡(RiskBalance)是Win-Win的合作关系.即,适应变动,拥抱变动的开发使客户获得想要的功能,另一方面,开发团队因客户满意而获得更年夜收益.
与此相对,瀑布式项目管理在制定计划时,顾客和开发团队之间就形成了一种风险的交易(Tradeoff).一旦发生变动,顾客和开发团队在谁承当风险上很容易形成对峙关系.这种对峙关系潜在地增加了项目管理的难度.变动越可能发生,项目管理就越难做.
敏捷项目管理的Point在于顾客和开发团队一起向一个目标奋斗,即提供更能满足用户需要的可交付功效.消解了对峙关系,构筑了一种积极应对变动的合作关系.这一点,相对传统的项目管理来说,无论在合同方式,还是在顾客和开发团队间的角色饰演(责任分担)上,都是一种激变吧!
1.4.敏捷项目管理之估算
敏捷项目管理中,计划(Planning)非常重要.计划之前,开发团队要估算出任务的年夜小(size).
这和传统的瀑布式项目管理究竟有何分歧呢?
敏捷软件开发中,估算有两个特征:
一是以顾客能够管理的需求为单位进行估算,另一个是只需估算出需求的相对年夜小.
关于这两个特征,解说如下.
1.4.1.以客户能够管理的需求为单位进行估算
第一个特征是要义客户能够管理的需求为单位进行估算.虽然这其实不是是敏捷项目管理固有的工具,但对敏捷项目管理来说,至关重要.因为采纳这样的管理方法,顾客可以自主排序选择需求.
首先,敏捷软件开发前,客户有责任准备需求列表.固然啦,年夜大都情况下,由开发团队帮客户制作需求列表.但开发团队要认识到需求列表的制作和管理是顾客的责任.
关于这种需求列表,每种开发方式都有自己的叫法,其中需求的粒度和暗示形式也分歧.例如,XP中,有Story.Scrum中有ProductBacklog.无论哪种,都是利害关系者期待的软件功能(Feature).
以客户能够管理的需求为单位进行估算,其实质在于使客户能够判断功能的优先度,以决定每次交付时,软件需要具有什么功能.
1.4.2.只需估算出需求的相对年夜小
这里的估算其实不是项目所需时间(人月)的估算.因为估算出来的累计时间,很可能因为人力资源等限制,会与实际需要的时间年夜相径庭.
第二点,需求的相对年夜小是由经验和感觉得来的,客户比力容易理解,也比力容易把持.
敏捷项目管理的前提是项目的不成预测性.因此,精细估算得来的计划和概算估算得来的计划,其精度分歧不年夜-都是不确实的计划.因此,与其在估算上花费本钱,倒不如把偏重点放在体制的整备上,以应对意外事态.
敏捷项目管理中,以需求的相对年夜小为单位进行估算.这个单位在XP中称作StoryPoint.
1.4.3.也有不能对应的不确定性
敏捷项目管理接受不确定性,需要时,可以调整估算值.可是,有时,估算阶段的前提条件中,也有一些不能不确定的要素.
这些要素一旦变动,其变动本钱往往不成接受.比力极真个例子,比如,一旦选定某种开发语言,就几乎不成能再变了.还有,架构的再构也是这样.
因此,事先必需详细调查这些不成更改的因素.例如,大都情况下,开发团队根据经验界说非功能需求,整理出架构的优缺点,明确其适用范围和潜在风险.
1.5.敏捷项目管理之流程设计
1.5.1.迭代(Iteration)
敏捷项目管理的要点在于能够设计出一个流程以平衡为获取反馈所花费的本钱和获得反馈给项目带来的好处.客户从开发人员那儿获得关于可交付功效的陈说,并进行决策.该决策作为仕样反馈给开发人员.然后,开发人员基于该仕样改进开发,并继续向客户陈说结果.如此这般,客户和开发人员一边切磋琢磨,一边做出更好的软件.
敏捷软件开发采纳迭代(Iteration)管理开发项目工作.一个迭代,一般继续一周或一个月.迭代是分配任务和制作可交付功效的管理单位.
迭代的长度一旦决定了,就不再更改.即,迭代的长度是固定的,不是由分配的任务年夜小决定的.Scrum使用Rugby中的术语,每个迭代被称作一个Sprint.
1.5.2.Time-box
Time-box被称作迭代面前的手.重视人与人之间互动的流程,往往会有规则不够用的缺陷.这是因为,这种流程的重点在于协调以完成实际的工作,而不是遵守严密的规章制度.这种流程更接近于管理的实质,可是更难掌控.
激发缔造力的交流是必不成少的,但有时候,用于调整的时间无限膨胀,甚至压缩了做实际工作的时间.例如,长时间的会议和辩说.简直,各种Session会给介入者带来一定的满足感,但也容易流于为会议而会议的形式主义,或者带来“开会就是完成工作”的虚假的成绩感.更坏的情况时,如果掌控欠好,会造成进度迟延、品质低下、以及本钱和回报的不服衡.那么,该如何解决这些问题呢?
有一种方法,对各项活动设定了时间,并要求严守结束时间.即,终了时间必需结束,即使会议的预期可交付功效还处于Inprogress的状态,也要结束,这个预期的可交付功效会成为下一道工序的输入.这种时间管理方法就叫做Time-box.
Time-box的Point在于其实不仓皇得出可交付功效.而是按时间进入下一道工序,获得客户反馈,再返回来,更好地完成可交付功效(由此可见,项目真的是一种目标导向、结果导向的工具).
重视客户反馈的敏捷项目管理就采纳了Time-box,依照界说好的时间,进入下个Step.
1.5.3.任务管理
1.5.3.1.把需求分配到各个迭代
需求是在迭代中实现的.在哪个迭代中分配哪些需求,一般是依照客户设定的优先度,从高到低地实施.
实际把持时,因为需求的年夜小分歧,而迭代的长度是固定的,所以无法完全依照优先级实施.另外,客户也纷歧定会主动设置需求的优先级.
开发团队要在每个迭代开始前,与客户密切交流,让客户发挥主动性选择需求.
1.5.3.2.需求分解成作业项目
敏捷软件开发中,将开发工作细分为任务,每个人自发地选择任务,一项任务完成后,自己再给自己分配下一项任务.把工作分解到可以分配给个人的水平,叫任务(Task).
迭代中,要把需求进一步分解为任务,并制成一览表.然后,通过管理任务的分配,每个人所做的工作都明了可见.虽然任务需要分配给Team中的某一人,但Team全体对任务负有管理责任.
不依赖于个人能力.而是通过Team一起管理剩余的任务,以判断迭代内是否能完成计划的可交付功效.两一方面,通过观察剩余的任务,可以早点发现异常.
设计流程时,一贯的指导思想是:
提高作业透明度,早期发现异常,缩短迭代期间,早期获得反馈.
早期发现问题,早期做出调整,在设计流程的过程中,要时时关注这一机制.
1.6.敏捷项目的交付
1.6.1.屡次交付
交付是指在软件开发中,核实可交付功效的行为.交付是指软件可以开始提供商业服务,或可在公司内部使用,或可开始作为Package产物生产/销售.
对外包公司来说,交付一般就是合同期满的时候,通常只有一次.可是,如果采纳敏捷项目管理,假设软件会随着环境变动和用户需求的变动而发生变动,将会有屡次交付.
1.6.2.每个迭代做交付
敏捷项目管理中,我们何时交付软件呢?
你已经知道,我们是以迭代为单位进行软件开发的.我们需要在每个迭代结束前,准备可以交付的软件.敏捷软件开发中,每个迭代的交付是必不成少的Practice.因为,我们要和客户确认每个迭代的可交付功效,获得客户的反馈,确保项目在正确的方向上运行.
反过来说,正因为敏捷软件开发需要频繁地获取客户反馈,所以要求迭代的时间不能太长.有时候,一个星期就是一个迭代,这时,我们需要每周交付一次.
普通的开发人员会认为这是不成能的.因为,交付一般陪伴着繁杂的手续,例如,压力测试,审计团队的检查,文档的整备等.一般认为不满足公司内部的流程,或者不完全满足合同上的要求,就没有到达可以交付的品质.
敏捷项目管理中,每个迭代的交付,会让人想到交付所花费的时间和人力,因此感觉有点不实用.其实,这只是表达的问题.敏捷项目管理中“每个迭代的交付”是指使软件到达“可交付的状态”(而不是真正就一次性交付了).
1.6.3.每个迭代做的简易交付
交付有两种.一种是每个迭代结束时的简易交付,另一种是作为项目的一个里程碑,即EndUser可以开始使用的正式交付.
1.6.4.简易交付的要求
正式交付的流程和手续由合同和公司规定.敏捷项目管理中,关键是要界说简易交付的交付条件.即,正式交付中的要求,有哪些在简易交付中必需满足.
例如:
单位测试在简易交付中必需满足(如果你使用测试驱动开发,肯定会有自动化测试).
那么,结合测试,和性能测试之类怎么办呢?
每个项目的性质分歧,团队的自动化工具的使用情况也分歧,有需要对每个项目具体问题具体分析具体判断:
需要把结合测试和性能测试放到简易交付中吗?
另外,简易交付的交付条件和迭代的长度也息息相关.
在设计流程时,需要重点讨论简易交付的交付条件.
1.6.5.敏捷软件的文档
1.6.5.1.文档最少化
敏捷软件开发极力排除文档工作.因为充沛交流和代码共享自己可以是项目团队用最少的文档实现仕样转达(Transfer)和共享(Share).简单说来,就是不需要,所以不做.
还有其他理由,例如文档的修改本钱,例如文档有损圆滑的沟通之类...
那么,敏捷软件开发中,真的不需要文档吗?
如果我们正确实践各种Practice,和利益相关者(包括客户)沟通顺利,那么最年夜可能减少文档也没什么关系.
可是,项目结束时,和利益相关者在默契基础上进行沟通的环境也没有了.为了和其他项目或者运营团队Transfer,有需要把信息书面化.除此之外,为了遵守现有的开发流程和公司内部规定,有时候其实不特别在意文档自身究竟有没有用,也必需把文档准备好.(用PMBOK里的说法:
更新组织过程资产)
1.6.5.2.在正式交付的迭代准备文档
那么,如何准备文档呢?
项目里,有一个迭代做正式交付,一般就在那个迭代整理文档.在正式交付的迭代,团队的工作就是测试、准备文档和交付(notcodecorrection).
1.6.5.3.正式交付的迭代要做的工作
正式交付的迭代中,团队实施本应在每次交付中实施的,但为了提高开发过程的效率没有实施的所有工作.例如:
文档、不能自动化的验收测试、内部审计团队的检查、在版本管理系统内做记录等.
1.6.6.敏捷项目管理的交付计划和流程设计
1.6.6.1.简易交付的条件要尽可能与正式交付相近
如何把两种交付结合到一起呢?
这是敏捷项目管理中,在设计流程时,必需重点考虑的另一个问题.
如果每次简易交付都去满足正式交付所要求的严苛的交付条件,那简易交付的本钱会增加,时间会延长,每个迭代中简易交付的工时比例会增加.如此这般,迭代的时间会变长,反馈的次数就会相对减少了.
如果简易交付只需满足较少的交付条件,我们就可以设计比力短的迭代.例如,在简易交付中,只包括单体、结合的自动化测试,不包括验收测试.这样只需较短时间的准备即可完成交付.既可确保充沛的作业时间,也可减少因测试带来的各种修正工作.因此,简易交付可以频繁地进行.
但这种情况下,一些问题只有到验收测试阶段才华发现.带着隐藏的问题,做关于下个迭代的决策,风险很高.最终的交付可能瀑布化.
敏捷项目管理建议简易交付的交付条件应尽可能贴近正式交付.提高开发工作的透明度,给顾客提供充分的信息,提高获取客户反馈活动的质和量.
1.6.6.2.根据开发团队的技能、体制的完善水平以及顾客的体制做调整
实际上,每个项目要根据开发团队的技能水平、各种体制的完善水平以及顾客的体制,做出需要的调整.我们要注意平衡简易交付的频繁度和深度,推进自动化的探讨和实践,多下功夫,一点一点提高简易交付的质量.
时间:
二O二一年七月二十九日
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 项目 管理