希望使敏捷开发适应小型软件开发团队。需要对整个过程进行一些澄清。如果我们决定花2周的时间冲刺10个工作日。每个资源每天8小时
对于设计师，我们计划使他们保持领先状态，以便开发人员在开始冲刺时拥有设计方面的所有需求。现在，他们的时间分为研发，会议，开发和单元测试。每天大约需要5-6个小时进行开发。并根据需要休息以进行会议和单元测试。
QA如何运作？是否有必要每晚进行构建并将其传递给质量检查？如果不是，推荐什么？错误如何处理？我们应该预留相同的Sprint时间来解决错误还是在下一个Sprint中处理它们？现在，如果开发人员每天都在开发，那么如何对在sprint的最后一天开发的东西进行测试，或者在最后一天不应该进行开发？测试会延续到下一个冲刺吗？如何制定发布计划？通常是在冲刺结束后立即发布还是提前1-2个冲刺发布工作？文档适合放在哪里？它是上一个冲刺中开发和测试的项目的冲刺或下一个冲刺的一部分吗？
最初的想法是预先设计1-2个sprint，在sprint中进行开发和测试，继承未测试的内容（不确定如何跟踪sprint的KPI，然后进行下一个sprint的测试并编写文档，然后一次发布）准备？这是正确的方法吗？
提前感谢。
您的问题的答案很简单，但并不总是那么容易。您所说的是周期时间，即从开始一项功能（从设计开始）一直到整个质量检查和准备发布工作的时间。在您的情况下，如果您要提前设计一个2周的冲刺，然后进行2周的开发和测试，并将泄漏内容释放到另一个2周的冲刺中，那么您需要6周的周期才能使用某个功能。要使Scrum发挥任何作用，您的周期时间必须短于冲刺的时间（理想情况下，时间要短得多）。
因此，最大的问题是“如何？”。有两个简单的答案：1）进行较小的工作，2）通过减少等待状态和切换来简化开发过程。
如果您有敬业的团队，他们将需要掌握所有的技能，那么他们应该能处理大部分＃2。现在，您只需缩小工作量即可。基本上，我们不会说“完成酒店预定”，而是进行诸如“显示预订选项”之类的小片段。我发现一个很大的观念转变可以帮助大多数团队习惯于识别整个解决方案，然后交付它。实际上，这使得分解工作更加困难。首先从问题开始。在酒店示例中，考虑预订酒店-作为客户，您面临的第一个问题是什么？可能类似于“给定区域在哪里可用的房间？”之类的东西。现在，请开发人员以可释放的方式解决此问题，而无需使用任何其他功能。如果太大，则可以将其分解为较小的对象，例如：给定特定的酒店位置时，则提供房间空房-依此类推。
当然，虽然这很简单，但可能很难。团队有时会担心这种解决问题的方式。技术架构可能一团糟。这个过程可能充满官僚主义的步骤，使事情变慢。这些都会使工作变得困难，但这些只是要克服的障碍。