文章

基于用户故事的计划及跟踪(三)

/分类： /编辑：

（这只是开发不能如期完成时的解决方法之一，这种方法应该是在客户比较有诚意合作的前提下使用。）
用户故事        故事点

卖饮料        4
取消购买        2
输入管理密码                                                        1
补充饮料        3
取出钱箱里的钱        1
安全警报        2
总计        13

然后他还要挑出总和至少为0.5个故事点的故事。
Read more →

基于用户故事的计划及跟踪(二)

/分类： /编辑：

然后开始考虑其他用户故事。比如，对于“取出钱箱里的钱”这个故事，我们认为它跟“输入管理密码”这个故事一样简单，所以它应该也是算1个故事点。我们在列表里面标上。当然，实际操作的时候，我们是在“取出钱箱里的钱”的故事卡上填上故事点。
用户故事            故事点
卖饮料
取消购买
输入管理密码     1
补充饮料
取出钱箱里的钱   1
安全警报
打印月销售报表
Read more →

基于用户故事的计划及跟踪(一)

/分类： /编辑：

用户故事(user story)

假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”
Read more →

用户故事，史诗，主题

/分类： /编辑：

最近收到的邮件里面经常有人问起“用户故事”，“史诗”和“主题”之间的区别。所以这个月，我决定回顾一下一些基础但是又很有用的术语。

首先，术语本身并不是最重要的。这些术语的名称并不像是“指针”对程序员来说那么重要。用户故事，史诗和主题的出现只是为了方便团队中的讨论。这些术语在最早的极限编程团队中都有标准的含义。当然，能够把这些术语的使用像工业标准一样固然不错，但是如果这些术语不存在，你就会自己杜撰一些出来。

好吧，让我们来看看它们分别是什么意思吧。
Read more →

短之又短的用户故事

/分类： /编辑：

Scrum团队通常喜欢使用用户故事来表示待办事列表项目。但是很不幸，一个用户故事中最重要的一环通常会被渐渐忘掉，那就是用户故事应该保持简短，慢慢地用户故事失去了它的本质和效力。

用户故事现在通常以“作为一个…我希望能…”的形式来描述。用户故事的编写者，应该马上利用约束列表或者自动化验收测试的形式来记录下该用户故事的验收标准。很多人觉得如果团队以外的成员（例如，高级经理或者股东）不能在没有别的文档的帮助下明白用户故事的目的，那么这个用户故事的编写就是失败的。

一个理想的用户故事的描述应该是一个简要的描述——Robert Martin把它叫做“助记令牌”。
Read more →

将用户故事分解为任务

/分类： /编辑：

将用户故事分解为任务没有什么捷径，许多的开发者在他们的工作当中也一直在做类似的事情-将需求分解为任务。由于放到Sprint当中的用户故事的规模已经比较小了，所以有些人认为已经没有必要在进行分解。那么为何还要对用户故事进行任务的分解呢？

尽管用户故事的确可以小到作为工作的单位，但是将他分解为更小的任务，通常跟符合项目的需要，主要表现在如下三个方面：
Read more →

什么是用户故事（User Story）?

/分类： /编辑：

什么是用户故事？

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1.     角色：谁要使用这个功能。

2.     活动：需要完成什么样的功能。

3.     商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：
Read more →

用户故事的划分

/分类： /编辑：

在Release计划会议和Sprint计划会议中，划分用户故事是一个很重要的活动。但是很多时候，团队成员并不清楚为什么需要小的用户故事，应该怎样划分。常常为这些问题争论不休，因此我在这里做一个回答。

为什么用户故事越小越好

  • 缩短完成用户故事的时间

很多人想当然的认为用户故事大小跟完成的时间是成正比（线性的）。但是事实并不是这样。有研究表明随着用户故事规模的增长，完成它需要的时间会呈非线性的增长。参见“Scale Lean & Agile Development”里面的截图。两倍大小的用户故事需要花五倍的时间来完成。为什么？因为随着其粒度的增大，不确定性(由于缺陷、人的因素，外部依赖等因素)会急剧提高。
Read more →

为大数值辩护

/分类： /编辑：

很多人为我允许（甚至是鼓励）大家将用户故事估算成20，40和100这样的大数值感到惊讶。我们在我们举行的会议以及课程中出售和赠送的计划扑克牌中也把这些大数值的卡片包含进去了。然而，很多人告诉我，他们一个开始就将这些20，40和100的点数卡片抽出然后再也不用了。
Read more →

编写敏捷开发的合同

/分类： /编辑：

通过用户故事来表达需求正在敏捷团队中变得越来越受欢迎。这些使用用户故事的团队把重点从描述需求转移到讨论需求。客户很高兴他们终于不用从项目开始之前就要确认所有需求。用户很满意以这种方式生产的产品，因为现在产品更能满足他们的需求。
Read more →