敏捷less框架 敏捷开发管理框架_敏捷开发


本系列对敏捷开发的相关基础知识做一个大概的梳理,后续各部分将会结合作者自身的工作经验详细的介绍。

敏捷开发是指一套软件开发方法,鼓励干系人之间持续合作并快速、频繁以小增量的方式交付有用的功能。敏捷方法种类繁多,其中最流行的包括Scrum、极限编程、精益软件开发、特性驱动开发以及看板方法。敏捷方法基于以前的迭代和增量式软件开发方法(最早见于Boehm 1988;Gilb 1988;Larman and Basili 2003)。

各种敏捷开发方法各有千秋,但是本质上都离不开适应性(有时称为“变化驱动”)方法,而非预测性(有时称为“计划驱动”)方法(Boehm and Turner 2004;IIBA 2009)。预测性方法视图在软件开始构建之前通过周密的策划和文档将项目的风险降到最低,比如瀑布开发就是预测性方法;项目经理和业务分析师要在开始构建之前就确保所有干系人都准确了解要交付什么产品,只有需求从一开始就得到充分理解,并且在项目期间能够相对稳定,这种方法才能可以很见效。敏捷方法等适应性方法旨在适应项目中发生的不可避免的变化,它们对需求高度不确定或波动的项目也很有效。

目录索引

(一)与传统的瀑布模型对比(二)敏捷开发基本概念(三)如何进行敏捷开发


敏捷less框架 敏捷开发管理框架_敏捷less框架_02


(一)与传统的瀑布模型对比

如果我们把通常软件工程的普遍环节划分为分析、设计、实现、测试和交付,并将其按此顺序重叠为一个完整物体(类似于盖房子)。那么对于传统的瀑布模型来说,是以垂直方向累积成果的,各个环节之间存在着前后的依赖关系,各环节投入的人力成本与积累产物百分比并不相关,并且对于变更的适应性和应对风险的能力都较差。


敏捷less框架 敏捷开发管理框架_敏捷开发框架_03


一般在瀑布开发项目中,为了尽量使整个需求集合“正确”,团队会投入大量的精力;即便如此,也几乎没有项目会使用完全串行的瀑布方法,在各阶段之间总会有某些重叠和反馈。

在从完全固定的、预测性的项目到完全不确定、适应性的项目之间的范围中,关键区别在于从某个需求创建到基于这个需求的软件交付给客户所经过时间的长短。

与之相对应的敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。对于需求范围不明确,需求变更较多的项目而言,可以很大程度上响应及拥抱变化。敏捷开发可最大程度体现80/20法则的价值,通过增量迭代,每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。


敏捷less框架 敏捷开发管理框架_瀑布模型_04


借用一个形象的例子,可以生动的诠释二者的区别:

  • 敏捷开发客人到餐馆来点菜(新项目)
  • 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
  • 根据图文菜单,客人点了个菜(根据原型和设计稿,基本确定了需求)
  • 后厨开始准备(项目启动)
  • 配菜、炒菜,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)
  • 客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)
  • 上菜过程中,客人突然发现有个菜的味道太淡了,让后厨加了点盐又端上来了(敏捷的好处,可以不断测试和需求变更)
  • 又上了两盘,不够辣,又拿到后厨加了辣(敏捷的坏处,需求没有提前明确,反复迭代,增加了工作量)
  • 到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)客人吃完,很满意(基本满足了全部的要求)
  • 瀑布模型开发
  • 客人到餐馆来点菜(新项目)
  • 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
  • 根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)
  • 后厨开始准备(项目启动)
  • 根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)
  • 半个小时了,菜还没上桌,客人饿极了(项目启动后很长一段时间客户什么都看不到)
  • 再过了二十分钟,十个菜都一起上来了(项目最终一次交付)
  • 客人说,有几个菜挺好的,但是有个菜味道淡了,有两个不够辣,还有两盘重复了想换掉(我是买单的,我要变需求)
  • 这时候大堂经理来了,说,“味道淡了可以加盐,不辣可以加辣,但是换菜不行,已经炒好的那两盘菜也是要算成本的”(瀑布的坏处,需求变更比较麻烦)
  • 于是,后厨只给客户加了盐,加了辣
  • 客人吃完,不是很满意,下次不来了(没有满足需求)

但总的来说,在现在管理项目过程中,并没有严格的按照完全的敏捷或者完全的瀑布模式,都是各自掺杂了其他的方式。在实际项目过程中,过于强调模式并没有意义,重要的是能不能预防问题的发生,在问题发生之后能不能用最小的成本解决,模式更多起一个参考作用,如果选择了某一种模式(这种选择可能是在经营层层面上的),那么就一定要按照方法论结合自身公司或项目的实际情况,严格的实施,才有可能从这种模式中获得对公司或项目的益处,否则只会徒增成本,徒劳无功。