您是否曾经参与过一个（全职）项目，使用敏捷方法实际上可以让您每周工作 40 小时？如果有，最有价值的敏捷实践是什么？
【问题讨论】：
是的，我在 40 小时（实际上是 37.5 小时左右，这就是我的合同规定）上一个从一开始就使用 SCRUM 运行的项目。那是大约 2 年前，也是我们第一次实施 SCRUM。这是我个人加班时间最少的项目，也是我们正在开发的PC游戏。即使我们在周五发布公开测试版，我现在什至还没有处于“紧缩”模式。
从那时起，我们学到了很多关于 SCRUM 和敏捷的知识。从我的角度来看，最有价值的一个教训是：pod 大小必须合理……我们从 12 到 20 名成员的 pod 开始，结果一点也不好。最多不得超过 10 个。在“片状”和“模糊”任务上达成一致太容易了，否则站立和任务计划会议将花费太长时间。因此，请保持 pod 的大小和任务的具体化，并让产品负责人或负责人与负责该任务的人员一起签字。
此外，对于每两周一次的任务计划时间表，您必须让每个产品负责人就当前 sprint 的任务列表和优先级达成一致，并且应该在该计划会议之前发出新的任务请求，否则它将被忽略对于当前的 sprint。这迫使我们改进 Pod 间的通信。
【讨论】：
愿意购买的 Scrum 和管理层。
公平的冲刺计划。当你协商自己的 sprint 时，你可以选择你的团队可以完成的事情，而不是让任务从上面下来。锁定你的 sprint 承诺（管理层不能在 sprint 中期改变它）可以让你摆脱人们每一个不断变化的突发奇想。
由产品所有者和高层管理人员合作维护良好的优先待办事项非常有用。它迫使他们坐下来思考他们想要的功能、他们想要的时间以及所涉及的成本。他们经常会说他们现在需要一个功能，但是当他们意识到他们必须放弃其他东西来获得他们想要的东西时，他们的期望变得更加现实。
时间拳击。如果您遇到重大问题，请开始从 sprint 中删除功能，而不是加班。
如果没有它，您的流程需要管理支持，敏捷只是一个词。
我提到过开明的管理吗？
【讨论】：
无法在每周 40 小时内完成任务可能是由于多种原因。
我发现这可能发生在 Scrum 项目的早期冲刺中，因为团队不确定：
他们也可能对在分配的时间内可以完成的事情过于乐观。
在那之后，我们进入了 Scrum 的几个不好的地方，具体来说：
如果其中任何一个插入，那么你是：
除了纠正第一个列表中的任何问题之外，您无能为力，但这只能通过经验来实现。
纠正第二个列表中的两点需要重新思考公司如何扼杀而不是雇用 Scrum 最佳实践。
HTH
问候，
罗伯
【讨论】：
这听起来可能很难，但让我们现实一点。使用敏捷或任何其他风格的软件过程与每周 40 小时无关。通常情况下，雇佣合同中规定了每周的工作时间，开发商可以自行决定是否提供任何额外的无偿工作。
请不要将神奇的治疗能力归因于您喜欢的任何软件过程。它可以提供不同的风险管理方法、不同的规划范围或更好的利益相关者参与；但是，除非奴隶制在您那里仍然合法，否则工作日从您进门开始，到您回家结束。
开发商有责任确保他们的管理不违反雇佣合同。无论使用何种方法，您的股份都受到您获得的薪酬金额和您同意付出的诚实工作时间的限制。
【讨论】：
当然。
对我来说最重要的帮助（按重要性排序）：
【讨论】：
除了以上所有因素（估计不准确、Scrum 实施不当等）之外，问题可能是对团队的Velocity 缺乏了解，就像“团队可以完成多少工作”一样简单，但不是easy to find as it may seem。
【讨论】：
我曾在多家实践各种敏捷方法的商店工作过。最有趣的是全天有 4 个“会话”，大约一个半小时，中间有 20 分钟的休息时间。周五是个人开发日，所以最后两节课是针对你想做什么的。
对我们来说，关键是沟通，真正确定用户故事的概念，将完成定义为“生产中”，以及信任。我们还确保将故事分成不超过一天的小块，最好是 1-2 次开发会议。我们通常在每个会话中将配对交换到每个其他会话。
目前我管理着一个 20 多人的开发团队，该团队部分分布。对我来说，关键的租户是可持续的节奏——这意味着我不希望我的团队每周工作超过 40 小时，即使是偶尔。显然，如果有人想迟到并处理事情，这取决于他们，但总的来说，我努力确保我们在每周 40 小时给我们的速度内工作。
【讨论】：
作为 Scrum Master 和人事经理，我一直大力倡导每周工作 40 小时。我积极劝阻团队成员不要工作超过 40 小时，因为随着工作与生活平衡的转变，生产力会迅速下降。我发现从深夜工作中恢复过来的时间通常比加班时间要长。
当运行良好时，Scrum 通过鼓励（要求？）始终保持一致的节奏来帮助最大限度地减少迭代结束时经常发生的“填塞”，并且速度和燃尽图等工具可以很好地计划和跟踪进度.
【讨论】：