我的敏捷开发方法论

从编写产品backlog说起

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

一般来说产品backlog需要包含以下几个重要的属性：

• 标识符——就是个自増长的数字而已，以防止重命名之后找不到。

• 名称——简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。

• 重要性——产品负责人评出一个数值，指示这个故事有多重要。例如10或150，分数越高越重要。

• 初始估值——初步估算完成该故事需要的工作量。

• 注解——相关信息、解释说明和对其它资料的引用等等。一般都非常简短。

这时候Worktile的优势就体现出来了——Worktile是一款类Trello的团队协作工具，增加了很多“本土功能”；每一个项目由若干card组成，我们可以给每个card设定类型并附加上自己所需的属性，非常的灵活。

下面我们来看具体的使用方法： 

首先需要创建一个项目，然后创建一个名为backlog的任务列表，接下来每一个任务卡片就表示一个backlog： 

Worktile中的任务有很多元素，对应backlog的属性刚刚好，以下是我的常规使用方法（在实际使用中，当然也可以根据团队自己的习惯来修改）：

• 标识符——Worktile中会为每个任务生成一个唯一编号，这个编号在任务创建时就已固定，不会编号，可以用于表示backlog的标识符。

• 名称——使用任务名，任务名可以非常直接的说明这个任务是做什么。

• 重要性——任务有一个优先级的属性，如果backlog的重要性只有高、中、低三个级别，就可以直接使用优先级来表示；如果backlog的重要性需要用50或200这样的数字表示，可以通过创建一个任务扩展字段实现。

• 初始估值——直接创建一个名为初始估值的扩展字段。

• 注解——使用任务描述即可，支持Markdown格式的文档。

  
  

如何召开Sprint计划会议

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

• 参会人员不知道Sprint会议的开始时间

• 参会人员有事忘记了会议时间

• 参与人员不知道会议的具体内容

类似这样的意外情况，都会影响召开一次成功的Sprint会议，在Worktile中可以通过日历很好地解决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中，系统会根据项目中任务的新增和完成状态，自动生成燃尽图。

写在最后

总的来说，Worktile不是专门的Scrum管理软件，但它非常灵活而且简单，兼具看板视图和统计功能，刚好可以满足需求，又不会出现人被产品限制的窘境。引用一段Worktile博客中的话作为结尾： 

“我们坚信，用户选择Worktile绝不是偶然。Worktile 不仅想做最好用的团队协作工具，更希望能提供一种方法论，让工作更简单，让工作成为一种享受”。