十年前对敏捷开发的体会

说明

翻到10年前的旧文，发出来。记录自己的成长。

正文

敏捷开发强调灵活性，适合小而精的团队。许多小公司10年来一直稳定在五个程序员，可能适用。

四大价值观

个体与交互甚于流程与工具。非常适合小而精的团队。沟通的成本正比于人员的平方。团队成员需要磨合才能高效沟通，所以不适合新团队，也不适合高流失的团队。
可运行的软件甚于面面俱到的文档。和客户确认需求时，如此甚好，很多时候通过文档确认需求的作用可以忽略。但文档可以记录总结、积累，和同行交流，也可培训新人。
客户合作甚于合同谈判。生产力是有限的，所以只能完成用户最需要的。只有反复谈判才能知道用户的取舍。
响应变化甚于遵循计划。具体情况具体分析。遵循计划可以避免遇到同类问题。

简单设计与测试先行

关于敏捷开发，我最认可的两个原则是：简单设计与测试先行。

简单设计，我理解的是：一，只完成系统分析师与架构师要求的需求，不要增加任何需求。二，反复优化设计，使得设计简洁。三，使用规范、惯例划分模块和命名，如果想创新，要能一句话能说明白。

工匠一，先拉上一根水平线，每砌一块砖时，都与这跟水平线进行比较，使得每一块砖都保持水平。工匠二，先将一排砖都砌完，然后再拉上一根水平线，看看哪些砖有问题，对有问题的砖进行适当的调整。工匠一就是测试先行。

Scrum（橄榄球）

类似于增量模型，每个子产品称为一个冲刺。不同点如下：一，文档少（产品订单、冲刺订单、燃尽图），且没有设计文档。二，每日站会代替工作日志。15分钟内，包括：昨天干了什么，今天计划干什么？遇到什么问题。三，需求没有评审，需求理解错误（这经常发生）的话，只有在冲刺结束的评审会才能发现。四，反思会/回顾会。有专门的时间进行反思和总结，这个有利于总结。

极限编程（XP）

极限编程的4个商业实践：一，测试驱动开发。二，结对编程。让2名开发人员共用一台电脑，写同一段代码。假定旁观者可以大幅提升效率。三，集体代码所有制和持续集成。集体代码所有制假定大家解决问题的思路完全一致，不会出现“按起葫芦浮起瓢”。持续集成可以提前发现问题。四，重构。永远保持代码处于较优状态。与Scrum的不同：没完成的需求可以被替换。