菜鸟Scrum敏捷实践系列(二)用户故事验收

菜鸟Scrum敏捷实践系列索引  

菜鸟Scrum敏捷实践系列(一)用户故事概念

菜鸟Scrum敏捷实践系列(二)用户故事验收(本篇)

菜鸟Scrum敏捷实践系列(三)用户故事的组织(即将到来)

一、用户故事的状态:

  用户故事推荐定义五种状态,分别是“构思”、“已批准”、“开发中”、“已完成”、“已验收”。

只有符合项目组规定的验收标准,才能置为“已验收”状态。

  二、用户故事验收标准 

  由团队决定验收标准。 该标准可包括:

    •已完成所有任务(开发、测试和记录)

    •正在运行和通过所有验收测试

    •无开放缺陷

    •产品负责人已验收

    •可交付予用户

  在每次迭代期间按此标准完成所有故事。

用户故事验收标准的录入:

    三、编写用户故事六原则-INVEST 

  一个好的用户故事应该遵循INVEST原则

  独立性(Independent)

  要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

  可协商性(Negotiable)

  一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。

  有价值(Valuable)

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

  可以估算性(Estimable)

  开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。

  短小(Small)

  一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。

  可测试性(Testable)

  一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的。

时间: 2024-10-14 14:58:11

菜鸟Scrum敏捷实践系列(二)用户故事验收的相关文章

菜鸟Scrum敏捷实践系列(一)用户故事概念

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

菜鸟Scrum敏捷实践系列(三)用户故事的组织---功能架构的规划

采用Scrum敏捷项目管理方法进行产品开发,当碰到较大规模的产品开发,用户故事较多时,就必须采取一定的方法来组织.管理用户故事,使其分门别类的管理,条理才清楚.通常我们采用“功能架构”来分层分类别来管理用户故事. 一.规划层次 遵循Scrum敏捷项目管理理论,可把项目划分为三个大的层次,分别是顶层的产品层,支持多个产品同时开工:第二层是功能架构(Features)层,能够规划软件产品的整个骨架(功能蓝图):第三层是用户故事层,把用户故事分门别类的放在功能架构之下.项目管理者和开发者能够一目了然的

Scrum敏捷实践之旅系列(一)用户故事概念

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

Scrum 敏捷实践中的三大角色

在我过去的近两年工作中,我们一直在应用 Scrum 敏捷项目管理方法来开展工作,今天,我先从它的角色划分来讲起,毕竟这可是它最鲜明的特征. 首先,为什么这种项目管理方法叫 Scrum ? Scrum 是一个引申词,原义是橄榄球场上的并列争球.橄榄球号称是美国的国球,受关注度最高,我们经常听到的超级碗 Super Bowl(/b??l/)就是它的年度冠军赛. 就像橄榄球运动极度强调团队协作一样,它是用于开发和交付软件产品的一个框架,且过程是增量和迭代的. 好,我们回到 Scrum 的角色划分. 基

[ 搭建Redis本地服务器实践系列二 ] :图解CentOS7配置Redis

上一章 [ 搭建Redis本地服务器实践系列一 ] :图解CentOS7安装Redis 详细的介绍了Redis的安装步骤,那么只是安装完成,此时的Redis服务器还无法正常运作,我们需要对其进行一些配置,这个章节我们重点来讲解下如何对Redis配置文件进行配置才能顺利的启动Redis服务. 要了解Reids的配置项,我们需要先来认识一个脚本文件redis_init_script,从名字我们就能看出来,他就是Redis的初始化脚本,那么这个脚本文件长什么样子,里面有什么内容,又该怎么找到他呢?哈哈

《用户故事与敏捷开发》阅读笔记04

  <用户故事与敏捷开发>阅读笔记04 今天抽出了两个小时读了<用户故事与敏捷开发>的第十二.十三.十四以及十五章并写了这篇阅读笔记.第十二章标题为"故事不是什么".IEEE 830是一本关于如何编写软件需求规格的指南,最突出的特征是使用短语"系统应该.....",但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务.因为用户看到正在开发的软件时总会有有效和重要的反馈循环.他们会改变之前的想法,而且每个需求的成本是不可见的,会造成分析

用户故事-匹配目标与角色

对于多数产品待办事项列表(product backlog)项,尤其是产品功能类,敏捷团队通常使用用户故事(user story)来表达预期的商业价值. 用户故事(user story)的格式通常如下: 简洁的格式可以帮助团队完成较好的用户故事(user story):容易让业务和技术人员准确理解.然而,有时候团队分配给用户角色的目标和利益,并不符合用户角色真实期望的需求和愿望.乍一看,这些用户故事(user story)写的很好,当从特定用户角色的角度去看时,发现并不正确. 我自己的一个例子.几

【DevOps】团队敏捷开发系列--开山篇

随着软件发布迭代的频率越来越高,传统的「瀑布型」(开发-测试-发布)模式已经不能满足快速交付的需求.2009 年左右 DevOps 应运而生,开发运维一体化,通过自动化工具与流程让整个软件开发构建.测试.发布更加快捷.频繁.高效和可靠. 本系列教程目录 本系列将详细讲解Devops落地细节.将构建整个持续集成与交付的一整套体系与流程.对于未来要开篇的系列博文列表如下: [DevOps]团队敏捷开发系列(一)--开山篇 [DevOps]团队敏捷开发系列(二)--版本控制之道Git [DevOps]

简洁的用户故事编写格式

对于多数产品待办事项列表(product backlog)项,尤其是产品功能类,敏捷团队通常使用用户故事(user story)来表达预期的商业价值. 用户故事(user story)的格式通常如下: 简洁的格式可以帮助团队完成较好的用户故事(user story):容易让业务和技术人员准确理解.然而,有时候团队分配给用户角色的目标和利益,并不符合用户角色真实期望的需求和愿望.乍一看,这些用户故事(user story)写的很好,当从特定用户角色的角度去看时,发现并不正确. 我自己的一个例子.几