确定障碍(废物)的成本

Question

一段时间以来，我们的Scrum团队经历了由外部因素对团队造成的反复障碍。团队在回顾中讨论了障碍，并在"Scrum of Scrum“中提出了这个问题。这些障碍似乎需要管理层的参与，因为它需要对我们的工作方式和技术环境的配置方式进行一些相当大的改变。在一个小范围内，这些问题可能会很容易处理，因为团队将有更多的控制，但在这种情况下，有多个团队，利益相关者和各方。我想听听你在浪费和成本方面的经验。您是简单地估计在反复出现的障碍上浪费的时间(例如，“我们在构建服务器上等待每个sprint浪费了10个小时)，还是您有一种更系统的方法来收集和显示浪费？

我想收集基于六西格玛(和精益软件开发)的废物，并估计废物成本的故事点。例如，在每一次回顾中，用每一类别中浪费的故事点数来突出浪费在七个类别中的浪费。这七种类型将是:部分完成的工作、额外的特性、重学习、切换、任务切换、延迟和缺陷。

在回顾结束时，将有一个明确的迹象，说明管理层很容易就能采取行动的外部障碍的成本。你认为如何？

Answer 1

如果你把你的问题彻底扭转过来，像这样呈现出来，也许你会得到管理层更多的支持；“如果我们解决了这个问题，我们能得到什么？”从积极的方面着手解决这个问题，根据我的经验，你会得到更好的回应。因此，与其强调问题(我们都可以做到这一点，直到我们面目全非)，不如指出解决方案，并指出改变的好处。

您可以列出您的团队认为是障碍的事情，并将自己设置为单独的“改进”待办事项。估计每一个项目，就像其他用户故事一样。然后，在你和你的利益相关者的计划会议上，你可以向他们展示你各种各样的建议，并给他们一个明确的成本效益。

“加里，如果我们把这个‘修复构建服务器’的故事包括在本周的sprint中，我们估计它有6分，我们认为，在未来，我们将能够提高速度约4分每冲刺。”

关于这一方法的一些额外的说明；

( 1)这些故事实际上是需要发生的(我完全忘记了这方面的'scrummy‘术语；故事点不应该对你的冲刺速度有所贡献，因为它们是一种成本，本身并不能推进真正的项目。

2)如果你先用一个小障碍故事成功了，你可能会在你的障碍清单上买到更多的东西。