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