敏捷宣言解读
1、个体与互动高于流程和工具：
意味着虽然流程和工具重要(尤其是大型组织)，但是它们无法替换有能力的个体和高效的互动。个体的技能和他们之间的互动才是最关键的。
- 当我们开发产品、解决问题或改进工作方式时，我们要寻找改进互动和提高能力的方法
- 在项目期间，产品管理和开发团队必须在一起工作
- 在项目期间，架构师、设计师和测试人员必须每天在一起工作
- 面对面沟通是极其重要的，它不能被其它形式完全替换
2、工作的软件高于详尽的文档：意味着已集成、已测试、潜在准备发布的产品才是关键度量，它能够有效地跟踪项目进度和对发布做出决策。
- 要以小步增量的方式构建产品：做一些分析、设计，然后开始编码和测试以验证设计
- 设计需要做，比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员，简易文档还是必要的
- 好架构是持续开发产品的关键，架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构会演进，所以持续追求卓越技术和好设计能够增强产品敏捷性。
3、客户合作高于合同谈判：
意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系，而不是靠公司内的正式接口。
- 在实践中，意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。
- 在与我们自己的业务方合作中，我们应该寻找开发期间增进和改善合作的方法。
- 产品管理和开发应该密切合作，而不是通过契约或手续。
4、响应变化高于遵循计划：
意味着欢迎需求变化，哪怕是开发后期。
- 首先，预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。
- 如果我们对客户需求变更做的好，我们就会增强客户的竞争优势还有我们自己。
- 为了鼓励响应变化并使其更容易操作，需要建立流程和工作方式。承认计划的不确定性
- 计划是必要的，但计划必须适应变化：我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时，我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。
五、敏捷原则解读
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值，这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。
- 尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好，至少我们应该给我们客户一个选择。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 我们的目标是为了开发能够帮助客户提升价值的产品，要支持任何变化。变化不是一种否定，它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 开发周期和发布周期完全不同。尽管有发布周期，但我们的目标是短开发周期。发布周期的长度依赖业务决策，并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍，增加了敏捷性和灵活性。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 只要在业务和研发之间建立起桥梁，我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合？我们需要作出睿智的决策
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力，自由是最重要因素。要让角色去适应人而不是让人去适应角色。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时，信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈，将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。
7. 可工作的软件是进度的首要度量标准。
- 跟踪有多少功能已经实现，集成，测试是一种更可靠的进度度量。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 目标是为了消除高负荷工作并保持可持续的速度工作(例如，不加班工作)。质量问题通常牺牲长期收益，人们越是疲劳创造力就越低。因此可持续开发吧！
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 任何技术负债(代码缺陷、架构缺陷)都会使开发减慢。我们不应该让技术负债积压，所以要持续地做重构，更改发现的缺陷，持续关注实现架构的质量。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
- 这种简单原则既适用于产品的功能特性也适用于流程。多余的功能不要增加。所有流程步骤应该时刻面临挑战(例如，这步真的需要吗? 谁会读这个文档？…)。
11. 最好的架构、需求和设计出自自组织团队。
- 架构、设计和需求会随着团队一起工作慢慢浮现，并且团队会从中学到很多。一些前置需求、架构和设计工作是需要的，但是不能把它们定义在纸面上传递。架构师和系统工程师是自管理研发团队的一部分，不要成为“孤岛”。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
- 花时间反思和从经验中学习能够促进持续化开发。因此“检查与调整”是敏捷核心实践之一。
内容整理自网络，如有侵权，请联系删除。