【发布时间】：2009-07-14 21:02:17
【问题描述】：
在从事敏捷开发项目时，您如何将用户故事/用例/等的时间估算纳入其中。培训新开发人员了解项目使用的不熟悉技术所需的时间？其他经理如何处理？
当然，我的问题是假设有人认为有问题的技术是成功完成项目所必需的……或者也许可以考虑偿还一点技术债务！
【问题讨论】：
标签： agile scrum estimation
【发布时间】：2009-07-14 21:02:17
【问题描述】：
如果我们面临对整个团队（或大多数团队成员）来说是新事物，那么我们已经进行了一种调查冲刺，我们允许自己有一些时间（时间盒）来调查/学习。
对于较小的事情，我们会在 sprint backlog 中添加一个timeboxed activity，以便进行培训/调查/实验。
在这两种情况下，我们只是从每天结束时的估计剩余时间中减去目前使用的时间。
【讨论】：
你只是猜测。
由于您的工作迭代很短，因此您很快就会知道您的 WAG 是否偏离了目标。
如果你离开了，你可以为下周的迭代进行调整。
请记住，敏捷是一个迭代过程，每次迭代都能让您更深入地了解项目。
但要开始，请先好好猜测一下。
迭代估计每周都会变得更好。
【讨论】：
我们的 Scrum Master 有一张图表，其中包含根据许多此类参数（新技术、新团队成员等）扩展估计的建议配额。不过，归根结底，它们仍然只是猜测。
【讨论】：
如果您使用的是（对您而言）全新的技术，我建议您将速度减半，以合理地尝试使用新技术估算速度。最终，当您的团队熟悉新技术时，您将能够实际测量您的新速度并使其恢复到更正常的水平。根据早期迭代期间的反馈调整未来估计。
【讨论】：