如何构造开发sprint？

Question

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

我想的是：

有一天，

• 计划
  • ，填充待办事项，并计算出每个开发人员在这个
  • 之后将做什么。

​

• 三周开发
  • 加油！去!GO!

​

“每日邮报”(

• Daily )起立与
  • 会面，查看是否有人需要帮助或感到不需要

​

项目干系人presentations，

• 两天内对
  • 代码进行审查

​

有一天，

• 回顾了
  • ，我们在最后一次冲刺中做了什么？我们怎样才能做得更好下一个time?

​

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

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

Answer 1

我会考虑尝试短跑，短于一个月。

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

即使是30天的冲刺-两天听起来大约是一天的短跑回顾.有一天听起来太长了0.5天的回顾展。我发现，如果您需要更多的信息，那么在迭代过程中就会出现通信问题--所以您可能希望将需要长时间的检查作为一个可能的危险标志。

当然，这只是我的经验--大部分是用小型(4-12人)的团队开发网络应用程序。你的经验可能各不相同。

也就是说-我肯定会尝试短跑。就像集成构建一样--如果你经常这样做的话，很多事情都会变得更容易。

Answer 2

关闭电子邮件，手机和即时通讯应用程序的核心代码时间。上午10点到下午1点、下午2点到下午5点可能是很好的选择。

当团队在“区域”时，为他们订购食物和饮料。

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

Answer 3

• 确保“站起来”仍然是站起来的。很容易陷入更长更长的会议。
• 一天的冲刺计划和三天的结束可能是太多了。
• +1只需根据需要安排多少时间就可以缩短迭代时间。就个人而言，冲刺中的四次为期一周的迭代效果很好。人们很善于估计短期任务；过去，这变成了越来越多的猜测。--