敏捷的理由

敏捷的理由

1、专业性
敏捷高度重视纪律而非形式，要把敏捷做对，需要结对编程、测试先行、重构并致力于简单设计，你必须在短循环周期内工作，每个周期都产出可以工作的软件，必须定期且持续地与业务部门保持沟通。
极限编程的生命之环中的每一个实践都是一个承诺、一个保证，敏捷开发就是承诺要拼尽全力成为一名专业人士，并在整个软件开发行业倡导专业的行为。

2、管理者、用户的期望

• 不会交付一堆垃圾

• 从技术上随时做好交付的准备
  敏捷要求系统在每个迭代结束的时候都应该是技术上可部署的——在开发人员看来，系统在技术上足够稳固、可以部署，代码整洁并且所有的测试通过。
  如果系统在每个迭代结束是在技术上做好了准备，那么是否部署就是业务决策了，而不是技术决策。

• 稳定的生产率
  开发人员对自己的要求应该是，持续地将架构、设计和代码保持在尽可能干净的状态。可以保持高生产率，并防止陷入生产率下降、重新设计的悲惨旋涡。——测试、结对编程、重构和简单设计等敏捷实践是跳出旋涡的技术关键。

• 划算的适应性
  软件：软是容易修改的，件是产品，软件——容易修改的产品。
  我们之所以发明软件，就是想要一种快速而且简单的方法来改变机器的行为，如果它的行为很难改变，可能就把它称为硬件了。
  开发团队经常抱怨需求变更，经常有类似这样的说法：这个需求变更完全不符合我们的实现。——如果需求变更破坏了你的软件架构，那说明你的软件架构太糟糕了。
  软件开发这个游戏的名字就叫需求变更，接受和实现需求变更，让变更成本相对划算，这种能力是我们的工作之本。

• 持续改进
  随着时间的推移，人类会把事情做得更好。软件也应该如此，软件越老应该越好才是。随着时间的推移，软件系统的设计和架构应该越来越好，代码的结构应该得到改善，系统的效率和吞吐量也应该得到改善，这不是很明显吗不是任何一群人做任何一件事情应有的期望吗/p>

• 无畏之力
  为什么大部分的软件系统不会随着时间的推移而变好，是因为恐惧，更具体来说，是因为害怕改变。
  想象一下你的屏幕前是一些旧代码，第一个念头是：这段代码写得太差劲了，我应该清理一下。但是下一个念头是：我不想碰它！因为你知道，如果碰了这段代码，你会把软件搞坏，然后这段代码就是你的代码了，所以你退缩了，尽管清理代码有可能对旧代码有所改善。
  测试驱动开发TDD的敏捷实践，让我们拥有一个按钮，在代码改动时，验证是否对系统造成了破坏。每次改动，都按一下按钮，确保没有破坏任何东西，从而消除了恐惧，可以使用重构、结对编程、简单设计等敏捷实践来改进系统了。

• QA应该什么也找不到
  如果QA发现了问题，开发团队应该去找他们的流程哪里出了错，并修复自己的流程。

• 测试自动化

• 我们互相掩护
  在船上，每个人都有自己的工作，并且每个人都了解如何做其他人的工作，因为在船上，所有任务都必须完成。我期望软件团队的成员能够相互掩护，管理者和成员有责任确保有其他队友能够接替你的工作。

• 诚实的估算
  可能不知道某件事将要花费多少时间，但是你可以将一个任务和另一个任务进行相对值的估算，或者进行一个概率范围，例如5-15天。

• 你需要说“不”
  尽管努力去寻找问题的解决方案很重要，但是找不到方案的时候，期望你能够直接说“不”。完整团队的敏捷实践支持这个期望。

• 持续主动地学习
  行业日新月异，我们必须跟得上它的变化。

• 指导
  最好的学习方法就是教别人。

3、权利条款
敏捷的目的就是消除业务与研发之间的鸿沟，客户和开发人员的权利是相辅相成的。

（1）客户权利

• 有权制定总体计划，并知道完成的时间的成本
  能够做到即确切又精准的唯一方法就是实际去开发项目，什么都没干是没法做到即确切又精准的。
  要想保证客户拥有这个权利，程序员必须要确保计划、估算、日程都恰当描述了不确定程度，并且要定义出减少不确定性的手段。
  简单来说，我们无法同意在固定时间期限内完成交付固定的项目范围。范围和日期必须有一个是弹性的。我们利用概率曲线来表示这种弹性，例如，在截止日期前完成10个故事的概率是95%，多完成5个的概率是50%。
  客户有权要求这种基于概率的计划，因为他们如果没有计划就无法管理业务。

• 有权在每个迭代得到最多的潜在价值
  业务部门有权利期望开发团队随时工作在最重要的事情上，并在每次迭代都可以提供尽可能大的可用业务价值。

• 有权在一个真实运行的系统上看到进展，所指定的测试都能可重复成功执行，证明系统正常工作；

• 有权改变主意，要求替换功能、修改优先级，并不用付出高昂的成本
  毕竟这是软件，软性是软件被发明的首要原因。

• 有权在时间表与估算发生变化时得到通知，以便及时选择如何缩小范围来达到项目日期要求

（2）开发权利
包含程序员、QA、测试人员、业务分析师。

• 有权知道明确的需求优先级顺序
  关键点在于知道，需求并非能做到完全精确，况且客户有权利改变主意。

• 有权保持高质量的工作输出
  业务人员无权要求开发人员走捷径或者降低质量。

• 有权向伙伴、经理以及客户提出请求并获得帮助；
  是赋予程序员沟通的权利

• 有权决定和更新自己的估算结果；
  估算永远不等于承诺，每当有新的因素出现，都可以改变估算。

• 有权决定是否承接某种职责，而不接受指派；
  专业人士承接工作，而非被指派工作。
  承接任务意味着承担责任，要对任务的质量和执行负责，要负责持续地更新估算以便管理时间表，要负责及时沟通，负责在需要时寻求帮助。

敏捷是一个支持专业软件开发的纪律框架，不是一个流程，也不是一种时尚，不仅仅是一组规则，还是构成软件开发职业道德基础的权利、期望和纪律的组合体。
信奉纪律的人接受并遵守管理者、利益相关者和客户的合理期望，他们享受并遵守敏捷赋予开发人员和客户的权利，这种对权利与期望的双向协商与彼此接受——这种职业的纪律，是软件道德标准的基石！

来源：弓长张_jack