学习目标
完成这个单位后，你会知道：
- 探索 敏捷的开端
- 了解敏捷的各个部分
- 弄清楚敏捷是否适合您
敏捷是一系列激动人心的新实践和技术，使产品开发更具周期性（或者我们喜欢称之为Agile-speaking），并且通过渐进式提升产品开发，让您更接近客户的需求步。它依赖于精益治理（管理），而不是依赖于重量级治理的更传统技术。
敏捷就是为了让团队更有能力，更接近客户的需求。它取代了严格的前期规划和基于阶段的流程，提供了一个动态的，迭代的构建和测试周期，可以很好地处理变更。 Agile的标志性功能之一是它可以在组织中降低决策制定流程，使该组织更具响应性和适应性。
敏捷可能会为您提供基本的方向，但Scrum允许您将敏捷带到您的组织并使其工作（有关Scrum的更多信息，请参阅第2章）。虽然敏捷建议需要良好的沟通，但Scrum为站立会议制定规则以及如何进行。在敏捷讨论迭代和增量开发的需求的地方，Scrum将这些术语聚焦于定义明确的sprint，代表特定的迭代。在敏捷建议您跟踪要使用列表执行的任务的地方，Scrum具有适当的特定技术。
为什么敏捷出生
敏捷最初被认为是一套软件开发价值和原则。这是对严格的“大前期规划”方法的反应，许多软件开发人员和业务分析师认为这种方法扼杀了开发过程并与客户联系，强调计划而不是产品和客户需求。
随着软件开发公司变得越来越大，他们往往越来越重视治理。自上而下的控制成为这个过程的重要部分，有时候开发人员花费大部分时间来处理这样的控制结构，因为开发过程的每一步都变得僵化和分层。这种开发环境与较小的，更具适应性的软件开发公司不一致，这些公司通过创建更接近客户需求的产品为流程带来更多客户价值，花费更少的时间来创建并降低开发成本。
敏捷不是一个简单的软件开发者的反抗。虽然敏捷开始受到软件开发人员的欢迎，因为它为创造力腾出时间并推动决策过程降低，但从业务角度来看，这些原则也很有意义。
通过大幅降低开发成本和时间，并创建比大多数传统方法更接近客户需求的产品，Agile已经证明自己是一种商业策略。与标准需求收集，计划驱动的项目开发相反，客户不断参与敏捷。持续参与会产生以下影响：
- 开发的产品更接近客户的需求，即使他的要求发生变化或变得更加复杂。
- 您的客户更快乐！
- 成本和开发时间可能会更短。
- 最大限度地减少项目偏离客户需求的风险。
所有这些都具有良好的商业意义。
敏捷的原则很长一段时间，它们最终在2001年的敏捷软件开发宣言（又名敏捷宣言）中被其17名宇航员在Wasatch Range的Snowbird滑雪胜地的The Lodge中提出。在犹他州的山脉。他们看重了
- 个人和流程与工具之间的互动
- 通过综合文档工作软件
- 客户通过合同谈判进行协作
- 响应遵循计划的变更
“宣言”阐明了从那时起成为敏捷的基本原则：
- 最高优先级是通过早期和持续交付产品来满足客户。
- 欢迎变化，即使在开发后期也是如此。
- 经常提供工作产品，通常为数周。
- 围绕有动力的个人建立项目。
- 强调面对面的交谈。
- 工作产品是进步的主要衡量标准。
- 必须持续关注卓越技术。
- 简单是一种伟大的美德。
- 最好的设计来自自组织团队。
“宣言”的统计者不是一群坚持维持狂野和毛茸茸的方式的牛仔程序员。敏捷的大部分内容都与内部控制模式有关，这些控制模式以前是外部管理的，并且在团队本身内部化了纪律。敏捷寻求培养自我激励的团队，他们的优先事项是项目。
当它起作用时，这种控制的合成是非常宝贵的。团队本身不需要从计划，计划和规则强制执行控制，而是接管并使外部治理基本上过时。简而言之，这就是敏捷的灵感和力量。
拥有敏捷心态
你需要做些什么改变才能开始思考更敏捷？希望通过本节中的信息，您可以解决这个问题。
本书的合着者Mario E. Moreira撰写了针对敏捷团队的适应配置管理。敏捷心态是该书概念的一部分。
认为自我赋权
在敏捷中，决策被压缩到最低有效水平，并赋予自我激励的团队成员权力。
考虑自我赋权和自我激励的团队，而不是外部指挥结构对不情愿的开发人员鞭打。
想小
敏捷依赖于分而治之的策略。您应该能够将任何任务分解为可管理的块，每个块的范围或多或少都是模块化的。您可以将问题重构为较小的问题，并在单个明确定义的位置进行全局更改。
想想商业价值
敏捷过程的最高优先级是为客户提供价值。敏捷鼓励团队成员内化提供最大商业价值的学科。团队成员在每个迭代周期中考虑价值交付。
想想连续
在现实世界中，变化发生了。当您处理项目时，客户可以随时更改要求。迭代方法允许在计划会话中引入更改以用于下一次迭代。
虽然敏捷宣言说敏捷开发人员欢迎变革，但在实际的开发环境中，这可能有点太多了。与传统的开发方法相比，敏捷能更好地应对变化，特别是持续变化。
由于客户始终参与其中，因此更改的范围可能比传统开发过程中的更小。与一次大规模的改变相比，通常可以更容易地处理50个小的变化此外，Agile考虑的是短迭代而不是单片（单块）项目，使更改更容易处理。
因此，虽然说敏捷团队在项目开发过程中欢迎许多重大变化可能太过分了，但他们能够更好地应对这些变化。
想想合作
敏捷非常重视协作，特别是面对面的协作。这种重要性与传统产品开发有明显区别，传统产品开发通常需要通过第三方进行。相反，敏捷协作鼓励跨标准角色协同工作以构建解决方案。
想想纪律
许多组织不愿意采用敏捷的主要原因是错误地认为它涉及临时或牛仔的发展。治理严重的组织认为，无人监督的松散团队会导致混乱，而不是成品。
在敏捷开发中，团队被授权并内化完成每个周期所需的规则。因此，虽然许多组织担心敏捷开发看似无人监督的性质，但事实是，当它按设计工作时，它会更加有效和高效。
敏捷会在您的环境中工作吗？
敏捷适合你吗？这是一个需要考虑的问题。首先来看看今天常用的方法：
- 瀑布：基于阶段的方法，您需要在移动到下一个阶段之前完成阶段
- 混合瀑布：基于阶段的方法，提供相位重叠，因此您可以在完成当前阶段之前开始下一阶段
- 增量：一种方法，以短增量提供客户交付 – 即更短的发布周期
- 迭代：一种方法，可用于多个短周期的进度，在周期结束时需要客户验证
- 敏捷：一系列方法论，它们源于迭代和增量的开发方法，以提供客户价值
使用瀑布式开发，您必须根据指定的计划从一个阶段移动到另一个阶段（即瀑布到瀑布）。客户仅在开始时的需求收集和最后的用户验收测试期间参与。
另一方面，敏捷没有设定阶段，而是以短循环迭代地进行。需求计划，实施，测试和评估在几周而不是几个月内重复进行。客户始终参与其中。
那么你如何判断敏捷是否适合你呢？敏捷和不完整应用的敏捷技术可能导致重大且耗时的问题。所以戴上你的思维上限并查看本节中敏捷部分的细分。
小团队
敏捷与12名或更少成员的小型面对面团队一起蓬勃发展。如果你不能将你的任务分解成可由这些小团队处理的部分，敏捷可能不适合你。
搭配
搭配意味着事物被放在一起，在敏捷意义上，我们使用这个术语来表示每个人都在同一个位置的偏好。虽然技术上不是绝对的要求，但这种团结在使敏捷 – 特别是Scrum – 工作方面有很长的路要走。
如果您的团队分布很广，敏捷可能无法满足您的需求，或者您的团队需要额外的努力来进行沟通。但是，一些敏捷实践可以帮助使其更加可行。
充满活力，经验丰富的开发人员
敏捷开发确实需要有动力，经验丰富的开发人员，他们可以监督自己。经验丰富的开发人员倾向于自我指导，而新手开发人员可能需要大量的监督。敏捷方法依赖于开发人员内化自己的规则。
如果您只有新手开发人员，敏捷方法可能不适合您。
精益治理
当敏捷团队独自完成自己的事情时，他们会做得最好。正确构建的敏捷团队是自律的，需要相对较少的外部治理。
有些组织无法摆脱繁重的治理模式 – 如果它描述了您的组织，敏捷可能不适合您。
客户参与
传统上，客户在项目开始时提交一组要求，并在接近完成的产品进行验证时接下来联系。这不是敏捷的工作方式。在这里，客户参与其中，特别是在Sprint的最终评论（或演示）中，收集持续的反馈以确保您提供客户实际需要的东西。如果客户不在场，产品负责人的角色就是客户的声音。 （有关产品负责人角色的信息，请参阅第2章。）
如果您的客户参与太多，敏捷可能不适合您。