您如何构建开发冲刺？

Question

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

我在想的是：

• 有一天冲刺计划
  • 填写待办事项并找出每个开发人员在此sprint之后会发生什么
• 三周的发展
  • GO！走！ GO！
• 每日站立会议
  • 检查是否有人需要帮助或感觉不合适
• 两天的冲刺回顾
  • 代码审查发生在这里，利益相关者介绍
• 有一天冲刺回顾
  • 我们在上一次冲刺中完成了什么？我们下次怎么能做得更好？

短跑应始终在星期二结束（以避免太多的周末压力）。

还有别的吗？显然比敏捷更敏捷。我想为团队提供一个简单的概述，说明我们如何开始运作这个项目。

Answer 1

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

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

即使是30天的冲刺 - 两天的冲刺回顾也只有一天到一天......而且回顾展的一天听起来大约有0.5天。我发现，如果你需要更多的东西，那么迭代一直在进行时会出现通信问题 - 所以你可能想看看需要长时间的评论作为可能的红旗。

当然，这只是我的经验 - 主要是与小型（4-12）人团队一起开发网络应用程序。你的经历可能会有所不同。

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

Answer 2

关闭电子邮件，手机和即时消息应用以获取核心代码时间。上午10点到下午1点，下午2点到下午5点可能是很好的阻止。

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

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

Answer 3

• 确保“站立”仍然是站立的。很容易滑入越来越长的会议。
• 一天的冲刺计划和最后三天可能太多了。只安排你需要的时间。
• +1更短迭代的想法。就个人而言，sprint中的四个一周迭代运行良好。人们善于估计近期任务;过去，它变得越来越猜测。

Answer 4

看起来是一个很好的方法。我的第二个是adrianh和jedidja所说的可能更短的迭代。我自己喜欢1个weekers。除了更好的估算外，它还可以在更短的周期内保持“工作软件”的理念。

几个问题：

为什么代码审核一直持续到最后？无论是配对计划，还是随时进行评论。

3周的开发是否意味着“开发，测试，文档，安装程序等”？即你真正需要做的一切吗？

Answer 5

我们的冲刺结构非常类似于你的轮廓，除了我们的冲刺评论是冲刺的最后一天，通常持续大约一个小时。冲刺审查是您向客户和任何其他相关方展示您的工作的时间，而不是进行代码审查的时间。如果您选择执行代码审核，则应在整个sprint期间定期进行。我们过去每周都有一个小时的时间段，我们会查看开发人员提名的代码，这意味着我们没有浪费时间审查每个写入的LOC。

我们也在星期二结束我们的冲刺，并在星期四离开星期三，以结束松散的目标并解决冲刺期间产生的技术债务。

Answer 6

我不建议在sprint之后推迟代码审查，它们应该是开发过程中不可或缺的一部分。换句话说，除非代码已经过审核（并经过测试，记录并且......），否则不会执行任务。

Answer 7

为了管理而远离管理非常重要。 SCRUM每天只需要一次会议，这是一个很短的会议。此外，在每个sprint期间，唯一的其他会议是Spring回顾会和sprint计划。这允许我们实现ROWE或结果导向的工作环境。让您的开发人员决定如何，何地，何时进行开发。使用您的日常站立来跟踪他们正在做的工作。除此之外，退一步，对他们的生产力感到惊讶。

诸如“在编码期间关闭手机，关闭IM应用程序等”的想法都是糟糕的想法。当你雇用你的团队时，你正在充满信心地雇用他们，他们知道如何正确地完成工作。如果你以这种理解雇用他们，你为什么要限制他们以他们知道的最佳方式完成工作的能力？如果你正在使用SCRUM，那么每个开发人员都会选择他们认为能够做的工作，你作为Scrum-Master的工作就是消除障碍，而不是创建障碍。

代码评论：绝对必要。对于参加会议的初级开发人员以及对其进行过代码审查的人来说，同行的代码审查是一个很好的教学工具。

设计文档：我个人认为详细的设计文档涵盖了开发人员打算做的事情非常重要，我也觉得它们是开发过程的重要部分。现在，这并不是专门针对敏捷开发的，但我个人经常回顾几年前创建的设计文档，看看原始开发人员在编写模块时的想法。