我们的敏捷版本无法正常工作。提示？

我在一个由4个开发人员组成的小组中工作。我们正在实施的Agile版本似乎每周又一周不断给我们带来同样的困难，我正在寻找可以帮助我们改善流程的建议。

背景：

我们通常进行2周的冲刺，而每次冲刺都容易低估我们的工作，并且由于进度落后，我们与经理发生了麻烦。

我们从开始每个冲刺开始，将任务经理为我们创建的故事分配出去。有时他也会抛出任务，我们会估算它们。我们不使用故事点。我们使用Urban Turtle软件来“管理我们的冲刺”，这实际上只是故事和任务以及相关的消耗。我们不打算在冲刺结束时发布版本。

发生的最常见问题是，我们计划在sprint的开头执行一项任务，只是发现它的范围要大得多，但是优先级仍然很高，因此我们需要在它上面花费更多的时间。第二个最常见的问题是我们当中的一个人遇到了技术问题，该问题减慢了燃烧的时间，造成了障碍。

提供给我们的唯一建议是更加主动地调整估计值，并在早上的站立训练中提供更新，以便我们可以调整所需的额外时间。

但是，我们的处理方式似乎存在根本性的错误。经理对项目的期望与对冲刺的期望之间可能存在脱节。因为我们正在根据项目计划进行这些sprint迭代，所以扩展sprint或推迟项目会破坏项目计划。因此，作为开发人员，我们被鼓励通过在必要时扩展估计值来执行敏捷，而且还要按时完成冲刺，这令人困惑。

这不是一个不常见的问题，所以我希望比那些聪明的人提出一个或两个建议，说明我们如何才能在每次冲刺时都不再遇到相同的问题。真令人沮丧

因为我们落后于时间表

这种想法是您的问题。您没有落后于进度，进度太紧。您应该开始以抽象点而不是小时来估算故事，然后在2-3次迭代过程中确定您的速度。您的速度是您通常每次迭代要完成的点数，而不是您的经理想要适应的点数。

此后，您是否始终低估任务都没关系-您的速度已经说明了这一点。

显然，如果您使用小时数代替积分，这是不可能的。

看来问题出在您的团队无法做出准确的估计，并且无法预见不可避免的问题。

小型任务比大型任务更容易准确估算，因此请尝试将任务分解成更小的块。

不要让任何人对任何任务进行估算，除非他们确切地知道他们将如何去做。对于开发人员不知道要完成什么的任何任务，请在此sprint的计划中花一些时间，以便开发人员进行一些调查和设计，并得出准确的估算值。不得少于半天。但是将任务移至下一个冲刺。然后，当您计划下一个冲刺时，您将获得一个不错的估计。请注意，这不会浪费额外的时间，因为在任何情况下，开发人员都要花费时间。

并且不要害怕回到项目经理那里并告诉他/她，您将需要更多的sprint来完成任务列表。这样做比将自己投入不可能的目标要好。

您是否要分配100％的时间？如果是这样，请停止这样做。首先，将您的团队在冲刺期间必须付出的所有时间加起来。为此，假设每个工人每天最多只能为该项目投入6个小时。这被认为是“理想的一天”。另外两个小时？被会议，休息，管理任务，早上阅读电子邮件和计划日程的时间等吸引住了。这不是“对冲赌注”或“打沙袋”，这是现实的。

第二，将每天6个小时乘以80％。为什么？因为作为人类，我们很容易预测任务将花费多少时间。这说明了我们判断中的错误。同样，这不是现实，而是现实。

现在，您有一个数字，表示希望直接用于您的任务的实际小时数。当您进行估算时，当下一个故事会使您失望时，请停止添加故事。

最后，不要让产品负责人添加任务。Scrum规划是针对团队的，PO不是团队进行工作的一部分。当然，在现实世界中，如果PO比团队中的任何人都知识渊博，她的输入将非常有用。但是，如果团队为落后而感到发狂，则团队需要完全掌握自己将要完成的任务。您的目标是能够满足接受标准；如果一项任务没有直接导致该任务，请不要这样做。

请记住，Scrum并不是要提高生产力。这是关于更加开放和交流。该工作将花费一切完成的时间。使用Scrum可以更轻松地进行估算，与利益相关者进行交流，以及使您的团队更容易做出承诺。

短跑开始时接受标准定义不正确？

初始估计值通常太低，因为故事卡在估计时接受标准很差（如果有）。转移到验收测试驱动开发（ATDD）又名故事测试以帮助团队真正弄清楚卡片是什么呢？

故事太大？

您发现冲刺中故事花费比预期更长的另一个原因可能是故事太大。您是否在Flash卡片组中看到了敏捷？他们有一个抽认卡，名为“适合收缩XL故事”。它提供了用于拆分故事的策略，例如推迟边缘案例，副作用，非功能性方面或对后续故事的错误处理。

由于您没有足够的信息而无法估算？

@sleske对尖峰信号提出了很好的建议。在估算时尝试找出技术未知数。如果有的话，请查看是否可以将故事推迟到以后的冲刺中，然后对该冲刺进行时间调查（尖峰），以尝试了解估计所需的时间。不要被带走并解决原始故事-当您足够了解故事的估计时，峰值就会完成。

失败更快

我同意@Patrick Hughes的想法-考虑改用1周的冲刺，以便您更快地发现问题。

除了@Kevin和@Patrick的好建议...

敏捷方法并非“一刀切”，但这一评论引起了我的注意：

我们正在实施的Agile版本似乎不断给我们带来同样的困难

您最好从“按书着手”的方法论开始（似乎在当今，Scrum占主导地位）-并完全执行其他成功团队所做的... ...进行一些冲刺...然后才开始考虑针对当地条件进行优化所需的更改。

租用经验丰富的Scrum教练（进行几次迭代）可能是一个真正的改变者。获得敏捷的权利有些微妙。

首先，我建议您阅读《scrum-xp-from-thetrenches》一书。请参阅第26页有关速度计算的要点。这个想法是定义一个焦点因素，并说下一个Sprint：

可用工时*聚焦因子=估计速度

估计速度是您计划在下一个Sprint中实施的故事的估计总和。

在完成一个Sprint之后，您将最后的Sprint聚焦因子计算为：

聚焦因子=实际速度/可用工时

实际速度是您在冲刺期间实施的故事的估计值之和。

然后，您可以将实际的焦点因子重新用于下一个Sprint，经过几个Sprint，您将能够更加精确地确定在Sprint期间实际可以实现的目标...

在您获得估算值以便将冲刺缩短到一个星期之前，这样您将更快地识别出超额费用，并能够以较小的增量做出反应。

在设计任务时要花更多的时间在前端，以留出喘息的空间来识别可能导致示波器全面出血的副作用。也可能是任务本身太长，无法进行正确的敏捷估计，请查看任务是否可以分解为更容易吞咽的较短步骤。

让每个人在遇到障碍时立即发出警告，而不是被困在问题上几个小时。尝试从这个过程中分离出自我和责备，对于某些人而言，这比其他人容易得多=）

就像@Kevin提出来的那样，您永远不会真正真正直接将100％安排在任务上，因为会议等总是会产生开销，因此您可能不会认为自己是时间消耗者。

当日程安排方面一切都很好时，再回到两周，您会神奇地从更少的会议中抽出一点时间。