当前位置:首页 > 开发 > IT生活 > 正文

用户故事Invest原则

发表于: 2012-07-15   作者:21jhf   来源:转载   浏览:
摘要: Invest描述: I ndependent(独立的):一个用户故事对于另一个用户故事应该是独立的(尽可能的)。故事之间的依赖性使得增加了计划编制,确立有限级,故事估计这些工作非常困难。通常,可以通过组合用户故事或者分割用户故事来减少依赖性。 N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张
Invest描述:
I ndependent(独立的):一个用户故事对于另一个用户故事应该是独立的(尽可能的)。故事之间的依赖性使得增加了计划编制,确立有限级,故事估计这些工作非常困难。通常,可以通过组合用户故事或者分割用户故事来减少依赖性。



N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。



V aluable(有价值的):每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。



E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。



S mall(短小):一个好的故事应该在工作量上短小,描述具有代表性,而且不超过2-3人周的工作量。超过这个范围的用户故事,将会在划分范围和估计时出现很多错误。



T estable(可测试的) :一个用户故事是可测试的来用于确认完成,记住,我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子:软件应该是易于使用的。


一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立,详情应该便于开发者和用户进行沟通,应该对用户有价值,应该对于开发者来说尽可能的清晰以便进行估计,应该短小,通过预定义测试用例的使用确保它是可以测试的。

用户故事Invest原则

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
用户故事(User Story) 用户故事是描述对用户有价值的功能,好的用户故事应该包括角色、功能和商业价
用户故事是描述对用户有价值的功能,好的用户故事应该包括角色、功能和商业价值三个要素。用户故事
在OutSystems,我们创建了一个平台,旨在简化应用程序整个生命周期的管理流程。但是,对于用户而言
在OutSystems,我们创建了一个平台,旨在简化应用程序整个生命周期的管理流程。但是,对于用户而言
摘要: 一件用户通过系统完成他一个有价值的目标(买一罐饮料)的事。这样的过程就叫“用户案例(user
设计真正伟大的用户界面没有什么伟大的奥秘可言,做到保持简单易用就可以。 ‘保持简单易用’意味着
“设计绝不是简单的拼合,排列甚至编辑;设计是通过阐明,简化、明确、修饰,使之庄严,有说服性,
这是敏捷开发用户故事系列的第一篇。(栏目目录) 全系列将涉及何为用户故事,面向客户价值编写故事
这是敏捷开发用户故事系列的第五篇。(栏目目录) 引子 在之一、之二、之三中,我们曾经提到了“作
在网上看到说这个是讲用户故事非常经典的一本, 本着"张口闭口谈敏捷而不知道user story的程序人生是
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号