From the question I assume you have some developers (probably, 2) 100% commited to the project and some (another 2-3) only participate at a times.
One thing you can do is set different process for core developers who are 100% commited and everyone else. Use you normal agile process for core people and release their work at normal iteration cycle. For non-core people, do little planning and assume their (and your) estimates would be way of at a times. Ideally their changes should be isolated and merged into stable branch of code by core members, but not every project's architecture and team roles allow this.
The point is to separate and isolate source of chaos and leave the heart of a project and team unaffected.
Maybe instead of agile approaches, you can slow things down with other iterative and incremental approaches. Instead of having iterations measured in weeks, having longer iterations (perhaps measured in months) would be better if you keep adding and dropping people from the team.
This doesn't mean that you still can't use some Agile techniques. I would still maintain your Backlogs and burn down charts, with the realization that instead of having a release every 2 weeks, you'll release every 6 weeks (~2 months). If you have new developers joining more experienced developers, use pair programming, assign the new developers to bug fixes, or assign the new developers to maintaining unit tests to help them learn the code base.
So, you have a project with a continually changing team size and your boss wants you to give him an accurate estimate of how long it will take? You can do this, as long as you keep in mind the difference between accurate and precise. Your precision will depend largely on the number of items and how granular (decomposed) each item is; the more items you have the more the Law of Large Numbers works for you, averaging out over- and underestimates.
Your accuracy is a function of confidence. Note that estimates aren't single-point values, they're a range with numbers with a percentage of confidence. For instance, a proper estimate wouldn't be "2 weeks" it would be "50% confidence of 2 weeks, 80% confidence of 4 weeks."
If I were the person assigned with the unenviable task of providing an estimate to completion for a project being managed as arbitrarily as in the original post, I'd try to figure out a range based upon the minimum number of folks assigned (e.g., "48 to 66 weeks given 2 developers [50% to 80% confident]"), and a range associated with the average number of folks assigned (e.g., "25 to 45 weeks with 5 developers [50% to 80% confident]"), and use the low figure from the average number along with the high figure from the minimum number (e.g., "25 to 66 weeks given anywhere from 2 to 5 developers [50% to 80% confident]"), and even then I'd put a disclaimer on it ("plus 10% for the lost time due to context switching").
Better yet, I'd explain exactly why this arrangement was, to be polite, sub-optimal, and why multi-tasking is a primary signpost on the road to project Hell.
As someone else suggested, changing the workflow from iteration-based to flow-based (Kanban) might well be a good strategy. With Kanban you handle changing project priorities by changing the priority of items in the backlog; once an item has been grabbed by the team it is generally finished (flows all of the way through the workflow, stakeholders aren't allowed to disrupt the team by screwing around with work-in-progress). I've used Kanban for sustained engineering projects and it worked very well. Re how it would help with estimates, the key to continuous flow is to try to have each work item be roughly the same size (1x, 2x, 3x, not 10x, 20x, 100x). You should track movement of items through the workflow by tracking dates of process state changes, e.g., Queue 1/15, Design 1/22, Dev 1/24, Test 2/4, Integrate 2/7, etc., and then generating a cumulative flow diagram regularly to evaluate the time-in-state durations over time. Working out how long the project should take given that you know the size of each item and the time through the workflow for items is a trivial computational exercise left to the reader. (The more interesting question is how to spot constraints... and then how to remove them. Hint: look for long times in states, because work piles up in front of constraints.)
Let the individual developer that will be working on the story estimate the effort required to complete the story. You can take into account historical variances in that developer's estimations, but the idea is that you can take their estimates and then figure out how many stories you'll be able to finish in that sprint.
如果您的团队规模（以及速度）在迭代之间波动，您仍然可以通过使用过去 N 个冲刺的平均速度来进行有用的发布计划，假设团队波动将继续，因此他们的长期平均速度实际上是稳定的。
Don't forget that average velocity is largely used for lookahead release planning; the team is responsible for selecting in each iteration how many backlog items to take on (although knowing historical velocity can assist them).
If your team size (and hence velocity) is fluctuating from iteration to iteration, you can still do useful release planning by using average velocities over the past N sprints, assuming the team fluctuations will continue and hence their long-term average velocity will actually be stable.
Your main problem here is that the team will find it hard to give predictable estimates and deliveries since the team is changing from sprint to sprint. This can also hurt the team commitment and continuous improvement.
This case might actually be well suited for a Kanban approach. Check out Henrik Knibergs introduction to Kanban for a quick overview.
发布评论
评论（7）
从这个问题来看，我假设您有一些开发人员（可能是 2 名）100% 致力于该项目，而一些开发人员（另外 2-3 名）只参与一次。
您可以做的一件事是为 100% 投入的核心开发人员和其他人设置不同的流程。对核心人员使用正常的敏捷流程，并按正常的迭代周期发布他们的工作。对于非核心人员，很少做计划，并假设他们（和你）的估计有时会发生。理想情况下，他们的更改应该由核心成员隔离并合并到稳定的代码分支中，但并非每个项目的架构和团队角色都允许这样做。
重点是分离和隔离混乱源，并使项目和团队的核心不受影响。
From the question I assume you have some developers (probably, 2) 100% commited to the project and some (another 2-3) only participate at a times.
One thing you can do is set different process for core developers who are 100% commited and everyone else. Use you normal agile process for core people and release their work at normal iteration cycle. For non-core people, do little planning and assume their (and your) estimates would be way of at a times. Ideally their changes should be isolated and merged into stable branch of code by core members, but not every project's architecture and team roles allow this.
The point is to separate and isolate source of chaos and leave the heart of a project and team unaffected.
也许您可以使用其他迭代和增量方法来放慢速度，而不是敏捷方法。如果您不断在团队中添加和删除人员，那么更长的迭代（可能以月为单位）会更好，而不是以周为单位来衡量迭代。
这并不意味着您仍然无法使用某些敏捷技术。我仍然会维护您的待办事项列表和燃尽图，因为我意识到您将每 6 周（约 2 个月）发布一次，而不是每 2 周发布一次。如果您有新开发人员加入更有经验的开发人员，请使用结对编程，分配新开发人员进行错误修复，或分配新开发人员维护单元测试，以帮助他们学习代码库。
Maybe instead of agile approaches, you can slow things down with other iterative and incremental approaches. Instead of having iterations measured in weeks, having longer iterations (perhaps measured in months) would be better if you keep adding and dropping people from the team.
This doesn't mean that you still can't use some Agile techniques. I would still maintain your Backlogs and burn down charts, with the realization that instead of having a release every 2 weeks, you'll release every 6 weeks (~2 months). If you have new developers joining more experienced developers, use pair programming, assign the new developers to bug fixes, or assign the new developers to maintaining unit tests to help them learn the code base.
速度只是一个估计。
天真地，如果您有一个由 4 名开发人员组成的团队的给定速度
v，那么以(v/4)*number_of_developers的速度安排迭代，您可以伪造这个值如果您失去的成员比平均水平特别强或弱。
这基本上就是 PivotalTracker 对其团队实力指标所做的事情。
Velocity is only an estimation.
Naively, if you have a given velocity
vwith a team of 4 developers, then schedule your iteration with a velocity of(v/4)*number_of_developersYou can fudge this value if the members you are losing are particularly stronger or weaker than the average.
This is basically what PivotalTracker does with its team strength metric.
那么，您的项目的团队规模不断变化，而您的老板希望您准确估计需要多长时间？只要牢记准确和精确之间的区别，您就可以做到这一点。您的精度很大程度上取决于项目的数量以及每个项目的粒度（分解）程度；你拥有的物品越多，大数定律对你的作用就越大，可以平均高估和低估。
你的准确性是信心的函数。请注意，估计值不是单点值，而是带有置信百分比的数字范围。例如，正确的估计不是“2 周”，而是“50% 置信度为 2 周，80% 置信度为 4 周”。
如果我是被分配了一项令人羡慕的任务的人，即为一个像原始帖子中那样任意管理的项目提供完成情况的估计，我会尝试根据分配的最小人数来找出一个范围（例如，“ 2 名开发人员为 48 至 66 周 [50% 至 80% 置信度]”），以及与分配的平均人员数量相关的范围（例如，“5 名开发人员为 25 至 45 周 [50% 至 80% 置信度]”） ，并使用平均数量中的低数字以及最小数量中的高数字（例如，“2 到 5 名开发人员 [50% 到 80% 置信]”），即使这样我' d 在其上添加免责声明（“由于上下文切换而损失的时间加上 10%”）。
更好的是，我会准确地解释为什么这种安排，礼貌地，次优，以及为什么多任务处理是通往地狱之路的主要路标。
正如其他人所建议的，将工作流程从基于迭代的更改为基于流程（看板）可能是一个很好的策略。使用看板，您可以通过更改待办事项中项目的优先级来处理不断变化的项目优先级；一旦项目被团队抓住，它通常就完成了（在工作流程中一直流动，不允许利益相关者通过搞砸正在进行的工作来扰乱团队）。我已经将看板用于持续的工程项目，并且效果非常好。关于它如何帮助估算，连续流的关键是尝试使每个工作项的大小大致相同（1x、2x、3x，而不是 10x、20x、100x）。您应该通过跟踪流程状态更改的日期来跟踪项目在工作流中的移动，例如队列 1/15、设计 1/22、开发 1/24、测试 2/4、集成 2/7 等，然后生成定期使用累积流程图来评估一段时间内的状态持续时间。鉴于您知道每个项目的大小以及项目工作流程的时间，计算出项目应该花费多长时间是留给读者的简单计算练习。 （更有趣的问题是如何发现约束......然后如何消除它们。提示：在状态中查找很长时间，因为工作会堆积在约束前面。）
So, you have a project with a continually changing team size and your boss wants you to give him an accurate estimate of how long it will take? You can do this, as long as you keep in mind the difference between accurate and precise. Your precision will depend largely on the number of items and how granular (decomposed) each item is; the more items you have the more the Law of Large Numbers works for you, averaging out over- and underestimates.
Your accuracy is a function of confidence. Note that estimates aren't single-point values, they're a range with numbers with a percentage of confidence. For instance, a proper estimate wouldn't be "2 weeks" it would be "50% confidence of 2 weeks, 80% confidence of 4 weeks."
If I were the person assigned with the unenviable task of providing an estimate to completion for a project being managed as arbitrarily as in the original post, I'd try to figure out a range based upon the minimum number of folks assigned (e.g., "48 to 66 weeks given 2 developers [50% to 80% confident]"), and a range associated with the average number of folks assigned (e.g., "25 to 45 weeks with 5 developers [50% to 80% confident]"), and use the low figure from the average number along with the high figure from the minimum number (e.g., "25 to 66 weeks given anywhere from 2 to 5 developers [50% to 80% confident]"), and even then I'd put a disclaimer on it ("plus 10% for the lost time due to context switching").
Better yet, I'd explain exactly why this arrangement was, to be polite, sub-optimal, and why multi-tasking is a primary signpost on the road to project Hell.
As someone else suggested, changing the workflow from iteration-based to flow-based (Kanban) might well be a good strategy. With Kanban you handle changing project priorities by changing the priority of items in the backlog; once an item has been grabbed by the team it is generally finished (flows all of the way through the workflow, stakeholders aren't allowed to disrupt the team by screwing around with work-in-progress). I've used Kanban for sustained engineering projects and it worked very well. Re how it would help with estimates, the key to continuous flow is to try to have each work item be roughly the same size (1x, 2x, 3x, not 10x, 20x, 100x). You should track movement of items through the workflow by tracking dates of process state changes, e.g., Queue 1/15, Design 1/22, Dev 1/24, Test 2/4, Integrate 2/7, etc., and then generating a cumulative flow diagram regularly to evaluate the time-in-state durations over time. Working out how long the project should take given that you know the size of each item and the time through the workflow for items is a trivial computational exercise left to the reader. (The more interesting question is how to spot constraints... and then how to remove them. Hint: look for long times in states, because work piles up in front of constraints.)
让负责故事的开发人员估计完成故事所需的工作量。您可以考虑该开发人员的估计中的历史差异，但其想法是您可以采用他们的估计，然后计算出您在该冲刺中能够完成多少个故事。
Let the individual developer that will be working on the story estimate the effort required to complete the story. You can take into account historical variances in that developer's estimations, but the idea is that you can take their estimates and then figure out how many stories you'll be able to finish in that sprint.
不要忘记平均速度主要用于前瞻性发布计划； 团队负责选择在每次迭代中要处理多少待办事项（尽管了解历史速度可以帮助他们）。
如果您的团队规模（以及速度）在迭代之间波动，您仍然可以通过使用过去 N 个冲刺的平均速度来进行有用的发布计划，假设团队波动将继续，因此他们的长期平均速度实际上是稳定的。
Don't forget that average velocity is largely used for lookahead release planning; the team is responsible for selecting in each iteration how many backlog items to take on (although knowing historical velocity can assist them).
If your team size (and hence velocity) is fluctuating from iteration to iteration, you can still do useful release planning by using average velocities over the past N sprints, assuming the team fluctuations will continue and hence their long-term average velocity will actually be stable.
这里的主要问题是，团队会发现很难给出可预测的估计和交付，因为团队正在从一个冲刺转变为另一个冲刺。这也会损害团队的承诺和持续改进。
这种情况实际上可能非常适合看板方法。查看 Henrik Knibergs 对看板的介绍以快速了解。
祝你好运！
Your main problem here is that the team will find it hard to give predictable estimates and deliveries since the team is changing from sprint to sprint. This can also hurt the team commitment and continuous improvement.
This case might actually be well suited for a Kanban approach. Check out Henrik Knibergs introduction to Kanban for a quick overview.
Good luck!