敏捷开发之二:名词解释

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