怎么用leangoo做迭代管理(Sprint Backlog、任务看板、燃尽图)?

在敏捷开发的实践当中,通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践。通过可视化的任务看板我们可以达到如下几个目的:

1. 可视化管理团队的目标;
2. 明确目标的优先级;
3. 明确目标分解后的任务项;
4. 可视化管理任务的进展状况。

敏捷的任务看板通常每个迭代一个,看板的结构通常包括如下几个列:

  • Story — 这一列代表的是用户故事,用户故事是敏捷开发中的需求表达方式,每个用户故事代表了从产品的用户视角表达的一条用户需求。用户故事这一列放的是这个迭代需要完成的所有用户故事,这些故事加在一起就是这个迭代的目标。这些故事通常按照优先级从上到下排列。
  • Todo — 这一列代表的是待办任务项,用户故事会被分解为对应的技术任务,这些待办的技术任务放到Todo列。
  • Doing — 进行中的任务,放正在进行的任务。
  • Done — 完成的任务,放已经完成的任务和用户故事。

在任务看板上除了有4个列之外,我们还要为每个用户故事建立一个泳道,通过泳道来管理故事和任务的对应关系。

一个标准的任务看板看起来如图-1所示:

图-1

在最近发布的leangoo版本中,我们新增了一个泳道的功能,有了这个功能我们就可以非常方便的创建泳道并且使用它管理故事和任务的对应关系了。下图(图-2)是使用leangoo实现带泳道的敏捷开发迭代看板示例,供参考:

图-2

关于作者:

廖靖斌,国际Scrum联盟认证CSP,CSM,国内知名敏捷教练、顾问、培训师

文章转自:leangoo.com

时间: 2024-10-13 01:18:14

怎么用leangoo做迭代管理(Sprint Backlog、任务看板、燃尽图)?的相关文章

怎么用leangoo做需求管理?(用户故事地图)

用户故事是在敏捷开发中表达需求的主要方式,我们在做敏捷开发的时候都有需求池的概念,在Scrum中这个需求池就是产品backlog,需求池里面是条目化的需求,每一条通常是一个用户故事.按照Scrum的定义,产品backlog是一个基于价值强制排序的队列,团队按照价值的高低,顺序地交付需求. 在开发的过程中,团队会逐步的细化产品backlog,为了保证短平快的交付,高优先级的用户故事会被分解为较小的粒度.但是这样带来了一个问题,对于那些规模稍大一些的产品来讲,故事的数量就会很多,故事拆分后通常会有只

敏捷实践/迭代管理-SprintBacklog-任务看板-燃尽图

在敏捷开发的实践当中,通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践.通过可视化的任务看板我们可以达到如下几个目的: 可视化管理团队的目标; 明确目标的优先级; 明确目标分解后的任务项; 可视化管理任务的进展状况. 敏捷的任务看板通常每个迭代一个,看板的结构通常包括如下几个列: Story - 这一列代表的是用户故事,用户故事是敏捷开发中的需求表达方式,每个用户故事代表了从产品的用户视角表达的一条用户需求.用户故事这一列放的是这个迭代需要完成的所有用户故事,这些故事加在一起就

如何使用Leangoo自动生成燃尽图

在上一篇,我为大家介绍了如何使用Leangoo管理sprint backlog,今天我们一起来看看Leangoo是如何自动生成Scrum燃尽图的.什么是scrum燃尽图?燃尽图能形象地展示当前迭代中的剩余工作量和剩余工作时间的变化趋势,是反应项目进展的一个指示器.一般在每日站会后团队会根据任务的完成情况对其进行更新.燃尽图有一个Y轴(剩余工作量)和X轴(时间).理想情况下,它应该是一个向下的曲线,随着日期的推进和剩余工作的完成而“烧尽”至零.   但是现实情况下,因为各种原因燃尽图往往会出现低谷

敏捷开发进度管理之燃尽图

很多时候,我们感觉什么都没干一天就过去了,但对领导者来说,事情最好已经提前做完了,而且是越快越好.聪明的管理者知道,“时间”是需要花大功夫去把控的限制因素,只有掌握了更多关于时间和工作的数据,我们才能更好地执行计划,在预算范围内按时完成项目. 燃尽图就是用来反映此类项目数据的工具,常用于敏捷软件开发中,如Scrum.它可以呈现剩余工作量和可用剩余时间,并通过可视化的图示表述繁复文字无法表述的意思. 一.燃尽图是什么? 燃尽图可以呈现团队处理用户故事进度,是一种对工作完成情况可视化展示的工具,燃尽

用leangoo怎么做需求管理及规划?(产品Backlog、用户故事)

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

用Leangoo做敏捷需求管理-敏捷团队协作

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

敏捷迭代:Sprint燃尽图的7个图形特征及说明的问题

本文写于很多年前(2006),并在很多地方被引用.而现在,笔者对于Sprint燃尽图的理解有了戏剧性的变化--在看到很多团队滥用它之后.笔者不再建议团队做Sprint燃尽图,因为它们不仅不会增加多少有用的信息,而且还会导致很多坏的行为.笔者差点想删了它,然而觉得更新一下会对大家更有帮助. 笔者观察了很多团队,并注意到了这些团队的Sprint燃尽图可以按图形的特征分成几大类,本文用来讨论几类燃尽图,以及其成因.燃尽图通常被敏捷团队用于让团队成员直观了解到剩余工作量.通常如下: 在下面,会展示7种典

利用 yEd 软件做元数据管理

yEd Diagram editor 是我常用的 flow chart 制图工具, 另外我也用它画 ER 和 use case 图. 总结一下我喜欢 yEd 的原因:1. 出色的对齐功能2. 可随意拖动Node, 永远不用担心相连的 Edge 会自动断开连接3. 每个 Node 都自带一个Label, 加说明文字非常方便4. 每个 Edge 都自带一个Label, 加说明文字非常方便 今天总结的是一个非常有价值的使用场景, 在数据仓库和大数据平台中, 数据表的关系很复杂,随着平台的不断建设, 到

万字干货:手把手教你做需求管理

通过这篇文章,总结自己在工作实践中需求管理的方法论--普拉姆方法.总结这个方法论的特点是,用最轻量化的投入,与他人协作,并管理需求,推动需求上线.这套方法论组合了项目管理.敏捷开发的知识,希望能对大家有所帮助.本文适合0-2岁产品经理阅读,产品大牛.敏捷管理大师请绕过. 本文大纲如下: 1. 为什么要做需求管理? 1.1 我们的工作是否像救火 1.2 需求管理是什么? 1.3 宗旨是什么? 1.4 结尾 2. 需求管理中的干系人和角色 2.1 什么是干系人 2.2 需求管理中的角色 2.3 如何