不深入理解敏捷宣言，就会误入歧途地认为敏捷就是没有规矩！
可确定的工作与高度不可确定的工作
项目工作包括可确定的工作与高度不可确定的工作。
可确定的工作项目管理具有明确的流程，它们在以往类似的项目中被证明是行之有效的。在完成设计后制造汽车、电器或建设住宅，这些都是可确定的工作的例子，其所涉及的生产领域和过程通常很好理解，并且执行的不确定性和风险通常较低。
新的设计、解决问题和之前未做过的工作都是探索性的。它要求主题专家携手合作，解决问题，并创建解决方案。遭遇高度不确定的工作是人员包括软件系统工程师、产品设计师、医生、教师、律师和许多解决问题的工程师等。
高度不确定的项目变化速度快，复杂性和风险也高。这些特点可能会给传统预测法带来问题，传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。而敏捷方法的出现是为了在短时间内探讨可行性，根据评估和反馈快速调整。
《敏捷宣言》及思维模式
2001年，软件业思想领袖共同发表《敏捷宣言》，正式宣告敏捷开发运动的开始。
我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。
通过这项工作，我们开始更重视：
个体以及互动而不是过程和工具
可用软件而不是完整的文档
客户合作而不是合同谈判
应对变更而不是遵循计划
也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。
源自上面这些价值观的十二大原则如下：
- 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
- 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
- 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
- 项目实施过程中，业务人员与开发人员必须始终通力协作。
- 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
- 无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
- 可用的软件是衡量进度的首要衡量标准。
- 敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
- 对技术的精益求精以及对设计的不断完善将提高敏捷性。
- 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
- 最佳的架构、需求和设计将出自于自组织团队。
- 团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
尽管这些原则源自软件行业，但已经扩展到许多其他行业。
这种思维模式、价值观和原则定义了敏捷方法的组成部分。今天所使用的各种敏捷方法都植根于敏捷思维模式、价值观和原则。它们之间的关系如下图：
《敏捷宣言》价值观、原则和能用实践之间的关系
敏捷方法是一个囊括了各种框架和方法的涵盖性术语。它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。下图还将敏捷方法和看板方法视为精益方法的子集。这样做的原因是，它们都是精益思想的具体实例，都反映了诸如以下概念： 关注价值，小批量和消除浪费。
敏捷是许多方法的一个总称
敏捷是一种方法、手段、实践、技术还是框架？
根据具体情况，上述词语均适用。
一般而言，可以通过两种策略践行敏捷价值观和原则。
- 采用正规的敏捷方法，它们为特意设计，经证明可达成期望的成果。那么，在变更和裁剪之前，就需要花时间学习和理解敏捷方法。不成熟和随意的裁剪会让敏捷方法的效果大打折扣，从而限制了收益。
- 以一种适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。使用时间盒创建功能，或者使用特定技术迭代优化功能。在适用于特定项目背景下，考虑将一个大项目划分为几部分发布。实现有项目成功的变更，这些变更不必是组织的正式实践的组成部分。最终目标不是为了敏捷，而是为了向客户持续交付价值流，并达成更好的商业成果。
精益与看板方法
看待精益、敏捷与看板方法三者之间关系的一种思路是，将敏捷和看板方法视为精益思想的衍生物。换言之，精益思想是一个超集，与敏捷和看板方法拥有共性。
这种共性非常相似，重点在于交付价值、尊重人、减少浪费、透明化、适用变更以及持续改善等方面。项目团队有时会发现将各种方法结合起来使用更为有用，只要是对组织或团队有效的方法，无论来源如何，都应该采纳。无论使用什么方法，目标都是为了实现最佳结果。
不确定性、风险和生命周期选择
有些项目在项目需求，以及如何使用现有知识和技术满足这些需求方面，具有很大的不确定性。这些不确定因素可能导致大量变更和项目复杂性的提高。如下图：
受斯泰西复杂性模型启发的不确定性和复杂性模型
随着项目不确定性的增加，返工的风险和使用不同方法的需求也会增加。为了减轻这些风险的影响，团队选择的生命周期要能够通过较少的工作增量解决项目的大量不确定性问题。
团队可以利用较少的工作量验证自身的工作，并且可以对接下来的工作做出相应的变更。与静态书面规范相比，当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。
团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。但是，随着项目不确定性的增加、变更、做无用功和返工的可能性也会随之增加，而这不仅代价高昂，而且耗费时间。
有些团队让项目生命周期发生演变，以便使用迭代和增量方法。许多团队发现，在探讨迭代需求、更频繁地交付增量时，团队会是错容易变更。由于团队获得反馈，这些迭代和增量方法减少了浪费和返工。这些方法应用了：
- 非常短的反馈循环；
- 频繁调整过程；
- 重新进行优先级排序；
- 定期更新计划；
- 频繁交付；
对于涉及新的工具、技术、材料或应用领域的项目、这些迭代、增量和敏捷方法非常有效。它们也适用于具有以下特点的项目：
- 需要研究和开发；
- 变更速度极快；
- 具有不明确或未知的需求、不确定性或风险；
- 最终目标难以描述。
通过构建一个小的增量，然后对其进行测试和评估，团队可以在短时间内以低成本 探索不确定性，降低风险，最大程度地实现商业价值的交付。
不过，迭代和增量管理方法也有其应用局限性。当技术和需求的不确定性都很高时，项目就会极端复杂，陷入无序状态。为了使项目尽可能可靠，需要遏制其中一个不确定性变量。
