本文共 2730 个字数,平均阅读时长 ≈ 7分钟
敏捷的核心价值观主要包括：敏捷的4大宣言和12条原则
敏捷宣言
上述宣言的模式不仅仅是4句话，而是1 4 1的模式
1.个体和交互胜过过程和工具
流程和工具是我们项目中需要的，将团队的目的聚焦于个体参与和互动。项目是通过人来完成的，而不是通过工具。困难也是由人来解决的，而不是通过流程。同样，项目由人来执行，范围由人来确定，项目成功也是由人来定义的。个体的参与和交互将有利于项目成功。但是，并不是说流程和工具对于项目的成功没有帮助，这些反而是重要的组织资产。第一条价值观“个体和交互胜过流程和工具”有助于聚焦个体的时间、能量和激情。
2.可以工作的软件胜过面面俱到的文档
软件项目以创造有价值、高质量的软件为首要目标。没有文档描述的软件在技术支持和维护上一定会出现问题及阻碍，但是只有详尽的文档而没有完成软件对于任何一组织而言都是没有价值的。所以，文档是需要的，但需要把握其中的度。 敏捷宣言“可工作的软件胜过详尽的文档”提醒项目成员更多地聚焦于项目的目标——价值。如果过多地关注了文档而牺牲了可以工作的软件，那么文档也是无用的、没有价值的。
3.客户合作胜过合同谈判
本条价值观提醒我们需要做到灵活与包容，而不能死板，类似于“正确地做事情”和“做正确的事情”。我们可以完全按照最初规定来完成产品，一旦客户改变想法或优先级，最好的做法是通过灵活的方法完成新的目标，而不是用最初的规定来对抗。
4.响应变化胜过遵循计划
遵循计划是指按计划行事，中间可能需要采取纠正措施，目的是为了使预期的未来绩效与项目计划一致而做的一切事情。响应变化则是适应的过程，通过卓越构想和不断反馈来采取适应措施，适应的目的是对实践而非预定计划的回应，是响应而非纠正。 敏捷宣言并没有建议我们为了 应对变化而完全放弃计划。我们需要对项目做计划，同时，我们也要 明白，最初的项目计划是我们在项目开始时制订的，随着工作的进 展，我们需要持续更新计划。敏捷中提倡5层计划。 敏捷价值观的主旨就是提倡适应性计划，要求全员积极参与。
敏捷宣言指导我们以价值为导向来实施项目。我们同样需要流程、工具、文档以及计划，然而相对于这些，我们的关注点需要更多地聚焦于从事项目的人、正在进行中的产品、合作和灵活性。
敏捷原则
(1)我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户。
第一点是要满足客户需求； 第二点是尽早和持续交付； 第三点是要交付有价值的软件，而不是未完成的工作产品、工作 分解结构(WBS)术语、文档或者项目计划。
(2)即使在项目开发的后期，仍欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客户创造竞争优势。
如果是为了交付更好的成果和更高优先级的产品，那么变更对项目就是好事。 高效处理变更可以帮助项目团队把更多的时间投入在产品开发上，而不是处理变更上。敏捷方法就是利用易理解、高可视的方法来处理变更，使项目更加灵活。
(3)要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
本条准则重点强调了将工作产品投入测试环境从而获得反馈。频繁的测试和反馈对敏捷项目非常重要，团队需要根据已完成产品的反馈来确定如何继续。当然，反馈中也会存在变更的要求。 短时间的交付有利于团队和业务人员之间的互动。频繁的交付使得项目团队可以得到更多的商业机会和反馈。通常在演示会上，团队会得到业务优先级的变更要求，这都是很有价值的。
(4)在项目过程中，业务人员与开发人员要每天在一起工作。
频繁的演示是业务代表和开发人员在项目中共同工作的一个很好的切入点。在实际工作中，开发人员每日和业务代表采用面对面的沟通往往比较困难，但是值得去推动。面对面的交流可以更好地观察肢体语言，相比而言，文档、电子邮件或者打电话都不能有效地传达信息。
(5)要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
我们虽然不能确保每个团队都是被精挑细选出来的理想组合，就像中国跳水团队——梦之队，但是我们可以尝试去激发团队成员，让他们成为一个可以自我驱动的理想团队。自组织团队作为项目的一个重要因素，一旦员工开始自组织和计划工作，其工作会更加高效。敏捷方法主张将团队从微观管理和甘特图中的任务式管理中脱离出来，聚焦于工作技巧和团队协作从而提高生产率。 知识性项目也包含有特殊经验和技能的成员。如果开发团队可以更好地做出日常决定以及处理好计划的工作，那么项目团队中每个成员都会是专家，可以为项目的成功给予支持。
(6)团队内部和各个团队之间，最有效的沟通方法是面对面的沟通。
面对面的沟通可以快速传达大量的信息，包括表情和肢体语言。梅拉宾法则 曾经提出:“在信息沟通中，除了以语言的方式外，信息还以许多方式表达。说话的内容仅占7%，语音语调占38%，肢体语言占55%。” 面对面会谈不能用于所有的沟通场合，只是提倡尽量遵循。随着团队规模的扩大，面对面的沟通很难实现，此时，我们就需要引入适当的文档要求。
(7)可工作的软件是衡量进度的首要指标。
首先，要将可工作的软件作为项目的关注目标，努力将创建文档等活动作为支持目标的手段而不是首要任务。如果产品不能工作，就不能被认为已完成了。强调“可工作”的软件是为了提醒团队功能特性只有被接受才算完成。项目是以结果为导向的，中间过程的可交付成果(比如文档和部分完成的工作)都不会得到外部的认可，被客户使用的产品才是项目的关注点。
(8)敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度。
针对周期长且紧张的开发阶段，敏捷方法认为应保持稳定的进展速度，其价值在于允许团队成员维持工作和生活的平衡。可持续的速度不仅对团队有好处，也会给整个组织带来益处。 因此，保持恒定的开发速度可以创造一个更加和谐、高效的团队，较小的压力会提高工作效率、促进团队之间的协作。
(9)对技术卓越和好的设计的持续关注有助于增强敏捷性。
当我们希望开发团队可以努力工作并且交付大量有价值的产品时，我们也必须注意保持设计的清晰、高效和变更的灵活性。精益求精的技术和良好的设计会使产品或开发团队更早地理解与更新设计。
(10)尽量做到简洁，尽最大可能减少不必要的工作。这是一门艺术。
敏捷方法专注于简洁，只完成必要的元素。敏捷方法寻求“允许工作的最简洁产品”，并将其推荐为首选的解决方案。这种方法在减轻风险的同时也帮助团队建立了信心。
(11)最佳的架构、需求和设计出自自组织团队。
自组织团队有更高的所有权以及对架构、需求和设计的荣誉感，团队所创建的观点如果已经通过审查，就不需要再去验证。 自组织团队更加贴近项目的技术细节，因此最适合去识别实施中的问题。虽然可以尝试采纳外部的建议，但是敏捷依然倡导用团队的能力去打造最好的架构、需求和设计。团队成员是最了解项目的人，所以也最应该被授权参与项目。
(12)团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为。
团队在项目进展中要不断地学习，对已经完成的任务进行反思和调整，从而为余下的项目工作做好准备。
敏捷的框架
敏捷项目管理可以把整个框架分为五个阶段，分别是:构想、推测、探索、适应和结束阶段。
- 构想:确定产品构想、项目范围、项目团队以及团队共同工作的方式。
- 推测:制订基于功能的发布计划、里程碑和迭代计划，确保交付构想的产品。
- 探索:在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。
- 适应:审核提交的结果、当前情况以及团队的绩效，必要时做出调整。
- 结束:终止项目，交流主要的学习成果并庆祝。
