跨职能团队

每个敏捷爱好者都将告诉您一个自我授权的跨职能团队的力量。 一旦拥有了一个，它就可以将完整的团队责任从产品构想带到客户支持，它自然会随着不断的改进而增长，并且会在创新和交付客户价值中找到自我激励。

这是一个美丽而强大的概念。 跨功能的团队有时实际的执行情况并不那么好，而且往往不是您所获得的。

让我们看看我遇到的跨功能示例。

伪专家跨功能团队

开发人员： “我是开发人员，无意测试，测试人员必须测试！”

测试人员： “我不需要了解产品的设计方式，我只关心客户如何使用它！”

业务分析师：“我不是技术人员，我不能帮助你们！”

跨功能团队“只要对我们有用”

开发人员 ：“它在我们的环境中有效，使其在生产中起作用是运营的责任”

测试人员 ：“听着，它在UAT中工作，这一定是配置问题，或者是缺少防火墙漏洞，在测试过程中我什么也没发现……”

客户：“您好！ 这里什么都没用……”

退位跨职能团队

开发人员 ：“建筑师告诉我要这样做”

测试人员 ：“好吧，让测试经理来解决它”

业务分析师 ：“我认为这个故事没有任何价值，但是产品负责人想要它，所以继续发展吧！”

持续下降的跨职能团队

开发人员 ：“回顾毫无意义，事情总是一样的”

测试人员 ：“我们没有时间尝试新事物！”

业务分析师 ：“我们这样做是因为，这就是我们在这里做事的方式，就是这样！”

分散的跨职能团队

开发人员 ：“我的代码完美运行，这是他们的系统不起作用，谁在乎”

测试人员 ：“我们的覆盖率达到100％，所有测试均通过，并且没有错误，如果系统X的开发人员是白痴，我们对此无能为力”

客户 ：“不过，这里什么也没做……”

纳粹跨职能团队

开发人员 ：“测试人员是失败的程序员，不应称为工程师”

测试人员：“开发人员只能产生错误，更多的测试人员和更少的开发人员将使世界变得更好”

业务分析师 ：“我不知道为什么要打扰测试人员和开发人员，他们是白痴”

您是否在上述类别之一中认可您的团队？ 到目前为止，您做了哪些工作来帮助您的团队进行变革？ 小？ 没有？ 但是，您仍然对此感到恶心，不是吗？

请记住，您非常强大，可以成为您想要看到的改变。

翻译自: https://www.javacodegeeks.com/2014/09/cross-dysfunctional-teams.html