透明思考

如果有一天……

如果有一天，所有的软件团队都争着宣称自己是敏捷的。

如果有一天，中国移动、工商银行之类的大甲方要求投标的公司采用敏捷开发方法。

如果有一天，文思、慧通之类的外包商都被逼着做敏捷改造或者买敏捷认证一如当年的CMM。

如果有那么一天，我就退出咨询行业，从此不为人师。

《持续集成》第二版召唤译者

Martin Fowler的文章，现在网上流行的那个第一版是我好多年以前翻译的。内容已经太旧了，并且我的翻译太差了。

我在译言上建了一个翻译文档。有兴趣的同志们赶快把它搞了吧。

《重构》再版，欲购从速

首先，不要恐慌。这不是《重构》第二版。只是由于某种愚蠢的原因，从前的那个中文版已经买不到了。现在，它换了个书皮，让需要的人能买到。仅此而已。

刘江兄写了一个煽情的宣传。“从一个光荣的大学辍学少年（步乔布斯、盖茨后尘？）成长为ThoughtWorks的资深咨询师，Martin Fowler的同事。”嗯，很好的阶段性总结。

（有时候我很怀疑自己做的一切是否真的有意义。如果“大家”真的会学习的话，为什么《重构》出版那么多年以后还有那么多烂代码存在──当然，如果“大家”真的会学习的话，为什么还有战争？）

时间，才是最神奇的重构工具。这句话，也很好，很隽永。

借鉴丰田方法对大型软件组织进行敏捷改造（上）

QWS是一款电信交换机产品，其软件部分用C语言开发。经过长期的发展演化，当本文所述的咨询项目开始时，QWS的总体代码量已经超过2000万行，代码库体积超过4GB。本咨询项目所涉及的版本需要新开发的代码量约90万行。

QWS的版本交付团队大致由90名左右开发人员和30名左右测试人员组成。这支交付团队又按特性和模块划分为6个特性团队和2个任务团队，共计8个子项目组。每个项目组分别有一个SVN工作分支，项目组成员将代码提交到分支，项目经理再负责将分支代码合并到主干。

在ThoughtWorks顾问组进入该团队之时，这支多年沿用CMM方法的团队正在自行尝试敏捷方法，刚刚开始第一个为期3周的迭代。但这第一个迭代远非一帆风顺。一方面，由于团队从来没有迭代交付的习惯，开发人员在编码阶段忽视质量，导致提交到SVN的代码有时甚至不能编译，即使编译出软件大包也存在严重功能缺陷，无法进行测试；另一方面，由于团队成员对SVN缺乏了解，多个分支的配置管理遇到了极大的困难。

就在这样一种混乱的状态中，由3名ThoughtWorks咨询师组成的顾问组进驻了这支交付团队，开始对其进行为期4个月的敏捷改造。在项目进展中，我们大量借鉴了源自丰田的精益思想，最终取得了显著的成效。

（阅读全文）

沙滩阅读记录

Buzz是个好东西。一边玩Buzz，一边抓紧时间看了几本书。

Organizational Patterns操作性缺缺，看完仍然不知道该怎么实施──甚至不知道能不能实施

说话的魅力废话超过文化

演说之禅“胶片”这个词真的很不好，因为它杂糅了幻灯片和讲义

让你的声音更有魅力系统性和可操作性都太差了，国人写书的通病

还在读Fearless Change。原来Linda Rising就是模式年鉴的作者，难怪我听着那么耳熟呢。

Evangelist = Test the Waters = Time for Reflection = Small Successes = Step by Step

Ask for Help, Connector, Guru on Your Side, Innovator, and Just Say Thanks

You’ve had a meeting using the pattern Piggyback or Brown Bag. Perhaps you were able to Do Foodand youscheduled the meeting at The Right Time. You brought some interesting books or articles, hoping toPlant theSeeds and point to External Validation for your new idea. You talked about the Next Steps for yourfledglingeffort and maybe you used e-Forum to help Stay in Touch with people who are getting interested inyour work. Ifyou were really lucky, your collection of like-minded folks has started to form a Group Identity.

昨天收到Strength Finder 2.0。

You might be especially adept at legal work, crafting sound business deals, or ensuring compliance toregulations.

郭晓说：I am surprised by Harmony!

伤了。

Leadership Over Management

灰色区域是普通员工，蓝色区域是被尊敬的员工，绿色区域是优秀的管理者，红色区域是危险的。

所以，得不到管理职位没什么好着急的，领导力更要紧。

Organizational Pattern- Producers In The Middle

(FromOrganizational Patterns of Agile SoftwareDevelopment)

In a project, not all roles hear everything. But much of the information communicated hasimportantimplications for the product.

Within any software project, there are many activities, roles, and individuals competing forattention. Ofcourse, there are the developers. But project managers have a need to be at the center ofeverything. They needto have their finger on the pulse of the project; to know everything that is going on. That’s theirjob. In asimilar manner, perhaps to a lesser degree, other roles also need to be involved in the project.

But all roles are not equal. Certain roles (developer and a few others) contribute directly to theproduct; theycreate it. Most other roles contribute indirectly to the product; they (should) exist only to helpthe producersdo their job. The producer roles need information in order to do their job.

Therefore,

The producer role(s) must be at the center or very near the center of the hive ofcommunication. Makesure the producers are party to all, or nearly all communication about the project.

Organizational Pattern- Don't Interrupt An Interrupt

(FromOrganizational Patterns of Agile SoftwareDevelopment)

It’s important to balance a desire thatSOMEONE ALWAYS MAKES PROGRESS(4.1.20) with the thrashing that can accompany short-term priority calls.One worker will inevitably be blocked on you—you can’t do both things at once. Complete, omniscientforesightand scheduling are unreasonable to expect.

Therefore:

If a developer is already working in “interrupt mode” on a critical issue, don’t put thatwork asideuntil it is complete or until that issue itself becomes hopelessly tangled.

Organizational Pattern- Day Care

(FromOrganizational Patterns of Agile SoftwareDevelopment)

Your experts are spending all their time mentoring novices.

You begin to hear things like “We are wasting our experts,” or “A few experts could do the wholeproject faster.”Indeed, the experts are not proceeding at the rate you or they would expect, because training thenew people isdraining their energy, time and concentration. But the new people must be trained, by experts, ofcourse.

At the same time, you must make progress on the project itself.

Therefore:

Put one expert in charge of all the novices, let the others develop the system.

Separate an experts-only “progress” team from a training team under the tutelage of one or morementors. Selectthe mentors for their ability to teach design and programming (object-oriented design andprogramming, forexample) to novices. Let the progress team design 85-95% of the system, let the training team focuson qualitytraining, delivering only 5-15% part of the system. Transfer people to the progress team as theybecome able tocontribute meaningfully.

Make sure that the training team does not simply do training exercises, but actually contributes tothe finalsystem in an ever-increasing way.

If you have many people to train (more than, say, six), you will have to design a series of tasks forthem toattempt. Otherwise you may give them a small, real part of the main system to design.

If the people in the training team are the ones who know the domain, you will have to make somefurtheradjustment, or else the division may cause conflict.

(zz)Agile Metrics