知识卡片
架构师在敏捷团队中的角色张力
内容
敏捷团队常把架构描述当成”大量预先设计”而排斥，专注快速交付看得见的功能；但系统变大变复杂后，性能、安全性、监控这些用户不关心却决定系统能否撑住的交叉关注点会暴露，纯敏捷团队易陷入失控重构。化解方式是让架构也敏捷化：递增式交付、只写”足够好”的文档、把工作聚焦跨团队的交叉关注点，其余细节交给开发者。发散：这是把[[架构定义的完成标准是风险已缓解而非架构完美|风险驱动够用就好]]应用到敏捷场景。
参考来源
- 位置：第7章《架构定义过程》7.7.3节「敏捷方法」（源文件：_epub-src/OEBPS/text00059.html附近）
- 结论依据：原文指出敏捷开发者常把架构描述视为"大量预先设计"而摒弃，但系统变大变复杂后性能/可用性/安全性/监控等交叉关注点会暴露，好的架构师应以递增方式交付架构、只写"足够好"的文档、专注交叉关注点，把细节设计留给开发者，直接支持卡片结论。
- 原始内容："敏捷开发者很少考虑到架构描述，认为它是'大量的预先设计'而摒弃……同样的团队会在系统变大或者变复杂的时候遇到问题，那时他们需要处理像性能、可用性、安全性或者系统监控等因素，最终用户往往对此不感兴趣……以递增的方式交付你的架构。在早期定义最基本的架构结构，然后使用基于需求的方法对其进行改进……把目标设定为创建'足够好'的文档……专注于交叉的关注点……将更细节的设计工作留给开发者。"