下面图例是从一个团队的Scrum电子看板中两个Dev的开发状态,这个团队刚刚从传统瀑布开发方式转型,当前这个项目是第一次用Scrum方式跑Sprint。每个Sprint为期3周,这是第一周周五时候的Snapshot。
singlevsmultiple.jpg
从图中看到以下几点:
Scrum的5个价值观中有一条就是Focus(聚焦),大家应该在同一时间聚焦一个任务。因为多任务造成的上下文切换会导致效率的损失。从实际工作角度,像Dev1这样同时开始4个任务也不太可能,除非这4个属于一个User
Story的子任务,否则在同一时间是无法真正并行的。肯定还是要串行来开发。那开发人员为什么还要一起开始这么多任务呢?宁可在1/3
Sprint时间过去都没有一个可以开始测试。如果4个用户故事属于一个更大的故事,而他们4个无法独立测试,那为什么要拆分这么多子任务?Dev2很聚焦,只作一个用户故事,同样经过很长时间,但测试无法开始进行。
按照Scrum的思想,我们是希望能够尽早测试用户故事,从而验证逻辑的正确性,以便能够通过反馈进行调整。所以Dev1和Dev2都需要做一些调整,例如将大的用户故事进行拆分;尽早完成用户故事并进行测试形成反馈闭环。
下面这个截图是同一个项目的另一个团队,在Sprint第二周周五的早会结束后的看板状态。
finishorstart.jpg
从图中可以看到,Testing状态的User
Story已经堆积了一些,同时有一些存在明显的Bug(验收标准没有通过)。团队虽然也在修改bug,而同时也在继续将的print
Backlog中的Item拽入Doing列中。和团队沟通发现大家有如下几个想法:
在Sprint中,我们应该保证每一个Sprint
Backlog都能尽快够通过AC(验收标准)的测试,同时也要达到DoD(完成标准),之后再开始新的Backlog,这样才能保证当Sprint
timebox结束的时候,得到的都是符合完成标准的,而不会有半成品。如果仍然有”Bug”剩余,而且已经通过了AC和DoD,那么可以考虑真的是Bug还是前面的标准过低了。Bug如果无法在当次Sprint完成,那么建议汇入Product
Backlog和其他Backlog一起重新排序,决定是否在后续Sprint中fix掉。这个故事另一个分享点就是,Sprint中也需要优先做最重要的事情,避免由于突然原因无法完成Sprint所有任务的时候,对Sprint
Goal的影响讲到最低。
这个问题是同一个项目中的BA来问的我,因为Team在Sprint中对某些用户故事提出了更好的建议,大家希望当成Improvement来做,这个时候希望能有JIRA来跟踪,但是BA不确定这类JIRA是否应该在当次Sprint内完成还是在紧接着的下一个Sprint中。我的想法是,先确定这类Improvement是什么性质的:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。