十年前对敏捷开发的体会

闻缺陷则喜何志丹

已于 2023-10-28 09:21:44 修改

阅读量294

点赞数 1

分类专栏：软件架构师何志丹文章标签：橄榄球设计先行测试先行极限编程敏捷编程结对编程交互

于 2023-09-26 18:14:10 首次发布

本文链接：https://blog.csdn.net/he_zhidan/article/details/133319300

版权

软件架构师何志丹同时被 2 个专栏收录

91 篇文章 0 订阅

订阅专栏

软件架构师何志丹的积累与扩展

34 篇文章 2 订阅

订阅专栏

说明

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

正文

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

四大价值观

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

简单设计与测试先行

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

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

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

Scrum（橄榄球）

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

极限编程（XP）

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