6

您是否曾经参与过一个（全职）项目，使用敏捷方法实际上可以让您完成每周 40 小时的工作？如果是这样，最有价值的敏捷实践是什么？

4

8 回答 8

8

是的，我在一个从一开始就使用 SCRUM 运行的项目上花 40 小时（实际上是 37.5 小时左右，这是我的合同规定的）。那是大约 2 年前，也是我们第一次实施 SCRUM。这是我个人加班时间最少的项目，也是我们正在开发的PC游戏。即使我们在周五发布公开测试版，我现在什至还没有处于“紧缩”模式。

从那时起，我们学到了很多关于 SCRUM 和敏捷的知识。从我的角度来看，最有价值的一个教训是：pod 大小必须合理……我们从 12 到 20 名成员的 pod 开始，但效果并不好。最多不得超过 10 个。在“片状”和“模糊”任务上达成一致太容易了，否则站立和任务计划会议将花费太长时间。因此，请保持 pod 的大小和任务的具体化，并让产品负责人或签字人与那些将从事该任务的人一起。

此外，对于每两周一次的任务计划时间表，您必须让每个产品负责人就当前 sprint 的任务列表和优先级达成一致，并且应该在该计划会议之前发出新的任务请求，否则它将在当前 sprint 中被忽略。短跑。这迫使我们改进 Pod 间的通信。

于 2008-11-04T18:31:23.367 回答
2

Scrum 和愿意接受它的管理层。

公平的冲刺计划。当你协商自己的 sprint 时，你可以选择你的团队可以完成的事情，而不是让任务从上面下来。锁定你的 sprint 承诺（管理层不能在 sprint 中期改变它）可以让你摆脱人们每一个不断变化的突发奇想。

由产品负责人和高层管理人员共同维护的维护良好、优先考虑的积压工作非常有用。它迫使他们坐下来思考他们想要的功能、他们想要的时间以及所涉及的成本。他们经常会说他们现在需要一个功能，但是当他们意识到他们必须放弃其他东西来获得他们想要的东西时，他们的期望变得更加现实。

时间拳击。如果您遇到重大问题，请开始从 sprint 中删除功能，而不是加班。

如果没有它，您的流程需要管理支持，敏捷只是一个词。

我有提到开明的管理吗？

于 2008-11-04T18:28:54.820 回答
2

无法在每周 40 小时内完成任务可能是由于多种原因。

我看到这可能发生在 Scrum 项目的早期冲刺中，因为团队不确定：

  1. 他们在冲刺中可以做的工作量，并且可能会咬得比咀嚼的更多，并且
  2. 他们有能力准确估计奖励给工作块的分数，或
  3. 完成“一个点的价值”工作所需的努力量。

他们也可能对在分配的时间内可以完成的事情过于乐观。

在那之后，我们进入了 Scrum 的几个不好的地方，具体来说：

  1. 不允许团队拥有自己的工作量，也许
  2. 管理层凌驾于 sprint 中应该包含什么的决策之上

如果其中任何一个切入，那么您是：

  1. 只在名义上进行 Scrum，并且
  2. “在没有桨的情况下上溪。”

除了纠正第一个列表中的任何问题之外，您无能为力，但这只能通过经验来实现。

纠正第二个列表中的两点需要重新思考公司如何扼杀而不是采用 Scrum 最佳实践。

高温高压

问候，

抢

于 2008-11-04T18:43:37.740 回答
2

听起来可能很难，但让我们现实一点。使用敏捷或任何其他风格的软件过程与每周 40 小时无关。通常情况下，雇佣合同中规定了每周的工作时间，开发商可以自行决定是否进行任何额外的无偿工作。

请不要将神奇的治疗能力归因于您喜欢的任何软件过程。它可以提供不同的风险管理方法、不同的规划范围或更好的利益相关者参与；但是，除非奴隶制在您那里仍然合法，否则工作日从您进门时开始，到您回家时结束。

开发商有责任确保他们的管理不违反雇佣合同。无论使用何种方法，您的股份都受到您获得的工资金额和您同意作为回报的诚实工作时间的限制。

于 2008-11-05T14:15:11.370 回答
1

当然。

对我来说，最重要的事情有帮助（按重要性排序）：

  1. 跨职能团队——让程序员、测试人员、技术作家和销售/服务人员在同一个团队中并每天互相交谈（每日通话）非常棒。
  2. 定期构建和持续集成
  3. 对利益相关者和客户进行频繁的审查/演示。这仅在迭代（Sprint）期间减少了风险和时间损失。
  4. 每日通话或站立会议
于 2008-11-04T18:54:44.253 回答
1

除了以上所有（不准确的估计、糟糕的 Scrum 实施等）之外，问题可能是对团队的Velocity缺乏了解，就像“团队可以完成多少工作”一样简单，但这不是看起来很容易找到。

于 2008-11-04T19:10:13.193 回答
1

作为 Scrum Master 和人事经理，我一直是每周工作 40 小时的坚定拥护者。我积极劝阻团队成员不要工作超过 40 小时，因为随着工作与生活平衡的转变，生产力会迅速下降。我发现从深夜工作中恢复过来的时间通常比加班时间要长。

当它运行良好时，Scrum 通过鼓励（要求？）始终保持一致的速度来帮助最大限度地减少迭代结束时经常出现的“填塞”，并且速度和燃尽图等工具可以很好地计划和跟踪进度。

于 2008-11-04T19:51:38.150 回答
1

我曾在几家实践各种敏捷方法的商店工作过。最有趣的是全天有 4 个“会话”，大约一个半小时，中间有 20 分钟的休息时间。周五是个人开发日，所以最后两节课是针对你想做的任何事情。

对我们而言，关键是沟通，真正确定用户故事的概念，将完成定义为“生产中”，以及信任。我们还确保将故事分成不超过一天的小块，最好是 1-2 次开发会议。我们通常在每个会话中将配对交换到每个其他会话。

目前，我经营着一个 20 多人的开发团队，该团队部分分布。对我来说，关键的租户是可持续的节奏——这意味着我不希望我的团队每周工作超过 40 小时，即使是偶尔。显然，如果有人想迟到做事，这取决于他们，但总的来说，我努力确保我们在每周 40 小时给我们的速度内工作。

于 2008-11-04T20:59:23.893 回答