16、管理Scrum团队：混沌边缘的智慧

管理Scrum团队：混沌边缘的智慧

在当今的软件开发领域，管理Scrum团队是一门极具挑战与艺术的学问。要想让Scrum团队发挥出最佳效能，管理者需要深入理解其所处的环境以及适用的管理原则。

混沌边缘的软件开发环境

传统的工作环境，尤其是自18世纪以来的制造业环境，是基于清晰定义的流程来实现成功的可重复性。在软件工程发展初期，人们也期望能像其他工程领域一样，通过明确的流程和规则来管理软件开发。然而，随着组织复杂度的增加，复杂性理论的研究揭示了软件工程的一些有趣事实。

复杂性理论中，存在稳定系统、不稳定系统和混沌行为三种系统状态。稳定系统在受到外界干扰后，能迅速恢复到稳定状态，如月球绕地球的轨道运行。不稳定系统则会逐渐远离稳定，直至受到某种约束而停止，就像在结冰道路上骑自行车滑倒的情况。而混沌行为系统介于两者之间，它有一定规律，但难以预测，例如天气。

软件工程就符合混沌系统的描述。1994年的CHAOS调查显示，83.8%的软件开发项目存在取消、交付不足、超预算等问题。同时，还有一些科学原则进一步说明了软件工程的不确定性：
- Ziv的软件工程不确定性原则 ：软件开发过程和产品中固有的不确定性是不可避免的。
- Humphrey的需求不确定性原则 ：对于新的软件系统，直到用户使用后才能完全明确其需求。
- Wegner引理 ：交互式系统永远无法完全被定义和测试。

这表明软件工程既不是稳定系统，也不是不稳定系统，而是处于混沌边缘。在这个边缘地带，传统的管理方法往往难以奏效。

混沌系统中的管理之道

现代大型企业已经意识到，传统管理实践在混沌系统中效果不佳。以谷歌为例，它的管理方式体现了对复杂性理论的理解：
1. 自主选择团队 ：开发者入职后有时间了解项目和团队，通过为团队产品提出新特性来申请加入团队，若团队认可其工作，便邀请其加入。
2. 灵活的团队调动 ：开发者若对当前团队感到厌倦，只需表达意愿，就能快速转到其他团队。
3. 鼓励自由探索 ：鼓励开发者每周花一部分时间从事与当前项目无关的工作。
4. 团队自主决策 ：谷歌不直接告诉开发者做什么，开发团队自行决定工作内容和方式。

这些管理方式反映了混沌系统中管理的基本经验，对于Scrum团队和敏捷开发环境具有重要的借鉴意义。

持续学习的重要性

在混沌系统中，组织虽然有明确的方向和目标，但很多情况在一开始是未知的。试图通过分析来应对一切意外不仅成本高昂，而且不能保证成功，甚至可能使组织陷入停滞。因此，在这样的环境中，管理和软件开发需要持续的学习循环。

在敏捷环境中，通常采用回顾机制来总结一段时间内的经验教训。在每个冲刺结束时，Scrum团队和管理团队都应评估上一个冲刺的表现，确定如何改进。很多时候，讨论中会发现团队需要获取或提升某些重要技能，团队应积极识别这些需求并尽快采取行动。

此外，组织文化也应注重持续学习。员工（包括管理者）应设定个人学习目标，定期提升专业和技术技能。为了提高培训目标的决策质量，员工应与团队共同确定最有利于组织的培训内容，并在此基础上制定个人目标。

鼓励变革与混沌

追求稳定性和僵化结构的组织往往创新能力不足，秉持“如果没坏，就别修”的理念。然而，软件开发充满不确定性，更合适的理念应该是“如果它有效，打破它，看看能否做得更好”。敏捷开发者倡导“快速失败，经常失败”，因为真正的改进来自于了解哪些方法行不通。管理复杂性理论强调对意外、巧合和偶然发现持开放态度，战略是在这个过程中逐渐形成的。

就像达·芬奇创作《蒙娜丽莎》，这幅画历经近二十年，有多达三十层的颜料。达·芬奇知道第一遍创作并非最佳，他不断改进画作和创作方法。在组织中，找到完成任务的“正确”方法并不意味着找到了最佳方法，混沌系统需要不断探索和改变。

结构的流动性

Scrum团队的一个原则是具备完成工作所需的技能。通常，我们会根据工作需求组建合适的团队，但一旦团队形成并开始高效运作，我们往往会将工作从属于团队，而不是重新评估团队组建的初衷是否仍然有效。

在混沌系统中，管理者应鼓励自发形成非正式结构，以应对组织面临的问题或抓住机会。这些结构应具有自组织能力，能够重新定义或扩展其职责，而不是受固定定义的束缚。

对于Scrum团队，每次冲刺后都应重新评估团队的目的和能力：
1. 问题或机会是否仍然存在 ：如果导致团队成立的问题或机会已经消失，团队应考虑解散，寻找其他合作机会。
2. 团队技能是否匹配 ：如果问题或机会发生了变化，团队的技能可能不再匹配，可能需要调整团队成员或平衡技能。

混沌环境能够挖掘员工的个人技能和兴趣，而传统管理策略可能会使这些潜力被隐藏。高级管理层的职责是在稳定系统的传统管理方法（分析和规划）与混沌系统的非常规管理方法（学习和灵活性）之间找到平衡。过度追求稳定会使组织停滞不前，而过度混乱则会导致组织陷入无政府状态，无法实现短期目标。

一线经理的职责

一线经理通常是Scrum团队中开发人员的行政主管，他们与团队的接触最为直接，在团队人员配置决策中起着重要作用。一线经理有时是技术资源，有时是领导者，但也可能成为团队的障碍。一个好的一线经理就像牧羊犬，围绕着Scrum团队，保持团队的专注和团结，处理影响团队进度的缺陷和障碍。他们的具体职责包括：
1. 帮助解决障碍 ：Scrum主管可能会被团队报告的障碍压垮，或者缺乏解决某些障碍的权力。一线经理应经常与Scrum主管沟通，确保没有障碍因缺乏权力而得不到解决。
2. 调解团队纠纷 ：当团队成员之间发生关于产品设计或个性冲突的争论时，一线经理应尊重团队的自我管理责任，引导双方达成合理的解决方案。
3. 支持个人发展 ：虽然开发者要对自己的绩效和职业发展计划负责，但经理可以提供想法、结构和支持。经理需要确保员工的绩效和职业发展计划与团队和组织目标相匹配，并提供必要的信息和建议。
4. 过滤组织“噪音” ：组织中充满了各种新员工入职、人员调动、消息发布等事件，这些都会产生噪音。一线经理需要帮助Scrum主管组织这些信息，确保团队在合适的时间听到他们需要的信息，避免团队被频繁打断。
5. 处理行政职责 ：一线经理还需要承担日常的行政职责，如撰写状态报告、参加会议、参与组织战略规划等。

同时，一线经理需要学会将大部分职责委托给Scrum团队，信任团队做出的决策，避免过度指导和微观管理。此外，他们还可能面临处理不适合团队环境的成员的问题，需要及时做出正确的决策，以免影响整个团队的士气。

一般管理职责

除了一线经理，中层和高层管理者在敏捷环境中也承担着重要的责任：
1. 与员工保持沟通 ：敏捷开发会引发组织中的许多问题，员工希望向管理层表达他们的担忧和想法。管理者应倾听员工的意见，让他们知道管理层理解敏捷开发，并愿意解决组织中的重大问题。
2. 展示对敏捷转型的承诺 ：向敏捷开发转型不仅仅是开发过程的改变，还会影响企业的各个方面和企业文化。员工需要在转型过程中感受到管理层的全力支持，即使出现错误和挫折也不例外。
3. 传达愿景 ：管理者应经常向员工解释企业的愿景，并说明团队的工作如何支持这一愿景。通过反复强调和扩展愿景，让员工深刻理解并明确自己在实现愿景中的角色。
4. 幕后领导 ：将权力下放给Scrum团队的管理者应学会从侧面指导团队，通过提出引导性问题而不是直接提供解决方案来领导团队。同时，要将自己视为团队的支持者，而不是高高在上的领导者。
5. 让团队自主决策 ：让Scrum团队决定标准和实践，并在讨论中强调这是团队的决策。避免将责任从团队转移到组织，让团队掌握主导权。

提升团队绩效的方法

Scrum团队作为自我管理和自我组织的团队，应定期评估和提升自己的绩效。然而，优秀的管理者应时刻关注帮助团队提升绩效的机会。许多Scrum团队在一段时间后会达到绩效瓶颈，他们解决了一些容易解决的问题，但可能会采用绕过问题而不是解决问题的方法。

管理者在评估团队绩效时，应避免以下两个错误：
1. 过度干预 ：Scrum团队应对自己的绩效和改进负责，管理者不应随意改变团队的实践。
2. 微观管理 ：过度参与团队的日常活动会削弱团队的自我管理能力，使团队依赖管理者来提供方向和解决问题。

为了挑战团队达到更高的绩效水平，管理者可以关注以下方面：
| 评估方面 | 评估要点 |
| — | — |
| 冲刺规划 | - 冲刺规划会议是否有效，是否设定了冲刺承诺，确定了完成每个待办事项的方法，并生成了支持承诺的冲刺待办事项。
- “完成”的定义是否是确定如何完成待办事项的关键要素。
- 整个Scrum团队（包括产品负责人）是否参加会议。
- 产品待办事项在冲刺规划前是否已排序、估算大小并准备好。 |
| 冲刺执行 | - 冲刺是否超过31天。
- 冲刺是否曾被延长以让团队成员“完成工作”。
- 是否有非Scrum团队成员修改冲刺规划承诺。
- 是否有非Scrum团队成员导致冲刺规划承诺被修改。
- 冲刺待办事项是否每天更新。
- 冲刺是否以可工作的软件结束。
- 团队是否生成了无人使用的文档。
- Scrum主管是否努力保护团队免受外界干扰和噪音。
- Scrum主管是否始终积极消除障碍。
- 团队承诺的待办事项和任务是否放置在大家都能看到的地方。 |
| 每日站会 | - 每日站会是否每天举行。
- 是否每个人都参加每日站会。
- 每日站会是否在15分钟内结束。
- 是否有非Scrum团队成员参加每日站会。
- 每个人是否都围绕三个问题发言。 |
| 待办事项梳理 | - 待办事项梳理会议是否在整个冲刺期间举行。
- 整个团队（包括产品负责人）是否参与。
- 团队是否持续拆分待办事项，直到它们小到可以放入一个冲刺，然后再处理其他待办事项。
- 团队是否陷入无价值的冗长讨论，是否有方法检查进度并决定是否继续讨论。
- 当产品待办事项上有足够（略多）的梳理好的事项用于下一个冲刺时，团队是否停止梳理。 |
| 冲刺评审 | - 评审是否主要是展示软件。
- 管理层是否参加冲刺评审。 |
| 冲刺回顾 | - Scrum团队是否在每个冲刺后举行回顾会议。
- 回顾是否导致团队实践的改进，团队决策是否关注根本原因而非表面影响。
- 回顾是否以列出三到四件需要继续做或改变的事情结束。 |
| 关于Scrum团队 | - Scrum团队是否过大（超过九人）。
- Scrum主管是否倾向于告诉团队成员做什么。
- 任何管理者是否倾向于告诉团队成员做什么。
- 团队成员遇到问题时是向自己还是团队外的人寻求答案。
- Scrum团队是否有明确的“完成”定义。
- Scrum团队是首先从如何解决问题的角度评估问题，还是关注谁导致了问题。
- Scrum团队是否将错误和失败视为改进的机会，还是变得更加保守。
- 团队是注重横向扩展技能，还是变得越来越专业化。
- 团队中的每个人是否都参与讨论，所有意见是否都被听取，还是一两个人的意见主导决策。
- 团队是否具备完成工作所需的技能和知识，还是经常需要等待所需信息才能完成工作。
- 团队是否愿意冒险和犯错，还是倾向于避免尝试新事物。
- 团队是将纠正组织决策和问题的责任推回组织，还是认为自己有权力做出决策。他们是抱怨问题、忽视问题还是解决问题。 |
| 关于开发实践 | - 团队编写的单元测试是支持代码应有的功能，还是已经实现的功能。
- 团队成员是否一起编写代码和测试、构建用户界面并同时更新文档，还是相互交接工作。
- 团队是否每天多次构建产品，以确保过去几个小时的工作没有破坏构建。
- 团队是否每天多次测试产品，以确保过去几个小时的工作没有破坏应用程序。
- 团队是否经常对代码进行重构，以提高代码的可维护性。
- 团队是否对冲刺期间编写或更改的代码进行某种形式的同行评审。 |

在帮助Scrum团队提升绩效时，管理者不应将一个团队的绩效与另一个团队进行比较。每个Scrum团队都是独特的，由不同的人组成，面临不同的问题和挑战。管理者应根据团队自身的行动和决策来采取相应的措施。

总之，管理Scrum团队需要管理者在混沌边缘找到平衡，理解软件开发的不确定性，采用适合混沌系统的管理方法，支持团队的持续学习和发展，鼓励变革和创新，同时注重团队结构的流动性和团队绩效的提升。只有这样，才能让Scrum团队发挥出最大的潜力，实现组织的目标。

管理Scrum团队：混沌边缘的智慧

深入剖析团队绩效评估要点

在上文我们已经提及管理者在评估Scrum团队绩效时需要关注多个方面，接下来我们进一步深入剖析这些要点，以便管理者能更精准地把握团队状态。

冲刺规划

冲刺规划是一个关键环节，它为整个冲刺阶段设定了方向和目标。有效的冲刺规划会议应该让团队成员清晰地了解冲刺的承诺，明确每个待办事项的完成方法。“完成”的定义至关重要，它是衡量工作是否达标的标准，确保团队成员对工作成果有一致的理解。整个Scrum团队，包括产品负责人的参与也不可或缺，产品负责人能从业务需求的角度提供关键信息，保证冲刺目标与业务目标的一致性。而产品待办事项在规划前的排序、估算大小和准备工作，则为冲刺规划提供了坚实的基础。

冲刺执行

冲刺执行过程中，有诸多细节需要管理者关注。冲刺时长的控制是一个重要因素，过长的冲刺可能导致目标不明确、进度拖沓，一般来说不应超过31天。同时，随意延长冲刺时间来“完成工作”并不是一个好的做法，这可能暗示团队在规划或执行过程中存在问题。非Scrum团队成员对冲刺规划承诺的修改或导致其修改，会破坏团队的自主性和稳定性。冲刺待办事项的每日更新能让团队成员及时了解工作进展，确保工作按计划进行。以可工作的软件结束冲刺是Scrum的核心目标之一，避免生成无人使用的文档，将精力集中在有价值的产出上。Scrum主管在这个阶段要扮演好保护者和推动者的角色，保护团队免受外界干扰和噪音，积极消除各种障碍，让团队能够专注工作。团队承诺的待办事项和任务的可视化展示，有助于提高透明度，促进团队成员之间的沟通和协作。

每日站会

每日站会是Scrum团队保持沟通和同步的重要机制。每天举行站会能让团队成员及时分享进展、问题和计划。控制站会时间在15分钟内，能保证高效沟通，避免冗长的讨论。只有Scrum团队成员参与站会，能确保信息的针对性和准确性。每个人围绕三个问题发言，即昨天做了什么、今天计划做什么、遇到了什么问题，能让团队快速了解整体情况。

待办事项梳理

待办事项梳理会议贯穿整个冲刺期间，有助于保持产品待办事项的有序性和可用性。整个团队（包括产品负责人）的参与能确保从不同角度看待待办事项，进行合理的拆分和优先级排序。持续拆分待办事项直到适合放入一个冲刺，能提高工作的可管理性。避免陷入无价值的冗长讨论，通过有效的方法检查进度并决定是否继续讨论，能提高会议效率。当产品待办事项上有足够（略多）的梳理好的事项用于下一个冲刺时停止梳理，能避免过度准备，保证资源的合理利用。

冲刺评审

冲刺评审主要是展示软件，让利益相关者了解冲刺的成果。管理层的参加能体现对团队工作的重视，同时也能从战略层面给予反馈和指导，确保团队的工作方向与组织目标一致。

冲刺回顾

冲刺回顾是团队持续改进的重要机会。每个冲刺后举行回顾会议，能让团队及时总结经验教训。回顾应关注团队实践的改进，深入分析问题的根本原因，而不是只关注表面影响。以列出三到四件需要继续做或改变的事情结束回顾，能让团队明确改进的方向和重点。

关于Scrum团队

Scrum团队的规模、团队成员的协作方式、问题解决的态度等方面都反映了团队的健康状况。团队规模过大（超过九人）可能会导致沟通成本增加、协作效率降低。Scrum主管和管理者应避免过度干预团队成员的工作，让团队成员有足够的自主性和决策权。团队成员遇到问题时的求助方向，反映了团队的知识共享和协作氛围。明确的“完成”定义能保证工作质量，从解决问题的角度评估问题能促进团队的成长和改进。将错误和失败视为改进的机会，鼓励团队勇于尝试新事物，注重横向扩展技能，能提高团队的灵活性和创新能力。团队成员的广泛参与和意见的充分听取，能保证决策的科学性和合理性。团队具备完成工作所需的技能和知识，以及愿意承担责任解决问题的态度，是团队高效运作的关键。

关于开发实践

开发实践直接影响软件的质量和可维护性。团队编写的单元测试应支持代码应有的功能，而不是仅仅基于已实现的功能，这有助于保证代码的正确性和可扩展性。团队成员一起编写代码和测试、构建用户界面并同时更新文档，能提高工作的连贯性和一致性。每天多次构建和测试产品，能及时发现问题，避免问题积累。对代码的经常重构能提高代码的可维护性，同行评审则能促进知识共享和代码质量的提升。

管理策略的动态调整

在管理Scrum团队的过程中，管理者需要根据团队的不同发展阶段和实际情况，动态调整管理策略。

团队形成期

在团队刚刚组建时，成员之间可能还不太熟悉，工作流程也尚未完全建立。此时，管理者需要更多地发挥引导作用，帮助团队成员明确目标、建立信任。可以组织一些团队建设活动，促进成员之间的沟通和协作。在这个阶段，管理者可以适当提供更多的指导和支持，帮助团队成员快速适应新的工作环境和工作方式。

团队风暴期

随着团队开始工作，可能会出现各种矛盾和冲突，这就是团队的风暴期。管理者需要及时发现并解决这些问题，引导团队成员以积极的方式处理分歧。鼓励团队成员坦诚沟通，尊重不同的意见，共同寻找解决方案。在这个阶段，管理者要保持耐心和公正，避免偏袒任何一方，确保团队的稳定发展。

团队规范期

经过风暴期的磨合，团队逐渐进入规范期，成员之间的协作更加顺畅，工作流程也更加稳定。此时，管理者可以适当减少干预，给予团队更多的自主权。鼓励团队成员自我管理、自我激励，发挥团队的最大潜力。同时，管理者要关注团队的创新和持续改进，引导团队不断优化工作方法和流程。

团队执行期

当团队进入执行期，能够高效地完成工作任务时，管理者的重点应放在支持团队的发展和创新上。为团队提供必要的资源和支持，鼓励团队成员尝试新的技术和方法，不断提升团队的竞争力。同时，管理者要关注团队的长期发展，为团队制定合理的发展规划。

借助工具提升管理效率

在管理Scrum团队的过程中，合适的工具可以帮助管理者更好地监控团队绩效、促进团队协作。

项目管理工具

如Jira、Trello等项目管理工具，能帮助管理者实时了解项目进度、任务分配和问题跟踪。这些工具提供了直观的界面，让管理者可以清晰地看到每个待办事项的状态和责任人，及时发现并解决问题。同时，项目管理工具还支持团队成员之间的沟通和协作，方便信息的共享和交流。

代码管理工具

Git等代码管理工具在软件开发中起着至关重要的作用。它可以记录代码的变更历史，方便团队成员之间的代码协作和版本控制。管理者可以通过代码管理工具了解团队成员的代码贡献情况，监控代码质量，及时发现潜在的问题。

沟通协作工具

Slack、Microsoft Teams等沟通协作工具，能促进团队成员之间的实时沟通和协作。这些工具提供了丰富的功能，如即时通讯、文件共享、视频会议等，方便团队成员在不同地点进行高效沟通。管理者可以利用这些工具及时了解团队成员的工作状态和需求，提供必要的支持和指导。

总结与展望

管理Scrum团队是一个复杂而又充满挑战的过程，需要管理者在混沌边缘找到平衡。理解软件开发的不确定性，采用适合混沌系统的管理方法，支持团队的持续学习和发展，鼓励变革和创新，注重团队结构的流动性和团队绩效的提升，是管理者的核心任务。

在未来的软件开发领域，随着技术的不断发展和市场需求的不断变化，Scrum团队的管理也将面临新的挑战和机遇。管理者需要不断学习和适应新的环境，灵活运用管理策略和工具，激发团队的创造力和潜力，为组织创造更大的价值。同时，团队成员也需要不断提升自己的能力和素质，积极参与团队管理和决策，共同推动团队的发展和进步。只有管理者和团队成员的共同努力，才能让Scrum团队在激烈的市场竞争中立于不败之地。

通过以下的mermaid流程图，我们可以更清晰地看到管理Scrum团队的整体流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(混沌边缘的软件开发环境):::process --> B(混沌系统中的管理之道):::process
    B --> C(持续学习):::process
    B --> D(鼓励变革与混沌):::process
    B --> E(结构的流动性):::process
    C --> F(一线经理职责):::process
    D --> F
    E --> F
    F --> G(一般管理职责):::process
    F --> H(提升团队绩效):::process
    G --> H
    H --> I(深入剖析评估要点):::process
    H --> J(管理策略动态调整):::process
    H --> K(借助工具提升效率):::process
    I --> L(总结与展望):::process
    J --> L
    K --> L

这个流程图展示了从理解软件开发环境到最终实现团队高效管理的整个过程，各个环节相互关联、相互影响，共同构成了管理Scrum团队的完整体系。管理者可以根据这个流程，系统地开展管理工作，不断优化管理策略，提升团队的整体绩效。