敏捷中何时执行峰值[关闭]

我们在迭代计划中直接包含峰值。它们的优先级很高,主要是因为它们是固定的时间。请记住,尽管峰值并不一定总能带来更多的发展。对于管理层来说,了解一个特定的想法是否值得,这是一个相当快的方法。我们发现,最好限制开发人员在每次迭代中花费在峰值上的时间,以停止我们称之为“兔子跟踪”(在这种情况下,您最终会在没有完成任何操作的情况下跟踪数百条路径)。还要确保开发人员知道何时停止。这个峰值只是为了确定一个估计,而不是为那个估计传递代码。它就像是其他用途的原型。你不想使用它,你只是想了解更多。

尖峰是一个调查的故事,当没有足够的或有多种方法来解决、增强或实现一个产品或功能时就完成了。

需要根据您试图实现的最终用户功能来定义峰值,您必须为此执行峰值。

峰值应该具有定义峰值结果的接受标准,即“完成”的定义。

尖峰应该是有时间限制的,通常不到40小时。如果某些东西确实需要更多的时间,那么将执行初始峰值,以根据第一个峰值结束时提供的信息确定需要多少额外峰值。

峰值要么在时间框事件结束时完成,要么在满足验收标准时完成。

下面是一个扣球故事的例子-

Story: 作为用户角色 我想在ABC上表演扣球 所以我可以做XYZ

接受: 假设我在ABC上表演扣球 当我完成扣球时 然后我应该生成/附加原型/工件来完成XYZ到故事中。

注意:您可以与技术架构师或产品所有者一起,他们要求峰值在验收标准上更加具体,以清楚地列出哪些类型的工件以及在这些工件中应该列出哪些细节来实现XYZ。

当我们需要调查一些我们不太了解的事情来实际计划和估计任务时,我们使用峰值。这就是为什么尖峰通常被时间限制的原因。这意味着,如果一个后续任务从来没有被安排好,那就完全没问题了,因为在尖峰中获得的知识可能会让你重新考虑。它还可能希望您延迟实际的实现,直到先决条件或更重要的任务完成。基本上我是说:也要敏捷地使用你的钉鞋,不断地重新评估你的处境。还有一件事:我们通常在实际的实现任务之前进行设计任务的审查,以确保开发人员了解问题和适当的解决方案。

在我工作的地方,峰值往往是对一些不容易估计的事情的时间限制的调查。可能需要一个小时,也可能需要100个小时,在做尖峰工作之前还不清楚。当时间到了或工作已经被正确估计时,一个峰值就完成了。

如何处理Bug?在某种程度上,bug在某些方面类似于峰值,比如不知道需要多长时间,因为不清楚必须改变什么。

当一个新的故事出现时,团队需要一个峰值来估计它,然后我们的产品所有者将这个峰值和这个故事添加到积压工作中,并对它们进行优先级排序。

我们的峰值被计划为迭代中的任何其他积压项。我们从来没有在同一个迭代中调度峰值并开始实现积压项。

令人惊讶的是,你所说的仅仅是管理层,而不是现场客户或产品所有者。 峰值是项目的一部分,因此应在项目时间内使用。 . 因此,PO决定将团队时间花在尖峰或故事上。