跳到主要内容

由于俄罗斯入侵乌克兰,我们已经暂停所有购买和培训进出俄罗斯。

您如何处理不希望将工作投入sprint的团队?

最后一篇文章由Joshua Uda于2015年1月16日下午05:17发表
6个回答
2015年1月11日02:09

团队正在进行第三次冲刺。管理层给了他很大的压力,要他把MVP赶出去。待办事项列表是按照大件工作应该完成的顺序排列的。

当被问及是否可以在2周内(在下一个sprint结束前)提交功能X时,他们总是闪烁其词,不会表示同意或不同意。一半的团队乐观地认为它会完成,另一半认为它不会完成(看看速度,我不认为它会完成)。

在这种情况下,PM应该做什么?我们都是scrum/敏捷的新手。


2015年1月12日12:02

以下是我认为在这种情况下可以做的一些事情。
故事可以被分解(SM应该和PO一起完成这个工作)。这将允许更好的评估,从而提高团队致力于某事的能力
团队成员之间似乎没有共识,因此SM可以通过一些团队建设活动来改善这一点。(我正在浏览《团队建设工具包》这本书)似乎团队正处于形成阶段。
同时,在与团队交谈时,SM可以再次强调团队承诺背后的原因。


2015年1月12日03:40

如果你阅读scrum指南,你会发现它谈论的是团队预测他们在sprint中可以交付什么,而不是承诺交付什么。这是一个关键字,可能会带来不同。
似乎团队中的一些成员对能够交付的内容有他们的犹豫——要么他们知道的不够多(没关系),要么他们知道的一些东西意味着他们要么能够完成,要么无法阻止它。让他们明白你想要的是诚实的答案,而不是别的。你想要作为一个团队进行讨论,并深入了解人们为什么会这样思考/感觉。
你也可以试试这个
问团队:“如果我们在这个sprint结束时坐在这里,我们已经完成了今天预测的所有故事,会发生什么事情呢?”
然后你可以问他们:“如果我们坐在这里,在这个sprint结束的时候,我们甚至还没有接近我们今天预测的故事,会发生什么事情?”
这使得团队可以自己扮演魔鬼倡导者。
然后你可以讨论每个列表上的每个项目——试着让“交付所有东西”部分的事情成为现实,让“甚至不接近”部分的项目远离团队。
通常情况下,“甚至不接近”将揭示存在哪些组织障碍,需要升级到更高的水平,并进行更多的辩论。

鼓励团队开放和诚实——这增加了透明度,在每个sprint结束时或团队觉得他们需要适应的时候,检查和适应会更容易!

记住,一切都是经验主义!


2015年1月13日凌晨03:20

+1和蒂姆,这都是经验主义!
充其量,团队成员可以给你一些估计(预测或百分比),但没有人能说“我100%肯定这项工作将在两周内完成”,否则他们只是为了取悦你而撒谎。


2015年1月13日上午05:02

一半的团队乐观地认为它会完成,另一半则认为
它不会完成(看看速度,我不认为它会完成)。
>
在这种情况下,PM应该做什么?我们都是scrum/敏捷的新手。

在Scrum术语中,最直接的问题不是工作是否可以实际完成。最直接的问题是,在Sprint开始之前,团队无法协作并达成可操作的共识。那么,为了交付一个成功的结果,团队能够在Sprint期间一起工作的机会有多大?

您应该将此视为改进这些协作方法的早期机会。需要考虑的事情包括:

-团队成员现在拥有的技术技能
-技能如何共享,例如通过结对
-团队成员是否对风险和依赖关系有相同的看法
-团队组成是否合适


2015年1月16日上午11:39

如果所有的用户描述都是基于“INVEST”原则创建的,我不明白为什么团队不能承诺交付。我建议团队用5个“为什么”来找出这种不情愿的根本原因:

-为什么我们没有信心在下个sprint完成这些故事,即使它们已经被估算出来了?
在达成一致的答案的基础上,你可以继续问为什么,找到根本原因,从而帮助团队解决他们的问题/顾虑。

我的2美分


2015年1月16日下午05:17

这是一个很好的问题,也是组织过渡到scrum的常见困境。以下是我听到和经历过的好建议。

你不能用滑板车跳50辆公交车……无论坡道多么陡峭。

管理层可以施加压力并提出要求,但除非团队懒惰或分心,否则高管们也可能会迫使太阳更快升起。他们在scrum中施加压力的唯一目的是将待办事项提前,而你似乎已经做到了。

Scrum是基于经验过程控制的。这意味着用我们知道的(过去)而不是用我们不知道的(未来)来进行预测。Scrum的答案就在你的陈述中,从速度(已知的过去)来看,你认为他们做不到。如果在努力上达成了共识,并且两周内需要付出的努力比两周内已经付出的还要多,那么这个噱头就不会很顺利。那些乐观的人依赖于他们不知道的东西(预测他们认为自己在一段时间内可以做什么),而不是依赖于他们知道的东西,速度(他们在一段时间内一直在做的事情)。

团队不应该做出承诺。

现在的细微差别是,scrum团队不应该关注来自管理层的“压力”,而应该关注产品所有者的优先级。团队没有向管理层承诺在sprint结束时会做x;相反,他们向彼此承诺,他们将在sprint中完成x。那些持乐观态度的人可能会觉得,他们可以实施一些过去行之有效的应急措施。也许在这段时间内速度会更高。在这种情况下,团队成员可能会相互承诺他们会尝试一下。

这里的海报上有很好的建议。

如果x太大,那么试着把它分解成更小的功能和价值。如果该特性必须是全部或没有,请考虑伸缩敏捷框架。x是一个可以在一个发布周期中交付的特性,它的子pbi是在sprint中交付的。有些可以用于内部用户。作为一名开发人员,我需要这个数据库模式,以便为最终用户创建x。

如果这是一个经常出现的问题,那么也许团队需要过渡到更长的冲刺。对于经常构建大型特性的组织,可能需要长达一个月的时间。

如果真正的问题是时间,管理层必须在两周内完成x,那么就放弃NOS或更换自行车。如果没有这些选项,就不要玩Evil Knievel。

希望这些想法能像帮助我一样帮助你。

最好的

杰克


在我们的论坛上发帖,即表示您同意我们的使用条款。

请注意,您的Scrum.org会员资料中的姓和名将显示在您在论坛上发表的任何主题或评论旁边。出于隐私考虑,我们不允许您发布电子邮件地址。所有用户在我们论坛上提交的内容,如果被发现违反了我们的使用条款,可能会被删除。Scrum.org不认可用户提交的内容或任何第三方网站的链接内容。

使用条款

Scrum.org可以自行决定删除任何它认为不适合这些论坛的帖子。不合适的帖子内容包括但不限于:Scrum.org专业级评估问题和答案、亵渎、侮辱、种族主义或色情内容。使用我们的论坛作为营销和招揽产品或服务的平台也是被禁止的。论坛成员发布被Scrum.org认为不合适的内容可能会在任何时候被取消访问权限,不作警告。Scrum.org可以,但没有义务,监督提交的内容。

Baidu