敏捷开发入门

之前在这里写过若干篇敏捷开发的入门心得,后来重新做了一个整理,以此pdf为准(1M多一点),感兴趣的同好分享。

下载:敏捷开发入门_v0.0.1_20140620.pdf

国内来说,作坊居多,或者就是外企那种传统瀑布式开发,敏捷这些年在一些互联网公司开展较多,但终究还是曲高和寡。

很多人对敏捷不了解,也有很多对敏捷的误解和滥用。

不是为了敏捷而敏捷,实践最为重要。

敏捷开发-缘起

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

敏捷开发之六:测试、生产测试和beta测试

在一般项目开发中,需求方和开发的矛盾主要体现在时间和完成的功能。同样这个问题,在敏捷开发中会依然存在。

测试的重要性。为什么要有专门的测试团队以及测试的方法论这里就不多赘述了。在敏捷开发中,平行观念很重要,所以测试是可以和开发几乎一起开始的。

对于测试团队来说,一部分测试工作可以跟着Issue(User Story),当开发人员完成一个Issue开发,就可以进行功能测试。对于有些不能直接进行测试的Issue,也没关系。标准的测试案例方法还是可以使用的。在开发的初期,平行测试并不能带来很多效率提升,因为功能还没有开发好,开发好的功能一会比较零散。到了开发中后期,同步开展测试的效率就体现出来了,可以让测试的进度比开发始终只滞后一点。这在传统的瀑布开发中是做不到的。不过,这对测试人员的要求高了不少,工作强度也会增大,会产生不少反复的回归测试。我们在实际敏捷开发过程中,测试人员是一早就进入的,就是为了便于团队之间的沟通。

我们发现,测试人员提早接入还会有很多小的好处。比如,在开发过程中,开发人员需要制造一些测试数据,制造测试数据的脚本越早准备好越好,由于测试相对的提前,数据脚本的问题可以及早发现。另外,之前由于开发和测试在时间上是分成不同阶段的,而在敏捷中产品、 开发、测试几乎一直在一起,对于需求在开发过程中的具体展开有一个感性的认识。

生产测试,一般是需求方和产品经理来负责。在生产测试过程中,提出需求的部门和产品经理需要按照需求来逐个功能点进行测试。瀑布开发方式中,需求方一般要等到测试通过后才能进行测试,发现的话,需要再提交到开发,然后再经过开发-测试-生产测试的流程,这样时间当然有开销。敏捷开发模式里面,生产测试几乎和 开发、测试一起开始,发现问题的时候,通过产品经理和项目经理可以立刻就增加一个Issue或者修改功能点,以保证项目进度受到的影响最小。

公开测试,也叫beta测试,对于有用户的产品来说,让一小部分用户先开始使用,并收集意见,在下一个迭代周期中进行改进,非常符合敏捷思想。这部分其实已经不是开发的范畴了,而是产品流程的一部分。敏捷开发Scrum是按照Sprint来发布的,因此我们可以通过这样的步骤来进行一个不断迭代升级:发布一个Sprint1作为beta版本,同时继续进行Sprint2的开发测试等,同时产品经理收集beta测试中用户的反馈,进行归纳讨论后,作为Sprint3或者之后Sprint的一部分。在发布时间上,如果可以做到2-3周一个Sprint的话,那么在几个月后,用户对于产品的满意度会上升很多,并且用户会感觉他们的意见得到了重视,从而愿意更好的体验产品和提出建议。

因此,beta测试并不是给用户测试那么简单,而是在互联网、移动时代贴近用户迅速提高产品质量的一种方法。国内小米、微信等例子已经不胜枚举。说到这里,大家或许可以明白为什么Scrum方法在互联网时代突然爆发出来成为一种非常有效的方法,其在本质上就是因需而变、因用户而变。

敏捷开发之五:站会和问题解决

敏捷开发Scrum中最有趣的形式要数这个“站会”了,Stand up。原意是说站着开会效率高,估计大家都参加过很多效率不高的会,在敏捷开发中,容不得浪费时间。

按照标准的Scrum模式中,站会是每天早上进行的。对于这个定义我们在实践中做了很大的扩展。

首先,因为我们的开发时间是早上九点到晚上九点,因此我们一天开两次站会,分别是早上九点的晨站会和晚上五点的暮站会。

其次,明确站会的任务就是提出问题,只提出不解决。因为一旦要解决问题就会讨论,就可能有不同意见,然后时间就不可控。基本上我们的站会时间控制在5分钟左右。

第三,站会的流程是先检查一下之前遗留的问题是否已经解决,责任人和时间有没有问题,然后每个组、每个成员都可以提出当前碰到的问题,问题一定要描述精确,不能泛泛而谈。要有专人记录问题是否解决和提出的问题。

第四,在站会后,专人发出邮件给项目组所有成员,列出最近解决的问题、这次提出的问题和历史解决问题。每个问题都会有一个日期+序号的编号,以及问题解决人是谁,便于跟踪。这个邮件还可以抄送给不在项目组的方方面面的领导,便于了解进度和指出可能的疏漏。

最后,既然站会只是提出了问题,那么之后的时间是要解决问题的,所以除了电子邮件以外,我们还是准备了白板,一分为二,一边是要解决的问题,一边是已经解决的问题,来提醒项目组的成员。我发现这几乎是Jira的敏捷工具唯一的问题,没有提供站会的功能,我之前使用的assembla敏捷工具中是有这个功能的,那样的话就可以派发给相关人了。

从我们实践上来看,绝大多数问题都在一天内提出到解决,问题尽量不要超过一周,还是这个道理,一个sprint大约两到三周。

敏捷开发的敏捷是全方位的,包括开会和问题解决,保证每个事务的效率,才可能整体效率提高。

敏捷开发之三:关于“用户故事(User Story, Issue)”

敏捷开发中的User Story,用户故事几乎是Scrum的基础,几乎所有的流程都围绕User Story而来。

为什么要拆分Issue

这是一个内部争论的话题,为什么要把一个需求拆分成Issue。在瀑布模式中我们叫它Issue或者Ticket,中文我以前喜欢叫特性。在2000-2008年的开发生涯中,我都使用一种称之为“特性列表法”的方法来管理开发项目,因为项目组的人员不多,一般是3个人到10个人以内,包括我自己业余做的一个人的项目。拆分特性的好处主要有以下这些:

  • 更加明确需求。因为需求书和原型设计中有时候会对某些功能描述过于简单,而技术分析的角度和需求又完全不同,如果不能对需求有很好的细分,是有可能带来无用功的。颗粒度来说,最好是拆分到一个按钮点击、一次用户交互等,以前从代码来说20行-50行,现在随着各类编程语言的进步,代码量不再做强求了。从时间上来说,一般一个特性是不超过一天的,一天2-3个都是合适的。在拆分需求的时候,产品经理和项目经理是会对需求有一个再认识的,为了避免浪费时间,这里并行就很重要。通常在Sprint 1开发的时候,可以开始Sprint 2的拆分需求了,并行思想是敏捷开发中的要旨,我也会反复强调这一点。
  • 容易控制和跟踪。从2011-2013年,我参与的开发开始人数更多,流程更长。而细分特性则更有价值了。不会所有的特性都是关于需求的,比如一些纯粹技术的,但是所有的需求都是特性,甚至和开发无关的,比如用户手册。只要有开发的特性,还会涉及到code review、测试等很多环节,因此特性的控制和跟踪非常重要,只是照着需求文档去做设计,不能从根本上防止遗漏。像Jira这样的工具对于每一个Issue都提供了像简单论坛一样的回复评论、附件上传等功能,来使一个项目组的成员对于信息的共享是一致的,并且可以通过Jira的流程设置来保证Issue在不同角色中的流转。我用过的开发管理工具不多,Jira是这方面最灵活和可自定义最强的。比如一个特性开发的同事完成后,可以自动成为代码检查者的任务,然后再自动转到测试同事等,并且这个流程是可以往前和分支的。有了这样的基础,敏捷Scrum中的看板就很有用了,可以看到每一个User Story分别在什么阶段,是谁在处理。
  • 知识保存。有了上面的介绍,这点就很容易理解了。在一个项目由产品经理完成后到最后上线,总是会有各种原因的修改或者微调,在敏捷开发中这个问题更加突出,虽然传统的变更文档还是不可少的,但是多了一个基于web的记录还是不错的,对于临时加入到项目中的或者新来的同事,都是一个较好的辅助手段,来知道一些事情的来龙去脉。
  • 时间控制。这也就不用再说多了,传统的项目分析或者敏捷的燃尽图因为有了这些特性,而每个特性都有计划完成时间和实际完成时间(通过log work,也就是时间记录功能),我们可以知道项目的进度,来安排加班或者增加人手,也有可能是可以稍微放缓一点。
  • 并行控制。加快开发项目不能只是依靠加班的投入资源或者减少需求,加班太累,投入资源即便从管理成本上来说也是昂贵的,减少需求是不太可能的。所以准时上线最好的办法之一是并行控制,多核CPU当然比单核的要快,为此要做的调度也是值得的。有了拆分的特性,假设有两个网页设计、五个程序员、四个测试等,每个人的工作分配会变得相对容易。人员不可能随意安排,因为特性虽然分拆了,但是还是有一定的连续性。只是拆分特性、网页设计、开发、测试、生产验收这些能够在时间上平行,已经可以比传统的瀑布方式至少快一倍(个人经验)。

这里再补充一下,我们用的基本都是Scrum方法,因此我提到的敏捷开发、Scrum开发等是一个概念。在我们使用的Jira系统中,User Stroy用户故事(这个是敏捷特有的)、Issue特性、Defect影响、Bug错误这些在逻辑层面上都是Issue,只是Issue的不同呈现。它们都具备Issue的共性,比如内容描述、责任人、下一步责任人、计划完成时间、计划耗用时间等。

敏捷开发之二:名词解释

敏捷开发Scrum方法的常用名词解释

敏捷开发的管理其实很难,效果好,所以难。

这次开始,聊一下平时碰到的各类问题以及应对方法,抛砖引玉。

传统的开发一般是产品、开发、测试、QA、上线这些角色,敏捷就复杂一点了,角色很多,名词也不少。我们先来做名词解释。

ScrumSprint

Scrum是一种敏捷开发框架,是一个增量迭代的开发过程。在Scrum中包括了若干个小的迭代周期(有的也叫冲刺),称为Sprint。大的项目会有若干个Scrum,每个Scrum中我认为至少有2个Sprint。

Scrum强调迭代,简单的可以理解一个Sprint就是一次迭代或者一次升级发布。

从逻辑上大致可以这么理解:Project-Scrum-Sprint-Epic-User Story,Project就是项目,Epic和User Stroy后面再说。

User Story

Sprint是一个目标,所以下面的User Story可以认为是具体的需求点,一个Sprint可能有十几个到几十个User Story。敏捷开发被很多互联网公司使用,因为这些互联网产品都是面对用户,并且用户需求从产品角度是不断变化的,所以这里需求点叫做User Story。但是我们现在其实还是会涉及到一些并不直接和用户打交道的功能点,不过为了统一也叫User Story了。(Jira系统中User Story和非敏捷方式的Feature,以及测试的Defect、bug都是一个级别,也就是Issue,所以User Story等可以理解为是Feature套了一件外衣。)

User Story(aka Feature)到底拆到多细,在我们执行敏捷的时候一直有争论。比较简单的来说,这要根据不同项目的情况来区分,web项目可以是一个页面,但是一个页面上有很多按钮的话,那么User Story也可以到一个按钮的功能。同时兼顾时间,一般一个User Story在3小时左右。如果程序员素质很高的话,还可以到代码行数,比如50行代码。颗粒度太粗,不能控制项目进度,太细也没有必要。

测试一部分是根据User Story来进行,也就是说既然都说要实现的功能点,自然要测试一下,但测试还不光是测试功能点,还会有专门的案例测试、压力测试等。产品和需求方根据User Story来进行生产验收测试,是够的。

我们在敏捷中,因为把需求、Sprint拆成了很多User Story,所以测试是可以提前介入的,但是会增加很多回归测试的工作量,对于交付时间来说是划算的。但对测试本身的工作量和要求来说,也提高了,这也是为什么说敏捷对于人员要求高的另一个原因。

测试的结果会有Defect或者Bug,这个测试包括开发测试和生产验收测试,比如在Firefox下打开页面菜单栏有5个像素移位,这是Defect,比如在Firefox下打开登陆页面后登陆浏览器报错,这是Bug。Bug基本是一定要解决的。Defect不一定,特别是在敏捷中,是可以区分优先级后放到之后的Sprint中的,这个取决于产品经理、项目经理、开发、测试等共同商量。

一个User Story从建立到开发到测试完成,也就close了。我们就是根据这个来查看、判断进度,做需求和资源调整。

Epic

Epic类似于传统的里程碑,在一些大的项目中需要。如果Sprint周期在2-3周,Epic意义不大。

Issue

项目开发管理中Issue的状态有已经建立、在开发、在测试、完成。

每一个Issue都是有估计时间的,最小单位30分钟,最多一般不超过3小时,和建立User Story的原则一致。

Stand up

Scrum每天有一个Stand up站会的要求,我们目前把站会简化成review上一日存在问题和提出目前问题,同时因为考虑到有时候开发在晚上有工作量,因此站会有两个,分别为晨站会和暮站会(很有诗意的名字),站会后邮件给到大家。(Jira的敏捷插件做的非常好,包含了几乎所有敏捷管理需要的工具和功能,但是站会没有看到小结的电子化工具,因此这部分用邮件),站会邮件中的问题列表是有日期编号的,提醒产品经理、项目经理、Scrum Master关注多日未解决问题。并且这样的话,比起纯粹站会或者邮件多了一个可追朔。每个问题都会有提出人、解决人、解决时间等。

对于Story Point,我个人认为意义不大,因为每一个Issue的Story Point的估计和时间估计是重复的,虽然说Story Point可以更加客观的评估,但是我认为项目管理是为了结果而不是为了评估,同时通过时间和一些后期设定也是可以完成项目评估的。要敏捷的话,该省的地方就一定要省。

敏捷开发中,对于项目开发的相关文档是另一个有争议的话题,我们这里一般瀑布管理的开发流程大约一个项目30-40个文档,那么敏捷是否可以减少文档的数量呢,在减少的同时怎么保证知识共享和知识传递呢?

敏捷开发之一:开篇简介

敏捷开发总论: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的时间控制,根据开发和项目发展的情况进行适度调整。