Question

如果你正在一个敏捷软件开发团队中工作，那就看看周围。不管是真实还是虚拟的，可能都有一个故事墙或看板，可视化了将要开始的、进行中的和已完成的工作。

为什么？简单来说，可视化软件开发流程是一个引入透明的奇妙方式，因为任何人都能从一个较高层次一眼看清当前的进度。将它与价值流程图1之类的技术结合起来，就可以开始设计一些复杂看板来体现团队的工作方式。我们这个行业已经变得非常善于可视化软件开发流程。

1http://en.wikipedia.org/wiki/Value_stream_mapping

然而，我们似乎已经忘了如何对正在构架的软件进行可视化。我指的不仅是项目完成后的文档，还包括软件开发过程中的沟通。

理解软件架构并不等于能够表达它。你办公室墙上的那些架构图，是反映了正在构建的系统，还是跟代码结构没有任何相似之处的概念抽象而已。多年来，我举办的架构培训班已有上千人参与，我可以非常自信地说，可视化一个软件系统的架构是一种只有极少人具备的技能。很多人都可以画图，但那些图往往有太多的想象空间，也几乎没有人使用正规的图表符号来描述他们的解决方案，这跟我十年前和软件团队工作的经验形成鲜明对比。

抛弃UML

回想一下，结构化流程给软件设计流程和表达最终设计都提供了参考点。广为人知的例子包括Rational统一过程（RUP）和结构化系统分析与设计方法（SSADM）。软件开发行业在很多方面已经发生改变，但我们似乎忘了这些老方法留给我们的一些好东西。

作为一个行业，我们有统一建模语言（UML），一种用来表达软件系统设计的正规的标准化符号。然而，就UML对软件设计沟通是否有效的辩驳，通常是无关紧要的，因为很多团队已经不再使用UML，甚至根本不知道它是什么。这样的团队通常会画些不正规的框线草图，但是这些图往往没有太大意义，除非再劳神费力加上详尽的叙述。下回再有人围绕那些不正规的草图给你展示软件设计时，你就问问你自己，他们展示的东西到底是在草图上的，还是在他们的脑子里的。

框线草图可以工作得很好，但也会为软件架构的沟通带来很多隐患

抛弃UML没什么问题，但在敏捷比赛中，很多软件开发团队都失去了视觉化的沟通能力。上图是软件架构草图的例子，说明了一些软件架构沟通的典型方法，都存在如下问题：

颜色标注通常意义不明或不统一；

图表元素（比如，不同样式的框和线）的作用不明；

图表元素之间的重要关系有时是缺失或含混的；

频繁使用如“业务逻辑”之类的术语；

技术选择（或可选项）通常被忽略了；

抽象层次混乱；

图表常常包含过多的细节；

图表常常缺少语境或逻辑起点。

框线草图可以工作得很好，但也会为软件架构的沟通带来很多隐患。我的方法是用一套简单图表，各自只展示整个故事的一部分，不使用UML时要密切关注图表元素。

敏捷需要良好的沟通

为什么这很重要？身处敏捷交付和精益创业的今天，很多软件团队都失去了对正在构建的东西的沟通能力。这些团队常常缺少技术领导力、方向和一致性，也就不足为奇了。要确保每个人都在为相同的目标付出，就要有效地表达你正在构建的东西是什么样的。想要敏捷，就要高效地表达。