敏捷开发之三:关于“用户故事(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的共性,比如内容描述、责任人、下一步责任人、计划完成时间、计划耗用时间等。

Leave a Reply