如何在团队不稳定时管理敏捷开发？

Question

多年来，我一直在为我的项目使用敏捷方法（XP和Scrum），效果很好。但在所有情况下，开发团队的所有成员都100％致力于该项目。

现在，当团队不稳定时，我面临这样做。例如，一次迭代可能有四个人工作，下一个可能只有两个或三个。

我意识到这使得使用正常速度方法估计很难（或不可能），因为它会波动很大而且不稳定。接下来的是，人们真的不希望能够在每次迭代结束时发布。

这里可能还需要另一种方法。只需从积压的东西中抓取东西，然后尽可能地混淆和释放。我真的不喜欢那样......

有什么想法吗？

Answer 1

从这个问题我假设你有一些开发人员（可能是2）100％致力于该项目，而另一些（另外2-3名）只参与一次。

您可以做的一件事是为100％提交的核心开发人员和其他所有人设置不同的流程。为核心人员使用正常的敏捷过程，并在正常的迭代周期中释放他们的工作。对于非核心人员，几乎不做任何计划，并假设他们（和您的）估计有时会是一种方式。理想情况下，他们的更改应该被核心成员隔离并合并到稳定的代码分支中，但不是每个项目的体系结构和团队角色都允许这样做。

重点是分离和隔离混乱的来源，让项目和团队的核心不受影响。

Answer 2

也许您可以使用其他iterative and incremental approaches来减慢敏捷方法，而不是敏捷方法。如果你不断添加和删除团队中的人员，那么不再需要在几周内进行迭代，而是进行更长的迭代（可能以几个月来衡量）会更好。

这并不意味着您仍然无法使用某些敏捷技术。我仍然会维护你的待办事项并烧掉图表，并意识到你不是每两周发布一次，而是每6周发布一次（约2个月）。如果您有新开发人员加入更有经验的开发人员，请使用结对编程，为新开发人员分配错误修复，或者指派新开发人员维护单元测试以帮助他们学习代码库。

Answer 3

速度只是一种估计。

天真地，如果你有一个由4名开发人员组成的给定速度v，那么以(v/4)*number_of_developers

的速度安排你的迭代

如果您失去的成员比平均成绩更强或更弱，您可以捏造这个值。

这基本上是PivotalTracker对团队实力指标的影响。

Answer 4

所以，你有一个不断变化的团队规模的项目，你的老板希望你准确估计需要多长时间？你可以做到这一点，只要你记住准确和精确之间的区别。您的精确度在很大程度上取决于物品的数量以及每个物品的粒度（分解）;你拥有的物品越多，“大数定律”就越适合你，平均过度和低估。

您的准确性是信心的函数。请注意，估算值不是单点值，它们是具有置信度百分比的数字的范围。例如，正确的估计不会是“2周”，它将是“2周的50％置信度，4周的80％置信度”。

如果我被分配了一个不值得羡慕的任务，就像在原始帖子中任意管理的项目那样提供完成估计，我会尝试根据分配的最小人数计算出一个范围（例如，“给予2名开发人员48至66周[50％至80％有信心]”），以及与分配的平均人数相关的范围（例如，“5至5个开发人员25至45周[50％至80％有信心] ]“），并使用平均数字中的低数字以及最小数字的高数字（例如，”从2到5位开发人员给出的25到66周[50％到80％有信心]“），甚至然后我会在其上加上免责声明（“由于上下文切换导致的损失时间增加10％”）。

更好的是，我会解释为什么这种安排是礼貌的，次优的，以及为什么多任务是在地狱之路上的主要标志。

正如其他人所建议的那样，将工作流程从基于迭代的更改为基于流程的（看板）可能是一个很好的策略。使用看板，您可以通过更改待办事项中项目的优先级来处理更改项目优先级;一旦项目被团队抓获，它通常就会完成（在整个工作流程中一直流动，利益相关者不得通过搞砸工作来破坏团队）。我使用看板进行持续的工程项目，效果非常好。再说一下如何帮助估算，连续流的关键是尝试让每个工作项的大小大致相同（1x，2x，3x，而不是10x，20x，100x）。您应该通过跟踪过程状态更改的日期来跟踪项目在工作流中的移动，例如Queue 1/15，Design 1/22，Dev 1/24，Test 2/4，Integrate 2/7等，然后生成定期评估累积流量图，以评估一段时间内的状态持续时间。计算项目应该花多长时间，因为你知道每个项目的大小以及项目工作流程的时间是一个微不足道的计算练习留给读者。 （更有趣的问题是如何发现约束......然后如何去除它们。提示：在状态中寻找很长时间，因为工作在约束之前堆积起来。）

Answer 5

让正在编写故事的个人开发人员估算完成故事所需的工作量。您可以考虑开发人员估算中的历史差异，但您的想法是，您可以获取他们的估算值，然后计算出您可以在该sprint中完成的故事数量。

Answer 6

不要忘记平均速度主要用于超前释放计划; 团队负责在每次迭代中选择 要采取多少积压项目（虽然知道历史​​速度可以帮助他们）。

如果您的团队规模（以及因此速度）从迭代到迭代波动，您仍然可以通过使用过去N个冲刺的平均速度来进行有用的释放计划，假设团队波动将继续并因此他们的长期平均速度实际上会稳定。

Answer 7

这里的主要问题是团队会发现很难提供可预测的估算和交付，因为团队正在从sprint变为sprint。这也可能损害团队的承诺和持续改进。

这种情况实际上可能非常适合看板方法。查看Henrik Knibergs对看板的介绍，以便快速了解。

祝你好运！