用户故事时间约束

Question

我的团队最近一直试图转向敏捷。线经理一直把每个用户故事的1-2天作为一个硬限制，而不是一个指导方针，如果时间限制没有得到满足，就把它设定为开发人员的失败。我不确定是否应该这样，因为在执行一个故事时有很多未知因素和可能的阻碍因素，或者故事可能在一开始就没有被正确地分解。我认为这部分与陷入瀑布思维有关，因此审查和调整需求并不是一个解决方案。

什么是好的方式，我可以沟通，这是造成不必要的压力？作为一种选择，我应该提出什么建议？

Answer 1

首先，Scrum指南相当清楚这种行为是错误的。开发团队，而且只有开发团队拥有这一点。(由于您在标签中指的是SAFe，我假设您也在使用Scrum )这不太可能阻止他，但是如果他觉得这是遵循规则的话(这是完全可能的)。他可能只是有个误会)。

在那之后，你也许想看看他为什么要这么做。这是误会吗？有其他地方的压力吗？也许他试图帮助团队完成一些事情，但这在他的信息中并没有体现出来。例如，他可能试图引入一种约束，让团队将工作分解得更小。

一旦你理解了他的观点，接下来的步骤就更容易识别了。就我个人而言，我通常与领导者分享，他们需要谨慎对待规则和度量标准。如果团队成员认为自己的成功最好是以牺牲代码质量等其他指标为代价，那么即使他的意图是好的，领导也可能会意外地造成一个巨大的问题。

Answer 2

敏捷软件开发的核心部分是自组织团队。

开发团队，而且只有开发团队，决定了sprint工作是如何完成的。开发团队的任何成员都不应该向该团队的其他成员报告。

外部人员(在您的情况下是经理)的任何干预都应该被scrum管理员或产品所有者阻止。如果经理是产品中的涉众，那么就有一个明确定义的过程，用于向待办事项中添加故事和审查已完成的工作。

当你必须在人工约束下工作时，你不能说你是“敏捷”的。如果你的经理不熟悉Scrum指南，那么我会在墙上贴上一些要点，以提醒你正在努力的方向和原因。

Answer 3

在我看来你需要一个Scrum大师。敏捷团队是自组织的，任何评估都应该由团队来商定，而不是一个人，特别是一个“项目经理”。

记住，这个想法不是做“好”的估计，而是做“一致”的估计。这意味着，如果你给一个故事的价值3，其他类似的故事应该有类似的价值。请记住，这个值与时间无关；因此，如果一个团队1等于一天(或8小时)，那么对于其他团队来说，这个值可能意味着16或4小时。随着你的冲刺来来去去，这个估计应该越来越“精确”。

在软件开发中，评估总是很困难的，我认为您的经理要么在这个特定领域缺乏(很好的)经验，要么认为压力和斥责有助于提高开发时间(提示:他们没有)。

关于如何沟通的话题:也许在一个回顾性的仪式上，总是从一些积极的事情开始。

PD:下面是一些关于规划扑克的信息：https://en.wikipedia.org/wiki/Planning_扑克