敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价，减少麻烦。敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作。
一、敏捷优点和缺点
敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价，减少麻烦。敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作。需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。
1、敏捷的优点：
- 更快交付价值
敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值，这是敏捷提倡的核心价值之一。
- 更低的风险
敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把较高风险的需求在项目的初期就开始做，可以较早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险。即使这个项目失败了，这个失败的代价相对来说小一些。
- 拥抱变化
在VUCA 迭代开发的后期也接受变更。因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力。而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。
- 更好的质量
敏捷提倡高频率的交付有价值的产品。每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准，DoD等等。同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。
- 持续改进
敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会。另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。
- 更高的客户满意度
敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。
- 更高的团队满意度
敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理。更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；团队成员可以一起评估故事点；同时，SM要引导团队成员之间相互协作并促进合作。通过这些，团队成员可以更高效的工作，交付的质量也会提高，团队成员的满意度也会大大提高，”A happy employee is a productive employee”，不是吗？
- 更大的灵活性
敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。还有，验收标准，DoD都可以根据实际情况进行调整。
作者：十亿
链接：https://www.zhihu.com/question/265968122/answer/2142954695
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
2、敏捷的缺点和不足：
尽管敏捷带来了很多改善，但是再次重申它并不是适合所有人和所有情况的。因此，了解敏捷的不足显得特别重要。知道这点后，你心理上是准备好的并且会根据具体情况来做裁剪和优化来规避或减少负面影响。
- 很难进行准确的资源规划
由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。
- 很难准确的定义“轻量的“或必要的文档
敏捷倡导的是用工作的软件即文档（核心是代码即文档）。整个项目用于产品开发的文档不是一开始准备好的（甚至都没有RP原型设计），而是在过程中”及时的“ just-in-time准备出来的。因此，我们看到的是非常简单的且常常被放在最后处理的文档（在项目中涉及到移交或问题分析时这一点显得尤其突出）
- 很难把握整体产品的一致性
增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点。因为当团队在不同的周期内对各个组件进行开发时，整体的输出往往会变得非常零散，而不是一个内部紧密集合的整体。（当项目对UI和UX有更高的要求时，这个挑战就变得更加明显）。
- 很难预测有限的终点
敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向。此外，这意味着项目没有限定的终点，因为从来没有一个明确的 “最终的产品”样子。
- 很难有效地进行度量
由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看。而 “边走边看 “的特性意味着你不能在项目开始时设置很多KPI。这种长期的游戏使得衡量进度变得相对困难。
作者：十亿
链接：https://www.zhihu.com/question/265968122/answer/2142954695
来源：知乎
延伸阅读
敏捷项目管理到底是什么
一、敏捷项目管理定义
敏捷：是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。
敏捷项目管理：指在项目活动中运用敏捷的理念，配合专门的知识、技能、工具和方法 ，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。
二、敏捷项目管理本质
敏捷项目管理本质是一种理念，并基于这种理念进行不断实践在不确定和混乱的环境种取得项目成功，同时将这些实践总结提炼为团队稳定的解决方案。
这种理念也被先驱者们总结为敏捷软件开发宣言和敏捷开发十二原则。
敏捷软件开发宣言：
我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
敏捷开发十二原则：
- 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果较好效率也较高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 较好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的行为表现。
文章标题：敏捷项目管理怎么样，发布者：小编，转载请注明出处：https://worktile.com/kb/p/37433
微信扫一扫 
支付宝扫一扫 
