敏捷开发-缘起

1986年,竹内弘高和野中郁次郎最早提出一种新的整体性方法,1991年,这种方法被称为Scrum,借鉴了橄榄球中的术语。1995年,萨瑟兰和施瓦伯的论文中首次正式提出Scrum概念 。

标准的Scrum中有三种主要角色, Scrum Master,确保团队合力的运作Scrum,产品负责人确定产品的方向,定义产品发布的内容、优先级、交付时间等,开发团队则拥有交付可用软件需要的各种技能。

产品订单和冲刺订单。在标准敏捷中,每一个冲刺,就是sprint中的功能来自一个大的产品订单,也就是product backlog,每一个sprint中有一个sprint backlog。

在Scrum的Standup会议上,是需要每个团队成员回答三个问题,分别是今天你完成了哪些工作、明天你打算做什么、完成目标是否存在什么障碍。

Scrum的会议包括Sprint计划会、每日站会、评审会议和回顾会议。

Scrum是强调所有团队成员坐在一起工作,及时的进行口头交流。

在大的企业中,单独团队的敏捷是一个理想的模型,一个大项目会有很多项目组成,这时候是不是不能用敏捷了呢?如果生搬硬套是不行,大项目适当的用敏捷管理,会取得更加明显的进步。

在Capital One,大的IT项目会被拆分成多个子项目,安排给各个“敏捷团队”,这种方式在“敏捷开发”中叫“蜂巢式(swarming)”,所有过程由一名项目经理控制。

为了检验这个系统的效果,Capital One将项目拆分,从旧的“瀑布式”开发转变为“并列式”开发,形成了“敏捷开发”所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行“冲刺”。每个冲刺始于一个启动会议,到下个冲刺前结束。

在与传统的开发方式做了对比后,敏捷开发使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。但是他们也觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。

Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。

1

2

敏捷开发之所以为敏捷开发,不是因为其方法(虽然方法也很重要),而是因为敏捷思想存在 。敏捷思想我通俗的说就是小步快跑。

小步快跑有两点,第一要先跑起来,多说无益,第二要快。因为这是一种思想和精神,是一种主人翁态度。很多时候,我们或许出发的时间太长,忘了在起点时候所设定的目标。不能只注重表面的形式,而忽略了内在的精神。

敏捷开发中Scrum、Sprint是这样的一种精神和态度,一种对产品,对项目的由内而外的热爱,乐于贡献的主人翁精神。每个个体都可以按照组织的最高利益,自我驱动的完成组织的目标。

第一要做到人找问题,而不是问题找人。尽量避免企业扩大团队人数多而带来的责任分散。

第二是流程与灵活的平衡,科学管理与情感精神的统一。当今商业环境快速变化,唯一不变的就是变化。冲在一线的“开发人员”是最了解系统架构和技术、开发工作量,某一件改动对项目影响的人。团队成员应该拥有在一定范围内的自我决策的能力,充分灵动的为产品创造最大价值。

在敏捷思想的指导下,有很多具体的方法,比如极限编程XP、测试驱动开发TDD、自适应软件开发ASD、特性驱动开发FDD、动态系统开发DSDM、精益软件开发LSD等,都有不同的应用场景和对团队的要求。

Ruby On Rails这样的敏捷对于2000时候的互联网发展起到了很重要的作用。2004年7月,大卫•海纳梅尔•韩森(David Heinemeier Hansson),公开了RoR框架,并响亮的提出了“敏捷的web开发”的口号。

其实这个敏捷和Scrum是有很大区别的,RoR是一种深度基于MVC框架并且崇尚设计原则包括“不做重复的事”(Don’t Repeat Yourself)和“惯例优于设置”(Convention Over Configuration)。

RoR从开发理念上来说和敏捷开发不谋而合,快速迭代、注重效率、简洁优雅。

3

Scrum为我们提供了一套非常好的项目开发管理框架,为我们打开了一扇窗,短短十几年,无敏捷,不开发。任何方法工具只有经历项目的锤炼才能发挥出其真正的价值!