用于估算Scrum工具的小时数的单位

Question

我一直在学习Scrum并尝试使用一种叫做Acunote的工具.我的问题是关于每个任务我在那里的两个领域.他们是"估计"和"剩下的".我应该用哪些单位？我使用故事点吗？剩下的呢？例如,我有一个任务需要10个单位,比方说.我在剩下的一天结束时填写了多少"单位",我相信它会让我完成？

谢谢!

Answer 1

我有几点建议:

• 如果你是scrum的新手; 使用白板,不要陷入特定工具的语义中; 它会妨碍你的学习和收养.
• 打破你的故事足够小,这样你就不必创建和估计任务.
• 不要做几个小时的事情,估计那个级别是浪费时间.
• 烧掉故事点.

由于任务正在完成并被烧毁,因此团队"思考"他们正在走上正轨非常容易和普遍.然后他们到达sprint的末尾,发现5个故事都完成了90%而且没有完成.如果你烧毁故事,你实际上是在追踪可交付的商业价值,而不仅仅是任意数量的开发者垃圾.

Answer 2

一如既往,我的第一个建议是在采用/学习Scrum时不使用工具(我开始厌倦了一遍又一遍地重复同样的事情:).相反,从最简单的事情开始(产品Backlog的电子表格,Sprint Backlog的白板和便利贴).这背后的基本原理是你想要学习和掌握Scrum,而不是工具.所以不要让工具告诉你如何做Scrum并推动这个过程.

然后,关于这个问题,有两种思想流派:1.Scrum在理论上说的是什么,2.有些人在实践中做了些什么.

从理论上讲,Scrum有两个级别的估计:一个用于在当前Sprint中完成的工作(任务),另一个用于更远的产品积压项目(PBI).在产品Backlog级别,应该在具有低精度的Story/T-Shirt/Unit-less点估计项目(正在构建的"内容").这种方法避免了"分析瘫痪"的陷阱,并准确地反映了有关工作的一般不确定性.在Sprint Backlog级别,项目被划分为以小时为单位估算的任务("如何"实现PBI).单独的估算方案是合适的,因为任务描述了粒度工作(通常大约几个小时,从不超过16小时).事实上,Scrum建议在任务级估算中使用"理想工程时间".

在实践中,有些人不估计小时,因为烧毁小时不显示"真实"的进步,这是不是假的,他们宁愿烧毁故事点(这实际上意味着一个项目完成与否,它的更多二进制).

虽然我理解后一种方法的"精神",但我并不适用它并坚持理论.实际上,由于前面提到的原因,以小时为单位估算对我来说确实有意义,而且我实际上发现它在Sprint期间更好地"控制"Scrum经验过程(在每天结束时,你应该更新估计的剩余工作量无论花费多少实际时间,这都会比较容易.

此外,我不喜欢只有小故事(这也可以被视为浪费)的缺点,但是当团队清楚地确定Sprint中需要做什么时(这有利于透明度并帮助产品所有者)了解真正的工作量,尤其是"以质量为导向"的任务).

最后,我认为你可以避免DancesWithBamboo提到的陷阱数小时.保持警惕:

• 始终首先关注最重要的PBI(和相关任务).
• 特别注意未完成的任务,他们应该继续在白板上移动(如果你使用列代表例如"待办事项","进行中","待验证","完成"等步骤); 不动的任务是气味.
• 在上一个完成之前不要开始新项目.

所以,在我看来,这是可以用小时,以避免在冲刺综合征的最后的"做什么".只是使用你的大脑(Scrum和/或任何工具都不会取代它,幸运的是我们).

说完了,如果你不把你的工具扔掉,那么要回答的问题是:你想要在燃尽时显示什么(点或小时取决于你是否将工作分解成任务,我给了你我的观点)以及Acunote用于绘制燃尽的字段(即我应该在哪里更新剩余工作的估算).如果您选择积分并且不使用任务,那么更新剩余的工作是没有意义的,除非它完全完成IMO(PBI已完成或未完成).