软件工程需要领导者，而不是ScrumMasters！

我最近回顾了SCRUM和ScrumMaster的角色。 我们知道，ScrumMaster应该充当仆人领导。 她应该提供指导而不是做出决定，消除障碍，但仍要赋予团队权力：总而言之，ScrumMaster应该充当团队内部的促进者，使团队与外界隔离，确保团队遵循SCRUM最佳实践。

我们还被告知，SCRUM团队不应选举技术负责人，因为团队中的每个人（ScrumMaster和产品负责人除外）应承担相同的责任。

首先，我认为，不管SCRUM怎么说，在任何团队中都注定要出现至少一位技术领导者。 这在我工作的每个团队中都发生过。总会有人自然地担任技术领导，并且团队成员愿意寻求决策。 我认为这个人应该带领团队是对的。 这显然与SCRUM告诉我们的内容相矛盾，因此我只是相信SCRUM在这方面做错了一切。

其次，我认为，除了第一次接触敏捷和SCRUM的团队之外，这将受益于ScrumMaster /敏捷教练，ScrumMaster的身材是没有必要的。 我相信，经验丰富的敏捷团队非常了解如何使用敏捷（SCRUM）工具，并且不需要帮助者来告诉他们该怎么做。 短跑，TDD，结对编程，回顾，团队责任等，都是经验丰富的敏捷团队的正常能力。

到底什么是仆人领导？ 看，但不要碰？ 触摸但不品尝？ 品尝但不吞咽？ 不，我认为团队领导/技术领导的旧概念仍然适用于我处理过的大多数情况，这代表了任何团队的自然发展。

我们应该将自组织Sprint的角色委托给团队，消除障碍（如果您愿意的话，可以采取更精益的方法），整理燃尽的东西，进行回顾等等。我认为ScrumMaster的概念在很大程度上营销活动的方向，在这种情况下，典型的顾问突然能够以ScrumMaster，敏捷教练，协调人的身份转售自己。

软件工程不需要那里存在的灰色图形，但是无法感觉到它们的存在，它们只负责团队交付的部分内容（例如，观察SCRUM实践，消除障碍等）。 我们需要可以在整个项目生命周期中采取行动的人员，可以前后做出决策的人，即使在团队认为该方向应该是另一个方向时，也可以负责将团队推向一个明确的方向……我们需要领导者，而不是营销活动和标签。

参考： 软件工程需要领导者，而不是ScrumMasters！ 来自我们的JCG合作伙伴   Marco Tedone在Marco Tedone的博客上 。

翻译自: https://www.javacodegeeks.com/2012/03/software-engineering-needs-leaders-not.html