27、软件架构师的团队管理与清单运用指南

软件架构师的团队管理与清单运用指南

1. 架构师的角色与类型

开发团队需要架构师的支持和指导，当技术或业务相关问题出现时，他们也期望架构师能随时提供解答。然而，存在一种“纸上谈兵型架构师”，这类架构师有以下特征：
- 未能充分理解业务领域、业务问题或所使用的技术。
- 软件开发的实践经验不足。
- 未考虑架构解决方案实施过程中的潜在影响。

有些时候，架构师并非有意成为“纸上谈兵型架构师”，只是由于同时参与多个项目或团队，精力分散，从而与技术或业务领域脱节。架构师可以通过更多地参与项目中使用的技术，深入理解业务问题和业务领域，来避免成为此类架构师。

与之相对的是“高效架构师”。高效的软件架构师会为团队设定适当的约束和边界，确保团队成员能够良好协作，并获得恰当的指导。他们还会确保团队拥有正确且合适的工具和技术，同时排除可能阻碍开发团队实现目标的障碍。要成为开发团队的高效领导者并非易事，这需要与团队紧密合作、协作，并赢得团队的尊重。

2. 架构师应施加多少控制

成为一名高效的软件架构师，关键在于明确对特定开发团队应施加多大程度的控制，这一概念被称为“弹性领导”。确定架构师应扮演“控制狂”还是“纸上谈兵者”角色，主要涉及以下五个因素，这些因素也决定了架构师一次能管理多少团队或项目：
|因素|说明|
| ---- | ---- |
|团队熟悉度|团队成员彼此了解的程度如何？他们之前是否曾在项目中合作过？一般来说，成员间越熟悉，团队的自组织能力越强，所需的控制就越少；反之，新成员较多时，则需要更多控制来促进协作并减少小团体的形成。|
|团队规模|团队规模大小（通常认为超过 12 名开发者为大团队，4 名及以下为小团队）。团队越大，所需控制越多；团队越小，所需控制越少。|
|整体经验|团队中资深成员和初级成员的数量，以及他们对技术和业务领域的了解程度。初级开发者较多的团队需要更多控制和指导；资深开发者较多的团队则需要较少控制，此时架构师的角色从导师转变为促进者。|
|项目复杂度|项目是高度复杂，还是只是一个简单的网站？高度复杂的项目需要架构师更多地参与团队并协助解决问题，因此需要更多控制；相对简单的项目则不需要太多控制。|
|项目时长|项目是短期（两个月）、长期（两年）还是平均时长（六个月）？项目时长越短，所需控制越少；时长越长，所需控制越多。|

例如，对于一个为期两个月的快速项目，由于时间有限，开发团队本身具有强烈的紧迫感，架构师应更多地扮演“纸上谈兵型架构师”的角色，过多的控制可能会阻碍项目进展。而对于一个为期两年的项目，开发者可能会比较放松，架构师则需要更多的控制来确保项目按时推进，并优先完成复杂任务。

通常在项目开始时，会依据这些因素来确定控制水平，但随着系统的发展，控制水平也会发生变化。因此，建议在项目的整个生命周期中持续分析这些因素，以确定对开发团队应施加的控制程度。

为了说明如何利用这些因素确定架构师对团队的控制水平，我们为每个因素设定一个固定的 20 分制评分标准。负分更倾向于“纸上谈兵型架构师”（控制和参与度较低），正分更倾向于“控制狂型架构师”（控制和参与度较高）。以下是两个具体场景示例：

场景 1
|因素|数值|评分|角色倾向|
| ---- | ---- | ---- | ---- |
|团队熟悉度|新团队成员|+20|控制狂|
|团队规模|小（4 名成员）|-20|纸上谈兵者|
|整体经验|全是有经验的成员|-20|纸上谈兵者|
|项目复杂度|相对简单|-20|纸上谈兵者|
|项目时长|2 个月|-20|纸上谈兵者|
|累计得分|-60|纸上谈兵者|

在场景 1 中，架构师应最初扮演促进者的角色，不过多参与团队的日常互动，让有经验的团队自主快速开发软件，但仍需随时解答问题并确保团队方向正确。

场景 2
|因素|数值|评分|角色倾向|
| ---- | ---- | ---- | ---- |
|团队熟悉度|成员彼此熟悉|-20|纸上谈兵者|
|团队规模|大（12 名成员）|+20|控制狂|
|整体经验|大多是初级成员|+20|控制狂|
|项目复杂度|高度复杂|+20|控制狂|
|项目时长|6 个月|-20|纸上谈兵者|
|累计得分|-20|控制狂|

在场景 2 中，架构师应参与团队的日常活动，承担指导和辅导的角色，但注意不要过度干扰团队。

需要注意的是，这些因素难以完全客观量化，某些因素（如团队整体经验）可能比其他因素更重要。在实际应用中，可以根据具体情况对指标进行加权或调整。

3. 团队预警信号

团队规模是影响架构师对开发团队控制程度的重要因素之一。确定最有效的开发团队规模时，有三个因素需要考虑：
- 过程损耗 ：也称为布鲁克斯定律，由弗雷德·布鲁克斯在《人月神话》一书中提出。其基本观点是，向项目中增加人员会导致项目耗时增加。团队的实际生产力总是低于团队的潜在生产力，两者的差值就是过程损耗。例如，当向代码仓库推送代码时频繁出现合并冲突，这可能表明团队成员在工作中相互干扰，在同一代码上进行操作。架构师可以通过寻找团队内的并行工作区域，让成员在不同的服务或应用区域工作，来避免过程损耗。当有新成员加入项目时，如果没有可并行的工作流，架构师应向项目经理说明新增成员可能对团队产生的负面影响。
- 多元无知 ：当团队规模过大时，容易出现多元无知现象。即每个人都表面上同意某种规范，但私下里却持反对意见，因为他们认为自己可能忽略了某些明显的信息。例如，在一个大型团队中，多数人认为在两个远程服务之间使用消息传递是最佳解决方案，但有一人因两个服务之间存在安全防火墙而认为这是个愚蠢的想法，但由于害怕被视为无知或傻瓜而不敢提出异议。高效的软件架构师应在协作会议或讨论中观察成员的面部表情和肢体语言，当察觉到多元无知现象时，应及时介入，询问成员对提议解决方案的看法，并支持他们表达自己的观点。
- 责任分散 ：随着团队规模的增加，沟通会受到负面影响，导致团队中出现对责任归属的混淆和任务被遗漏的情况。例如，在一条乡村小路上，有人的汽车抛锚，路过的人可能都会停下来询问是否需要帮助；而在大城市的繁忙高速公路上，即使有成千上万辆车经过，也很少有人会停下来。架构师应关注团队的健康状况，确保团队成员能够共同协作实现目标，通过识别并纠正这些预警信号，来保证开发团队的高效运作。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([确定团队规模]):::startend --> B{团队规模大小?}:::decision
    B -->|大| C(关注过程损耗):::process
    B -->|大| D(警惕多元无知):::process
    B -->|大| E(注意责任分散):::process
    C --> F(寻找并行工作区域):::process
    D --> G(观察成员表现并介入):::process
    E --> H(明确责任归属):::process
    F --> I(避免过程损耗):::process
    G --> J(促进真实沟通):::process
    H --> K(确保任务完成):::process
    I --> L([团队高效运作]):::startend
    J --> L
    K --> L

4. 利用清单

航空公司的飞行员，即使是经验丰富的资深飞行员，每次飞行都会使用清单。飞行员有起飞、降落以及数千种常见和特殊情况的清单，因为一个被遗漏的飞机设置（如襟翼设置为 10 度）或程序（如获得进入终端管制区的许可）可能会导致飞行安全与灾难之间的巨大差异。同样，阿图尔·加万德医生在《清单革命》一书中，描述了清单在外科手术中的强大作用。他创建的手术清单成功降低了医院的葡萄球菌感染率。

清单是确保所有事项都得到涵盖和处理的有效工具，但软件开发行业却没有充分利用它们。虽然清单能显著提高开发团队的效率，但软件开发与飞行、手术不同，并非所有事情都需要清单。关键在于明确何时使用清单，何时不使用。

以下是一些关于清单使用的要点：
- 不适合清单的情况 ：具有依赖任务的程序性流程，以及简单、频繁执行且无错误的已知流程，不适合使用清单。例如，创建新数据库表的所谓“清单”，实际上是一系列程序性步骤，不应该以清单形式呈现。因为在表单未提交的情况下，无法验证数据库表。
- 适合清单的情况 ：没有程序顺序或依赖任务的流程，以及容易出错、步骤易被遗漏的流程，适合使用清单。
- 清单创建的注意事项 ：
- 避免过度创建清单，否则会导致边际效益递减，开发者使用清单的可能性会降低。
- 清单应尽可能简洁，同时涵盖流程中的所有必要步骤，因为开发者通常不会遵循过于冗长的清单。
- 可以将能够自动化执行的项目从清单中移除。
- 不要担心在清单中列出明显的事项，因为这些往往是最容易被跳过或遗漏的。

常见且有效的清单包括开发者代码完成清单、单元和功能测试清单以及软件发布清单。

5. 霍桑效应与清单使用

引入清单到开发团队时，一个常见问题是开发者可能不会真正使用它们，有时会在未完成任务的情况下就标记清单项目已完成。为解决这一问题，可以采取以下措施：
- 与团队沟通清单的重要性，让成员阅读《清单革命》，确保他们理解每个清单的用途和原因。
- 让开发者参与讨论清单应包含和不应包含的内容。
- 当其他方法都无效时，架构师可以利用“霍桑效应”。该效应指的是，当人们知道自己被观察或监控时，他们的行为会发生改变，通常会做出正确的行为。架构师可以告知团队清单对团队效率至关重要，所有清单都会被验证，但实际上只是偶尔抽查，以此促使开发者认真对待清单，减少跳过或虚假标记的情况。

6. 开发者代码完成清单

开发者代码完成清单是一个非常有效的工具，特别是当软件开发人员声称代码“完成”时，它也有助于定义“完成的定义”。如果清单中的所有项目都完成了，开发者才能真正声称代码完成。以下是开发者代码完成清单中应包含的一些内容：
- 自动化工具未涵盖的编码和格式化标准。
- 经常被忽视的项目（如被吸收的异常）。
- 项目特定的标准。
- 团队的特殊指示或程序。

通过合理运用这些清单和管理策略，架构师能够更好地领导开发团队，提高团队的工作效率和软件质量。

软件架构师的团队管理与清单运用指南

7. 单元和功能测试清单

单元和功能测试是软件开发过程中确保代码质量的关键环节，单元和功能测试清单能帮助团队系统地进行测试工作，确保所有必要的测试都被执行。以下是单元和功能测试清单可能包含的内容：

测试类型	测试要点
单元测试	- 对每个独立的函数和类进行测试，确保其功能符合预期。 - 覆盖各种边界条件，如输入的最大值、最小值、空值等。 - 检查函数的异常处理机制是否正常工作。
功能测试	- 根据需求文档，对软件的各项功能进行全面测试。 - 验证不同用户角色在系统中的操作是否符合设计。 - 检查系统在不同环境下（如不同操作系统、浏览器）的兼容性。

在执行单元和功能测试时，架构师可以按照以下流程进行：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始测试]):::startend --> B(制定测试计划):::process
    B --> C(编写单元测试用例):::process
    C --> D(执行单元测试):::process
    D --> E{单元测试是否通过?}:::decision
    E -->|否| F(调试代码):::process
    F --> C
    E -->|是| G(编写功能测试用例):::process
    G --> H(执行功能测试):::process
    H --> I{功能测试是否通过?}:::decision
    I -->|否| J(修复功能问题):::process
    J --> G
    I -->|是| K([测试完成]):::startend

8. 软件发布清单

软件发布是一个复杂的过程，涉及到多个环节和团队的协作。软件发布清单可以确保发布过程的顺利进行，避免出现遗漏和错误。以下是软件发布清单的一些常见项目：

• 代码方面 ：
  • 所有代码都已通过单元和功能测试。
  • 代码已合并到主分支，且主分支代码稳定。
  • 代码注释和文档已更新，确保新功能和修改部分有清晰的说明。
• 环境方面 ：
  • 生产环境已准备就绪，包括服务器配置、数据库连接等。
  • 对生产环境进行了预演测试，确保系统在生产环境中的正常运行。
• 部署方面 ：
  • 部署脚本已编写完成，且经过测试。
  • 制定了回滚计划，以应对可能出现的问题。
• 沟通方面 ：
  • 通知相关团队（如运维、客服等）软件发布的时间和内容。
  • 准备好发布说明文档，供用户和相关人员参考。

发布阶段	具体任务
发布前	- 完成代码审查和测试。 - 准备生产环境。 - 编写部署脚本和回滚计划。 - 通知相关团队。
发布中	- 执行部署脚本。 - 监控系统运行状态。
发布后	- 进行最终检查，确保系统正常运行。 - 收集用户反馈，及时处理问题。

9. 综合运用清单和管理策略

架构师在团队管理中，需要综合运用上述各种清单和管理策略，以确保开发团队的高效运作和软件项目的成功交付。以下是一些具体的操作建议：
- 项目启动阶段 ：根据项目的特点和团队情况，确定架构师对团队的控制程度。运用团队熟悉度、团队规模、整体经验、项目复杂度和项目时长等因素进行评估，并制定相应的管理策略。同时，制定软件发布清单，明确各个阶段的任务和责任人。
- 开发阶段 ：使用开发者代码完成清单，确保开发者按照规范完成代码编写。同时，利用单元和功能测试清单，保证代码质量。架构师要关注团队的预警信号，如过程损耗、多元无知和责任分散，及时采取措施进行调整。
- 发布阶段 ：严格按照软件发布清单进行操作，确保软件的顺利发布。在发布过程中，持续监控系统状态，及时处理可能出现的问题。
- 持续改进阶段 ：定期对项目进行回顾和总结，分析清单的使用效果和管理策略的有效性。根据反馈结果，对清单和管理策略进行调整和优化，以适应不同项目的需求。

通过以上全面的管理方法和清单的运用，架构师能够更好地领导开发团队，提高团队的工作效率和软件质量，确保项目按时、高质量地交付。同时，团队成员也能在清晰的规范和指导下，更加有序地开展工作，减少错误和重复劳动，提升整个团队的协作能力和竞争力。