当Agile已经变成一个贬义词的时候，我们是要把Lean变成下一个贬义词吗？还是脚踏实地去做一些改进？

在这里，向大家推荐 James Coplien 的 Organizational Patterns。它不是一套新的过程，一上来弄十几个实践，也不知道为什么就开始结对开始 TDD 了。它也不是什么大师思想，只有大师才能领会。它更像一个中药柜，里面列了许多药方，更重要的是还告诉你了什么时候用什么药，相关的药有哪些，吃了药有副作用的话用什么药去化解。

在Oredev 2008上有一个相关的演讲视频（原视频地址被墙，这是我放在Youku里的）： 
http://v.youku.com/v_show/id_XMTUxNzgyOTI0.html

这本书在电驴上有。国外的朋友可以去买纸版的：

http://www.amazon.com/Organizational-Patterns-Agile-Software-Development/dp/0131467409 
在他的主页上有Top 10 Patterns：

http://users.rcn.com/jcoplien/Patterns/Top10OrgPatterns.html

本来有一个wiki的，不过现在已经挂掉了。利用web.archive.org还可以找回来。 
http://orgpatterns.wikispaces.com/

模式有很多。在我看来最重要的就两个： 
第一个是要有Unity of Purpose，大家必须要朝一个方向努力。另外一个是Distribute Work Evenly，工作必须在所有组员之间平均分担。不过最重要的也是最无用的，因为只要达到了这两个状态，基本上也没有项目管理问题了。所以我把其他的模式都看成达到Unity of Purpose & Distribute Work Evently的手段。 
关于Distribute Work Evently这个模式特别有意思。Coplien用CRC卡记录了组员的角色，职责以及互相沟通的频率。然后标以红黄绿的颜色表示连接强度。这个非常有意思。让我想其了包之间的依赖。让我想起了玩Bridge游戏时钢铁受力图。也许协作问题根本要解决的就是如何平均分摊受力吧？

Cope总结得非常好，他说软件开发组织有多高效，主要就是取决于沟通的强度。上面那张图就很形象地标榜出了什么是高强度，健康的沟通。健康的人际关系网络，就是没有瓶颈的网络。信息能够及时地传达到需要的人的手上。在上面的图我看到的是平衡负载的人际关系，没有人是Overloaded的。

在这张图里，我们就明显的可以发现有人是Overloaded的。在你的团队里有这样人吗？很多项目里的项目经理，不但要管项目，管需求还要管技术，显然是会Overloaded。有的项目专门有人负责“沟通”，就是他去和客户沟通，然后回来和程序员沟通，然后和QA沟通。很快，沟通就变成他的全职工作，那么他的附加值是什么呢？只要团队内有这样的Overloaded的角色，他们就会变成薄弱点。一旦团队的规模变大，外部的压力变大，就会整体垮掉。所以，平均负载是关键。

有一个非常形象的类比。就是Bridge游戏。这个游戏让你设计钢铁互相搭配的形状，设计一座桥梁，然后让汽车从上面通过。如果受压大的钢条就会变红，超过负载就会断掉。

但是这个是模式吗？James Coplien认为这个是，这个模式叫Distribute Work Evenly。但是我觉得这个不是常规意义上的模式。至少我理解的模式是为了解决特定问题在特定上下文中的特定解决方案。而Distribute Work Evenly只能说是一个愿望，并没有具体可实际操作的解决方案。我有一个想法是“如果不能轻易地想出一个不适用的场合，那么这个模式就不是一个模式”。按照这个想法，我把组织模式的四个Pattern Language几十个模式做了一些整理。下一篇，我们就来看看，组织模式都包含哪些内容。