敏捷开发之故事墙

需求澄清后,SE把所有的故事卡贴到故事墙上,等待开发人员的开发。故事墙的模板为:

分析      : 需求澄清完成后,SE把所有的故事卡都贴到分析阶段

等待开发: 开发人员和SE确认了需求,明确了做什么以及怎么做以后,把故事卡从分析阶段移到等待开发

开发中   : 开发人员一次只开发一张故事卡,把相应开发的那张卡移植到开发中

阻塞      : 如果开发过程中,由于配合的原因,导致故事卡无法继续走下去,则把该卡移动到阻塞阶段

开发完成 :如果开发完成,并向SE  SHOW CASE以后,开发人员吧故事卡移植到等待测试

等待测试 :测试人员看到等待测试中有卡以后,对故事卡进行测试,测试完成以后把卡移到测试完成阶段,如果测试有问题,则移出该卡到开发中阶段

测试完成  : 本张卡的生命周期结束

故事墙的等待开发、开发中属于开发人员。等待测试,测试完成属于测试人员,开发人员和测试人员必须坚守自己的领地,当卡移动过去时,必须确认了才接受,如果有不清楚以及问题,及时的移除自己的领地。

为什么要有故事墙,故事墙的作用是什么了?

故事墙描叙了开发过程中的各个阶段,能反应当前团队开发的健康状态。在每天的站立会议中,开发人员依据故事墙,给大家分享其开发状态,问题,需要的帮助。项目领导者也能够及时的通过故事墙,了解当前团队的状态,并及时调整。

时间: 2024-10-03 14:45:15

敏捷开发之故事墙的相关文章

我跟敏捷开发的故事--三面墙

在上篇文章中提到,敏捷开发并不是万能的,而是要结合自己公司的特点和问题摸索出适合自己的一套模式.而项目刚开始的时候,也就是我们整个团队开始摸索敏捷开发的时候. 第一次开始正式进行会议是把所有的相关人员都集合到一个会议室,在这会议室有三面墙,一面是窗户玻璃. 为什么要提会议室的三面墙呢? 这时候是敏捷教练开始让大家一起活动了,首先因为整个团队是新组建的团队,对整个系统的框架,架构,业务,流程等内容都不是很了解,敏捷教练为了让大家能够在最短的时间内去消化这些内容,就依托这三面墙来对比较核心的内容进行

我和敏捷开发的故事--结对搭建开发框架

在整个团队经过三面墙的快速对整个项目的三个方面进行整理了解之后,接下来便开始了开发的流程. 因为项目是新开始的,没有一个现有的开发框架或平台,所以初始阶段搭建框架的工作显得十分迫切.如果没有一个基本的开发框架的话,其他的开发人员也是没有进行相关的开发. 因为基本的项目架构的内容已经设计完成,接下来需要根据架构来搭建相关的开发框架,所设计到的技术都有Kissy,Bui,SpringMVC,Spring,Dubbo,Zookeeper,Ibities,MySql集群等.这些技术是组成开发框架的基本支

我和敏捷开发的故事--敏捷角色PO

在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发. 通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正开始是大家都可以行动的时候.当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解. 第一个要说的角色是PO 敏捷开发中的PO即ProductOwner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑.流程.设置等方面事宜的人员,一

我跟敏捷开发的故事--背景

关于敏捷开发,本人在很早之前已经了解相关的概念,第一次对他了解是在准备软件考试的时候了解到的,然而真正的在实际的项目中运用是从去年一月份,到现在也差不多快两年的时间了,在这两年的实际对敏捷开发这个东西从陌生到熟悉,然后又从熟悉到陌生,一路走下来感觉这个东西还是很有味道的,接下来的内容主要是聊聊这个所谓的敏捷开发. 当然,官方有很多关于敏捷开发的解释,先看看下面的解释. 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子

项目管理(十一)- 敏捷开发搜集故事

你怎么收集故事?本文章告诉你如何与用户一起工作,如何和他们沟通来发现故事 下面四个是收集故事最有效的一些方法 一.用户访谈 1.是许多团队用户获取用户故事的默认方法,访谈成功的关键点是访问正确的受访者 2.不要只询问“你们需要什么”,大多数用户不太善于理解,更难以表达他们的真实需求 3.最好从背景无关的问题开始提问.这样就能从客户那里获得更多样化的回答 例如: “为了让我们的产品在浏览器里面运行,你愿意舍弃什么?" 用户可能有很多种回答,无论那种回答,对我们来说都会有很大的意义 二.问卷调查 1

用户故事与敏捷开发方法笔记06

用户故事得到这么多人的肯定,是因为它自身的优势有很多:1.用户故事强调口头沟通,因为传统的通过各种文档进行表达,每个人对于文字的含义的理解都不同,所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响:2.人人都可以理解用户故事,并且用户故事可以增强人们对各种事件的记忆:3.用户故事的大小适合做发布规划以及进行编程和测试:4.用户故事适合于迭代开发,项目过程中可以写出一部分故事然后就进行编码和测试5.用户故事鼓励延迟细节:6.用户故事支持随机应变的开发,因为用户故事注重口头交流,而且很容

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

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

敏捷开发(四)- 故事验收测试

接着上篇 "估算故事"讲,故事估算完成以后就要开始考虑如何进行验收测试了,只有验收通过故事才算开发完成. 对于一个故事,开发人员和客户可能会讨论很多,讨论的内容可以以测试用例的形式记录下来,这样就为我们故事测试做了铺垫,目前敏捷开发中测试大约有如下2个步骤    1.将测试要点记录到敏捷的故事卡的背面,任何时候发现新的测试,都可以记录到故事卡背面     2.将测试要点变成全面测试,这些测试用来演示故事已正确.完整的实现 下面说一下什么时候写测试用例,以及测试的方法.  在编写代码之前

用户故事驱动的敏捷开发 – 2. 创建backlog

本系列的第一篇[用户故事驱动的敏捷开发 – 1. 规划篇]跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog.产品backlog是敏捷开发中用来管理需求列表,排定优先级,形成迭代计划,组织开发/测试和交付过程的工具.可以说,产品backlog是一个敏捷团队管理开发过程的核心,所有的活动和交付物都围绕backlog来进行.一旦需求明确,我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程,确保我们的想法可以按