所以我有一个积压的功能，我们即将开始一个相当大的项目。我正在努力定义我们 sprint 的结构，我对社区的反馈很感兴趣。
我在想的是：
冲刺应该总是在周二结束（以避免周末压力过大）。
还要别的吗？敏捷显然不止于此。我想为团队提供一个简单的大纲，说明我们在启动这个项目时将如何运作。
我会考虑尝试短于一个月的冲刺。
就我个人而言，我发现一两周的迭代更有效地快速获得有效的反馈。它还可以防止任何可能导致迭代级别出现问题的问题上升到难以管理的级别。
即使是 30 天的 sprint——对于 sprint 评审来说，两天听起来要花上一天的时间……而对于回顾来说，一天听起来要长 0.5 天。我发现，如果您需要的远不止这些，那么在迭代过程中就会出现沟通问题——所以您可能希望将需要长评论视为一个可能的危险信号。
当然，这只是我的经验——主要是与小型 (4-12) 人团队一起开发 Web 应用程序。你的经验可能会有所不同。
也就是说 - 我肯定会尝试更短的冲刺。就像集成构建一样 - 如果您更频繁地执行它们，很多事情会变得更容易。
在核心代码时间关闭电子邮件、手机和即时消息应用程序。上午 10 点到下午 1 点，下午 2 点到 5 点可能是很好的选择。
当他们在“区域”时为团队订购食物，饮料。
取消计划会议之前和之后以及审查日的所有其他会议。
看起来是个不错的方法。我赞同 adrianh 和 jedidja 所说的可能更短的迭代。我自己喜欢1周。除了更好的估计之外，它还使“工作软件”的概念保持在更短的周期内。
几个问题：
为什么代码审查要留到最后？要么结对编程，要么边做边做评论。
3 周的开发是否意味着“开发、测试、文档、安装程序等”？即你需要真正完成的一切？
我们的 sprint 结构与您的大纲非常相似，除了我们的 sprint 审查是 sprint 的最后一天，通常持续大约一个小时。冲刺审查是您向客户和任何其他相关方展示您的工作的时间，而不是进行代码审查的时间。如果您选择进行代码审查，则应在整个 sprint 中定期进行。我们过去每周有一个小时的时间来审查开发人员提名的代码，这意味着我们不会浪费时间审查每个编写的 LOC。
我们还在周二结束我们的冲刺，并在周四离开周三开始，以结束未完成的任务并解决冲刺期间产生的技术债务。
我不建议将代码审查推迟到冲刺之后，它们应该是开发过程中不可或缺的一部分。换句话说，除非代码已经过审查（和测试、记录和......），否则任务不会完成。
为了管理而远离管理很重要。SCRUM 每天只需要 1 次会议，而且时间很短。此外，在每个 sprint 期间，唯一的其他会议是 Spring 回顾和 sprint 计划。这使我们能够实施 ROWE，或以结果为导向的工作环境。让您的开发人员决定他们将如何、在何处、何时进行开发。使用您的每日站立会议来跟踪他们正在做的工作。除此之外，退后一步，对他们的生产力感到惊讶。
“在编码过程中关闭手机、关闭 IM 应用程序等”之类的想法都是糟糕的想法。当你雇佣你的团队时，你是在自信地雇佣他们，因为他们知道如何正确地完成他们的工作。如果您以这种理解雇用他们，为什么要限制他们以他们所知的最佳方式完成工作的能力？如果您使用 SCRUM，那么每个开发人员都会选择他们认为自己能够完成的工作，您作为 Scrum-Master 的工作是消除障碍，而不是创造障碍。
代码审查：绝对必要。代码的同行评审对于参加会议的初级开发人员以及对他们的代码进行评审的人来说是一个很好的教学工具。
设计文档：我个人觉得详细的设计文档涵盖了开发者的意图是非常重要的，我也觉得它们是开发过程的重要组成部分。现在，这并不特别符合敏捷开发，但我个人经常回顾多年前创建的设计文档，以了解原始开发人员在编写模块时的想法。