文章

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

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

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

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

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

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

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

用户故事(user story)

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

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

什么是用户故事(User Story)?

什么是用户故事?

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

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

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

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

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

用户故事的划分

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

为什么用户故事越小越好

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

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

scrumcn602120522

在Sprint中间改变目标

我曾经应聘过一个SCRUM Master的职位,面试官问我这样一个问题:“在一个Sprint进行中,如果用户想改变某个正在这个Sprint中实现的User Story,你觉得应不应该改变它?”SCRUM的规定在我脑海中明明白白的印着:“在Sprint里不许改变任何任务,团队在第一天承诺一系列工作,然后期望它们在整个Sprint保持不变。” Read more

让管理层害怕的 8 个敏捷理解

敏捷体系中,有许多种不同的开发方法。各类敏捷开发方法中,较成体系的有 XP、FDD,只说明管理框架的有 Scrum,只说明建模的有敏捷建模,具体的技术实践包括 TDD 测试驱动开发、持续集成、结对工作、快速迭代等等。敏捷涉及面非常广泛,不同的人当然有一些不同的理解和解释。也许由于敏捷开发方法首先发端于程序员,不 少的理解可能来自于程序员。本文试图来整理当前主要的让管理层害怕的敏捷理解,而不论这个理解是否正确。本文所指管理层是指团队以上的管理者们,不包括项 目经理和项目团队领导。
Read more