敏捷与速度

敏捷与速度

陈能技

2007-12-25

 

原文：From Here to Agility：The Physics of Speed – Linda Hayes

 

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

 

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

 

减少摩擦

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

 

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

 

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

 

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

 

提高速率

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

 

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

 

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

 

扩大不确定性

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

 

更重要的是，缺少正式的程式会增加不可预见的更改带来影响的风险。如果缺少文档，后续的开发人员不能很好地理解软件的各个方面，以及如何运转，将会增加犯错误的机会。而且缺少需求和用例，将来的测试人员会更容易漏测一些功能。

 

对于很多人来说，敏捷给人的感觉是把小心谨慎抛之“九霄云外”，一头扎进混乱中去。毕竟，传统的过程已经被认为是不必要的了 – 从课程上学到的。

 

扩大包括的范围

尽管瀑布模型和类似的模型有存在的理由，但是其中的很多理由已经不再成立。早期使用计算机的目的是通过把手工过程加速来提高生产率，代码被小心翼翼地通过图表设计，并且从头到尾手工构造出来。软件开发可以 - 并且也确实是 – 花上几年的时间来完成。

 

然而今天的软件则专注于竞争 – 让过程和产品不能被手工复制，通常通过快速地组装各种组件和服务。不再是为了生产率，而是持续发展。整个市场形势可能在一年中剧烈地改变，因此速度不仅仅是需要的，而是必要的。每人会关注一个在4月16号以后发布的税务软件，即使它是多么的优秀。

 

那么你如何弥补因为缺乏正式的程式和更短的周期规划带来的风险呢？把所有利益相关方包括进来。

 

与其使用文档来与用户、分析师、开发人员、测试人员和技术文档编写人员进行信息的交流 – 这些人中的每一位都负责进度表中自己的那一部分任务 – 敏捷方法要求即时的、直接的、面对面的交流。讲和听会比读和写花费更少的时间，通过讨论要比通过编辑文档更容易暴露不确定性。这样，通过上下文来驱动进度，而不是通过其他方式。

 

但是这种方法的最显著的影响莫过于不再是业务需要IT企业的发布日期，而是业务决定什么时候得到自己的需要。这种责任的转移是关键的，因为IT企业不再负责“按期”发布，更需要防范变更。

 

这是管理层在考虑敏捷时经常遗漏的。经理们设想敏捷改变了IT操作方式，实际上，敏捷需要整个组织的改变。除非大家接受了这个新的模型中的角色和职责，敏捷开发只是一时的狂热，承诺的比实际得到的少。