因此，我有很多积压的功能，我们将要开始一个相当大的项目。我正在努力定义sprint的结构，并且对社区反馈很感兴趣。

我在想的是：

冲刺应该总是在星期二结束(以避免过多的周末压力)。

还要别的吗？显然，敏捷还比这更多。我想为团队提供一个简单的大纲，说明在开始该项目时我们将如何运作。

解决方案

回答

关闭电子邮件，手机和即时消息传递应用程序以获取核心代码时间。上午10点至下午1点，下午2点至下午5点可能是个不错的选择。

在"区域"内为团队订购食物和饮料。

取消计划会议之前和之后以及审核日之前的所有其他会议。

回答

我会考虑尝试短于一个月的冲刺。

就个人而言，我发现一两周的迭代可以更有效地快速获得有效反馈。它还可以防止任何可能导致迭代级别问题累积到难以管理的级别的问题。

即使是30天的冲刺，对于冲刺审查来说，也要花上两天的时间，而对于回顾会议来说，一天的声音也要花0.5天左右。我发现，如果我们需要的不止于此，并且在进行迭代时出现了通信问题，那么我们可能希望将需要长期审核的问题视为可能的危险信号。

当然，这只是我的经验，主要是与人数较少的(4-12)人团队一起开发Web应用程序。经验可能会有所不同。

那就是说我绝对会尝试短距离的冲刺。像集成一样，如果我们更频繁地进行构建，许多事情会变得更加容易。

回答

• 确保"站立式"保持站立状态。滑入越来越长的会议非常容易。
• 冲刺计划的一天和最后三天的计划可能太多了。只安排我们需要的时间。
• +1为缩短迭代的想法。就个人而言，在一个Sprint中进行了四个为期一周的迭代，效果很好。人们擅长估计近期任务；过去，它变得越来越多。

回答

看起来是个好方法。我赞同adrianh和jedidja所说的可能更短的迭代。我本人喜欢1个星期。除了更好的估计，它还使"工作软件"的想法保持在更短的周期内。

几个问题：

为什么将代码审查保留到最后？可以配对程序，也可以随时进行评论。

3周的开发意味着"开发，测试，文档，安装程序等"吗？ IE。我们需要真正完成的所有工作？

回答

我们的Sprint结构与大纲非常相似，只是Sprint评论是Sprint的最后一天，通常大约一个小时。冲刺审阅是我们向客户和任何其他有关方面展示作品的时间，而不是进行代码审阅的时间。如果我们选择进行代码审查，则应在整个sprint中定期进行代码审查。我们过去每周有一个小时的时间来检查开发人员提名的代码，这意味着我们不会浪费时间来审查每个编写的LOC。

我们还将在星期二结束冲刺，并从星期四开始离开星期三，以结束松散的局面并解决在冲刺期间产生的技术债务。

回答

我不建议将代码审查推迟到冲刺之后，它们应该成为开发过程中不可或者缺的一部分。换句话说，除非对代码进行了审查(测试，记录和证明)，否则不会完成任务。