6

几年来，我一直在我的项目中使用敏捷方法（XP 和 Scrum）并取得了很好的成果。但在所有情况下，开发团队的所有成员都 100% 地致力于该项目。

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

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

也许这里需要另一种方法。只需从积压中获取东西，然后尽可能地应付和释放。虽然我真的不喜欢...

有什么想法吗？

4

7 回答 7

3

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

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

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

于 2009-10-31T02:23:07.923 回答
1

也许您可以使用其他迭代和增量方法来减慢速度，而不是敏捷方法。如果您不断地在团队中添加和删除人员，那么使用更长的迭代（可能以月为单位）会更好，而不是以周为单位衡量迭代。

这并不意味着你仍然不能使用一些敏捷技术。我仍然会维护您的积压工作并烧毁图表，并意识到您将每 6 周（约 2 个月）发布一次，而不是每 2 周发布一次。如果您有新开发人员加入更有经验的开发人员，请使用结对编程，分配新开发人员进行错误修复，或分配新开发人员维护单元测试以帮助他们学习代码库。

于 2009-10-30T14:54:50.833 回答
1

速度只是一个估计。

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

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

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

于 2009-10-30T14:55:55.480 回答
1

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

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

如果我被分配了一项令人羡慕的任务，即为像原始帖子中那样任意管理的项目提供完成估计，我会尝试根据分配的最少人员数量来确定一个范围（例如，“ 48 到 66 周，给 2 名开发人员 [50% 到 80% 的信心]”），以及与分配的平均人数相关的范围（例如，“5 名开发人员的 25 到 45 周 [50% 到 80% 的信心]”） , 并使用平均数字中的低数字和最小数字的高数字（例如，“从 2 到 5 名开发人员 [50% 到 80% 的信心] 的任何地方给出 25 到 66 周”），即使那样我' d 在上面加上免责声明（“加上 10% 的因上下文切换而损失的时间”）。

更好的是，我会准确解释为什么这种安排是礼貌的、次优的，以及为什么多任务处理是通往地狱之路的主要路标。

正如其他人所建议的那样，将工作流程从基于迭代更改为基于流程（看板）可能是一个很好的策略。使用看板，您可以通过更改待办事项中项目的优先级来处理不断变化的项目优先级；一旦一个项目被团队抓住了，它通常就完成了（贯穿整个工作流程，利益相关者不允许通过乱搞正在进行的工作来扰乱团队）。我已经将看板用于持续的工程项目，并且效果很好。关于它如何帮助估计，连续流的关键是尝试让每个工作项的大小大致相同（1x、2x、3x，而不是 10x、20x、100x）。您应该通过跟踪流程状态更改的日期来跟踪项目在工作流中的移动，例如，队列 1/15、设计 1/22、开发 1/24、测试 2/4、集成 2/7 等，然后定期生成累积流程图，以评估一段时间内的状态持续时间。考虑到您知道每个项目的大小以及通过项目工作流的时间，计算项目应该花费多长时间是留给读者的一项微不足道的计算练习。（更有趣的问题是如何发现约束......然后如何移除它们。提示：在状态中寻找很长时间，因为工作堆积在约束面前。）

于 2009-11-30T09:28:42.570 回答
0

让负责故事的开发人员估计完成故事所需的工作量。您可以考虑该开发人员估算中的历史差异，但想法是您可以接受他们的估算，然后计算出您将能够在该 sprint 中完成多少故事。

于 2009-10-30T14:43:29.513 回答
0

不要忘记平均速度主要用于前瞻发布计划；团队负责在每次迭代中选择要处理多少待办事项（尽管了解历史速度可以帮助他们）。

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

于 2009-11-01T02:28:19.143 回答
0

你的主要问题是团队会发现很难给出可预测的估计和交付，因为团队正在从一个冲刺到另一个冲刺。这也会损害团队的承诺和持续改进。

这种情况实际上可能非常适合看板方法。查看 Henrik Knibergs 对看板的介绍以获得快速概览。

祝你好运！

于 2009-11-02T12:24:16.960 回答