敏捷 绩效_改善敏捷团队绩效

敏捷 绩效

Lonesome Cowboy Reflex（LCR）是一种在软件开发团队中经常出现的现象，并且似乎是导致性能不佳的主要原因。 但是，如果您知道要查找的内容，那么就不难发现，并且有缓解该问题的方法。

什么是寂寞牛仔反射？

从日常情况中考虑以下情形：

约翰 ：我一直在研究故事X，希望今天完成。

Scrum管理员 ：好的，但是在过去两天里你一直在这样说。 别人可以帮你早点完成吗？

约翰 ：Pfff ...不。 我几乎知道仍然需要发生什么，并且我现在正在该代码库上工作，因此，新手将使我更加放慢脚步。 不用担心，我今天解决。

Scrum master ：好的，好吧，让我们知道是否可以伸出援手。

约翰 ：会的。

听起来很熟悉？

在许多软件团队中，这种情况一次又一次地发生。 John只是展示了我们称为“寂寞牛仔反射”的故事：他打算独自走上故事X的道路，并且不想要伸出援手。

如果您只是忽略LCR，会发生什么？

假设您有一个跨职能团队，进行了为期两周的冲刺，其中包括测试人员，Scrum管理员，开发负责人和其他五个开发人员。 如果应用上述方案，最终可能会同时处理五个故事，每个开发人员一个。

以下是一些必然会发生的事情：

Scrum主管将听到很多“仍在处理”的信息，但与此同时，也发出了无法采取任何措施的信号。 他可能会开始感觉自己像每个开发人员的私人服务员。
首席开发人员将不得不不断将自己的精力和注意力分配到五个不同的故事和解决方案中，同时参与这五个故事和解决方案。 根据他所扮演的角色的确切要求（例如代码审查），他会变得很苗条。
另一方面，测试人员很可能会抽动拇指直到冲刺结束，这时突然有五个故事可供测试，他必须急于完成工作。 对于他的压力水平来说可能不大。

您自己的团队设置和角色可能有所不同，但是您可以掌握要点。 这种情况与SCRUM和Kanban等敏捷方法所针对的目标完全相反……然而，在所谓的敏捷团队中，它却经常发生。

使用Lonesome Cowboy Reflex，您没有一个团队致力于达成一系列目标，而是拥有一系列个人，各自致力于实现自己的单个目标。 力量分散得太少，交付的不确定性增加，一切都取决于个人的努力。 缺乏团队责任感，对于“不是我的问题”行为还有很大的空间，并且个人压力分配不公。 所有这些几乎破坏了建立团队的全部目的。

不解决“寂寞牛仔反射”问题，可能导致没人再关心“团队成果”。

什么原因导致LCR？

关于LCR的最常见的解释是，不可能在同一个故事中一起工作。 “真的没有意义，我们只是互相妨碍。”

那明显是错的。

在软件工程方面进行协作时，有很多工具可以简化它。 良好的软件体系结构使得完全可以在软件的不同领域进行工作，而且可以在相同的故事上进行工作。

因此，争论实际上归结为没有认真考虑如何去做。 除非有人或某物强迫我们，否则我们可能不会。

免责声明：我想指出，我一直都是并且自己仍然是软件开发人员。 出于叙述的目的，LCR似乎是开发人员表现出的某种令人讨厌的，邪恶的行为，但是，当然，它的细微之处要多得多。

那么到底是什么导致了LCR？

大多数软件工程师都很有能力并且很乐意独自完成某项工作。 这实际上是问题的核心：留在我们的舒适区。

通常，我们自己做某事会感到很自在，因为我们对所要包含的内容有很好的了解。 我们控制并信任自己的行为。 最重要的是，我们希望拥有所有权和随之而来的个人成就感。

不幸的是，有两个复杂的因素：

我们个人认为是成就或负责任的行为，需要与团队保持一致，因为通常只有真正重要的是总结果，而不仅仅是我们付出的全部故事。 而且，我们在认知上有偏见：我们倾向于高估自己的能力，同时又低估了同事的能力。

有时候，还有其他一些因素在发挥作用，例如害怕在小组比赛中丢脸。 但是无论如何，这一切都没有什么坏处，只是人类的行为。 努力做到安全舒适是我们自然追求的目标。 但是，众所周知，这不是魔术发生的地方。

LCR的原因与软件工程师无关。 有些人只是比其他人拥有更多，但我不敢宣称任何软件开发人员通常都会遇到这种情况。

我们如何应对LCR的影响？

避免Lonesome Cowboy Reflex的最佳短期解决方案是，通过消除LCR发生的可能性，简单地改变环境。 从长远来看，这一切都是为了在新的环境中创造积极的体验，因此个人的舒适区域会转移到团队中。

应用敏捷方法本身不足以解决此问题。 尽管它提供了一个处理此问题的框架，但实际执行才是最重要的，这可能非常困难。 最后，它是关于建立和指导团队的。

有效解决LCR从上而下开始：

作为项目经理：不要分散力量

当涉及到资源计划时，控制预算的人很多时候倾向于以一种安全感为目标。 当正在进行3个项目时，项目经理都希望知道他们的项目正在“今天”进行。 因此，您将看到一个团队通过从上方推动而分为三种方式。

从交付的角度来看，这确实是一种错误的安全感。 更好的选择可能是让一个团队连续处理每个项目中的项目。 如果可能会觉得违反直觉，那是因为有人会觉得自己正在承担所有风险，甚至完全被排除在外。 但实际上，我们通过改善重点降低了整体风险。

抵制将人控制为资源的冲动，但与整个团队更多地合作，以确定可交付成果并以此方式建立信任。 在计划级别，请确保所有项目经理都在同一页面上有关其项目的分布，并确保他们可以长期来看（而不是每天）感到公平。

作为团队负责人：限制正在进行的工作并消除障碍

这是看板的基本原则，短期内最有效。 我经常看到，虽然正确地安排了故事的优先顺序，但在团队层面却不尊重“先完成故事再开始”的方法。

强制协作的最快方法是不提供其他出路。 请尝试以下操作：只给团队提供一个项目，然后告诉他们尽快完成。 尽管这看起来有些苛刻，但它要求每个团队成员都拉平他们的常规思维并以“艰难的方式”做某事……或什么都不做。

但是要当心：您将必须在那里消除障碍。 有时，有人需要帮助我们越过我们竖起的看不见的墙。 愿意寻找使事情成为可能的方法。 不要试图告诉他们如何去做，而只是不要拒绝，也不要放弃您的问题。

作为个人：抑制自己的React

我本人经常遭受LCR的折磨，但是我不得不承认，每次我被迫超越它并与其他开发人员真正地携手合作时，它最终都会得到回报。 甚至在大多数情况下，即使我一直在思考一些“实际上还不错，但确实速度更快”的思路。

意识到自己的React并愿意承认我们在某些事情上可能略有扭曲的观点，这可能会在采取行动改善它方面大有帮助。

真正意义上的就是使开发人员在足够低的水平上一起工作：边做边学，并建立将个人转变为高绩效团队的经验。

即使这是对“非常规”现象的过分简化，但本文还是关于提高团队绩效的。 就像在体育运动中一样，组建一支好的团队需要付出很多努力，并且需要在保持个人满意度的同时将个人优势指向团队成果。 这意味着一直都在使用整个团队的全部人才库！ 我们经常倾向于忘记最后一点。

希望我给您足够的信息来帮助您识别LCR，以及一些有关如何采取措施防止LCR的想法。

翻译自: https://www.javacodegeeks.com/2018/08/improving-agile-team-performance.html

敏捷 绩效