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

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

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

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

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

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

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

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

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

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

敏捷开发之四:主要流程

敏捷开发的目的是为了快速交付,通过精细化的项目管理来保证质量和开发的平衡。一个利用敏捷开发方式进行的项目多半是具有持续性的。 我们经过很多项目的实践的敏捷开发项目的大致流程如下,对于团队搭建、场地准备等先不多说了,这些最好另有专人在立项后决定用敏捷的时候就都准备好,防止后面的忙乱:

  1. 需求讨论。发起人是提出需求的BD、产品经理、研发团队的项目经理和主要的参与人员,包括UED、测试、QA和敏捷顾问(Scrum Master)。在时间资源允许的情况下,尽量早参加产品需求的各类讨论总有益处。需求讨论需要明确这次产品大约做什么功能,大致划分几个阶段。难点是需求和开发在时间上要取得共识。开发时间在敏捷中可以理解为固定的2-3周(一个Sprint),那么这2-3周的产出到底是多少,需要协商讨论。很多时候需求讨论都需要2-3次会议才能完成。需求讨论会议的重要性在于定好一个大的基调,甚至包括是否用敏捷开发方式。开会虽然也耗费资源,但是比起到了开发阶段推倒重来还是划算的太多了。需求讨论之后,产品需求文档、原型图等都要准备好了。
  2. Scrum周期。敏捷开发和瀑布开发在时间控制上不是循序渐进,而是平行开展的。在一个Scrum周期中,得到了确认了的产品需求文档和原型图等资料,就开始进行User Story分拆、UED页面设计、技术方案设计、测试用例编写等工作。因为基于Feature的最小颗粒度,所以分拆和执行的同步不会有太多问题。项目经理现在开始要成为主导,还有敏捷顾问。项目经理负责整个Scrum周期中每个Sprint的细化,敏捷顾问要从方法论上给予指导以及根据实际情况的微调。
  3. Sprint周期。Scrum中有若干个Sprint,在一个Sprint周期中,包括User Story拆分、UED设计、技术开发、单元测试、代码评审、功能测试、测试案例测试、生产测试、用户手册编写、质量评审、上线评审等环节,不一定都要,视情况而定,当然最基本的开发、测试、生产验收、QA、上线是不可能少的。
  4. 每天周期。每天的流程里面,站会(Stand up)是不可缺少的。对于认领任务在目前大部分的项目中都不太具有操作性,因为任务还是研发、测试等经理来派分的,效率还高一些。如果有晚上加班的,建议下午5点左右再开一次站会,避免问题累计。站会的细节之后另外详细叙述。项目经理白天要做大量的审核检查,对于分析、开发中、测试、完成等四个阶段的Issue查看细节,和上游需求提出方保持沟通,为第二天、当前Sprint、下一个Sprint等做各类前期工作。
  5. Issue的生命周期。一个Issue基本上会在四个阶段流转,每个Issue在不同的阶段属于不同的拥有人。测试岗位会产生新的Issue,通常我们称为Defect和Bug,这些Issues中如果是Defect,则会讨论一下是否在当前Sprint修改,Bug的话一般都是要在当前Sprint中解决。这就是为什么看一个Sprint的完成曲线,会在项目中后期进度发生回退的原因之一,因为新开出来不少Defect和Bug的缘故。需求方、产品经理、测试都会在项目过程中给到一些建议,敏捷开发是灵活的,因此对于这些建议是否被采纳,需要根据实际情况讨论,至少可以作为之后Sprint的基础,我们有时候称之为需求池。我是建议需求池中的Issue也先建立到系统中,这样产品经理可以直观的从数量和内容上有控制,敏捷开发中要旨之一就是可以不断迭代,而迭代的源泉这样逐渐出现会比集中完成要更接近实际。技术开发的重构不在上面说的行列,因为技术开发重构优化是为了适应未来需求的变化或者提高处理效率等,不是几个Issue可以解决的。
  6. Sprint和Scrum小结会。在这两个阶段结束,特别是Sprint上线或者发布之后,要开一个全体参加的小结会,时间不用长,半小时就可以了。要超过半小时的话,说明平时沟通有很大问题了。这个小结会是为了反映一些系统性的问题。对于Scrum来说,效率很重要,凡是影响效率的都是问题。在不同的Sprint周期,项目重点会不一样,之后还会说,Sprint完成也不一定是上线看得到,同时Sprint的beta测试等之间还是有一定关系的,一些系统性的问题不解决的,至少会被带到下一个阶段,甚至会被放大。所以小结会上要列出问题并且解决,除了BD、产品经理、项目经理、敏捷顾问等以外,有更高级别的主管参加是有益处的。

 

敏捷开发之二:名词解释

敏捷开发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个文档,那么敏捷是否可以减少文档的数量呢,在减少的同时怎么保证知识共享和知识传递呢?