Sprint 结束的前一天,某个重要的 story 出了问题,导致团队无法完成该 story。接下来该怎么做呢?把这个 story 放入到 backlog 中,还是延长 sprint 的期限? Pablo Emanuel 说可以把 story 放回到 backlog 之中,极端情况下甚至可以取消 sprint。他继而说道延长 sprint 期限与迭代式软件开发的原则背道而驰:
迭代式开发的核心思想是尽可能频繁地反馈。你一不小心就会延期,尤其在初始阶段,但是,与体育锻炼类似,那些有私人教练及固定计划的人,与想来就来想走就走的人相比,他们在体育馆露面的机会要多得多,所以永远不要拖延。
除此之外,他指出迭代的演示非常重要,即使可演示的功能很小,它可以让大家有机会见面并回顾最近的迭代计划。
Maurice le Rutte 提示说:“承认发现了问题、任务无法完成会提高团队的可信度,乃至诚信。推迟演示则会发出完全不同的信号,即你们无法控制流程,将来都会拖延。”他继而提醒我们应该感谢团队,因为赶在客户之前就发现了问题,同时要使用回顾会议来发现故事到底出了什么问题。
Dan Rawsthorne 指出:举办审查和回顾,这可以让产品负责人重新评定下一个 sprint 中要完成的故事的优先级,可能把这个有问题的 story 排除在外。
如果团队总是定期出现这种情况,Scrum Master 应该相信是计划出现了问题。 Cenk Çivici 追问为什么 story 没有完成:“Story 是不是太大了?有没有明确的验收条件?是否测试花费了太多的时间?有没有足够的测试人员完成 story?”
Juan Banda 则提醒我们使用 INVEST 六原则:好的用户故事应该满足这样六个原则: Independent 、 Negotiable 、 Valuable 、 Estimatable 、 Small 和 Testable ,并怀疑 story 是否没有满足 Small 原则。
Inanc Gumus 解释说团队只有 3 个人(不包括产品负责人和 Scrum Master),他们初步估算 story 只花费 3 天。比如:“作为广告客户,如果我的活动经费用完了,我希望你们停止推送我的广告和活动”。团队认为这是他们所能分解的最小 story。
Paul Hudso 给出了更小的 story,这些小 story 可以合并成一个大的:“作为广告客户,我希望在任何时候都能让你们停止推送我的广告和活动。作为广告客户,我希望能在任何时候知道我已经花费了多少费用。”而 Ron Jeffries 采取了另一种方式:“第一个可以拆分出来的故事是:‘如果活动已经没有经费了,就停止推送’。这样就有两件事要做:包含一个 if 语句的业务逻辑;手工创建一个经费耗尽的活动。如果需要半天以上的时间才能完成,我想知道为什么。”
本文作者 Mark Levison 建议,Inanc 可以在回顾会议上问团队他们认为问题在哪里,可以使用根本原因分析以及其他的回顾工具。很可能他们已经知道了一些答案。
无论何种情况,最终达成的一致意见有:发现问题就马上提醒产品负责人;演示已经完成的功能;产品负责人可以重新排定优先级;使用回顾会议发现根本原因;不要延长 sprint。
评论