前言:
本人所在企业采用了敏捷开发,拥有一套自身的“敏捷开发流程”。目前还处于僵化与优化阶段,为敏捷的本地化而探索与实践着。
作为一名软件工程师,我有幸参与到了软件的设计与开发阶段。本文以我在工作中的学习与感悟,配合一些实例解读我对敏捷开发的理解。
本文更多的是从一名程序员,一名执行者角度去解读。内容难免浅显与直白,我的目的也是在写本文的过程中通过总结与分析进一步升华对敏捷开发的理解与认识,若有错误还请诸位资深实践者及时指正,以免误人子弟。感谢!
正文:
引用wiki对敏捷软件开发的解释:
“敏捷软件开发又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。”
敏捷发展背景:
敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述。这些表述最终形成了敏捷宣言。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法,
身体力行的同时也帮助他人。由此我们建立了如下价值观:
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说,尽管右项有其价值,
我们更重视左项的价值。
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler | James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick | Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
本篇所谈的敏捷开发是一种思想、一种价值观。我的理解:各个企业制定的所谓“敏捷流程”只是敏捷思想的实例。
宣言中还包括以下原则:(蓝色字体是我个人的解读)
- 对我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要。企业看重的是利润,利润=收入-成本,开发周期缩短直接带来开发成本下降。
- 我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。开发后期如何能快速响应变化?1)开发流程中有完善的需求变更通道。2)OO,Design Pattern,低耦合高内聚,体现架构师的价值。
- 经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。时间尺度越短,功能粒度越小,每次交付一个业务或功能,测试更集中,引入问题可以及时发现与定位。
- 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。实施过程中若与原始需求出现偏差可以及时发现并校正。拉近开发者与客户的距离,也使开发者体会到自己工作的价值,增加其成就感。
- 围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。团队士气很重要,引导开发者的责任感更加重要,计划制定时要每一位开发者自己承诺交付期限,有风险及时上报。这样开发者感觉自己享受到更多信任与自由,他们更加看重自己的承诺。
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。尽量做到能够面谈的不允许电话沟通、能够电话沟通的不允许文本或邮件沟通。沟通是开发者间对对方模块了解与认识的过程,也是针对问题深入分析的过程。
- 可以工作的软件是进度的主要度量标准。可工作的软件是我们关注的价值所在,也是可以直观度量的。
- 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。开发与上线周期短,不停的开发与上线。
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性。与我第二个观点吻合。
- 简单——尽可能减少工作量的艺术至关重要。工作量减少同时意味着维护成本的降低。
- 最好的架构、需求和设计都源自自我组织的团队。每个业务或特性交付团队的Leader需要根据业务特点从资源池中挑选团队所需要的人参与到开发中,使每个人的价值能得到最大体现。
- 每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。企业需要根据自身所处领域、客户、产品交付形式、组织架构、团队素质等多方面因素制定适用于自身的开发流程。比如敏捷实践有很多,仅“结对编程”一项就不是每个企业都做得来的。