开发用户故事而不是任务

作者 Chris Sims 译者 张晓庆 发布于 2009年1月14日

领域

架构 & 设计,

过程 & 实践

主题

敏捷 ,

故事和案例分析

标签

值和度量 ,

用户故事 ,

结对编程

开发者通常把用户故事分成多个任务，以方便组内人员分布开发，并允许以更细的粒度跟踪进度。不幸的是，用户故事可能被分成一组并不小的任务，从而导致迭代结束时故事也不能交付。Ron Jeffries建议： 把用户故事作为基本单元，不要再分成任务。

为了这样，故事应该足够小，团队能够很好地理解和估计。我们可以列出所有的验收条件，逐个查看，看看哪些条件本身就能够成为故事。如果某个验收条件给产品增加了价值，用户可以查看，相对独立，并且可以测试，那么就是它就是很好的候选，可以单独作为一个故事。

很 多团队都有几个专家关注于产品或者后台技术的特定领域，这样让单个工程师完成整个故事很困难。而如果对开发人员进行交叉培训，让他们拥有需要的各项技能， 能开发系统的各个部分，这才是长久之计。团队能够胜任各种工作，不会因为缺少“关键一人”，而给系统的某一领域带来风险。结对编程可以达到这个目标。“负 责”实现用户故事的那个人与拥有该项技能的人结对，以交付整个故事。

Ron建议到：“开发用户故事，而不是任务。”如果在任务层次跟踪（开发），开发人员能够“做自己的那一部分”，完成了很多任务，但是没有交付用户可以使用的功能。如果团队只跟踪故事的完成，只有当故事结束时开发人员才能因为完成而感到高兴。这能激发大家把故事真正“完成”，这才是更有价值的。

你同意Ron的方法吗？欢迎留言分享你的观点。

查看英文原文：Burn Stories Not Tasks

译者 张晓庆 有多年的软件开发经验，主要是J2EE项目、Web应用和分布式系统等等，在电信网管开发方面经验丰富。

1. 返回顶部

   虚构角色

   发表人 任 逍遥

   虚构一个鲜活的人，并相信他是真实的，满足他的需求就是团队的使命。
   
   不是我的看法，是cooper的

   回复

2. 返回顶部

   Re: 虚构角色

   发表人 张 晓庆

   说的没错，这是目标。如何达到这一目标是现在我们需要探讨的

   回复

3. 返回顶部

   按照故事来跟踪进度和开发

   发表人 Huang Xin

   跟踪进度是按照完成的故事来统计的，如果迭代里某个故事没有完成，谁知道它被完成了40%还是60%呢？

   回复

• 更早的 >