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

Question

几年来，我一直在我的项目中使用敏捷方法(XP和Scrum)，并取得了很好的效果。但是在所有情况下，开发团队的所有成员都百分之百地投入到项目中。

现在，当球队不稳定的时候，我面临着这样的问题。例如，一次迭代可能有四个人在工作，下一个可能只有两三个人。

我意识到这使得很难(或不可能)用法向速度法来估计，因为它会波动到很大，而且不稳定。下面是一个人不能真正期望能够在每次迭代结束时发布。

也许这里需要另一种方法。只要从待办事项中抓取一些东西，只要可能的话，就可以勉强完成并发布。但我真的不喜欢这样..。

有什么想法吗？

Answer 1

从这个问题中，我假设您有一些开发人员(可能，2) 100%地完成了这个项目，还有一些( 2-3)只参加了一次。

您可以做的一件事是为100%的核心开发人员和其他人设置不同的流程。为核心人员使用正常的敏捷过程，并在正常的迭代周期发布他们的工作。对于非核心人员来说，少做计划，并假设他们(和你的)估计在某一时刻是可行的。理想情况下，它们的更改应该由核心成员隔离并合并到稳定的代码分支中，但并不是每个项目的架构和团队角色都允许这样做。

关键是分离和隔离混乱的根源，让项目和团队的核心不受影响。

Answer 2

也许您可以用其他迭代和增量方法来减缓事情的速度，而不是敏捷方法。与其以周为单位进行迭代，不如进行更长的迭代(可能以月为单位)，如果您不断地将人员从团队中添加和删除则会更好。

这并不意味着您仍然不能使用一些敏捷技术。我仍然会保持你的积压和刻录图表，意识到不是每两周发布一次，而是每6个星期(~2个月)发布一次。如果有新开发人员加入到更有经验的开发人员中，可以使用对编程，指定新开发人员修复bug，或者指派新开发人员维护单元测试，以帮助他们学习代码库。

Answer 3

速度只是一种估计。

天真地，如果您有一个由4个开发人员组成的团队的给定速度的v，那么就用(v/4)*number_of_developers的速度来安排您的迭代。

如果您正在失去的成员比平均值更强或更弱，则可以伪造此值。

这基本上就是PivotalTracker对其团队实力度量所做的事情。