在本系列中,我们将研究我们的工作方式以及原因。 更重要的是,为什么我们应该做事情,以及预期的结果是什么。 如果没有得到这些结果,也许您应该尝试做其他事情,或者重新调整您的期望。
现在,我知道根据标题,您会期待一些#NoEstimates东西,但今天不会。 您可以在此处找到#NoEstimates帖子 。
上一次 ,我们开始讨论迭代计划,尤其是为什么我们要计划迭代的长度。 让我们继续我们如何计划迭代的内容,并讨论故事点,相对估计计划扑克。
通常我们在这一点上开始计划仪式:
- 产品负责人的故事优先级高。 (这是修饰过程的结果,我们将在以后讨论)。
- 编写故事以供呈现和审阅。
- 尽管Scrum假定团队以前没有有关故事的知识,但通常不是这种情况。 至少有一些团队成员已经掌握了有关构建和测试内容的知识。 这些讨论可能已经影响了故事及其优先级。
- 计划会议的预期 结果是团队在迭代中“承诺”(ugh!)完成的故事列表,以便最终将它们演示给利益相关者。
接下来发生什么?
让我们从目的开始。 还记得迭代计划的承诺吗? 短期内的可预测性,可以在团队和业务之间建立信任。 我们商定的计划是基础。
当履行“承诺”时便建立了信任。 但是在迭代的开始,我们只有故事列表。 我们如何批准计划?
我们需要在有限的时间内回答故事是否可以在迭代中完成。 我们的计划基于以下假设:
- 每个人都以相同的方式理解“完成”。
- 我们知道如何构建它。
- 将会浪费。
- 将会有改变。
我们做的计划的一部分是能力计划。 我们删除了所有不支持故事的已知团队可用性活动。 (刚刚意识到这需要一个自己的职位)。
虽然我们可以减少后两者的生产能力(吉姆将待几天,但琼的需求将在传统的粘糊糊中游泳,所以我们需要提高一点),但前两点并不是那么容易。 即使对“完成”进行了详尽的解释,也可能不是您所获得的(没关系),并且当我们学习如何进行构建时(我们也可以),我们如何改变它。
但是,假设我们考虑了可能出错的所有内容,这意味着我们知道我们可以在迭代中进行多少实际工作。 我们仍然需要回答我们适合的故事。 现在我们开始估算技术。
你的故事是什么?
故事点是一种通过使用组合单元来抽象实时估计的机制。 它是为在低信任度的环境中工作而设计的,在该环境中,企业总是询问“需要多长时间?” 团队说:“只要需要”。 抽象将消除讨论(至少那是希望)。 您可以了解到这里的情况 。 可以这么说,罗恩·杰弗里斯(Ron Jeffries)说:“我不确定我是否是故事点的发明者,但是如果我是,我很抱歉”。
通常用于故事点的斐波那契数,就像T恤衫的大小一样,是基于这样的想法:虽然我们精于精确地估计某些东西,但我们可以将两个或多个项目相互比较,例如“这至少是商品的三倍。我们最后一次冲刺了”。 斐波那契数以相同的方式散布,因此我们可以相对比较故事。 从来没有打算辩论某个东西是3分还是5分。 精度不是这里的重点,如果您要实现精度,那就错了。
最后,我们计划扑克。 其背后的想法不是估计“更好”,而是中和支配性意见,缩短达成协议的讨论,并根据分歧开放讨论。 将所有卡片放在桌子上时,我们消除了“不会超过三张,对吗?” 管理自我解答问题。 如果您很安静,则不喜欢争论,而只想回到工作上–您会说是三点。
如果投票中有离群值,则有些人不会以相同的方式看待这个故事。 这可能与理解,复杂性或经验有关。 需要讨论。 同样,3比5并不是离群值,需要进行大量讨论。 为了安全起见,请选择5。
这些机制可以帮助我们提出一些代表我们对工作理解的数字。 仍然是一个估计。 有了这个数字,我们感觉到了在迭代时间内可以做什么。 这不是承诺。 不应该这样对待它。
因此,当您以自己的方式进行估算时,请确保它对您的目的有所帮助。 否则更改它。
顺便说一句,故事点或我们估计的任何单位的问题之一是,我们记录估计的数字,以便基于它们进行未来的估计。 我们将在谈论速度时看到为什么这是错误的。
翻译自: https://www.javacodegeeks.com/2016/06/youre-wrong-iteration-planning-part-2.html