规划和Scrum的

Question

最后期限应对从wikipedia：

在每个“冲刺”，通常两 到四个星期的时间（与长度 被球队所决定），球队 创建潜在的可销售产品增量 （例如， 工作和测试软件）。设置 的功能进入冲刺来从产品“积压”，这是一个 优先级高层次 需要完成的工作要求。其中 积压物品进入冲刺是 在冲刺计划 会议期间确定。在此次会议中， 产品负责人通知产品积压件中 项目的团队，他或她希望完成 。 然后球队 确定他们可以在接下来的 sprint承诺完成多少。冲刺期间，没有人允许 改变冲刺积压， 这意味着的要求是 被冻结的冲刺。冲刺 完成后，该团队演示 使用该软件。

我读这篇文章，立即出现在我的头两个问题：

1）如果一个冲刺是一对夫妇只长星期，决定在一个会议上，你怎么能准确地规划什么都可以实现？根据我的经验，无法准确估计高级任务，并且可以轻松地将看起来合理的事情翻倍。作为一名开发人员，我讨厌被推迟承诺在下个月根据一系列客户要求提供的服务。这与我所了解的有关产生可靠估计值的所有信息相反，而不是粗略估计然后加倍。

2）由于需求被锁定，最终可交付产品可用，当某些事情需要两倍的时间时会发生什么？如果这个功能在冲刺结束时只完成了1/2，该怎么办？

这篇wiki文章继续讨论Sprint计划，其中事情被分解为更小的任务进行估计（< 1天），但这是在Sprint功能已经计划好并且发布达成一致后，是不是？有点像推销员在没有咨询开发人员的情况下做出承诺。

BTW：

尽管这个词不是一个缩写， 一些企业实施 过程已经知道用大写字母为SCRUM拼一下 。这 可能是由于肯·施瓦布的 早期论文之一，其中标题SCRUM 大写。

Answer 1

1. 你应该使用velocity计划的下一个冲刺。速度整齐地处理你的估计是错误的事实，但他们一直是错误的。另外请注意，故事应该很短，我会说最多2-3天。比这更大的故事应该被分解成更小的故事。

2. 如果一个故事没有按计划完成，那么你的速度就会下降，你将无法在下一次迭代中承担尽可能多的工作。

Answer 2

当我们在早期的一个项目做了SCRUM，我们首先商定了一个粗略的冲刺计划，包括高级特性（故事），然后通过打破每一项下来的最好具体任务组细化计划最长1天，估计每个任务。在此之后，我们经常发现原始计划在某种程度上被过度使用（通常是因为我们没有考虑到开发一个故事包括单元测试，代码审查和文档），所以我们相应地进行了调整。顺便说一句，我们使用“估计扑克”：每个成员选择一个卡上有一个数字（工作时间/天），每个人都显示他的卡数到3。如果数字差异很大，我们简要地讨论了为什么，然后有直到我们达成共识后才开始新一轮。

还要注意，估计是非常依赖于领域和技术的。在那个项目中，我们都很好地理解了这一点，并且我们从头开始构建一个新的应用程序，所以我们的估计相当准确。在我目前的项目中，我们正在使用遗留代码，在一个我们还不太了解的领域，所以我们的估计通常超出范围。

随着项目的不断推进，估算值逐渐变得越来越好（与越来越多的风险和棘手问题正在得到解决以及团队领域专业知识不断增长的事实有关），因此团队的速度实际上可能会增长时间。

Answer 3

在回答＃2中，如果某个功能在冲刺结束时没有完成，则不会传递它。您可能能够提供其中的一部分，并且如果您可以以有用的方式进行操作，请这样做。但是如果你不能将它传递给它，那么将其移除，并在下一次冲刺中传递它。

在回答＃1中，有许多方法可以尝试提高估算的准确性。您可以使用功能点分析或者只是一个简单的练习，其中整个项目团队分别获取任务列表，并为每个任务提供自己的估计值，然后审查每个任务并分享他们的估计值，并讨论为什么实例）鲍勃的这项任务的估计是8小时，蒂娜的是16小时。团队计算出谁是对的（有希望）或达成共识，并将其用作估计值。

随着时间的推移，您将会了解您的哪些估计值过于乐观，哪些过于悲观，从而提高估计自己任务的能力。

燃尽图可以真正帮助你。它是整个项目组的早期预警系统，让大家知道一个或多个人落后的时间。然后，团队可以进行重组，以帮助在必要时做出冲刺承诺，或者由于不可预见的情况而取消冲刺，并通过对问题空间的深入理解开展新的冲刺。

最后，您可能会认为统计数字在您身边。如果你高估了10％的任务，并低估了10％的任务，你可能会确定。

Answer 4

其实很简单： 您优先考虑任务，并且如果您发现时间不够，那么低优先级任务只会被放弃或移动到下一个冲刺中。

项目负责人决定他想要什么并设置优先级，然后按照该顺序进行开发。在冲刺结束时你应该有一个可用的产品，而不是全功能的产品。

Answer 5

回答＃1，我不确定我是否同意这个问题中的一些假设。根据我的经验，敏捷（包括Scrum）与时间估计无关。整个想法是远离这一点，而是转向一个拥有已知速度和特定冲刺时间的系统。例如，你每两周发布一次（一个很好的冲刺时间）和一些新的代码。你会看到有多少故事点（而不是时间单位，但是故事点）在一次冲刺中完成，然后是另一个，并且在完成了几次冲刺之后，你就知道你的速度很快了（也就是说，你可以做多少个故事点平均每次冲刺）。

这个想法是客户在每次冲刺完成后都能持续更新应用程序，并且可以看到持续的进展。他们知道哪些项目计划在未来的冲刺中出现，但他们意识到，如果出现某种情况（由于评级不正确，即故事点估计或外部问题），它会在下一次冲刺中出现，而其他所有事情将被移出一点。

所以它不是关于开发基于一些看似任意估计的软件。相反，它关于规划你想要的功能或功能，并为这些功能（相对于其他功能）分配难度（故事点）并通过它们来确定速度。只有这样才能获得粗略的估计。一旦平均速度已知，我们可以对时间框架进行一些粗略的猜测。然而，即使这些也应该被认为是粗略的近似值，因为再次，它不是关于时间，而是关于不断的特征发布。很显然，这种思维方式必须存在于团队中的每一个人，而不仅仅是工程师。

这是a link (wikipedia)，它进一步。

无论如何，我希望这可以帮助你，祝你好运！

Answer 6

维基文章接着谈Sprint计划，那里的东西被分解成更小的任务估计（< 1天），但这是后Sprint的功能已经规划并释放同意，不是吗”它呢？

错，他们是在同一次会议上完成的。在每个人离开冲刺计划会议之前，冲刺的故事都没有达成一致。无论您需要什么样的问题，都可以通过PO来确保您对故事的承诺;你在之前或在SP会议中做过

由于需求被锁定，最终可交付产品可用，当某些事情需要两倍的时间时会发生什么？如果此功能在冲刺结束时仅完成1/2，该怎么办？

该故事的功能目标是锁定的，而不是实现细节。冲刺期间的细节出现在对话中。任何被认为包含在当前sprint作用域中的细节都会放回backlog以供以后确定优先级。请记住，您在这里构建增量产品。就像剥洋葱一样。这个故事必须得到满足，并且代码必须在短跑结束时开始工作。这并不意味着整个功能对用户来说完全可以完全释放。

如果一次冲刺只有几个星期，在一次会议上决定，您如何准确计划可以实现的目标？根据我的经验，无法准确估计高级任务，并且可以轻松地将看起来合理的事情翻倍。作为一名开发人员，我不喜欢被迫在下个月根据一系列客户需求提交我所能提供的内容，这与我所知道的有关生成可靠估算值的所有信息相反，而不是粗略估算，然后加倍。

你在这里正确的，你不能准确地估计。 Scrum拥抱这一事实，并使用速度，趋势，平均和直觉来接近。如果您没有仔细考虑准确的小时增量测量，您就不会对Scrum感到满意。