一、敏捷价值观和敏捷原则

敏捷价值观

敏捷价值观有四项内容,即:

1、个人与互动胜过过程与工具(Individuals and interactions over processes and tools)

在项目管理过程中,过程和工具是比较重要的。在过程、工具和个人、互动相比较,过程、工具就显得没那么重要。这也就是我们常说的:成也萧何,败也萧何。事在人为。天下事,重在商榷。

2、可用的软件胜过复杂的文件(Working software over comprehensive documentation)

在互联网plus、大数据时代下,通过收集有效数据、信息,再进行汇总、分析、挖掘,项目干系人通过移动端即可实时监控项目进展和状况,这远比复杂的文件更高效。那么,要想实现这一功能,就离不开可用的软件平台。

3、与客户合作胜过合同谈判(Customer collaboration over contract negotiation)

甲乙双方,在平等互利的基础上,签署合同。换句话说:签订合同,就是在平等的基础上,为了实现双赢。只有彼此合作,才能追求双赢。这也正是项目管理之所以重视沟通的原因所在。

4、响应变更胜过遵循计划(Responding to change over following a plan)

项目的特征之一就是渐进明细。人们常说:计划赶不上变化快。在规划阶段,不论我们的计划做得多么详细,在实施阶段,总会有意想不到的问题发生。在项目管理过程中,变更在所难免。正确面对变更,是每个项目管理者最睿智的抉择。

敏捷原则

敏捷原则共12条,为了更好地理解和掌握敏捷原则,我们把它重新排列归为两类,即成果交付原则(6条)和人员交互原则(6条)。

1、成果交付原则

价值排序,尽早交付

敏捷原则第1条:我们第一优先的任务是,通过尽早且持续交付有价值的软件(系统)来满足客户(Our highest priority is to satisfy the customer through early and continuous delivery of valuable software)。

项目之所以被立项,是因为它有存在的价值。既然项目是有价值的,那么它越早交付,价值呈现越明显。在安排交付顺序(里程碑)时,把握客户的痛点和敏感点,优先交付客户关注的内容,可以尽早、持续地让客户满意,有效降低项目收尾时,客户不满意的风险。

拥抱变化,提高优势

敏捷原则第2条:即使在最后开发阶段,也要竭诚欢迎改变需求,敏捷过程掌控变更,以维护客户的竞争优势(Welcome changing requirement , even late in development . Agile processes harness change for the customer’s competitive advantage)。

在项目管理过程中,既然无法回避变更,那么就该正确面对变更。发生变更,分析变更,做出正确判断,最后执行变更计划。敏捷团队不能坐视问题不管,要敢于迎接改变,尽早修正,让价值最大化、伤害最小化。

持续交付,小步快跑

敏捷原则第3条:经常交付可用的软件(系统),频率可以从数周到数月,以较短的时间间隔为佳(Deliver working software frequently , from a couple of weeks to a couple of months , with a preference to the shorter timescale)。

在项目管理过程,我们与客户沟通,往往出于两种原因:第一种原因是遇到问题,需要沟通、协商、解决,第二种原因是有成果产出,需要用户确认。如果能持续、快速地交付成果给用户,无疑会博得用户的青睐、支持和认可,利于项目工作推进。

成果达成,衡量进度

敏捷原则第7条:可用的软件(系统)是进度的主要测量标准(Working software is the primary measure of progress)。

现在,一些企业实行项目管理考核制,旨在提高项目管理效益,可是人为衡量、鉴定项目的进度,相对困难(延误的借口总会有的),甚至产生意见和分歧。如果能借助相应的管理软件(平台),可以让干系人直观地查看项目进度,回避意见和分歧。

追求卓越,强化敏捷

敏捷原则第9条:持续专注于追求卓越的技术与优良的设计以强化敏捷力(Continuous attention to technical excellence and good design enhances agility)。

精益求精,让敏捷更加敏捷。在发布、迭代的过程中,不断精益设计,卓越产品或成果,产出令用户满意的产品或成果。返工少了,变更少了,项目更敏捷了。

精简产品,杜绝浪费

敏捷原则第10条:精简——精髓是要尽最大的可能,排除不需要做的工作(Simplicity-the art of maximizing the amount of work not done-is essential)。

敏捷管理,虽然以客户为导向,拥抱变更,但是同样要控制范围,尽最大可能排除不需要做的工作。坚决杜绝需求范围蔓延现象。

2、人员交互原则

团队合作,每日互动

敏捷原则第4条:业务人员与开发者在项目进行中,必须每天一起工作(Business people and developers must work together daily throughout the project)。

不论是传统项目管理,还是现代项目管理,甚至敏捷项目管理,都提倡集中办公。不过敏捷管理,要求更加苛刻。敏捷团队成员,必须在一起工作,每天组织15分钟立会。

信任成员,给予支援

敏捷原则第5条:项目靠积极的个人来完成,给予他们所需的环境与支持,并相信他们可以完成工作(Build projects around motivated individuals . Give them the environment and support they need , and trust them to get the job done)。

无数条河流,汇聚成大海。来自不同岗位、技能的成员,组成敏捷团队,共同完成项目工作。相互信任、支持和配合,积极、主动完成工作,加强团队凝聚力,工作就会无坚不摧。领导再像仆人一样提供服务,为团队创造环境,给予支持,项目不敏捷都没人信。

面沟通,高效明了

敏捷原则第6条:在开发团队与团队成员之间,面对面的沟通是传播信息最有效率与效能的方式(The most efficient and effective method of conveying information to and within a development team is face-to-face conversation)。

影响沟通效果的因素之一就是距离。如果项目团队成员能面对面沟通,是最高效的沟通方式。

各方成员,稳定节奏

敏捷原则第8条:敏捷过程提倡稳定持续的开发,发起人、开发者及用户都应该能不断地维持稳定的步调(Agile processes promote sustainable development .The sponsors , developers , and users should be able to maintain a constant pace indefinitely)。

敏捷管理,是在愿景、资源和时间明确的条件下,采取的一种高效管理方式。这也就意味着资源不会改变,保证项目时间进度。持续稳定的工作节奏,有利于控制项目的时间进度。项目干系人应该维持稳定的步调,在适当的时机做适当精度的规划、设计,才能按时持续输出可用的阶段成果。

同心协力,自我组织

敏捷原则第11条:最佳的架构、需求及设计皆来自于能自我组织的团队(The best architectures , requirement , and designs emerge from self-organizing teams)。

团结就是力量,这力量能克服各种困难。敏捷团队是自我组织、管理的团队。敏捷项目管理没有明确的架构、需求及设计时间。团队成员同心协力,一起规划、设计,一起完成任务,一起克服困难,一起分享胜利的喜悦。

团队自省,持续改进

敏捷原则第12条:团队定期自省应如何更有效率,并据以调整与修正行为(At regular intervals , the team reflects on how to become more effective , then tunes and adjusts its behavior accordingly)。

笔者提倡精益敏捷管理,也就是说敏捷要建立在精益的基础之上,脱离精益,盲目敏捷,必将造成返工,或者更多的变更。

敏捷团队成员,在追求卓越的同时,要加强学习,定期反省。在提升自己技能的过程中,及时调整与修正自己的行为,才能成为真正的敏捷成员。

以上敏捷价值观和原则,摘自《敏捷项目管理——基础知识与应用实务》。

参考文章:http://blog.sina.com.cn/s/blog_53e932a10102wusx.html

你可能感兴趣的:(一、敏捷价值观和敏捷原则)