当前位置：编程学习 > XML/UML >>
答案： 团队沟通
团队进行架构设计的时候沟通是一个非常需要注意的问题，上述的情境在软件组织中是经常发生的，因为技术人员很自然认为自己的技术比别人的好，如果自己的技术受到质疑，那怕对方是抱着讨论的态度，也无异于自身的权威受到了挑战，面子是无论如何都需要捍卫的。而沟通如果带上了这样一层主观色彩，那么沟通信息的受众就会潜意识的拒绝接受信息。相反，他会找出对方话语中的漏洞，准备进行反击。因此，我们要注意培养一种良好的沟通氛围。
在实际的观察中，我发现团队沟通中存在两种角色，一种是建议者，他们经常能够提出建议。一种是质疑者，他们对建议提出否定性的看法。这两种角色是可能互换的，现在的建议者可能就是刚才的质疑者。质疑者的发言是很能打击建议者的积极性的，而在一个脑力激荡的会议中，最好是大家都能够扮演建议者的角色，这就要求沟通会议的主持者能够掌握好这一点，对建议给予肯定的评价，并鼓励大家提出新的建议。
例2：敏捷方法非常注重的就是团队的沟通。沟通是一个很有意思的话题，讲起来会花费大量的时间，我们这里只是针对架构设计中可能存在的沟通问题做一个简单的讨论。我们这里假设一个讨论情境，这个情境来源于真实的生活：项目主管徐辉、设计师李浩、设计师罗亦明正在讨论一个新的软件架构。 "李浩你认为这个软件数据库连接部分应该如何考虑？"徐辉问。李浩想了想，"我觉得方案A不错…" "方案A肯定有问题！这个软件和上一次的又不同。"罗亦明打断了李浩的发言。 "你懂什么！你到公司才多久，方案A是经过很长时间的证明的！"发言被打断，李浩有点恼火，罗亦明进入公司没有多久，但在一些事情上老是和他唱反调。 "我进公司多久和方案A的错误有什么关系！" 在这样一种氛围中，会议的结果可想而知。
良好的沟通有助于架构设计工作的开展。一个成员的能力平平的团队，可以藉由良好的沟通，设计出优秀的架构，而一个拥有一个优秀成员的团队，如果缺乏沟通，最后可能连设计都出不来。这种例子现实中可以找到很多。
标准和风格
我们总是在不知不觉之中使用各种各样的标准和风格。在团队设计中，我们为了提高决策的效率，可以考虑使用统一的标准和风格。统一的标准和风格并不是一朝一夕形成的。因为每个人都有自己不同的习惯和经历，强制性的要求开发人员使用统一的标准（风格）容易引起开发人员的不满。因此在操作上需要注意技巧。对架构设计而言，比较重要的标准（风格）包括界面设计、流程设计、建模规范、编码规范、持久层设计、测试数据。
在我的经验中，有一些组织平时并不注意标准（风格）的积累，认为这种积累属于雕虫小技，但正是这些小技，能够非常有效的提高沟通的效率和降低开发人员的学习曲线。试想一下，如果一个团队中所有人写出的代码都是不同标准和风格的，那么理解起来肯定会困难许多。当然，我们没有必要自己开发一套标准（风格）出来，现实中有很多可以直接借用的资料。最好的标准是UML语言，我们可以从UML的官方网站下载到最新的规范，常用的编码标准更是随处可见。不过虽然有了统一的标准，如果风格不统一，同样会造成沟通的障碍。例如下图显示的类图，虽然它们表示的是同一个类，但是由于版型、可视性、详细程度的差别，看起来又很大的差别。而在其它的标准中，这种差别也是普遍存在的。因此，我们在使用了统一的标准之后，还应该使用同样的风格。Scott W. Ambler专门成立了一个网站讨论UML的建模风格的相关问题，有兴趣的读者可以做额外的阅读。
图 4. 两种风格的类图
在统一的风格的基础上更进一步的是使用术语。使用沟通双方都了解专门的术语，可以代表大量的信息。最好的术语的范例就是设计模式的模式名。如果沟通的双方都了解设计模式，那么一方只需要说这部分的设计可以使用工厂模式，另一方就能够理解，而不用再详细的解释设计的思路。这种的沟通方式是最高效的，但它所需要的学习曲线也会比较陡。
团队设计的四明确
为了最大程度的提高团队设计的高效性，可以从4个方面来考虑：
1、明确目标
泛泛的召开架构讨论会议是没有什么意义的，一个没有鲜明主题的会议也不会有什么结果。在源自需求的模式中，我们谈到说可以有非功能需求的架构，可以有功能需求的架构。因此，在进行团队设计之前，我们首先也需要确定，此次要解决什么问题，是讨论业务逻辑的架构，还是技术架构；是全局性的架构，还是各模块的架构。
2、明确分工
我们之所以重视团队，很重要的额一个原因就是不同的成员有不同的擅长的区域。有些成员可能擅长于业务逻辑的建模，有的擅长于原型设计，有的擅长于数据库设计，有的则擅长于Web编程。你能够想象一个软件没有界面吗？（有些软件可能是这种情况）你能够想象一个软件只有数据库，而没有处理逻辑吗？因此，架构设计就需要综合的考虑各个方面，充分利用成员的优势。这就要求团队的各个成员都能够明确自己的分工。
3、明确责权
除了明确自己的分工，每位成员都需要清楚自己的责任。没有责任，分工就不会有任何的效力。每位成员都需要明确自己要做些什么。当然，和责任相对的，没有成员还需要知道自己的权力是什么。这些清楚了，进行高效的沟通的前提就具备了。每次架构的讨论下来，每个人都清楚，自己要做些什么，自己需要要求其他人做些什么，自己该对谁负责。如果这些问题回答不了，那这次的讨论就白费了。
4、明确沟通方式
这里使用沟通方式可能有一点点不恰当，为了明确的表达意思，大家可以考虑信息流这个词。一个完整架构包括几个方面，分别都由那些人负责，如何产生，产生的整个过程应该是什么样的？这样的一个信息流程，囊括了上面提到的三个明确。如果团队的每一个人都能够为架构的产生而努力，并顺利的设计出架构，那么这样的流程是完美的。如果你发现其中的一些人不知道做些什么，那么，这就是流程出问题的现象了。完美的流程还会有一个额外的副产品，架构产生之后，团队对于软件的设计已经是非常的清晰了。因为我们提倡的是尽可能多的开发人员参与架构的设计。
不仅仅是架构
讨论到这里，其实有很多的内容已经脱离了架构设计了。也就是说，很多的原则和技巧都是可以用于软件开发的其它活动的。至于哪一些活动能够利用这些方法呢？大家可以结合自己的实际情况，来思考这个问题。提示一点，关键的入手处在于目前效率较低之处。
『引自 IBM DW中国』
