我们正在进行的一系列关于敏捷方法的博客提供了对该方法及其对组织的影响的深入讨论。在本博客中，我们专注于敏捷团队中的协作。

大多数人在谈论敏捷内部的协作时会想到Scrum。 Scrum肯定是促成更有效协作的主要因素。请注意，我们将其称为一个促成因素; Scrum非常强调务实方面，而不是人为因素。在这篇博客中，我们的目标是突出敏捷中两个因素之间的联系。

Scrum

敏捷基于明确建立的时间框架内的迭代和协作软件开发的理念。这些迭代在Scrum中被称为“sprint”，这是最流行的敏捷方法。许多组织都应用Scrum框架，因为它相对简单，并且避免了开销。 Scrum组织的核心是一个多功能和自治的团队。每个团队成员都参与规划，暴露障碍和任务分配。 Scrum方法假设团队内部可以获得所有必需的知识，这反映在多功能和自治团队的想法中。通过这种方式，敏捷方法与传统的“瀑布式”方法完全不同，它们采用基于分工和“大设计前期”的线性，自上而下的方法。

敏捷软件开发发生在团队中，重点关注价值流。这与传统的项目管理方法（它们是IT失败的主要来源，与我们在另一篇博客中所论证的）完全不同。团队为每个sprint建立自己明确定义的目标，有时甚至是当天。目标是可以实现和现实的，因为团队成员自己将工作分成可管理的部分，并提供他们自己对这些任务需要多长时间的估计。由于固有的灵活性，务实的方法以及对任务的关注，团队成员共同努力实现共同目标。在每个Scrum团队中，都有一些定义明确的角色：产品所有者，Scrum主管和团队成员。

许多组织赞扬敏捷方法，因为他们的团队生产力提高了。如果方法在每个团队中正确应用，则情况确实如此。我们经常看到的是，许多应用该方法的组织很少关注团队中的人为因素，例如信任，动机，透明度，团队精神等。

根据Scrum的说法，任何关注计划，积压培训（优先考虑用户故事的会议），角色，职责，目标等的团队都将作为一个团队有效地协同工作。然而，一个重要的问题是，在缺乏相互信任的情况下，将很难取得进展。团队的成功不仅取决于方法的合理应用，还需要考虑人为因素。团队可以将Scrum的理性方面完美地执行，但最终，人类需要完成工作，因此关注这些人为因素同样重要。

人为因素

那么这些“人为因素”究竟是什么意思呢？考虑诚实，信任，团队成员的个性与作为一个整体的团队之间的平衡，勇气，勇气，领导力，发展，从错误中学习，变革管理，动力，同伴压力等等。从团队成员到团队成员，所有这些事情都会有不同的体验，并会对团队的成功产生影响。这些人为因素对于成功实施敏捷是绝对关键的。经验告诉我们，在敏捷框架内，关注和激发协作，建设性批评和持续改进至关重要，以确保从sprint到sprint的成功协作。

示例1：所需的空间和灵活性

敏捷团队通常由一些专业人员组成，他们从个人知识和技能的角度为最终结果做出贡献。预计这些专业人士将展现出一种开放和参与的参与，这自然意味着他们在团队合作中表现出色。每个专业人员都需要在结构化环境中拥有所需的空间和灵活性。当专业人员没有所需的空间时，他或她无法以最佳方式使用他或她的知识和能力。这反映了个人贡献者和贡献的可见性。许多团队成员/专业人员都在为此而努对许多敏捷团队来说，这是一个共同的挑战。

示例2：信任

在敏捷环境中，团队本身受到了很多关注。建立敏捷团队，并根据所需的知识，技能和经验将团队成员分配给团队。之后，工作将分配给各个团队和团队成员，以及具体目标。整个团队的建立和定义，但有时团队成员可能不会相互信任，因为误解，过去与同事的糟糕经历，焦虑等等。因此，团队成员可以作为个人而不是作为影响整个团队绩效的团队工作。通常，团队的结构受到很多关注，但对团队内部的情况没有那么多。就团队结构本身而言，这在成功和结果方面至少同样重要。

从这些示例中可以清楚地看出，成功的敏捷实现并不仅仅取决于建立正确的结构。人为因素也起着重要作用。 Scrum大师在改善人际互动和指导团队应用良好实践方面至关重要。他或她可以通过帮助团队制定一些黄金法则来实现这一目标。例如：敢于尽可能早地和频繁地分享。这是团队成员之间的合同，这将促进合作。此外，关于团队内部黄金法则的内部沟通非常重要。团队成员需要有空间来讨论他们在团队会议中的恐惧和错误。黄金规则是一种工具，可以帮助团队成员和Scrum管理员为这类会议提供便利。这是团队成员更好地熟悉Scrum方法的理想方式。

团队中的另一个关键任务是提供反馈，新成立的团队需要实践这一点。这将使团队成员有机会分享他们的个人故事和观点。创建一个开放和信任的环境，团队成员可以随时讨论改进问题。 Scrum主管可能还需要单独指导一些团队成员提供反馈。例如，当他们受到限制时，对同事给予反馈或过于批评。

敏捷方法比传统方法更需要合作，信任，承担责任和纪律。团队成员共同负责整体结果。作为个人成员，您不能简单地将结果的一部分扔到围栏上给另一个成员。因此，喜欢独自工作的开发人员可能在敏捷团队中表现不佳。逃避或孤独的行为对这样的团队来说是致命的。

这种开放和清晰沟通的需求是敏捷团队不能太大的原因之一。您需要个人交流，最适合最多7到10人的团队。 Scrum Master的作用是指导团队建立这样一个以团队为中心的文化。这是敏捷团队成功（或失败）的关键“软”因素之一，尤其是对于缺乏经验的团队。

在本博客的介绍中，我们重点介绍了Scrum方法如何为基于项目的团队提供结构和形状。成功的敏捷环境不仅取决于形式方面（计划，设定目标等），而且考虑团队中的人为因素也是关键。将软件开发中的正式方面和人为因素结合在一起将使组织能够以最佳方式运行敏捷。然而，在实践中，情况并非如此。

在本系列的未来博客中，我们希望讨论在具有复杂业务流程和系统环境的大型IT密集型组织环境中使用敏捷方法。在这样的背景下，项目组合管理，企业架构，业务流程设计和敏捷开发之间的关系变得越来越重要。然而，这些学科之间存在着各种紧张关系，一方面是在匹配他们不同的节奏和周期，另一方面，或许更重要的是，在他们的文化差异中。

请不要犹豫，分享您在敏捷团队中工作的经验和意见！

原文：https://bizzdesign.com/blog/efficient-collaboration-within-agile-methods/

本文：http://pub.intelligentx.net/efficient-collaboration-within-agile-methods

讨论：请加入知识星球或者小红圈【首席架构师圈】