什么是敏捷开发

传统的软件开发模式:瀑布模型

瀑布模型是软件开发企业使用最多的开发模型,它把大型软件分成几大工序:需求分析、系统设计、程序编码、软件测试。

大致流程是:

先采集用户需求,需求人员做需求分析,形成《需求规格说明书》交由设计人员进行系统设计,再形成《设计说明书》交由编码人员开发,最后形成软件并进行测试。

瀑布模型就像工厂流水线,前一个阶段的输出就是下一个阶段的输入,形如瀑布流水。

瀑布模型在软件工程中占有重要地位,瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。

瀑布模型的缺点

瀑布模型不适合需求不断变化的场景

在软件开发过程中,一是开发人员要弄懂用户想要什么,也就是需求分析,但往往最终做出来可能并不是用户想要的;二是有时用户也不知道他想要什么,经常新增或变更各种需求;三是有些产品前期没有真正意义上的用户提供需求,或者市场竞争激烈,需要尽可能快的验证产品;

瀑布模型很难提前发现风险

即使前期花在需求上的时间足够长,有些需求注定会在设计实现或用户使用过程中才逐渐出现。另外由于开发是线性的,用户只有等到整个过程的末期才能见到开发成果,早期的错误可能要等到开发后期才能发现,进而带来严重的后果。

以上几种情况都会导致出现返工,按照瀑布模型,可能要从需求分析或者系统设计开始返工,极大地增加了返工或变更成本。

什么是敏捷开发

敏捷开发的通俗解释:

如果把软件开发比喻成是要做一桌好菜。

瀑布模型是先了解清楚客户想吃什么菜,口味是什么样,然后将所有菜做齐一起送上桌。

敏捷开发是先做了一道菜,尝了一下感觉还行,就先把一道菜摆上来,之后继续做下一道菜,同时根据客户的反馈,再改良菜的味道,不断迭代,直到做出一桌好菜来。

敏捷开发的专业解释:

敏捷来源于精益思想,精益思想是20世纪80年代日本丰田发明的生产方式,其核心思想是消除浪费,创造价值。敏捷是精益思想在IT行业的一种应用。

敏捷开发拥抱变化,是应对快速变化的需求的一种软件开发模式。

相对于“非敏捷”,敏捷开发更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

人是获得成功最重要的因素。

一个优秀的团队成员能很好地和他人合作,即合作、沟通以及交互能力要比单纯的编程能力更重要。

合适的工具对成功很重要,但不要过分夸大工具的作用。

团队的构建比环境的构建重要得多。

没有文档的软件是一种灾难,但过多的文档比过少的文档更糟糕。

对团队而言,需要编写并维护一份系统原理和结构方面的文档。

成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述,而是让软件的客户和开发团队密切地在一起工作,并尽量经常提供反馈。

那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。

响应变化的能力常决定一个软件项目的成败。

计划不能考虑过远。

较好的做计划的策略是:为下两周做详细的计划,为下三个月做初略的计划,再以后就做极为初略的计划。

敏捷团队建设

敏捷开发团队人数一般在10人以内,这样才能使敏捷中主要的沟通方式“面对面”是可行的。

如果是数十人的大型项目,可以拆分成若干个小项目,分成几个敏捷团队,每个团队控制在10人以内。

敏捷开发强调把关注点回归到“人”上,对团队成员要求很高,从能力到态度上,一个优秀的团队成员能很好地和他人合作,即合作、沟通以及交互能力,有时候要比单纯的编程能力更重要。

同时主张面对面交流和客户参与开发, 弥补了缺少文档而产生信息流通不畅问题, 认为开发人员之间、开发人员和客户之间相互协作、相互信任、彼此尊重是保证沟通成功的必要条件。

敏捷的几种工具

  1. 站立会:每天召开站立会,围绕三个问题:昨天完成了哪些工作?明天计划完成哪些工作?哪些阻碍性问题可能影响工作?
  2. 看板:将工作进度可视化,反映流程遵守情况,反映流程缺陷。
  3. 用户故事:站在用户的角度讲需求。
  4. 持续集成:随时高质量交付的基础,有利于应对变化剧烈的市场。

总结

对于敏捷开发,不应该理解为更快,而应该理解为更灵活。

瀑布模型也好,敏捷也好,都不能盲目的迷信。就像敏捷适用于需求快速变化的场景,但并不是所有的项目都适合敏捷。而传统的瀑布模型已存在了几十年,被无数次验证是可靠的软件开发模式,因此还是有它的可取之处。

好的方法和工具能使优秀的人更加优秀,但不能使平庸的人变得优秀。

Table of Contents