浅谈敏捷开发scrum工具leangoo(三)

之前两篇有说到敏捷开发及Scrum的一些概念及实施,现在再来记录下我们在敏捷开发实施中使用的一些工具,主要说下leangoo

工具不是敏捷开发及Scrum的必须品,但有了工具,可以让敏捷开发更好的实施。

因为篇幅及时间问题,这里先说下Leangoo

关于leangoo,我想讲的主要有三张图,PO的Product Backlog、Team的Sprint Backlog及Sprint的燃尽图。

Product Backlog

以下是我们PO使用的Product Backlog,基本与leangoo的示例一致,这个示例也是满足软件开发过程的。

编辑

PO-Product Backlog.jpg

这是一张PO的Product Backlog(如果看不清,可以放大),需要注意的都已经用红色标注:

1. 待梳理需求

PO从用户(包含领导、客户、自己)得到的需求,肯定是不完善的,大多都是需要做一个什么功能之类的“一句话需求”,对开发团队而言,这些都是不可执行的;但是PO可能也不能及时进行梳理,所以先把这种“一句话需求”放入该列记录起来。

2. 以后的Sprint

这些都是PO已经梳理了,可执行的需求,我们称之为Story(故事),一般这一列都是紧急度不是非常高,但是在后续需要做的。从这一列起,任务是带有时间点数的,这里一般是PO估算的大概点数,与迭代中团队估计的点数可能有差别,但是随着团队的默契度上升,这个点数应该能与团队评估点数越来越接近。

3. 下个Sprint

这些一般来自于“以后的Sprint”一列,是可执行的,而且紧急度较高的(紧急度由PO根据需求来源、商业价值、工作量等因素进行确定),而且这一列的Story都应该是紧急度排好序的,越往上越紧急。PO大概评估,这一列的Story点数一般略高于团队能完成的点数。这一列的Story需要PO在当前迭代开始准备,在迭代结束前整理好,这样才能让迭代不会中断。

4. 当前Sprint

这一列是当前迭代进行的Story,原则上是不允许替换的,除非是特别紧急的任务。这一列开始,Story的任务点数可以换为与团队评估的时间点数一致。

5. 已交付

这一列是已经交付的Story,是一些已经通过PO验收,已经上线或者随时可以上线的Story。

leangoo上主要的两张Backlog,PO一个人就需要维护一张,可见,在Scrum迭代中,PO处于一个能决定迭代成败的绝对核心位置,PO的任务及责任都是非常重的。

Team的Sprint Backlog

下图是我们团队的Sprint Backlog,这个需要整个团队都主动去维护,每天完成的Task和Story都主动去拖动。

编辑

Team-Sprint Backlog.png

这个Backlog我们与示例一些差别,我们分为了六列,这样更适用于软件开发,这哥Backlog一般在迭代的第一天(迭代启动会后)生成:

1. Story

这个很好理解,迭代中需要完成的故事,在故事都是标记好点数,标记好晚上时间,并标记好负责人的,而且每一个Story都应当有检验项供测试及PO验收。

2. Task

对应的Story拆分为可以执行的且短时间内可完成的小任务,每一个Task都有完成时间和负责人,这些Task都是待执行的状态。

3. Task-doing

Task的执行当天,负责人将该Task从Task列拖到Task-doing列,表示该Task正在处理。

4. Task-done

Task完成后,由负责人将Task拖入该列。

5. Story-testing

当该Story对应的所有Task都完成后,将该Story拖入Story-testing列,测试人员开始进行测试工作。

6. Story-done

当测试人员完成测试后,将Story拖入该列,表示该Story已经顺利完成。

一个迭代会有很多的Story,我们每个开发人员都会建立一个泳道,然后将自己的Story拖入泳道中(也有的团队是每个Story一个独立的泳道,这个看自己的需求情况而定);在Task及Story完成后,团队成员需要主动、及时的拖动Task和Story,不然对应Task或Story会变为红色,而且整个Sprint对应的燃尽图会变得很怪异;在迭代的第一天,应该讲Story拆分为Task,并且Story完成时间不能标记到迭代的最后一天(最后一天应该是产品验收会及迭代总结会),开发Task完成时间不能标记到迭代的最后两天(给测试预留时间,并且需要进行回归测试);在迭代正式开始后,Story和Task应该是不变的,不然很难保证迭代的顺利进行;

燃尽图

燃尽图是基于Sprint Backlog的,以下是一个迭代的燃尽图示例:

编辑

燃尽图.jpg

燃尽图能反馈一个迭代任务周期内的整体进度,一般这个图由SM来管理及分析,如果发现燃尽图偏离参考值,则应该考虑具体原因:在上方则应该询问团队是否出现无法解决的阻碍;如果在下方,则迭代式朝着良好的方向走着,如果下方偏离过多,则表示该团队这个团队战斗力有所提升,可以接受更多的Story。

以上是 Leangoo 中,我认为最重要的三个图表,这些做好了,可以让迭代更好的进行,迭代的执行更清晰,在迭代管理上也更轻松。

来源:CSDN

原文:https://blog.csdn.net/andy_5826_liu/article/details/88889359

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值