问技术债的敏捷估计

EN

在敏捷中，如果您可以在不进行更改的情况下进行更改，那么就不应该将更改作为故事的一部分。因此，在这种情况下，你将不包括科技债务的要点。

你能以最快的速度完成这个故事。如果承担科技债务会加速这个故事，即科技债务+故事=比没有技术债务的故事更短的时间，那么你绝对应该选择包含科技债务的途径。但是如果故事是3没有技术债务，5有技术债务，那么你可以选择3。你仍然可以选择清算技术债务，但它会对你的速度产生影响。

你的估计当然应该考虑到技术债务。估计故事的目的是为了表明要完成某件事需要付出多少努力，而技术债务肯定会对此做出贡献。实际上，您应该采取一切可能影响在您的评估中实现一个故事所需的时间/精力的方法(例如，学习业务域)。

有时，当有大量的重构工作要做时，我在一个故事中添加了一个单独的子任务，并据此进行了估计。否则，重构和处理技术债务将成为每个故事的自然部分。应该对此作出相应的估计。

让我们同时尝试两种方法：

1. 没有技术债务:当工作开始时，您知道必须重构代码才能工作，您可能会降低速度--因为总体复杂性被低估了
2. 与技术债务:你会增加‘故事点’的分数，因为它将链接到技术债务，并“明确”到每个人，可以被考虑到现有的速度计算，可以这么说。

那么，你应该选择什么？我会选择#2，因为这使得故事的内容更加清晰，更加真实，并且暴露了隐藏在下面的工作(可能是细节中的魔鬼)。

如果你真的同意第一条，那么团队可能会因为在会议中降低速度和“没有提出技术债务解决方案”而受到质疑。只要保持清楚--用技术债务来估算，你的团队就会很高兴( PM也会一样-一笔债务会被偿还，因为有价值的东西在它之前就有了:)