如何构建开发冲刺？[关闭]

Question

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

我的想法是：

• 一日冲刺计划
  • 填写积压工作并弄清楚每个开发人员在本次冲刺后将做什么
• 三周的开发
  • 去！去！去！
• 每日站会
  • 检查是否有人需要帮助或感觉偏离轨道
• 两天的冲刺评审
  • 代码审查在这里进行，利益相关者演示
• 一日冲刺回顾
  • 上一个冲刺我们完成了什么？下次我们怎样才能做得更好？

Sprint 应始终在星期二结束（以避免周末压力过大）。

还要别的吗？敏捷的意义显然不止于此。我想向团队提供一个简单的概述，说明我们在启动这个项目时将如何运作。

Answer 1

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

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

即使对于 30 天的冲刺 - 对于冲刺评审来说，两天听起来似乎是漫长的一天......对于回顾来说，一天听起来太长了 0.5 天。我发现，如果您需要的远不止于此，那么在迭代过程中就会出现沟通问题 - 因此您可能需要将需要长时间审查作为一个可能的危险信号。

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

也就是说——我肯定会尝试更短的冲刺。就像集成构建一样——如果你更频繁地做很多事情就会变得更容易。

Answer 2

关闭电子邮件、手机和即时通讯应用程序以获取核心代码时间。上午 10 点到下午 1 点、下午 2 点到 5 点可能是比较合适的时间段。

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

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

Answer 3

• 确保“站立”仍然是站立站立。很容易陷入越来越长的会议。
• 一天的冲刺计划和最后三天可能太多了。仅安排您需要的时间。
• +1 缩短迭代的想法。就个人而言，一个冲刺内的四次为期一周的迭代效果很好。人们善于估计近期任务；过去，它变得越来越猜测。

Answer 4

看起来是个好方法。我赞同 adrianh 和 jedidja 所说的可能更短的迭代。我自己喜欢1周。除了更好的估计之外，它还使“工作软件”的想法保持在更短的周期上。

几个问题：

为什么代码审查要留到最后？要么结对编程，要么边做边做评论。

3 周的开发是否意味着“开发、测试、文档、安装程序等”？IE。你需要真正完成的一切吗？

Answer 5

我们的冲刺结构与您的大纲非常相似，只是我们的冲刺评审是冲刺的最后一天，通常持续大约一个小时。冲刺评审是您向客户和任何其他感兴趣的各方展示您的工作的时间，而不是进行代码评审的时间。代码审查（如果您选择这样做）应该在整个冲刺期间定期进行。我们过去每周有一个小时的时间来检查开发人员指定的代码，这意味着我们不会浪费时间审查每一个编写的 LOC。

我们还会在周二结束冲刺，并在周四开始，周三结束，以结束未完成的工作并解决冲刺期间产生的技术债务。

Answer 6

我不建议将代码审查推迟到冲刺之后，它们应该是开发过程中不可或缺的一部分。换句话说，除非代码经过审查（并测试、记录和......），否则任务不会完成。

Answer 7

重要的是要远离为了管理而管理。SCRUM 每天只需要 1 次会议，而且会议时间很短。此外，在每个冲刺期间，唯一的其他会议是春季回顾和冲刺计划。这使我们能够实施 ROWE，即以结果为导向的工作环境。让您的开发人员决定如何、在哪里、何时进行开发。通过每日站立会议来跟踪他们的工作情况。除此之外，退后一步，你会对他们的生产力感到惊讶。

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

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

设计文件：我个人认为涵盖开发人员打算做什么的详细设计文档非常重要，而且我也认为它们是开发过程的重要组成部分。现在，这并不特别符合敏捷开发，但我个人经常回顾几年前创建的设计文档，看看原始开发人员在编码模块时的想法。