自组织SCRUM团队和经济效率

由于SCRUM团队是自我组织的,他们可以自由选择如何实施任务。

但是,并不存在团队最终决定每隔几年进行一次完全重写(而不是不断重构)的风险,因为有一个新的花式框架可以稍微提高效率,忽略了整体经济观点?

如果是,如何在SCRUM中处理这个问题?

2
如果我理解正确,那么你认为重构总是比完全重写更有效。什么让你有那个想法?
额外 作者 Giorgio,
问题可能更简洁。怎么样“开发人员是一个不负责任的人,他们只是想以偷偷摸摸的方式摆弄。我们如何应对?”除了提供两个选项,让人们不要提出你自己没有的东西,让他们进入正确的思维模式。
额外 作者 Martin Maat,
@Euphoric明确它会破坏部分乐趣。正是那个时刻“哼哼噢喔喔喔!”我的目标是。
额外 作者 Martin Maat,
这个问题解决了真实产品生命周期中面临的非常有趣的风险!许多答案证明了这一点。不幸的是,它在某种程度上是主观的,这解释了许多downvotes。我试图以更客观的方式改写它,提出问题而不是做出假设,并谈论潜在的风险而不是无条件的问题。如果我误导,请不要犹豫。
额外 作者 Christophe,
这是人的问题,而不是技术问题。如果你的开发人员觉得重写是必要的,但你觉得他们只是很好,但没有必要,那么沟通在某处失败了。
额外 作者 Euphoric,
“这更有效地做事,忽视经济观点”你在这里自相矛盾。如果事情可以变得更有效率,那么这是完全合理的经济观点。
额外 作者 Euphoric,
@MartinMaat我希望你忘了你的
额外 作者 Euphoric,
@MartinMaat你永远不会在互联网上知道!在这里,我们有OP确切地说,只是用更好的词语。
额外 作者 Euphoric,

5 答案

经济观点原则上在产品负责人(PO),谁对 最大化交付价值 感兴趣,并且商业头脑。他/她通过对产品积压物品进行处理来实现这一目的。

开发团队致力于提供工作软件,并实施sprint计划会议中协商的产品待办事项。这是否需要重写或重构是属于团队的技术决策。必须相信团队正在做出最佳选择,并且在没有破坏高效团队动力的风险的情况下,技术决策不会受到PO干扰。

现在,如果团队决定重写主要部分会导致交付管道在较长时间内放缓,那么肯定不会出于花哨的原因。这可能是必要的投资。 但是,这会影响燃尽率,从而影响较长时间的sprint计划,这应该与PO讨论并达成一致,澄清什么是利害关系,并给出可预测性。

有争议地使用开发人员故事有助于保持对此类内容的可见性技术任务,但这些应在sprint积压中使用,如果不给用户带来额外价值,则不得对产品积压进行评估。

也可能是新框架的采用可以显着改善(甚至启用)现有的用户故事,在这种情况下,它对PO也很重要,并且会间接出现在产品积压中。

Attention: the thought that DT could start turning wild and is not committed to the product delivery bears the risk of breaking a fundamental trust. This might undermine the effectiveness of the agile approach, and in the worst case evolve into a self-fulfilling prophecy (e.g. DT starts to hide these technical aspects to PO fearing misunderstanding, and the PO only observing an unexplainable measurable decrease in performance, creating doubt and suspicion, which decreases DT motivation and increase turnover, etc.).

7
额外

这太傻了。每当一个团队每隔几年重新编写一次所有内容时,就会有数百个团队陷入困境,因为产品所有者要求减少技术债务。

如何解决这个问题?

与所有事情一样,过程无法解决人们的问题。而人们的问题很少会被解决 ......

最后,您的技术利益相关者和业务利益相关者需要实际合作才能找到合适的余额,以便为客户提供短期长期的最大价值。

但实际上 - 你没有,因为这不是问题。绝大多数常见问题是需要重写的团队,但感觉好像他们不能。

6
额外

在实践中,这是不正确的。 Scrum团队无法编写积压项目,重写通常会影响单个任务的范围。

其次,必须估算任务。这使产品负责人可以看到任务的经济影响。如果该功能的成本太高,那么它就不会被放入sprint中。

第三,每天团队都有一个产品所有者可以参加并听取的立场。每个人都会很快意识到重写并质疑它。

说了这么多,CV驱动的开发是一件事。产品所有者应该了解提供功能的其他方法,并且团队成员的动机(即奖金)应与其雇主目标保持一致

5
额外

Scrum需要信任。您应该相信您的开发人员正在做正确的事情。

我是一名开发人员,曾多次担任团队负责人。从我的角度来看,维护代码库时有三个选择:

  1. 随着时间的推移减少技术债务
  2. 通过定期重写组件(或整个应用程序)来支付一笔款项
  3. 不支付债务,并承受无法维护的遗留代码库的后果

不支付技术债务是失去优秀开发人员的最快方法。没有人愿意花费六个小时阅读逻辑来进行一线改变。这是浪费每个人的时间。

使用最新的框架不仅仅是关于简历构建或获得花哨的新功能。您还将更新供您使用的框架和工具的供应商和社区支持窗口。

就个人而言,我认为重写是更好的业务决策,因为您在较短的时间内整合工作,并且需要更少轮次的回归测试。

考虑到Scrum的性质,可能看起来估计的简单任务远远高于必要,但是当开发团队正在处理技术债务时,这种情况就会发生。你应该习惯它。

当各方相互信任时,Scrum最有效。您不能要求开发团队构建产品,然后质疑他们构建产品的方式。非开发人员通常没有意识到在功能增强的疯狂期间代码库变得混乱的速度有多快。

3
额外
“Scrum需要信任。您应该相信您的开发人员正在做正确的事情。”:任何工作环境都需要信任。
额外 作者 Giorgio,

不用说,这不应该发生。短跑的故事应该在PO的帮助下进行整理并选择即将到来的冲刺。如果故事的优先级不够高,那么它甚至不会进入冲刺阶段。

这一切都假设一个故事甚至会被认为而不是被拒绝。很难制作出一个作为...我想......所以... 故事从用户的角度构成,除了开发人员获得温暖的感觉之外没有任何好处因为他们正在使用前沿技术,他们可以把他们的简历。

最终,你在这里遇到了失败的过程。

0
额外
示例公式(当然取决于具体情况):“作为...我希望这个库(我的产品所基于的)升级到最新版本,这样在一年的时间里我仍然会得到bug修复“。
额外 作者 Giorgio,
正如我所说,这取决于具体情况。我的观点是技术升级可以为客户使用,在这种情况下,您可以为其编写用户故事。
额外 作者 Giorgio,
@Giorgio OP特别提到了一个新框架而不是更新。即使这样,简单地坚持使用一个版本(即使是一个不支持的版本)并不罕见,因为它是一个已知的数量,这样做可以避免大量的回归测试。
额外 作者 Robbie Dee,
@Giorgio当然,但前提是用户的要求可以通过新框架满足。客户很少关心使用什么框架,只要它能够完成工作。
额外 作者 Robbie Dee,