锁定老帖子 主题:关于用户故事这件事
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2005-11-09
ddd 写道 也许您的这个客户不是现场客户,或者即使在现场,也没发挥应有的反馈作用。有敬意的打听一下,这就是沟通不够。
或者就是你们的开发队伍没有向现场客户提供必要的信息。 很多设计方面的信息必须要给现场客户,否则单凭一句“满足你的需求”来打发现场客户是不负责任的。这样实质是切断了现场客户在第一时间反馈的渠道。 我推测你们和客户沟通的良好气氛根本就不存在,那么出现这种双方“相敬如宾”的情况也就正常了。 怎么说呢?确实在开发过程中客户并不是整天的在我们身边。这样我们不得不引入虚拟的现场客户,也就是曾经开发过该系统的资深人员。由他负责把需求方面 的问题全部搞定。这当中有些小问题,不过还是一种切实可行的工作方式。 你说的方式,更多的会出现在合作开发的团队里,在这种情况下,双方都会派出 人员参与到开发团队,软件公司负责构架和开发方法,客户负责需求和将来的二次开发工作。为了将来能够自己维护程序,客户知道设计应该理所当然。 至于说能不能满足需求的问题,我认为这不是交流的问题,而是测试的问题,通过验收测试客户就能知道是否满足了需求。 气氛的问题,到目前来说还不错,关键是充当产品经理的人要负起责任来,他可是开发团队和客户的桥梁阿。 |
|
返回顶楼 | |
发表时间:2005-11-09
partech 写道
可能我对现场客户的感觉比较强烈,所以凡事都要联想到他,不过用户故事肯定要涉及现场客户。 没有现场客户我的感觉是xp四原则沟通反馈简单恐怕都要没了,就剩勇气了,那么还xp做什么。 虚拟的现场客户在我看来无法代表真正的现场客户,这可能也是大陆的现状决定的,无法改变,所以我说大多数情况可能要放弃xp。 〉〉气氛的问题,到目前来说还不错 相敬如宾的气氛确实不错,让双方心情都很好,但远远不够,这种气氛对双方不错,但对沟通来说就大大的错了。 倒不是说你所在团队不会成功,而是成功的因素恐怕就不在于用户故事了。 已经跑题到现场客户了:) |
|
返回顶楼 | |
发表时间:2005-11-10
·为了避免从一个用户的视角编写所有的用户故事,需要识别同系统交互的不同用户
· 为每一个用户角色定义相关的属性,能够更好的区分他们 · 有些用户角色能从角色扮演中获益。角色扮演就是代表某个用户角色的虚拟人物,使他们看起来就像真实的项目成员。 · 对于一些应用来说,附加属性能够帮助查找通过其他手段可能会忽略掉的故事 · 不要通过“启发(elicitation)”和“捕获(capture)”的方式,来获取需求 · 使用“拖网捕鱼(trawling)”的方式,来搜罗/收集需求。因为不同网格大小的网,能得到不同大小的鱼, 需求也有大小;鱼会出生,长大,死亡,需求也会;就像捕鱼一样,不可能捉到所有的鱼,也不能获得所有的需求;并且有可能会捉到一些没有的废物;最重要的是撒网人的技能,有经验的撒网人知道该在哪里撒网,该如何撒网。没经验的撒网人效率低下或者会把网撒错地方 · 如果缺少现场真实用户,那么可以使用用户代理开发出好的软件 · 当存在真实用户但不能随时处在现场,可以考虑定期的让他们使用并对系统给予评价,这些将对日常开发有参考作用 · 如果完全没有真实用户可用,那么可以参考竞争产品,上一版本的系统,另外,用户代理最好是多元化的组合 · 在不能找到真实用户时,开发人员不要自认为理解用户的想法,而不需要用户代理 · 不要追随用例模型的指导来开发软件,要跟随用户的指导 · 客户团队的组成,尽量多元化,这样就可以搜罗到多方面的信息,供思考,决策 |
|
返回顶楼 | |
发表时间:2005-11-10
测试是为了充实故事
测试最好被看作两步过程,1.记录将来的测试;任何时间某人想起一个测试,都可以记录下来;2.作为某个故事被正确和完全的实现的证明 客户可以考虑开发人员可能的某种假定,给出测试,以提醒开发人员编码是应该注意的事项 能够通过验收测试是故事被完全实现的基本标志 验收测试能带来大量的信息,开发人员能在编码前利用它们。比如对于“取款”故事,“输入不同金额(包括负数,超过余额的金额)”,开发人员在编码时就会注意到需要处理它们,否则开发人员可能会忽略这些情况,基于上面的原因,验收测试必须要在开发人员实现前给出 测试通常在下面的时间写出: 当客户和开发人员想捕获明确的细节时 在迭代开始时所做努力的一部分,编码实现前 在编码实现期间或之后的任何时候,发现了新的需求 理想情况下,客户和开发人员讨论一个故事,讨论出的细节作为测试。然而在迭代的整个过程中,客户要随时添加他想到的测试。做这个好的方法是问下面类似的问题: 关于这个故事开发人员需要知道什么? 关于这个故事的实现,我还假定了什么? 在什么情况下,这个故事可能会有不同的行为? 在这个故事中,什么东西可能会弄错? |
|
返回顶楼 | |
发表时间:2005-11-11
*由客户来指定验收测试
*让开发人员给测试员描述新的特性,然后测试员测试,由于没有客户和用户的参与,开发的特性也经过了测试员的测试,但不一定满足客户的需求,另外,开发人员可能给测试员误解的需求 *测试是开发过程的一部分,并不是“发生在编码后的事情”,测试在迭代开始被指定,并在整个迭代中被完善 *只要测试能够带来价值和澄清作用,客户就需要持续的编写测试。但要避免无价值的重复,比如:已测试了过期的招行卡不能取款,就不用再测试过期的交行卡。 *另外,好的开发团队会有单元测试来验证低级别的情况,比如:二月三十和六月三十一为非法日期。客户不用识别每一个可能的测试。客户的测试在于给开发人员阐明故事的意图 |
|
返回顶楼 | |
发表时间:2005-11-11
***似乎很激动的样子哦。 长篇大论来了?
|
|
返回顶楼 | |
发表时间:2005-11-11
测试是为了发现BUG,而不是察看代码覆盖率
在一个大项目中,特别是包含了许多用户角色,有时是很难知道从哪里开始识别故事。我发现最好的方法是考虑每个用户角色并识别用户同系统交互的目的作为开始。也就是最高层的“目的故事”。然后再据此分解为更小的“目的故事” 如何将大故事分解为小故事?较好的方法是采用“切蛋糕”的方式,每一层的内容都有一点;每个故事都是从前到后能够运行的功能,这样也有机会验证各层的构架结构是否合理,另外,可以把基本的功能和附加到功能分开,更早的给客户带来价值 闭合的故事。闭合的故事就是完成了某个有意义的目标,使用户感觉他已经完成了间事情。“招聘人员能够管理他发布的招聘广告”就不是一个闭合的故 事,因为他没有表明究竟什么事情完成了;可以将它分解为如下的闭合故事: 招聘人员能够检查申请人应聘的简历 招聘人员能够改变招聘广告过期的日期 招聘人员能够删除不符合招聘要求的申请 完成上面的任何一个闭合故事,用户都会有完成了一件事的感觉。 写闭合故事是希望能够调节同需求的关系。记住,故事需要足够小,来用于评估,进而方便制订迭代计划。但是故事同时必须足够大,以避免在没有必要时过早地捕获细节 约束型故事卡。每一个故事都要遵守它而不是实现它。这就是通常说的非功能需求。比如: 软件要达到在99.999%的时间内正常运行 假如后面软件需要国际化,不要使它变得困难 新系统必须使用我们存在的订单数据库 软件必须能运行在Window98及以上的操作系统上 |
|
返回顶楼 | |
发表时间:2005-11-11
firebody 写道 ***似乎很激动的样子哦。 长篇大论来了?
赫赫,有啥好激动地,大把年纪了。 这都是user stories Applies那本书里的,俺来一个速读。 |
|
返回顶楼 | |
发表时间:2005-11-12
*视野里用户故事的大小
我们总是想把注意力集中在最需要的地方,通常这意味着需要更多的关注将要发生的,而不是将来发生的。用 用户故事,可以通过不同层次的故事来实现。这意味着,较近的一两个迭代的故事需要细化到能够做计划的层 次,更远的故事就要大和粗得多。在写故事时,可以利用故事任意层次带来的弹性,合理安排我们的精力。 *尽可能的避免涉及UI *有些东西不是故事 用户故事对于描述许多系统功能工作的很好,它是一种非常有弹性的形式,但这不意味着它适合于每件事。如果有其他形式表达需求比用户故事更有效,用就是了。比如:用户界面指南等。 *在故事中包含用户角色 将角色包含在故事中,有助于帮助开发人员思考软件需要满足来自于实际、具体用户的需要,而不是面对一个模糊用户。“我是一个(用户角色),想要(...的功能),这样(能带来...的商业价值)”上面的模版可以帮助从琐碎的故事中分辨出重要的。 *如果只写给一个用户,故事通常会更可读。 *采用主动语态来写故事,更易读。 *理想的情况下,客户写用户故事。在许多项目中开发人员在开始阶段写用户故事或给客户建议新故事。但写用户故事的职责还是客户而不是开发人员。因为客户需要为每个迭代的故事划分优先级,客户理解每一个故事就显得至关重要,做到这个最好的方法就是写这些故事。 *不要给故事卡编号。给故事卡编号增加了不必要的抽象思维工作来对应实际的故事。可以考虑用简短的标题来代替。 *不要忘记故事卡的主要目的是为了讨论某个特性担当提示作用。所以要保持故事简明。增加细节提醒你从哪里恢复交谈,但是不要增加更多的细节来取代交谈。 |
|
返回顶楼 | |
发表时间:2005-11-14
可以把需要一个理想天的工作看作一个故事点
团队拥有对全体故事的评估。有以下两个原因:1.团队还不知道谁将负责该故事,不能分配比全体团队更精确的故事的所有权。2.团队做出的评估比个人的更有用 因为故事的评估属于团队,那么让团队参与评估就很重要。如果团队较大,那么不是每个开发人员都必须参与,但通常来说更多人参与会更好。客户需要参与评估,来澄清可能碰到的疑问,但对评估不发表意见 每件事情都需要4个小时。评估故事,需要考虑完成故事需要的每一件事情,如:测试,同客户交谈,帮助客户计划、自动验证测试,等等;而不仅仅是编码时间 评估。采用专家黑箱评估的方式,可以最终确定故事点 在第一个迭代选择的故事必须相互独立 是否采用结对编程对评估没有影响 采用下面离散的故事点标记故事,因为我们不可能更加精确。½, 1, 2, 3, 5, 8, 13, 20, 40, 80 对于分解故事和把故事分解成任务,子故事或子任务累加的时间不必等于它们所属故事的时间评估 |
|
返回顶楼 | |