《敏捷之旅》认识一下敏捷(1)

第一部分:敏捷方法

1.1认识一下敏捷

说不清的“敏捷”

经常有人问:“能和我说一下敏捷是什么吗?“虽然敏捷出现很久了,但“敏捷”一词的具体含义却有点混乱。有人说敏捷是:

  • 敏捷是一种迭代方法

  • 敏捷注重反馈与响应

  • 敏捷是留下必须要有的,去掉想要却不需要的

  • 敏捷是一种轻量级过程,不需要那么多文档了

  • 敏捷是一种思想、一种艺术、一种精神

  • 敏捷是凝聚集体智慧的,让软件生产过程变得有趣和高效,同时节约成本

  • 敏捷是一种实践,光是理念理论敏捷就失去了意义

  • 敏捷是一个单词

  • ……

往往在这么回答之后,提问者依旧感到迷茫,或者感到更迷茫J然而这也不是我们的错,因为“敏捷”本来就是我们抽象出来的一个代名词,想要获得关于它的统一定义真的不容易。

虽然我们难以统一定义敏捷是什么,但是我们在敏捷不是什么应该较为容易达成一致,例如:

  • 敏捷不是一个流程和一种方法(XP、Scrum、Kanban才是方法)

  • 敏捷不是一套固定模板(敏捷有多种方法,每种方法有自己的模板)

  • 敏捷不是一些可直接重用的实践(敏捷有最佳实践,但是每个团队都可以有所选择,并且可以形成自己的实践)

  • ……

不过一个大家都关注的词频频出现时,终究我们还是需要为提问者提供一种较为完整而清晰的解释。那到底什么是敏捷呢?

每本书都代表着作者自己的观点,我先说出我对敏捷的一句话理解,再慢慢细数敏捷的前世今生:敏捷是一种以人为本的轻量级开发方法论,它在价值观指引下通过一系列最佳实践来凝聚集体智慧,能让团队快速响应的为用户持续交付最有价值的产品。 

敏捷诞生的历史背景

任何一个新的事物产生一定有着其历史,让我们先来大概看看软件时代的发展历程:

  1. 1960-1969年软件作坊时代:软件开始作为一种产品被广泛使用,出现了软件作坊专职应别人需求写软件,这个时期的软件规模都还很小,基本上沿用个体化软件开发方式。

  2. 1970-1979年软件危机时代:随着硬件飞速发展,软件规模和复杂度激增带来的开发和维护难度越来越大,失败的项目屡见不鲜,从而引发软件危机,这个时期提出软件工程。

  3. 1980-1989年瀑布时代,引入成熟管理方法,以“过程为中心”分阶段来控制软件开发,一定程度上缓解了软件危机,但开发成本高,开发周期过长。

  4. 1990-1999年重型过程时代,软件失败的经验促使过程被不断增加约束和限制,软件开发过程日益“重型化”,使得开发效率降低、响应速度变慢。

  5. 2001-至今,随着信息时代到来,卖方市场逐渐向买方市场转化,客户的影响力越来越大,在需求加速变化的现在,原有的软件开发模式已经难以适应这种以用户为中心、需要快速响应变化的时代,那我们希望迎来什么样的新时代呢? 

雪鸟生出敏捷宣言

在2001年2月,有17个软件开发领域的软件顾问和思想领导人,参会者们包括来自于XP、Scrum、DSDM、ASD、Crystal、FDD等代表,还包括希望找到现有开发过程替代品的一些推动者。他们聚在美国犹他州瓦萨奇山雪鸟滑雪胜地,试图找到一种新时代软件开发过程的统一定义。但是大家也知道,要对新的开发方式达成一致是很难的,因为他们每个人都有着自己如何建立一个成功软件的观点,令他们开心的是,最终大家共同签署了《敏捷软件开发宣言》来达成共识。

 

                           

宣言很简单,其实就是4句“A胜过B”的话,换句话,尽管右边陈述的条目有价值,但敏捷更强调左边陈述的价值:

  1. 个体和交互 胜过  流程和工具

  2. 工作的软件 胜过  详尽的文档

  3. 客户合作    胜过  合同谈判

  4. 响应变化    胜过  遵循计划

 

基于这些价值观,大家还整理了敏捷实践的12条原则供大家更多参考

1.   我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

2.   欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

3.   经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

4.   业务人员和开发人员必须相互合作,项目中的每一天都不例外。

5.   激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

6.   不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

7.   可工作的软件是进度的首要度量标准。

8.   敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9.   坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

10. 以简洁为本,它是极力减少不必要工作量的艺术。

11. 最好的架构、需求和设计出自自组织团队。

12.团队定期地反思如何能提高成效,并依此调整自身的举止表现。 

 

如果想确定现在做的是不是敏捷,那么可以参考宣言,你现在的行为更多是左边一列还是右边一列。也可以参考每条原则,看看自己是否在这么做。

然而,这些原则条数太多,能记住下来的人不多。而且如果想深入了解敏捷,这几句简单的宣言和原则是远远不够的,那我们应该从哪种角度去深入了解呢?

(......待续)

你可能感兴趣的:(《敏捷之旅》认识一下敏捷(1))