我一直在为我的项目使用敏捷方法（XP和Scrum）多年，并取得了丰硕的成果。但在所有情况下，开发团队的所有成员都承诺100％参与该项目。如何在团队不稳定时管理敏捷开发？
现在我面对团队不稳定的时候这样做。例如，一个迭代可能有四个人在工作，接下来可能只有两个或三个人工作。
我意识到这使得它很难（或不可能）使用正常速度方法进行估计，因为它会波动很多而不稳定。接下来的是，在每次迭代结束时，人们无法真正期望能够发布。
也许在这里需要另一种方法。只要从积压的东西中抓取东西，只要有可能，就会混淆并释放。我真的不喜欢，虽然...
任何想法？
从这个问题我假设你有一些开发者（可能是2）100％承诺项目和一些（另外2-3）只参加一次。
您可以做的一件事是为100％承诺的核心开发人员和其他人设置不同的流程。为核心人员使用正常的敏捷过程，并在正常的迭代周期中发布他们的工作。对于非核心人员，不要做太多的规划，并且假设他们（和你的）估计会成为一次。理想情况下，他们的变更应该被隔离，并由核心成员合并成稳定的代码分支，但并非每个项目的架构和团队角色都允许这样做。
问题的关键在于分离和隔离混沌源，让项目和团队的心脏不受影响。
我喜欢这种方法。仍然能够与核心敏捷。其他“不稳定”的团队成员的工作主要被认为是我猜想的奖金。我认为他们应该只是为了支持核心团队，也许只是为了支持外围的故事。 – 2009-10-31 12:31:56
让将要在故事中工作的单个开发人员估算完成故事所需的工作量。您可以考虑该开发者估算中的历史差异，但是您的想法是，您可以估算出他们的估算值，然后计算出您可以在该冲刺中完成的故事数量。
也许代替敏捷方法，您可以减慢其他iterative and incremental approaches。如果你不断增加和减少团队成员，那么如果以周为单位进行迭代，而不是以更长的周期进行迭代（可能在几个月内进行测量）会更好。
这并不意味着你仍然不能使用一些敏捷技术。我仍然会维护你的积压和烧毁图表，意识到不是每两周发布一次，而是每隔6周（〜2个月）发布一次。如果您有新开发人员加入更多经验丰富的开发人员，请使用配对编程，将新开发人员分配给错误修复，或指派新开发人员维护单元测试以帮助他们学习代码库。
啊，但敏捷是迭代和渐进的，我认为你的意思是使用类似RUP的东西？已经使用它，不喜欢它:-) 我认为这将是有益的，以保持早期和持续释放（征求反馈等），但它可能无法准确计划_ what_将包括在下一个版本中，只有这个星期会有一个发布。 – 2009-10-31 19:17:58
Agile和RUP一样是迭代和增量式的。你可以把它们全部拿出来挑选。把它看作是一个自己制造的过程。 – 2009-10-31 20:04:15
速度只是一个估计。
天真，如果你有一队4个开发一个给定的速度v，然后安排你的迭代与(v/4)*number_of_developers
的速度，如果你正在失去成员特别是小于或强或弱您可以做傻事这个值平均。
这基本上是PivotalTracker与其团队强度指标。
我想过这个，但是如果你有一个新的开发者（对于这个项目），他会比现有的开发者慢，只是因为他不知道代码库。我不认为你可以说每个队员都有相同的速度。 – 2009-10-30 14:58:01
同意，这就是为什么我认为你需要根据涉及的个人进行一些调整 – DanSingerman 2009-10-30 15:05:50
我不认为这是一个正确的答案。这太不精确了。 – 2009-10-30 16:13:46
不要忘记，平均速度主要用于先行发布计划; 团队负责在每次迭代中选择需要处理多少积压项目（尽管知道历史速度可以帮助他们）。
如果您的团队规模（因此速度）从迭代到迭代波动，您仍然可以使用过去N次冲刺的平均速度进行有用的版本规划，假设团队波动将持续，因此它们的长期平均值速度实际上是稳定的。
您的主要问题在于，从团队从冲刺变为冲刺，团队会发现很难给出可预测的估算和交付。这也会伤害团队承诺和持续改进。
这种情况实际上可能非常适合看板方式。查看Henrik Knibergs介绍看板的快速概述。
祝你好运！
感谢您的回复，我同意。但我不明白看板如何帮助球队给出更可预测的估计值，尽管我确信它在其他方面有所帮助。 – 2009-11-03 12:20:14
因此，你有一个不断变化的团队规模的项目，你的老板希望你准确估计它需要多长时间？你可以做到这一点，只要你记住准确和精确的区别。您的精确度将主要取决于物品的数量以及每个物品的粒度（分解）如何;越多的项目你有更多的大数定律为你工作，平均超出和低估。
您的准确性是置信度的函数。请注意，估算值不是单点值，而是包含置信度百分比的范围。例如，适当的估计不会是“2周”，即“2周50％的置信度，4周80％的置信度”。
如果我是被赋予不值得羡慕的任务的人，他提供了一个项目的完成度估计，这个任务与原始文章中的任意管理一样，我会尝试根据分配的最小人数（例如，“给予2名开发人员48至66周[50％至80％自信]”）和与所分配的平均人数相关的范围（例如，“5个开发人员25至45周[50％至80％自信]“），并使用平均数字中的低位数字和最小数字中的高位数字（例如，”从2到5名开发人员[50％到80％自信]给予25到66周“），以及即使如此，我也会对此做出免责声明（“由于上下文切换导致的损失时间加上10％”）。
更好的是，我会解释为什么这种安排是礼貌的，次优的，以及为什么多任务是Hell项目的主要路标。
正如其他人所建议的，将工作流程从基于迭代的改为基于流程（看板）可能是一个很好的策略。使用看板，您可以通过更改积压项目中的项目优先级来处理更改项目优先级;一旦项目被团队抓住，一般会完成（在工作流程中一直流动，不允许利益相关者通过拧入正在进行的工作来破坏团队）。我使用Kanban进行持续工程项目，效果非常好。考虑到它对估计有什么帮助，持续流动的关键是尝试让每个工作项目的大小大致相同（1x，2x，3x，而不是10x，20x，100x）。您应跟踪过程状态更改的日期，例如队列1/15，设计1/22，开发1/24，测试2/4，集成2/7等，然后生成通过工作流跟踪项目移动一个累积的流程图定期评估随时间推移的状态持续时间。考虑到你知道每个项目的大小和通过项目工作流程的时间，计算项目应该花费多长时间是一个留给读者的微不足道的计算练习。（更有趣的问题是如何发现约束......然后如何去除它们......提示：在状态中查找很长时间，因为工作堆积在约束之前。）
...社区wiki ... – joshcomley 2009-10-30 14:42:10
不，不是社区wiki。在这种情况下，这个问题将有一个适用于wic和他的团队的答案。 – 2009-10-30 14:42:50
我投票结束这个问题作为题外话，因为它不是关于编程 – 2017-10-20 09:40:31