使用Worktile进行敏捷软件开发管理

Scrum的核心思路,是首先承认我们的客户(或者我们的产品服务的用户)并不清楚自己的需求,并且人类的需求会不断变化(“requirements churn”:就是需求本身在不断地倒腾),所以我们默认需求是变化的需求,并且制定出一套策略能让整个组按照小功能快速开发,并且后续不断迭代。回归 Scrum 的英文含义:把开发就搞成一堆人在合力拼抢,把功能分成小块,快速开发和迭代。

结合我之前在Facebook工作的时候的具体经验,我把scrum的步骤总结如下:

  1. 项目负责人(一般是PM)列出一个要做的功能列表,按照优先级排好;每次从列表中抽出最重要的,且可以在二到三周内可以完成的几个;安排成子任务,分配好;
  2. 对于每个任务分配一个PM,一个Designer,一两个程序员和一个测试,一个sprint(由一个小组快速迭代开发一小功能)。Sprint:有快速的意思,美国第三个无线运营商 Sprint。这里就是快速开发小功能的意思,不是百度百科上面翻译成的“冲刺”。
  3. 马上开始做,且小组成员共同参与明确需求,设计原型,和编码迭代等整个过程(和scrum的本意一样,一群人一起上去“野蛮”完成任务)。这是和传统开发区别最大的地方。它并不像瀑布模型那样:设计等待pm确定需求;技术等待设计师出稿,或者技术等待PM写完需求(这种分级开发是最原始的办法)。上述瀑布工作流的问题是:每个阶段的某个角色很忙,但其他人闲的蛋疼;但是由于组与组做得远,没有任何讨论,所以对于需求或者设计的细节没有任何了解。技术人员往往直接拿到一个要求就开干,完成了事。极大地扼杀了技术人员的积极性,创造性和成就感。
  4. 每天开小会(daily scrum)来分享每个小组具体完成了哪些进度;同时项目负责人再总结总体的进度;
  5. 2-3 周后,小任务们应该告一段落,然后回顾总结一次。准备下一次的小任务(next sprint)。

 

如何编写产品backlog

产品backlog是Scrum的核心,也是一切的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序。它里面包含的是客户想要的东西,并用客户的术语加以描述。
一般来说产品backlog需要包含以下几个重要的属性:

标识符——就是个自増长的数字而已,以防止重命名之后找不到。名称——简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确,这样开发人员和产品负责人才能大致明白我们说的是什么东西,跟其他故事区分开。重要性——产品负责人评出一个数值,指示这个故事有多重要。例如10或150,分数越高越重要。初始估值——初步估算完成该故事需要的工作量。注解——相关信息、解释说明和对其它资料的引用等等。一般都非常简短。

接下来看一下在Worktile中如何编写产品backlog呢?首先我们需要创建一个项目,然后创建一个名为backlog的任务列表,接下来每一个任务卡片就表示一个backlog:

 

Worktile中任务有很多属性,对于backlog的属性来说,可能有多个任务的属性可以用来表示,所以在实际使用中,需要根据团队自己的习惯来使用。

标识符——Worktile中会为每个任务生成一个唯一编号,这个编号在任务创建时就已固定,不会编号,可以用于表示backlog的标识符。名称——使用任务名,任务名可以非常直接的说明这个任务是做什么。重要性——任务有一个优先级的属性,如果backlog的重要性只有高、中、低三个级别,就可以直接使用优先级来表示;如果backlog的重要性需要用50或200这样的数字表示,可以通过创建一个任务扩展字段实现。初始估值——直接创建一个名为初始估值的扩展字段。注解——使用任务描述即可,支持Markdown格式的文档。

 

如何召开Sprint计划会议

如何成功的召开一次Sprint计划会议,对于Sprint的实施至关重要,在召开Sprint计划会议中最困难的事情有:

参会人员不知道Sprint会议的开始时间参会人员有事忘记了会议时间参与人员不知道会议的具体内容

类似这样的意外情况,都会影响召开一次成功的Sprint会议,在Worktile中可以通过日历很好地解决Sprint会议问题。

 

日程支持多种方式的提醒,可以在Sprint会议开始前提醒参会人员。

 

###如何管理Sprint backlog

很多团队都尝试过用多种形式来保存Sprint backlog,如Excel,有很多公开的Excel模板可以用来管理sprint backlog——包括自动生成的燃尽图等等,也有团队发现挂在墙上的任务板是管理Sprint backlog最有效的形式。

 

Worktile中,项目中内置支持看板视图,直接使用项目的看板视图可以非常方便地完成Sprint backlog的管理。

让燃尽图发挥作用

下面这张燃尽图包含的信息有:

Sprint的第一天,8月1号,团队估算出剩下70个故事点要完成。这实际上就是整个sprint的估算生产率。在8月16号,团队估算出还剩下15个故事点的任务要做。跟表示趋势的虚线相对比,团队的工作状态还是差不多沿着正轨的。按照这个速度,他们能在sprint结束时完成所有任务。

 

以前我们需要通过Excel的记录生成燃尽图,或者是在一张白板上手工绘制燃尽图。在Worktile中,系统会根据项目中任务的新增和完成状态,自动生成燃尽图。

 

 

相关文章