问什么时候文档、单元测试、QA和重构需要在2周的敏捷冲刺中完成？

EN

有几种方法你可以采取。

这似乎是我想要解决的“疯狂的工作”部分的终极问题。您应该为可持续步伐而奋斗，这是一种可以无限期地维持下去的努力。你需要“像疯子一样工作”，但却不能生产出高质量的产品的想法似乎是一个问题。

你如何创造一个可持续的步伐？

从过程的角度来看，看看您的团队组织。质量保证似乎是在最后实现的。考虑一下跨功能团队协同工作的想法。不要把质量放在最后，而是在每一步都涉及到质量。您可能希望利用连续积分来帮助实现这一目标--如果您有专门的测试人员，定期(每晚？)把改变放在他们的手中，并得到反馈。使用自动化测试来确保他们所拥有的几乎是正确的，至少基于开发人员对预期结果的解释。如果他们发现问题，更新您的自动化测试，以帮助防止这些问题再次发生。

从团队的角度来看，看看您的冲刺长度。长度几乎总是显示为1-4周。2周在光谱的较短的一端。也许你会更好的与更长的冲刺-增加一到两个星期。

从评估的角度来看，考虑一下您的已完成的定义。故事什么时候写完？当它实现和单元测试的时候？当它被整合时？当它被整合并通过验收标准的时候？这听起来好像你需要一个坚实的定义，完成和估计故事点与完成的努力。这种完整的工作可能包括重构、单元测试、集成测试和验收测试。让整个团队都参与其中。

首先要做的是认识到你目前的方法行不通。分配给每个sprint的任务数量使您不得不走捷径，并招致技术债务(如向客户发布错误)。因此，这些技术债务必须在随后的冲刺中偿还，从而减缓未来的发展。

你已经清楚地认识到你有问题。因此，您的下一个任务是向管理层解释这个问题。他们所期望的比能够交付的要多，因此他们伤害了公司。把这个传达给他们。

最后你需要一个解决方案。该解决方案是在任务完成时重新定义。每个任务都需要时间进行重构、单元测试、"QA“测试和文档化。因此，与团队和管理层一致认为，所有这些活动都必须在完成任务之前完成。然后调整您的任务估计，以允许这些活动。这意味着在sprint中排定的任务较少。要么接受(作为一个组织)减少在两周内可以实现的目标，要么增加你的冲刺持续时间。