关于 Agile Software Development 的随笔

今明两天，公司从外专局联系专家给我们培训 敏捷开发，两位专家都是在国外工作20年左右的博士、大腕，经验丰富，跟他们做些沟通确实能够对 Agility 有更深的理解。

我03年底接触敏捷思想，04年充满激情的在开发团队中推广，后来基本上算是失败了，接下来几年也没有在刻意执着于什么样的名词，保留了敏捷的核心思想：沟通、质量，用自己的方式根据情况来推动开发工作。方法论方面基本上四不像，或者说我的管理手段本身就很敏捷，呵呵。

今天听两位专家讲课，并做了一些分组讨论和沟通，有几点感觉值得记下来跟大家分享：

1、敏捷并不适用于所有项目。
专家打了个比方：传统软件开发是炮弹，敏捷开发是巡航导弹。
如果是针对固定目标，使用炮弹的成本很低，而且命中率也很高。
如果是针对移动目标，则传统炮弹的命中率很低，要打中总成本很高，巡航导弹则会不断追踪目标并调整方向。

敏捷开发和传统软件开发，只是两种不同的招式，对付不同的项目，要用不同的招式，而且，经过几年的发展，现在两种方法互相融合的现象越来越明显。

2、业界对敏捷有误解。敏捷开发的最典型代表是XP，在其出现之初，由于其相对传统软件开发思想的叛逆性，其拥趸都有一定得狂热性，很多初试水者，并不是特别理性。有些人在采纳敏捷或者XP的时候，对其了解不够全面，往往会剑走偏锋，比如：敏捷说“可工作的软件重于文档”，但却被很多人理解为文档可以不要，甚至有些人在实践XP的时候，别人一提文档就会起急。

无论是敏捷还是XP，都需要适当的文档，只是XP对文档的样式要求不太严格，可以使画在纸上的草图，可以是画在白板上并拍下来的照片等等。

3、最常见的导致敏捷开发失败的原因，是部分采纳其最佳实践。
有些人看到敏捷所宣称的美好图景，只看到了其快捷、简单、自由的一面，却忽视了其严谨、复杂的一面。敏捷开发的很多实践，比如重构，比如代码共有、比如持续集成等等，都有一个最重要的前提，那就是：有完备的自动测试。而这一点，正是敏捷开发中最复杂，最难做到的，但它恰恰是核心。

做不到，又宣称自己是在敏捷开发，那么很容易演变成无序状态。因为没有手段保证重构的代码中不出现问题，随着codebase不断变大，需要救火的情况会越来越多。

4、敏捷开发是一种文化，对组织者的要求非常高。
传统软件开发管理过程，致力于通过限制和明确的规定来保证大家做的事情不跑偏。敏捷开发提倡一种文化，它希望通过激励和气氛，让所有人能够积极的参与，从而创造出更好的结果。

我个人非常喜欢敏捷开发，主要是因为书里对敏捷开发团队的工作场景的描述，太诱人了，多少年不看了，脑海里还留下如印象：
开发人员屋子的墙壁上，只要空白的地方就挂上白板，大家在白板上讨论的结果尽量不要擦掉。每个人都可以对白板上的设计图提出自己的疑问，随时展开讨论。结对编程，两个人一边沟通一边写代码，一个人敲代码，一个人在旁边提醒可能的错误，每隔一段时间互换。对代码精益求精，让人觉得是在雕琢一件艺术品。使用CRC卡片，像拍电影一样讨论故事场景和任务的分配。

这些是美好的，我也非常期待有一天我的团队能够这样工作，这需要合适的公司，合适的团队，还有，必须解决自动测试的问题。