真敏捷可与企业级融合伪敏捷特事特办对架构有破坏性需事后补影响分析和重构方案

很多CIO口中的”敏捷开发”未必是”敏捷宣言”定义的敏捷，更多是 应对特殊需求时的”特事特办”式快速开发——作者把这两种敏捷 严格区分开来对待。”真”敏捷是软件过程层面的差异（大周期改成 小周期冲刺、类似多线程并发的组织模式、一次性到位人力资源）， 它不意味着要违反企业级架构，反而可以和企业级很好地融合—— 关键机制是业务架构师必须直接参与敏捷项目本身，在项目一开始 就用模型工具快速澄清项目范围、列出需要调整的架构事项，并根据 项目具体情况实时调整模型，而不是待在项目之外、按部就班等着走 流程——这本身也是对企业”通用语言”构建效果的一次检验。”非 正宗”的敏捷则是”临时事项”，因事而立、事过则废，本质是不管 不顾、上线是唯一目标，为达目标不择手段，事后往往无人负责， 直接扔给运维团队维护，甚至做完就再无人问津——这种敏捷确实 会对企业整体架构管理带来破坏性。面对真正形势逼人、必须”举全局 之力搏一隅”的紧急项目，作者给出的应对之道不是一味阻拦，而是 业务架构师必须切实参与，当场给出架构设计建议，并且尽快补上 影响分析和事后的重构方案：如果成本允许，就在”搏命”之后把 架构拉回正轨；如果成本不允许，就要把这块特殊处理过的架构 “飞地”标识清楚，让它未来能成为可以复用的”轮子”，而不是变成 后人会掉进去的”陷阱”。对于不具备紧急价值、纯粹图省事的”特事 特办”，架构师应当明确申明立场、给出详尽分析意见并保留记录， 这是职业操守的体现，但企业是否真的能容忍架构师坚持这份意见， 则是企业文化的真实体现。

结构图：

flowchart TB
    S[项目要求快速上线] --> Q{属于哪种敏捷}
    Q -->|真敏捷 软件过程差异| T1[架构师直接参与项目]
    T1 --> T2[当场用模型工具澄清范围并实时调整]
    T2 --> T3[与企业级架构融合]
    Q -->|伪敏捷 特事特办| F{是否真有紧急价值}
    F -->|是 举全局之力搏一隅| F1[架构师参与+给出影响分析]
    F1 --> F2{成本是否允许事后回归正轨}
    F2 -->|允许| F3[补重构方案 拉回架构正途]
    F2 -->|不允许| F4[标识为架构飞地 变成可复用的轮子]
    F -->|否 纯粹图省事| F5[架构师申明立场+保留分析意见记录]