敏捷软件开发与传统软件工程

在结对编程中，两名程序员在同一台工作站前工作，其中一个编写代码，称作驱动者；另一个在他打字的时候审查每一行代码，称作观察者或导航者。两名程序员经常互换角色。这种开发方式的最大好处是提高完成代码所需要的工资小时，但是同时显著减少程序中的缺陷。知识在不断地在伙伴之间传递，从工具（甚至鼠标）使用的技巧到编程语言的规则，设计和编程的习语，以及整体设计技巧。尤其在新手-专家结对中，新手积极参与，有名正言顺的工作要做，更能学到有价值的知识，同时新手在外围工作，不会对专家的效率有过多负面影响。最终所有人互相学习、互相信任，也都对于系统的一部分有了完全的了解。[1]在 Lui, Kim Man 等人完成的案例分析中，挑选三名能力相同的被试者，其中两人结对，重复 8 次，每次从头开始，编写一个先进先出的仓库应用，模拟新手程序员逐渐成为专家的过程。结果发现，在完成时间和在软件质量和维护的角度上，新手结对比新手独立效果更好，但是需要更多工作量；解决熟悉的问题时，独立比结对需要的工作量更少 。如下图所示，其中 REAP 定义为（结对编程用时 × 2 – 独立编程用时）／（独立编程用时）× 100%。[2]   极限编程是由 Kent Beck 在为克莱斯勒公司重写工资系统的时候发明的。1990 年代的软件开发主要受到两种潮流的影响，一种是面向对象开发方法，一种是 .com 爆炸式繁荣对于发布时间的强调，极限编程就是在这两种潮流的影响下发明的。极限编程共有如下 12 中做法[3]

1. 结对编程
2. 计划游戏（每次迭代发生一次，计划哪些要求在哪次发布中解决，以及开发者的活动）
3. 测试制导开发
4. 整体团队（客户始终在场解答问题）
5. 连续整合（整个开发团队始终处理软件的最新版本）
6. 改进设计（如果出现 1. 每次修改都需要修改相同或相近的多份代码 2. 对一个部分代码的修改影响到许多其他部分，那么说明应该改变架构）
7. 频繁发布
8. 代码规范
9. 共同代码所有权（开发团队的所有人都对代码负责）
10. 简单设计（简单的设计是好的设计，最简单的设计是最好的设计）
11. 系统比喻（将一个关于系统如何运作的故事）
12. 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 的批评是对的但是毫无必要，因为世界上总是要存在这样或那样的说辞，这些说辞从来都不是为了真的实现什么伟大的理想，只不过是用来卖。

  [1] Cockburn, Alistair; Williams, Laurie (2000). The Costs and Benefits of Pair Programming. Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000). [2] Lui, Kim Man (September 2006). Pair programming productivity: Novice–novice vs. expert–expert. International Journal of Human–Computer Studies. 64 (9): 915–925. doi:10.1016/j.ijhcs.2006.04.010.  [3] Extreme Programming, Computerworld (online), December 2001, webpage: Computerworld-appdev-92. [4] Ken Schwaber, Jeff Sutherland. “The Scrum Guide”. Scrum.org. [5] Kupersmith, Kupe. “Agile is a Fad”. https://www.batimes.com/kupe-kupersmith/agile-is-a-fad.html

相关资源：哄女孩子开心的小软件-其它其他资源-CSDN文库