说明
翻到10年前的旧文,发出来。记录自己的成长。
正文
敏捷开发强调灵活性,适合小而精的团队。许多小公司10年来一直稳定在五个程序员,可能适用。
四大价值观
个体与交互甚于流程与工具。非常适合小而精的团队。沟通的成本正比于人员的平方。团队成员需要磨合才能高效沟通,所以不适合新团队,也不适合高流失的团队。
可运行的软件甚于面面俱到的文档。和客户确认需求时,如此甚好,很多时候通过文档确认需求的作用可以忽略。但文档可以记录总结、积累,和同行交流,也可培训新人。
客户合作甚于合同谈判。生产力是有限的,所以只能完成用户最需要的。只有反复谈判才能知道用户的取舍。
响应变化甚于遵循计划。具体情况具体分析。遵循计划可以避免遇到同类问题。
简单设计与测试先行
关于敏捷开发,我最认可的两个原则是:简单设计与测试先行。
简单设计,我理解的是:一,只完成系统分析师与架构师要求的需求,不要增加任何需求。二,反复优化设计,使得设计简洁。三,使用规范、惯例划分模块和命名,如果想创新,要能一句话能说明白。
工匠一,先拉上一根水平线,每砌一块砖时,都与这跟水平线进行比较,使得每一块砖都保持水平。工匠二,先将一排砖都砌完,然后再拉上一根水平线,看看哪些砖有问题,对有问题的砖进行适当的调整。工匠一就是测试先行。
Scrum(橄榄球)
类似于增量模型,每个子产品称为一个冲刺。不同点如下:一,文档少(产品订单、冲刺订单、燃尽图),且没有设计文档。二,每日站会代替工作日志。15分钟内,包括:昨天干了什么,今天计划干什么?遇到什么问题。三,需求没有评审,需求理解错误(这经常发生)的话,只有在冲刺结束的评审会才能发现。四,反思会/回顾会。有专门的时间进行反思和总结,这个有利于总结。
极限编程(XP)
极限编程的4个商业实践:一,测试驱动开发。二,结对编程。让2名开发人员共用一台电脑,写同一段代码。假定旁观者可以大幅提升效率。三,集体代码所有制和持续集成。集体代码所有制假定大家解决问题的思路完全一致,不会出现“按起葫芦浮起瓢”。持续集成可以提前发现问题。四,重构。永远保持代码处于较优状态。与Scrum的不同:没完成的需求可以被替换。