敏捷开发-缘起

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

敏捷开发之一:开篇简介

敏捷开发总论:IT开发项目中使用敏捷思想的Scrum开发方式。

从2005年开始研究如何可以让技术项目开发的更快更好,2011年前尝试过很多方法,我自己总结为这些是半敏捷的办法,有一定的敏捷思想,然后还不是很成体系,同时对于需求分析和测试、质量控制兼顾不够,当时的测试更多的是生产验收测试。2012年开始,一方面继续对半敏捷的方法进行实践,同时也开始试验基于敏捷框架实现的Scrum方法,通过连续的Sprint,来保证项目的迅速开发和迭代。

目前我们使用的是基于Scrum为主的敏捷开发方法,一次Scrum至少有2-3个Sprint,比较复杂的项目会有几个Scrum并行。

对于从需求提出、需求分析、技术分析、开发、测试、生产验收、生产配置等环节的主要流程基本支持的很好,新项目不算的话,一个Sprint基本可以在两周完成。并且在单元测试、案例测试、功能测试、生产验收测试上总结出一套行之有效的方法,达到敏捷开发的核心思想:快速+质量。

敏捷团队大约15个人左右,再多就不太好管理了,基本涵盖产品、UED、开发、测试等team,加上Scrum Master和QA等,20个人里面效率比较高。如果实在要超过20个人,建议分拆成不同的大team,单独配置Scrum Master和QA。

我们用的敏捷工具主要是Jira+GreenHopper,因为我们大部分的瀑布式项目还是基于Jira,所以用了Jira的敏捷插件后,对于Issue层面的管理没有什么问题,电子看板、燃尽图、Epic-User Story等Scrum特有的功能学习起来也很快。

我对敏捷开发的基本思想是兵无常势,水无常形,不拘泥于敏捷理论,通过对Scrum-Sprint-Epic-User Story/Defect/Bug的拆分,通过对每个Issue的时间控制,根据开发和项目发展的情况进行适度调整。