敏捷与速度

　我开始对敏捷的狂热感到惊讶。敏捷看起来成了快速的代名词，就像他们说的：“我们每个月发布一次，我们变得敏捷起来了。”但是你并不是因为更快而敏捷，你是因为敏捷而更快。事实上，如果你什么也不做，仅仅是缩短了发布周期，而其他什么都一样的话，你会比以前完成更少的工作。

　　明白敏捷开发如何让你更快速 – 而不是相反的 – 是让敏捷工作的关键。

减少摩擦

　　敏捷开发与传统方法的核心区别在于让变更变得更友好。这不意味着你需要笑着迎接变更；它意味着期待变更，并且让变更带来的影响最小化。换句话说，你通过减少摩擦来赢得速度。这可解释为更少的程式和相关的管理。 

　　在瀑布模型你从业务需求分析开始，然后开发功能需求。随后是功能需求被用于描述用例，用例由测试用例验证和为最终用户文档化。软件围绕着高层设计来组织，然后由低层设计来细化和解析并转换成代码。这种阶梯式的行进方式实际上是在避免变更：我们设想通过系统的、全面的方法可以完全防止变更发生的必要性。

　　敏捷方法在脑海中始终保持这种逻辑思维：断言变更就是标准。软件反映的就是用户的需求，而用户是在一个动态改变的组织中，处于一个充满竞争的市场。因此，你永远也不可能真正预知什么是需要的 – 你只能适应它。为了避免对相同功能的多个表达方式的变更，需求被归纳成为索引卡；功能需求和用例被分解成测试用例；而代码则表达了设计的思想。

　　因此，通过减少大量的输出，我们可以减少变更所需要的工作量。

提高速率

　　敏捷模型的另外一个响应变更的方法是通过更小的迭代。不仅仅是更短，而是更小。与其收集所有可能的需求然后分配到一系列的迭代周期中，我们专注于目前的迭代。规划的周期越长，你就会越倾向于抵制变更：细化一个迭代周期只会带来下一个迭代周期的代价，让你脱离进度。

　　这个思想的背后是：用户在直到看到真正的产品之前是不可能真正知道他们自己需要的是什么。需求文档就像散文一样可以用不同的方式解释，但是代码操作只有一种方式。我们往往发现：当软件产品最终暴露在用户面前时，才发现需求文档充满了错漏和误解。

　　因此，用户能越快见到软件，与软件交互，你就越快知道软件是否满足他们的需求，即使不满足需求，你需要改动的东西也会比较少。

扩大不确定性

　　对敏捷方法抵制，不管是公开的抨击还是悄悄的害怕，都是由于敏捷论引入了不确定性。你不能预见下一个迭代，更不用说真正的发布，因为每一个迭代周期都可能包括新的功能或者对已有特性的调整。而如果你不能预见迭代的话，如何能计划发布呢？

　

原文转自：http://www.ltesting.net