一、敏捷价值观和敏捷原则
发布网友
发布时间：2022-09-29 15:48
共1个回答
热心网友
时间：2024-11-16 02:36
1、个人与互动胜过过程与工具 （Indivials 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 indivials . 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
