31、专业人士与通才：软件开发中的角色权衡与项目管理挑战

专业人士与通才：软件开发中的角色权衡与项目管理挑战

在软件开发的复杂世界中，专业人士（Specialists）与通才（Generalists）的角色定位以及项目管理中的人力投入问题，一直是备受关注的焦点。这些问题不仅影响着项目的质量和效率，还决定了团队的整体表现。

专业人士与通才的冲突

在软件开发项目里，为避免代价高昂的返工，尽早发现故障至关重要。例如，在设计手机系统时，若假定手机能从消息系统调用网页浏览器，而开发开始后才发现很多目标手机不具备此功能，整个项目就会陷入危机。

多数敏捷方法主张在项目早期引入开发者，他们通常是通才，需参与需求工作，确保需求在技术上可行、切实可行且风险最小。然而，这与Capers Jones的研究结果相冲突，他认为专业人士团队能产生更高的吞吐量。

通过“蒸发云图”（Evaporating Clouds diagram）可以直观地看到这种冲突。其目标是尽早发现错误并在成本增加前纠正。图中展示了两条冲突路径：一方面，分析师（专业人士）需尽早参与以捕获问题；另一方面，开发者（通才）也需尽早介入。

一些敏捷方法学家认为图中的分析师路径不可行，他们认为专业分析师无法深入思考问题，问题往往在开发者编写代码时才被发现。敏捷方法倾向于使用开发者。但TOC理论认为，Capers Jones的数据与敏捷经验之间的冲突可能存在错误假设。

这些假设包括：只有开发者能深入思考流程，因为他们要编写代码并处理细节；分析师不能或不会深入思考问题。开发者的假设看似合理，但分析师不能深入思考问题的假设是否成立呢？实际上，人们不会故意做不好工作，可能有两个原因：一是组织的政策或流程使分析师认为无需深入思考问题；二是分析师为尽快完成工作而缺乏深度思考。

解决这一冲突的方法是“注入”新想法，消除错误假设。若问题源于政策或流程，需改变政策、重写流程，让分析师认识到深入思考问题是其职责。若问题是局部关注分析阶段，可改变评估规则，以整个系统的吞吐量衡量分析师，避免其只关注局部效率。Carmine Mangione提出，分析师还应编写分析的验收测试用例，这能让他们意识到系统的循环性质和质量问题的后果。

因此，Capers Jones认为专业人士应优于通才，而敏捷方法学家认为通才开发者更优，二者的冲突是有合理解释的。Jones衡量的是专业人士受良好流程激励和控制的组织，而敏捷方法学家是对自身环境的反应，他们认为无法解决分析师的系统问题，通过消除分析师来提高质量和性能。最终结论可能是，一个组织糟糕、激励不当、技能不足的专业人士团队，会被通才的敏捷团队超越；但一个优秀的专业人士团队，在合理规则和质量导向下，应能胜过敏捷通才团队。Scott Ambler提出的“通才专家”（Generalist Specialists），即具备特定领域深入技能且在其他领域有足够技能的软件工程师，可能是敏捷团队的理想成员。

增加人力使项目延期

Fred Brooks认为，给延期项目增加人力会让项目更晚完成，这与约束理论中应提升约束的观点冲突。软件开发是劳动密集型过程，人力是约束，按常理应增加人力来提升。但为何会出现冲突呢？

这是因为改变会带来干扰，即“J曲线效应”。当引入改变时，生产速率（R）会下降，若改变是真正的改进，系统会学会利用改进，生产速率会上升并超过原水平。Brooks观察到，引入更多人力时软件生产速率会下降，主要原因是现有开发者要花费精力培训新开发者。虽然新开发者跟上进度后生产速率可能提高，但并非线性提升。

Brooks所说的给延期项目增加人力会使项目更晚，是指从J曲线底部恢复并弥补新人力引入造成的生产损失所需时间，超过了项目剩余时间。这基于项目延期早期预警缺失的假设，当项目经理意识到项目真正延期时，增加人力已为时过晚。

Brooks建议通过加班完成项目来提升人力约束，加班可暂时消除8小时工作日的政策约束，提高生产速率。这表明选择开发和提升约束的方法很重要，应根据具体情况而定。Eli Goldratt指出，所有改进都是改变，但并非所有改变都是改进，只有在其他约束范围内提高吞吐量的改变才是改进。在项目中，交付日期是约束，若改变不能在交付日期约束内带来净改进，就不是有价值的改变。

软件开发的控制状态与变异减少

在软件开发中，关于过程的可预测性和可控性存在不同观点。Beedle和Schwaber支持Scrum时认为，所有软件开发都是经验性的，无法精确规划、不可重复且难以分类，敏捷方法通过持续评估和反馈应对这一问题。“经验性”（Empirical）在敏捷领域被广泛使用，但实际含义存在争议。

“经验性”意味着基于观察，如观察到太阳每天升起且间隔24小时，可据此推测明天太阳也会升起。实际上，仅通过观察的过程不一定是混乱的，可能是可预测的。重要的是经验性过程是连续还是不连续（收敛或发散）。在本文中，“经验性”仅指基于观察，这类过程通常是可预测和连续的，“混乱”指不连续过程。

有人认为所有敏捷方法应完全依赖反馈而非规划，这意味着软件开发处于混乱边缘。但Walter A. Shewhart和W. Edwards Deming开创的统计过程控制技术为这一问题带来了科学视角，他们的工作推动了日本制造业的质量提升。

Shewhart认为，若一个过程能在一定范围内定期测量，就是“受控”的，即过程收敛、无混乱行为且在约定范围内。他用控制图（Control Chart）展示这一状态。Don Wheeler基于其工作将控制状态分为四种：理想状态、阈值状态、混沌边缘状态和混乱状态。

• 理想状态 ：过程随时间稳定，输出的自然波动在产品规定的公差范围内。过程以稳定一致的方式运行，不随意改变。过程的平均吞吐量已知且可设定和维持，产生的错误极少或可忽略不计。传统软件工程生命周期方法常假设软件开发能处于此状态，但实际上软件中的错误很常见，软件开发很少处于理想状态。
• 阈值状态 ：过程在统计上基本可控，超出约定公差的变异很少，因变异产生的错误数量少、可预测且可管理。要使处于阈值状态的过程向理想状态发展，可改变规格（放宽公差）或改进过程以减少变异，如六西格玛方法。FDD（Feature Driven Development）可通过调整功能列表改变特定版本的规格，还可使用5点加权量表评估功能复杂度，精确测量软件开发过程的控制水平。FDD能跟踪每个功能的错误和时间，并与估计值比较，根据趋势调整量表。FDD通过特定语言描述功能（
• 混沌边缘状态 ：即使过程能生产合格产品，也处于失控状态。多数敏捷方法假设软件开发处于此状态，认为过程会受到随机、不可预测的严重干扰，导致超出可接受公差。在这种情况下，预测和规划往往无效，因为会产生错误。Scrum和XP等敏捷方法通过快速反馈、开发者的经验知识来应对，但没有固定的应对方法，建议让有经验且能自我组织的人员处理混乱情况。快速反馈的优势在于管理层能迅速发现异常情况，在问题影响交付前采取补偿措施。
• 混乱状态 ：过程无法生产合格产品且不可控，这对许多软件开发人员来说并不陌生。

综上所述，在软件开发中，专业人士与通才的角色选择、人力投入以及过程控制状态都是需要深入考虑的重要因素。合理平衡这些因素，才能提高项目的质量和效率，实现项目的成功交付。以下是这些内容的总结表格：
| 主题 | 关键内容 |
| — | — |
| 专业人士与通才冲突 | 敏捷方法用通才开发者，Capers Jones认为专业人士团队吞吐量高；冲突源于假设差异，可通过改变政策、重写流程等解决 |
| 增加人力使项目延期 | 与约束理论冲突，因“J曲线效应”，增加人力初期生产速率下降，需根据情况选择提升约束的方法 |
| 软件开发控制状态 | 分为理想状态、阈值状态、混沌边缘状态和混乱状态，不同状态特点和应对方法不同，FDD可使过程处于阈值状态并向理想状态发展 |

下面是软件开发控制状态的mermaid流程图：

graph LR
    A[软件开发控制状态] --> B[理想状态]
    A --> C[阈值状态]
    A --> D[混沌边缘状态]
    A --> E[混乱状态]
    B -->|稳定、错误极少| F(特点描述)
    C -->|基本可控、错误少可管理| G(特点描述)
    D -->|失控、受随机干扰| H(特点描述)
    E -->|无法生产合格产品| I(特点描述)
    C -->|改变规格或改进过程| J(向理想状态发展)
    D -->|快速反馈、经验应对| K(应对方法)

专业人士与通才：软件开发中的角色权衡与项目管理挑战

不同控制状态下的软件开发策略

不同的控制状态对软件开发策略有着深远的影响，下面进一步探讨在各个状态下如何更好地制定和执行策略。

理想状态下的极致追求

在理想状态中，软件开发过程高度稳定，错误几乎可以忽略不计。这是一种理想的追求，但在实际操作中很难长期维持。为了尽可能接近和保持这种状态，我们需要建立一套严格且完善的质量保障体系。

• 持续的流程优化 ：定期对开发流程进行审查和改进，确保每一个环节都能高效、稳定地运行。例如，采用自动化测试工具，对代码进行全面的单元测试、集成测试和系统测试，及时发现并修复潜在的问题。
• 人员培训与发展 ：为开发团队提供持续的培训和学习机会，使他们能够不断提升技能水平，跟上技术的发展步伐。可以组织内部技术分享会、参加外部技术研讨会等。
• 严格的变更管理 ：对任何可能影响开发过程的变更都要进行严格的评估和控制。在引入新的技术、工具或方法时，要进行充分的测试和验证，确保不会破坏现有的稳定状态。

阈值状态下的稳步提升

阈值状态是软件开发中比较现实的目标，通过合理的策略可以逐步向理想状态迈进。

• 精准的需求管理 ：在FDD中，通过调整功能列表和5点加权量表，能够精确地管理需求。在项目启动阶段，要与客户充分沟通，明确需求的优先级和范围。在开发过程中，根据实际情况对需求进行动态调整，确保项目能够按时、高质量地交付。
• 数据驱动的决策 ：利用FDD提供的详细数据，如每个功能的错误数量、开发时间等，进行深入的分析。通过数据分析，找出影响开发效率和质量的关键因素，制定针对性的改进措施。
• 团队协作与沟通 ：建立良好的团队协作机制，加强开发人员、测试人员和客户之间的沟通。可以采用敏捷开发中的每日站会、迭代回顾等方式，及时解决问题，提高团队的工作效率。

混沌边缘状态下的灵活应对

在混沌边缘状态下，软件开发面临着诸多不确定性和挑战，需要采取灵活的应对策略。

• 快速迭代与反馈 ：Scrum和XP等敏捷方法强调快速迭代和反馈，通过短周期的开发和频繁的评审，及时发现并解决问题。在每个迭代结束后，根据反馈结果对产品进行调整和优化，确保项目始终朝着正确的方向前进。
• 风险管理 ：识别并评估可能影响项目的风险因素，制定相应的风险应对计划。可以采用风险矩阵等工具，对风险进行分类和排序，优先处理高风险的问题。
• 知识共享与经验传承 ：鼓励团队成员之间的知识共享和经验传承，提高整个团队的应对能力。可以建立知识库、组织技术交流活动等，让团队成员能够快速获取所需的信息和经验。

混乱状态下的绝地反击

当软件开发处于混乱状态时，需要采取果断的措施来扭转局面。

• 重新定义项目目标和范围 ：对项目的目标和范围进行重新评估和定义，确保项目的可行性和可操作性。如果项目的目标过于宏大或范围过于宽泛，要进行适当的调整，集中资源解决关键问题。
• 建立有效的项目管理体系 ：引入专业的项目管理方法和工具，建立明确的项目计划和进度控制机制。加强对项目的监控和管理，及时发现并解决项目中的问题。
• 团队重建与激励 ：对团队进行重建，调整人员结构，引入有经验的人员。同时，建立有效的激励机制，激发团队成员的积极性和创造力，提高团队的凝聚力和战斗力。

总结与展望

在软件开发的旅程中，我们面临着诸多的挑战和选择。专业人士与通才的角色权衡、人力投入的决策以及过程控制状态的管理，都直接影响着项目的成败。

通过合理地选择专业人士和通才，根据项目的实际情况调整人力投入，以及针对不同的控制状态采取相应的策略，我们可以提高软件开发的质量和效率，实现项目的成功交付。

未来，随着技术的不断发展和创新，软件开发领域将面临更多的机遇和挑战。我们需要不断学习和探索，采用更加先进的方法和技术，优化软件开发过程，以适应不断变化的市场需求。同时，加强团队建设和协作，培养高素质的软件开发人才，也是提高软件开发竞争力的关键。

希望本文能够为软件开发人员和项目管理者提供一些有益的参考和启示，帮助他们在复杂的软件开发环境中做出明智的决策，实现项目的目标。

以下是不同控制状态下应对策略的总结表格：
| 控制状态 | 应对策略 |
| — | — |
| 理想状态 | 持续流程优化、人员培训与发展、严格变更管理 |
| 阈值状态 | 精准需求管理、数据驱动决策、团队协作与沟通 |
| 混沌边缘状态 | 快速迭代与反馈、风险管理、知识共享与经验传承 |
| 混乱状态 | 重新定义项目目标和范围、建立有效项目管理体系、团队重建与激励 |

下面是不同控制状态下应对策略的mermaid流程图：

graph LR
    A[软件开发控制状态] --> B[理想状态]
    A --> C[阈值状态]
    A --> D[混沌边缘状态]
    A --> E[混乱状态]
    B -->|持续流程优化| F(应对策略)
    B -->|人员培训与发展| F
    B -->|严格变更管理| F
    C -->|精准需求管理| G(应对策略)
    C -->|数据驱动决策| G
    C -->|团队协作与沟通| G
    D -->|快速迭代与反馈| H(应对策略)
    D -->|风险管理| H
    D -->|知识共享与经验传承| H
    E -->|重新定义项目目标和范围| I(应对策略)
    E -->|建立有效项目管理体系| I
    E -->|团队重建与激励| I