敏捷软件开发与传统软件工程
2001 年 2 月，17 个软件开发者在犹他州见面，讨论轻量的软件开发方法。他们发表了敏捷软件开发宣言，全文如下：“个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。也就是说，尽管右项有其价值，我们更重视左项的价值。”此后，敏捷开发迅速发展，受到了广泛的关注和采用，也发展出了许多分支，其中本文主要讨论三种敏捷开发方法：结对编程，极限编程和 Scrum。
- 结对编程
- 计划游戏（每次迭代发生一次，计划哪些要求在哪次发布中解决，以及开发者的活动）
- 测试制导开发
- 整体团队（客户始终在场解答问题）
- 连续整合（整个开发团队始终处理软件的最新版本）
- 改进设计（如果出现 1. 每次修改都需要修改相同或相近的多份代码 2. 对一个部分代码的修改影响到许多其他部分，那么说明应该改变架构）
- 频繁发布
- 代码规范
- 共同代码所有权（开发团队的所有人都对代码负责）
- 简单设计（简单的设计是好的设计，最简单的设计是最好的设计）
- 系统比喻（将一个关于系统如何运作的故事）
- 40 小时（所有的开发者每周工作只 40 小时）
Scrum 是一种轻量的，易上手，难精通的软件开发方法，建立在经验的过程控制理论上，使用迭代递增的方法最大化可预测性和控制风险。经验的过程控制都有的三个支柱：“透明”，“检查”和“适应”。“透明”是指过程的重要方面必须被负责成果的人知道，大家使用同一种通用语言，执行者和接受者必须对“完成”有相同定义。“检查”是指用户必须经常将 Scrum 的架构和过程与一个冲刺目标比较，以发现不受欢迎的变化。而“适应”是指如果发现偏离必须及时修正。Scrum 推崇的价值是付出，勇气，专注，坦诚和尊重。
Scrum 团队主要有三个组成部分，即产品所有者（Product Owner），开发团队和一个 Scrum 大师（Scrum Master）。
- 产品所有者负责管理产品积压，包括：清楚地表达产品积压项，将产品积压项排序来最好地实现目标，最大化开发团队的工作的价值，确保产品积压对每个人透明，表明开发团队下一步的工作，确保开发团队对于产品积压项理解到位。
- 开发团队负责实现一个可能可以发布的已完成项目的增量，有如下特征：自组织（没有人可以告诉他们如何把一个产品积压变成增量），多功能（拥有需要的所有技能），所有的成员都只是开发者，不存在小组，不同的人可能有不同的特长，但是整个团队共同负责。
- Scrum 大师负责确保整个团队理解和践行 Scrum，既帮助产品所有者也帮助开发团队。
Scrum 包括四个活动
- 冲刺计划（每个一月的冲刺最多计划 8 小时，包括做什么和怎么做）
- 每日 Scrum（15 分钟，同步进展，计划第二天的工作）
- 冲刺复习（每个一月的冲刺最多复习 4 小时，每一个冲刺结束时检查增量和调整产品积压，Scrum 和付款人共同参加，开发团队讲解已经完成的增量，产品所有者讲解产品积压，如果有需要给出完成日期，整个团队为下一次冲刺计划做准备）
- 冲刺反省（每个一月的冲刺最多计反省 3 小时，在复习和下一次计划中间，识别出下一次冲刺中可以采取的改进）[4]
在我看来，敏捷软件开发和传统软件工程，无非就像保险公司推销员的合同，卖菜大妈的秤杆和秤砣，说白了，都是为了卖。客户对传统软件工程的条条框框拖拖拉拉烦了，于是就有人发明出敏捷软件开发这一套说辞，无非是说给买的人听。程序员们其实也从来没有（也不应该）指望，换了一种开发方法，自己的效率就能够提高多少，毕竟卖的还是那些菜。
Kupersmith Kupe 曾经直接指出 "Agile is a Fad"。也就是说敏捷无非是把之前好的做法换了一个行话来表达，是一个一时兴起的风尚。他指出敏捷开发是在推崇一种“一个型号适合所有人”的想法，是在错误地强调方法论而不是结果。[5]传统软件工程的团队里程序员要写不知所云的文档，要与可怕的产品经理沟通，每次延期都要好说歹说，但是敏捷软件开发的团队里程序员也要“actively contribute”，也要几天发布一个小版本，要与更可怕的客户直接沟通。其实真的无所谓高下。
为什么从来没有一种软件开发方法彻底统领天下？为什么就算是敏捷软件开发都分了几十个小的分支？为什么极限编程的第一个做法是结对编程？无非是因为要卖的出产品就要见人说人话见鬼说鬼话。客户不满意了，软件做不出来了，我们就批判一下自己的路线，说之前的开发方法不够敏捷，之后我们来敏捷开发，哄过了这次 deadline 就万事大吉。Kupe 的批评是对的但是毫无必要，因为世界上总是要存在这样或那样的说辞，这些说辞从来都不是为了真的实现什么伟大的理想，只不过是用来卖。
浙公网安备 33010602011771号