十年前对敏捷开发的体会

简介: 十年前对敏捷开发的体会

说明

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

正文

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

四大价值观

个体与交互甚于流程与工具。非常适合小而精的团队。沟通的成本正比于人员的平方。团队成员需要磨合才能高效沟通,所以不适合新团队,也不适合高流失的团队。

可运行的软件甚于面面俱到的文档。和客户确认需求时,如此甚好,很多时候通过文档确认需求的作用可以忽略。但文档可以记录总结、积累,和同行交流,也可培训新人。

客户合作甚于合同谈判。生产力是有限的,所以只能完成用户最需要的。只有反复谈判才能知道用户的取舍。

响应变化甚于遵循计划。具体情况具体分析。遵循计划可以避免遇到同类问题。

 

简单设计与测试先行

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

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

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

Scrum(橄榄球)

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

极限编程(XP)

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

 


相关文章
|
6月前
|
开发者
拥抱不确定性:在软件开发中实践敏捷思维
【4月更文挑战第27天】 在不断变化的技术领域,不确定性是一种常态。本文探讨了如何在软件开发过程中采用敏捷思维来应对和利用这种不确定性。通过分析敏捷方法论的核心原则,我们将了解如何通过迭代开发、持续反馈和适应性规划来增强项目的灵活性和响应性。文章将提供实用的策略和实例,帮助读者在技术项目中实施敏捷思维,从而更有效地管理复杂性和变化。
51 2
|
6月前
|
敏捷开发 Kubernetes Docker
拥抱变化:我的敏捷开发之旅
【4月更文挑战第25天】 在快速迭代的软件开发世界里,我经历了从瀑布模型到敏捷开发的转型。本文记录了我在实践敏捷方法中的技术感悟,探讨如何在不断变化的需求中寻找平衡点,提升团队的反应速度和产品质量。我将分享实施敏捷过程中的挑战与成长,以及如何通过持续学习与改进,让敏捷成为推动项目成功的动力。
|
6月前
|
敏捷开发 开发框架 持续交付
【软件工程】航行敏捷之路:深度解析Scrum框架的精髓
【软件工程】航行敏捷之路:深度解析Scrum框架的精髓
|
6月前
|
敏捷开发 安全 测试技术
拥抱不确定性:软件开发中的敏捷思维与实践
【4月更文挑战第17天】 在快速变化的技术世界中,不确定性已成为常态。本文探讨了如何在软件开发过程中应用敏捷思维来应对和利用这种不确定性。通过分析敏捷方法论的核心原则,我们揭示了它们如何帮助团队更灵活地响应变化,提高产品质量,并最终实现持续交付。文章还将分享一些实用的敏捷实践技巧,以及如何在团队中培养这种思维方式。
|
敏捷开发 持续交付 项目管理
艾伟也谈项目管理,敏捷开发,在路上
  如果有一种方法能使你的软件缺陷率降低63%,核心缺陷率降低79%,整体投入减少62%,整个项目开发的时间缩短69%,你会采用这种新的软件开发方法吗?   在回答这个问题之前,你可能会问:是什么方法能达到这样的效果?答案是:敏捷开发。
1218 0
|
敏捷开发 测试技术