关心 : 移山之道

移山之道故事 32 结束语

关心 — Thu, 24 Sep 2009 06:11:00 GMT

大牛

这是我从网上看到的故事，所以肯定有水分——

话说二战时美军在太平洋上某个小岛修了机场，岛上的土著们看到美军士兵头戴钢盔，身背步话机，嘴里不停地叽里咕噜。然后，神奇的大鸟从天而降，鸟肚子里拉出一箱箱货物，土著们也时不时能分享到一些香烟、口香糖等新鲜玩意。战后美军撤了，只留下空空的机场和瞭望塔。土著们后来经常举行庄严的仪式，仪式中一位土著爬到瞭望塔上，把椰子壳绑在脑瓜上，模仿美军的样子，朝空中喊叫，希望神奇的大鸟能和以前一样从天而降。大鸟终究还是没有来，于是另外的土著用椰子树和野花扎了一个色彩斑斓的飞机模型来模拟大鸟的降落。这样的仪式持续了很多年，后来成为当地民俗表演的保留节目之一。其中大鸟降落的场面引起诸多人类学者的兴趣，他们推断当地土著曾经上古时期和外星人有神秘接触。

在阿超归来之前，我们就像土著一样，搞一些形似而神不似的开发模式，希望能撞大运，写软件发财。或者把软件开发神秘化，或者把软件开发庸俗化，现在看来，写软件也简单，也不简单，认真做才能成功。

小飞

小飞：我只能想起这样一段话。

“……于是鲁肃邀请庞统入见孙权。施礼毕，权见其人浓眉掀鼻，黑面短髯，形容古怪，心中不喜。乃问曰：“公平生所学，以何为主？”统曰：“不必拘执，随机应变。”

——罗贯中《三国演义》第五十七回

果冻

果冻：既然大家都引经据典，把我的本行都抢去了。我只好来一句俗的：发布才是硬道理！

荔荔

荔荔：我在这个项目中学到很多很多，千言万语，可以用下面的句子来表达：蓦然回首，那人却在灯火阑珊处。

大栓

大栓：解决用户的问题是纲，其余都是目，纲举目张。

二柱

二柱：移山方法好！这是我们自己思想的结晶，土生土长，要大力推广。

九条

九条：写软件就像打麻将，要想做些大牌，但是不要非大牌不胡，有时要胡些小牌，然后等下一圈，只要宿舍不熄灯，我们总可以有下一圈，就像我们总是可以等下一个里程碑一样；有时摸到一张好牌，但是和手里其他的牌型不配，也只好打掉，这和我们要砍掉功能是相似的；听牌的时候，要有耐心，不能老换张，这也和我们做项目有共通之处。总之软件开发就像一局麻将。

芸芸

芸芸：我在这个项目中一行代码都没有写，但是我对这个项目的了解比我在任何一个以前的项目都深，PM这个工作我原来觉得既风光，又轻松，没想到它把我给累坏了，我现在觉得做一个只写代码的开发人员也挺好的。我也酸一回：

试问卷帘人，却道海棠依旧，知否，知否，应是绿肥红瘦。

移山之道故事 31

关心 — Mon, 21 Sep 2009 06:10:00 GMT

它山之石（Stone）项目结束了，项目的成员都得了三天假。阿超实现诺言，和大牛一起请小李吃饭……饭后推门出去，大牛有事先走，外面已经暗下来了，小李建议到桥边走走，他们走过了王屋桥。

明月别枝惊鹊，清风半夜鸣蝉。

稻花香里说丰年，听取蛙声一片。

七八个星天外，两三点雨山前，

旧时茅店社林边，路转溪桥忽见。

阿超：你还记得中学学过这首词么？当时老师让我们分析中心思想。你们文科班的肯定对此有深入研究吧。

小李：我早就忘了，不过你一说我就想起来了，辛弃疾的词用典太多，我不喜欢，你也是用典不少……

阿超和小李都笑了。

阿超：当年真是为赋新词强说愁，非得编造出个中心思想来。不过，我现在倒是理解了一些。

小李：真的？大学也考过了，都毕业这么多年了，你还在想正确答案？是啥？

阿超：我忽然觉得就是说我现在的心境。

小李：稻花香里说丰年，当然了，你们这个项目成功了，很正常。只是希望你不会把我的话当做“蛙声一片”。

阿超：当然不止这个，我觉得这首词表现了一种境界——旧时茅店社林边，路转溪桥忽见。在寻寻觅觅中，夜里，好像又要下雨，也不知道会不会是大雨，但是路转溪桥，看见了熟悉的茅店，觉得在那里见过，好像离家不远了。这半年来我忙忙碌碌，到这里好像是一个句号。

小李：我从河这边看过去，觉得当初你们搞的那一套挺笨拙的，没想到后来跌跌撞撞也走过来了，回过头来看，好像以前的投资也挺值得。现在我们公司都有一些人要投靠你们了。

阿超：写软件就是跌跌撞撞的过程，希望下次我们能走得稳一些。对了，我一直想问你一个问题，我们以后能经常一起散步么？

移山之道故事 30 衡量员工工作质量——Test

关心 — Fri, 18 Sep 2009 06:07:00 GMT

项目终于结束了，移山公司的员工和实习生工作质量如何？

阿亨说，还记得我当时立下的规矩——

绩效考核最重要的指标：发现的bug的数量

后来我的测试团队发生了一些很有趣的事，也导致了我的衡量标准一再发生变化。听我一一道来。

以bug数量为核心的政策出台后，我发现大家工作都很努力，但是有些人找到一些鸡毛蒜皮的小问题，也一个一个的单独发bug，另外一些人则是报一个bug，然后把一些相关问题都列在上面。还有就是别人已经报告了问题，但是相似的问题还是被不同的人报了上来。

所以我做了修改：

（1）一个问题只报告一次，后面重复报告的bug，不但不计入总数，还要倒扣分。

（2）同属于一个问题的子问题，不要报告多次。

这样就好了不少，但是有人提出来，“我花了两小时，经过仔细调研，发现了一个很严重的bug，但是别人两小时就报告了10个不痛不痒的bug。这样不公平吧！”

我想也对，于是就加了新的一条：

（3）bug的严重性也考虑在内。

过了两天，问题又来了，同学们反映：

a. 严重性的评判很主观。

b. 如果我负责的功能就不是太重要，那么即使有错误，也到不了“严重”这一级，这对我不公平。

c. 一些人把建议也当成bug，或者把还未实现的功能当成bug来报告，有些人整天琢磨一些异想天开的bug，但是规格说明书上写得很清楚，这些都不属于bug。

d. 好的开发人员的bug不多。我要是摊上像白菜这样的开发人员，怎么办？我只有寄希望于和我合作的开发人员的低能，才能衬托出我的优秀，这好像太矛盾了。

怎么办？我还要改进，于是我又加了两条新的规则——

（4）严重性由阿亨最后定夺。

（5）如果bug被认定是“as designed”，那不算在总数内。

同学的最后一个问题d：[我只有寄希望于和我合作的开发人员的低能，才能衬托出我的优秀]，倒是问到了痛处，我还没有想清楚怎么办。没容我仔细想，最后事情发展到有点疯狂的地步。一天早上，一个测试人员跑来告诉我，他发现他负责的领域的bug已经被九条都报告了，后来才知道，原来我们每天晚上发布了构建后，九条就在深夜安装了最新的构建，然后先测试了别人负责的领域，把一些明显的bug都报告了。这样别人第二天再想创建bug，却发现bug都已“名花有主”了。

我后来问了阿超，他说，这听起来是一件好事呀。一方面你有很能干的测试人员，另一方面，也许另一个测试人员是多余的。

但是这样下去，所有测试人员都没有安全感，都要等构建一出来就玩了命地测试，而且还是从别人的领地开始测试。开发人员就可以讲“共同拥有源代码”，但是测试人员“共同拥有”什么呢？

另外，有些开发人员也反映，测试人员在平时讨论的时候交流并不积极，但是代码签入后，他们报告的bug非常多，如果能事先有沟通，就好了。但是测试人员好像就要等着你的bug，然后通过TFS来报告。

这些都让我反思原来的“数量至上”的衡量方法是否正确。经过和愚公多次E-mail交流。我得出了下面的改进方案——

我们还是要计算bug的数量，但是它只是一个次要的参考数据。测试人员要把重点放在如何让产品达到预期的质量标准，如何防止bug的发生，在每次我们发现一个bug的时候，我们都要问自己：

（1）为什么我们以前没有发现这个问题？

（2）产品中还有类似的问题么？

（3）有什么办法可以防止类似问题再度发生？

（4）我们能否自动检测这样的问题？

在bug数量的统计上，我们把重点放在每个发布（代码完成，Alpha，Beta）之后发现的bug才计算在内。在发布之前，Dev/PM/Test都应该为一个目标努力——让我们的功能在发布的版本中表现得最好。

移山之道故事 29 扁鹊的三兄弟

关心 — Tue, 15 Sep 2009 06:04:00 GMT

果冻说：我听说了萝卜和白菜的故事，其实类似的事儿古代早已有之，请看一段关于“扁鹊的三兄弟”的古文：

王独不闻魏文王之问扁鹊耶？曰：‘子昆弟三人其孰最善为医？’扁鹊曰：‘长兄最善，中兄次之，扁鹊最为下。’魏文侯曰：‘可得闻邪？’扁鹊曰：‘长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，镵血脉，投毒药，副肌肤，闲而名出闻于诸侯。’

扁鹊是这么说的：“俺大哥治病是看病人的神色，病还没有表现出来他就把病给治了，所以他的名声不出家门。俺二哥治病是在病人稍有不适的时候，就把他们搞定，所以他的名声不出巷子。而我扁鹊看病用的是疏通血脉的针、有毒副作用的汤汁、埋入肌肤之内的草药。所以我的名声反倒传遍了各个诸侯国。”

二柱说: 这个跟王屋河的防洪是一个道理，上游搞得好，不发洪水没人知道，下游要决堤了，一堆人上去堵，死伤几个，就出名了。我们最善于搞末端治理。

在软件开发上，如果在软件开发的早期发现并解决了问题，除了“家里人”，没人知道；项目中期发现问题并解决，项目的许多相关人员“公司”都知道了；项目后期出了问题，我们要加班，重写代码，hack 原来的设计，开一些后门来解决问题（下一些很有副作用的猛药），总算把项目给救活了，这时候全公司的人都知道了。

阿超：我记得小学六年级学过“曲突徙薪”的故事，也讲了类似的道理。我们往往奖励末端治理的英雄，但是最初提建议的人未必得到奖励，移山公司会不会也是这样?

移山之道故事 28 银弹之战

关心 — Fri, 11 Sep 2009 06:02:00 GMT

阿超和果冻到河曲数码做讲座，下午回到了移山公司，发现公司门口有一些人围着议论纷纷。

小芸：今天在会诊的时候，二柱为了一个bug 和大牛争执了起来，双方都坚持自己的意见。后来二柱说，那好，我用一颗银弹解决这个问题 – 不修改！。大牛也不示弱，说我也有银弹，我用两颗银弹来保证一定要修改！。二柱说那我用三颗。大牛说，我用我的所有银弹。。。然后两人拍案而起，互相瞪着眼睛说 - 光说有什么用，要不要出去练练？结果两人就出来就在楼前的草地上扭打在一起…… 我们费了好大劲才把他们拉开。他们都回家去了。

果冻蹲在草地边仔细看了看，说：的确是有大型哺乳类动物扭打的痕迹。

阿超：那现在是不是只有大拴才有银弹了？那我就放心了。

大拴：哈哈，我现在是超级大国了。

小芸：那你不担心么？我们的项目还能做下去么？

阿超：这只是一个软件项目，为什么做不下去？晚上我在顶球酒吧请客，让他们都消消气。

银弹真的有用么？

移山之道故事 27 反动分子阿超

关心 — Mon, 07 Sep 2009 05:59:00 GMT

在最后的稳定阶段，阿超不断地把事情推到下一个版本，二柱和果冻都不耐烦了 - 为什么不拼一下，把所有事情在第一版搞定？

阿超说：有两种做法 –

1）根据事情的轻重缓急，安排大部分事情在下一个版本作。正因为我们对项目，团队，商业模式有信心，我们才把很多事情安排在以后的版本中。

2）拼一下，把所有事情搞定，后果是大家都累得够呛，出现了burnt-out 的情况，然后人也走了，没有人有兴趣做下一个版本。

二柱：我记得当年我们公社组织修水利的时候，大家都拼了老命，有几个前辈都牺牲了，才把水库修好。。。难道这些不是有价值的么？

果冻：对！我记得山坡上还用巨石刻了一些标语，有两个前辈就是牺牲在炸开巨石刻字的时候。

阿超：是啊，现在看起来，那些刻在山上的标语是属于可“cut” 的功能。至少我们可以把它推迟到下一个版本。到今天，我们大家都意识到刻巨大的 “人定胜天” 标语不是特别重要的 “功能”，对么？这样岂不更好？当年我们的叔叔伯伯们的确没有必要 “誓死完成” 所有的任务。

二柱：要在以前，你就是反动分子。

阿超：我们写商业软件，是要赚钱养家，如果自己都burn out，那拿钱来养啥？如果还要刻字，我建议在山坡上刻 “以人为本” 几个大字。

移山之道故事 26 侵官之害甚于寒

关心 — Thu, 03 Sep 2009 05:57:00 GMT

昔者韩昭候醉而寝，典冠者见君之寒也，故加衣于君之上，觉寝而说，问左右曰：“谁加衣者？”左右对曰：“典冠。”君因兼罪典衣与典冠。其罪典衣，以为失其事也；其罪典冠，以为越其职也。非不恶寒也，以为侵官之害甚于寒。

——《韩非子·二柄第七》

九条：（来找阿超）我最近新建了不少bug，今天发现它们的状态都变成了closed，本来要测试的bug 都变成了关闭状态，我还用测试么?

阿超：是别的测试人员替你测试了么？

九条：没有，从记录上看是果冻修改了这些缺陷，然后把状态变成resolved，过了两天他又把状态变成 closed，但是我还没有运行验证测试呢。

他们把果冻找来了。

果冻：我是看着我的bug 老是没有关闭，心里很着急，然后昨天我就认真地把所有bug 验证了一遍，确信没有问题后，就把它们顺手关闭了。

九条：是不是你的领导在统计你的bug 数目了？呵呵。

阿超：不同的角色在开发过程中有相互合作，相互制约的作用，不能替代。测试人员在做验证测试时，需要做多方面、多平台的测试，这些工作量，也许远远超过了开发人员的能力范围。因此，必须要由测试人员来验证并处理已经修理好的bug。

侵官之害甚于寒——我们不是不鼓励开发人员主动帮助测试，我们是要避免导致职责不清的越界行为。

果冻：韩昭候真过分！我很好心地帮助别的同事，没有功劳也有苦劳，他怎么能说 “甚于寒”？这样我的心都寒了。

阿亨：果冻，你不是有“各司其职”的笔记么，好好看看。

九条：果冻，谢谢你的帮助，你如果急需验证某些问题，可以告诉我，我会安排尽量早日完成。

移山之道故事 25 萝卜白菜，各有所爱

关心 — Mon, 31 Aug 2009 05:54:00 GMT

项目进行了一段时间，TFS上也积累了不少数据。大拴做了“数据挖掘”，整理出来一些统计信息。在头碰头会议上汇报。

大牛：哇塞！看起来UI组的这位哥们是冠军呀，他的bug数量约等于所有其他成员的总和。

二柱：那是有客观原因的，你可能不知道他的工作量是最大的。

阿亨：那也不能因此产生这么多小强，而让整个团队的进度停下来吧。

二柱：别人工作得这么辛苦，我倒是不太忍心再批评他。阿超，其实我觉得我们应该鼓励成员多做贡献，错误总是难免的，但是你知道他上星期完成了两个功能，明显比别人快多了。别的同事和他一比，就慢多了。

阿亨：我不太同意，从TFS的数据来看，他的bug数量远比别人多，而且不少bug都有一段时间了，你说的 “慢” 的人，好像没有多少bug，也是差不多按期完成的。

大牛：问题是你希望团队里是 “萝卜快了不洗泥” 类型，还是 “慢工出细活”类型？

阿超：我有一个故事，假设团队里来了两位年轻人，嗯，就叫“萝卜”和“白菜”:

萝卜做事很快，是“萝卜快了不洗泥”类型；白菜是“慢工出细活”类型。

分配了任务后，萝卜很快就说做好了做好了！白菜还在吭哧吭哧的和PM/Test讨论。

领导很高兴，让萝卜去做更多的事。开发阶段结束了，萝卜比白菜多做了不少功能。稳定阶段开始了。大家发现萝卜负责的功能出了很多问题，白菜的模块倒是比较稳定。然而萝卜在团队中的曝光率很高，很多问题都在等着他解决，从统计数据上看，他也修复了不少小强。白菜结束了自己模块的工作，开始帮助其他人，由于不熟悉其他人的模块，白菜修复的缺陷不多。由于萝卜的设计有缺陷，导致模块非常复杂，萝卜也成了唯一了解他的模块的开发人员。项目最后阶段，几乎都是萝卜工作得最晚，把最后几个缺陷修复了。领导们说：有问题，找萝卜！

项目结束了，开始了绩效考核，领导A认为白菜绩效不错，模块按时完成，没有大多问题，然后还能帮助其他成员；领导B认为萝卜是超级明星：第一个完成模块，修复的缺陷最多，而且掌握了最复杂的模块，离开他不行，工作得也很晚，有突出贡献。至于白菜，领导B没感觉他做了啥，仅仅是按要求完成任务了。

萝卜白菜，各有所爱。那萝卜和白菜谁该得到奖励，谁该得到批评呢？

假如领导B的评价方式占了上风，萝卜得到奖励，白菜离开了团队，你觉得下一个版本会出现什么情况？

阿杰：我估计萝卜会成为“构建大师”，每天忙得不可开交。然而项目进展不一定会像以前那样顺利……

二柱：有人会怀念白菜。

大牛：你的意思是团队的领导者文化决定了团队的风格。但是当前该怎么办呢？

阿超：所以我们要让“萝卜快了不洗泥”的人慢下来，这样能减少他们的危害。

大牛：授予他们“萝卜大师”的称号？

阿超：恐怕不灵了，我们要胡萝卜和大棒并用。

移山之道故事 24

关心 — Thu, 27 Aug 2009 05:49:00 GMT

问：每次里程碑结束后，我们给客户汇报的的时候，客户总是会惊讶地说，某某功能不是我们当初商量的那样啊，而PM却也同样一脸诧异地说，不对啊，当时咱们就是这么说好的啊，有文档为证。客户不干了，威胁不加/不改xx功能就如何如何，这时PM该怎么办?

大牛：我们在合同里要写明到底我们要交付的是什么，这就要看PM的分析和说明能力了。有时要对客户说“不”。同时，我们在需求说明中也要从用户的角度去描述问题和解决方案，这样用户才能了解他们最终会得到什么。

问：项目开发中后期，Dev lead用工具一统计，乖乖，足足xx万行代码，xx千个存储过程，可是每到给客户演示时，却不时出现程序的各个功能相互不配合，不能自圆其说的尴尬场景，Dev lead很郁闷，想想自己可是没少加班啊，代码量也有，可是问题究竟出在什么方面呢？

阿超：一个原因是每个人都沉浸在“我要写出最强大的某某类或某某模块”，不停地优化一些没有人用的功能，但是真正能够为其他模块使用的功能却未能实现。他们忘了他们写的代码是给别人用的，而且是为了解决用户的问题。所以这个时候我们要想想“用场景驱动”的方法，保证典型的用户场景能够实现。如果从“场景”出发，各个模块的互相集成就能得到充分的测试，按照场景演示起来就更有保障了。

问：在项目开始之前, 有很多队员还没有接触过编程语言（例如C#），导致PM在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于C#的初学者来说，就得先花两天来理解Web Service的实

现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？

阿超：对于这些队员，可以考虑在他们自己的任务估计值之上再乘以4。另外，如果你是写一个商业项目，请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得 “写” 程序才是对项目有贡献，有时不写也是很好的贡献。如果他们有热情，就从测试开始学习吧。请参看前面提到的 “大马哈鱼洄游模型”。

移山之道故事 23

关心 — Mon, 24 Aug 2009 05:45:00 GMT

在这一次的头碰头会议上，平时不主动发言的阿亨也说话了。

阿亨：开发的同志们，你们手里有那么多小强，为什么都揣着掖着，不舍得修复，让测试人员有事情做？测试人员反映因为现有的小强没有被修复，有越来越多的小功能点不能进行测试，我们都要没事做了。

大拴：我们的开发任务很重，必须先把新功能全部实现后，再修复旧的小强。

阿亨：这是不对的，我们有些小强在你们手头很久了，看似举手之劳，为什么不尽快修复，让我们测试组能继续完成测试？

二柱：我们都是按优先级来进行，开发新功能的优先级远大于修复小强。

阿亨：但是有些开发人员手里头有二三十个小强，难道数量不是一个考虑因素？

阿超：我同意，随着项目的深入，每个人同时要开发新的功能，修复以前的缺陷。由于没有明确的优先次序，一般人都愿意把时间花在开发新功能上。但是我们的确需要平衡进度和质量。有这样的一种方法：

小强地狱（Bug Hell）

如果开发人员的小强（bug）数量超过一规定值，则此君被送入“小强地狱”，在地狱中，他能做的唯一一件事就是修复小强，直到小强数量低于此阈值。

这一阈值由团队根据实际情况来确定，要注意：开发人员同时“入狱”的人数应在全体成员的5%~30%之间，若比例太高，则要考虑阈值或者小强数量的计算方式是否合理（是否只包括某一严重程度以上的bug）。

在项目过程中，阈值不宜频繁调整，最好事先宣布阈值。

大拴：但是我们已经违反了“最好事先宣布阈值”这一规定。

阿超：如果我们现在要让20% 的同志入狱，我们马上运行一个TFS 查询看看这一个阈值是多少？是15？好，那我们现在宣布给大家三天时间，第三天后，小强数量达到或超过15 的开发人员请入狱，然后每天早上9点头碰头会议时统计并宣布入狱/出狱名单。

大牛：其实先把所有的功能写完也不错，至少我可以告诉客户“功能写完了”，让他们高兴高兴。

大拴：大牛，这不就是咱们以前项目的情况么？你一直问“功能都写完了，为什么还不能用”? 我们一直说“还有一些小问题”，然后小问题总是不能解决，因为要真正解决这些“小问题”的话，我们还得重写一些功能。

阿超：对，很多问题，甚至是大问题，都隐藏在目前的小强后面，如果一味赶所谓的“进度”，到时候有些小强就变成了大怪物，因为我们已经在错误的基础上搭建了很多新的逻辑和功能，这时再来处理一些历久弥新的小强，就有投鼠忌器的麻烦。

阿亨：那怎么办？

阿超：我们要分析小强，看看这是一个小问题，解决了就万事大吉呢？还是冰山的一角，解决后也许会发现更多、更棘手的问题。或者看似不经意的一个小强会让很多人加班重新实现功能——这就成了设计变更需求——DCR。

移山之道故事 22

关心 — Thu, 20 Aug 2009 05:42:00 GMT

阿超：我好像有几天没有收到每日构建（Daily Build）的报告了。

小飞：已经有一阵子 Daily Build 没成功了。

阿超：哦？我们上课的时候不是说过“每日构建”的重要性么？

小飞：我同意在我们有时间的情况下，我们要做每日构建，但是当我们忙的时候，我们的确实没有时间去管构建的问题。

阿超：这么说还是应了那句话——在理论上，理论和实践是一回事，而在实践上，理论和实践是两回事。

阿超指着窗外，河对面的工地。

阿超：他们在建楼房吧。

小飞：对，据说是软件学院的新大楼。

阿超：那，他们的脚手架自从搭好了之后，就没有垮下来过吧。

小飞：那当然不会，俺爹是干这一行的，所有的工人和材料都得运上运下，脚手架要搭得特别结实。

阿超：那你爹他们有没有因为工期紧，就凑合着搭个架子，就往上盖楼？或者脚手架倒了也不管？

小飞：那哪成！要倒下了，就要出人命了，哪还能盖楼？！

阿超：对呀，我们的软件构建，就和脚手架一样，每天都要立着，倒下来就麻烦了。

小飞：不过，我们搞开发的都有点不屑搞构建，没有写程序来劲。

阿超：不会建脚手架的小工，你爹会要么？

小飞：不会。

阿超：不会做构建的程序员，就像不会搭脚手架的小工，运球不熟练的球员。这样的程序员，我们也不要。

小飞：我明白了。

下午，阿超在喝水的时候碰到小飞来报告说Daily Build正在运行中。发现的几个错误都改正了。估计晚上就可以产生一个新的构建了。

阿超：了不起，这么快就做好了。

小飞：超总，我想提一个和我职业发展有关的问题。我们接受的可都是科班的软件工程教育，我们当时的院领导说我们毕业后都是要朝CTO发展的，至少是软件金领，我当然知道这是遥远的将来的事，但是我总觉得我可以做一个软件白领吧，这些构建之类的事情，嘿嘿，是不是要由所谓软件蓝领来做？

阿超：问题提得好……

他望着这位将来的CTO、软件金领，突然想抄起身边的塑料水桶，把水都从他的白领里灌进去。他喝了一大口水，退到窗边，勉强把这个念头压了下去。阿超看着窗外的操场——

阿超：听说你篮球打得不错？

小飞：还行，常和二柱几个玩。

阿超：你提到大学的课程，让我想起大学的篮球课。我们当时考试的科目之一是定点投篮。老师叫每个要考试的同学站在罚球线上，别的同学负责捡球，考生就站着不动，一个一个地瞄准了投，如果进了一个球，老师才开始算分。平时玩球的同学都是十个进七八，连运动细胞不多的同学都是十个球中五个以上，皆大欢喜，好像大鲨鱼奥尼尔罚球也不过50%上下，大家都有NBA球星的感觉。另一个考试科目是两人配合上篮，当然这是在球场空荡荡的时候进行的，大家接/传/投一气呵成，颇有马龙和斯多克顿的风范，觉得篮球“技止此耳”！考试后，我们意犹未尽，和在一边玩球的同学打球赛，尽管我们“定点投篮”和“二人配合”的分数都很高，但是我们都输得很惨……

小飞：为啥？

阿超：因为我们运球、传球都不熟。这都是我们平时不屑练习的东西，即使勉强到了篮下，投篮都是在踉跄之中完成，当然没有考试时候的准星。

小飞：超总，您把我绕远了，您的意思是？

阿超：我觉得大学的软件工程课，本来要教全面的技术，但是考试往往只考定点投篮和无防守情况下的配合。所以有些大学的高材生到了实际工作中，很多“蓝领”的基本功，比如实战中的运球、传球都不灵，他们津津乐道的定点投篮十中八九的功夫也没有发挥的机会了。我还没有见过从天而降的白领或者金领。所谓的大拿们都是从蓝领摸爬滚打出来的。换句话说，我眼里没有白领或蓝领，只有“汗领”——就是大家都得出汗干活。

小飞：你是说构建就像运球、传球……好，我明白了。超总，下班后我们球场见！

移山之道故事 21 闭门造车

关心 — Mon, 17 Aug 2009 05:40:00 GMT

荔荔：我今天真失败！在办公室里坐了10个小时，但是真正能花在开发工作上的可能只有3个小时，然后我的工作进展大概只有两个小时！

阿超：那你的时间都花到哪里去了？

荔荔：就是我们以前说的 “我没看见你在写软件，你到底在忙什么” 上面列出来的破事儿。每一件随机事情看起来都是挺重要的，我就放下手里的开发工作。但是好不容易做完了，刚想进入状态，又一件随机事情来了……

阿超：你要厚着脸皮，说 “不”。

当场景、功能都计划好的时候，要给员工足够多的时间，让他们投入到工作中去，而不要经常打断他们。

要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。由于MSF鼓励沟通，TFS也设置了不少提示（Alert）自动报告全体成员项目个方面的情况，因此团队的E-mail会特别多。在这种情况下不要整天被E-mail牵着鼻子走。在Outlook上设置好邮件规则，按下面的规则把邮件自动分类到不同的邮件夹中：

（1）从直接老板来的，发给你一个人的——马上处理。

（2）从团队成员来的、和项目有关的事情，自动分配到一个叫“Team”的邮件夹中。

（3）从TFS来的状态信息，如团队的check-in email，自动分配到一个叫“Check-In”的邮件夹中。

（4）从其公司他同事来的与工作无关的消息（如笑话，大减价的消息等），自动分配到一个叫“Other”的邮件夹中。

最好每隔两三小时集中阅读和回复一下E-mail。

荔荔：河对岸的河曲数码经常把所有人都拉去做“封闭开发”，这样是否就能避免干扰？

阿超：我们做开发软件，并不是让团队像被关在监狱里一样。要有大家自由交流的时间，团队成员们在无拘束的环境中，会更乐意提问和分享，这会比召开正式会议，强迫每个人分享好得多。在“封闭开发”的情形下，领导也更有可能每天、每小时来询问项目的进度，这种团队内部的干扰源，并不会因为团队搬到一个监狱里而消失。大家还记得MSF的“充分的授权和信任”？

果冻：我这里还有笔记。

小飞：另外，我经常去看测试人员又发现了什么bug，有时就花时间研究和修复它们。

阿超：可以等第二天会诊之后再看看是否值得马上修复。

果冻：这样新建的bug 要等到第二天门诊之后才能给开发人员处理，是不是影响进度？

阿超：不一定。

提示：

（1）开发人员在开发阶段最重要的任务是把规定的功能完成！

（2）在项目初期，可以不用集体会诊，开发/测试人员可以直接处理“缺陷”，不必等待。

（3）在任何时候，测试人员都可以把“缺陷”交给开发人员，但是只有会诊的人员才能改变会诊决定。

移山之道故事 20 persona

关心 — Thu, 13 Aug 2009 05:37:00 GMT

大牛和小飞在讨论一些界面的时候吵了起来。

大牛：这个界面对于一般用户来说太复杂了。一般人根本搞不懂。

小飞：我们这个界面是针对有很多经验的用户，就像卖石头的吴石头，他搞石头生意有那么些年了，他应该对我们用的术语比较熟悉，而且会用电脑，我们并不针对初次使用我们系统的用户，或者对奇石生意有了解，但是对电脑一窍不通的人，就像石头他爹。

大牛：不对，我们要针对那些对奇石生意有了解，但是对电脑一窍不通的人，我们有一些功能是为这些用户设计的。

小飞：不对，我们主要的用户是对石头生意很了解，并且对电脑的使用很熟悉。而且这也符合所谓“Persona”的要求。

大牛：我不管你的“Person-a”，我们要分析用户的需求，在把需求搞清楚之前，管他“Person-a”还是“Person-b”，都没有用。我们还是不要用这些名词忽悠我们自己。

他们俩一起来到阿超面前，把事情原委说了一遍。

阿超：所谓“Persona”，就是典型用户，吴石头/石头他爹就是我们系统的两个典型用户。我们的确要了解系统的用户（不是公司的商业客户），那么，什么是典型用户？

在产品开发的过程中，我们经常需要描述一组典型的用户。以前大家通常是以一些抽象的名词来表示，如“家用电脑初学者”，“经验丰富的系统管理员”，现在我们建议用一个“典型用户”来代表。典型用户不再是一个抽象的概念，而应该是一个活生生的人物。

典型用户有哪些特性?

一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。

大牛：以前我们管台风叫1号、2号，现在都起了名字，叫云娜、海棠、卡特丽娜，等等，是不是跟MSF-Agile学的？

阿超：这你得问气象部门，至少台风“海棠”比单纯的数字好记。但是我们的Persona还包括了更多的特性，不光光只是一个代号，一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。

阿超：在别的行业中可以用到Persona的设计方法。我今天去银行开账户。开完账户后，服务生在窗口后低着头，过一会看我还坐着，就说，没事了，你可以走了。我还想了解一些其他的服务，比如信用卡/理财账户，等等，她好像对此没有兴趣。看起来银行把我的“开户”处理成一个单独的事件，开了账户就完了。如果银行分析开户人的Persona，它可能了解一些典型用户的典型心理，比如小企业主崔大智来开户，他就是来开个户就完了？当然不是！他有不少钱，可能申请信用卡、建立理财计划、贷款、联系代发工资，等等。如果银行仅仅帮他开个户就把他打发走了，那样失去了多少商机？！

在设计软件的过程中，我们（设计/开发者）往往会以我们使用产品的习惯和我们对产品的熟悉程度出发设计，忘了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下，搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。

大牛：阿超刚才提到别的行业，我想起一个例子，两年前俺们村接待了国外的投资参观团，我临时被抓过去作翻译。村长和支书兴冲冲地带领他们参观了王屋村的产值大户——小化工厂和烟花爆竹厂。他们带领客人穿过粉尘弥漫的化工厂车间，弄得老外咳嗽不止。在车间外，大家看到没有处理的污水直接排放到王屋河中；到了烟花爆竹厂，大家看到数十名没有任何安全保护的女工在安装各式烟花，空气中不用说有硫磺和其他化合物的味道。参观团的团员们发出了介于惊讶和恐惧之间的评价，我很难翻译成中文。参观团走后就杳无音信了。

如果分析客户的情况，从客户角度出发，就会发现他们是想来开发这一带的以历史传说为背景的人文旅游资源，他们想看到的是未被污染的风景——王屋河的上游有不少，还有淳朴农家的生活方式，我们也有，当然支书家的生活方式已经不能用“淳朴”来形容。可惜我们没有让客户看到他们想要的东西。

小飞：对呀，去支书家可以看到资产阶级的生活方式，我目前没有搞懂的是小资还是大资。

移山之道故事 19 打印预览功能

关心 — Mon, 10 Aug 2009 05:34:00 GMT

荔荔：我听了这么多方法论，是不是所有的好功能都是一步一步根据用户需求，按照用户场景设计，然后可用性测试等等步骤之后得来的？

阿超：有人说：功能本天成，妙手偶得之——我有一个来自微软的故事。

约摸在1985年，微软的一个叫Steve Hazelrig的工程师正在写Mac Excel版本的打印功能，那时候激光打印机很贵，而且离办公室也不近。他懒得经常跑到打印机那儿取打印纸，检查打印效果，就写了一个小程序，把要输出打印的图像显示在屏幕上，还有一个放大镜功能可以把局部放大以检查每个像素的位置及效果。这时一个PM路过看到了这个小工具，说，这么酷的东西，为啥不做成一个功能呢？所以后来微软的编辑软件都有“打印预览”这一功能。然而，用户们并没有正式地要求这一功能。

九条：真是传奇，现在这样的事已经不可能发生了吧，因为软件所有可能的功能都被人想到了，并且实现了。

阿超：很难说，贝多芬在写第五交响曲“命运”之前，没有人提出这样的“用户需求”，没有人说，“小贝，为了鼓励世人，写一个反映和命运抗争的交响乐吧。现在市面上正缺少这样的产品。” 但是他写出来之后，大家觉得都离不开它。这又说明了啥？

小飞：嗯，同理，对于情呀爱呀这些主题，流行歌曲不知有多少，完全覆盖了每一种可能的“场景”，但是每年都有几首流行歌，好像道出了前人未道之境。

斯坦：普契尼写了《蝴蝶夫人》后说：这部歌剧的音乐是直接由上帝口述给我的；我只不过是功能性地将它写在纸上，然后分享给大众。

果冻：但是软件和艺术是有区别的……

大牛：难道软件不是艺术创造么？

众人：是么？不是么？

移山之道故事 18

关心 — Thu, 06 Aug 2009 05:31:00 GMT

在头碰头会议上：

阿亨：我们一起做项目都是大家一起上，项目管理的书也看了，但是说实话，我觉得和实际差得太远。你说我们每周有8小时用于管理，这8小时里我们都要干什么？

阿超：这就牵涉到项目管理人员在项目中的角色问题，在一个多层次的团队中，以前的管理人员事实上是扮演一个“抄表员”的角色。他们总是不停地问各个员工：“你干完了吗“？然后把个人和小组的进展逐级上报，上级要是问到一些细节，管理人员又得回头来问各个员工，再上报上去。

现在有了TFS，所有的项目进展的数据都一览无遗，管理人员就能从“抄表员”的角色中解放出来，把精力放在如何能更有效地推动项目的进展的方面。例如：

（1）和员工一起，分析场景和QOS的需求，估计成本。

（2）会诊缺陷。

（3）掌控项目的走向，分析项目目前的速度，然后得出结论：如果我们按照目前的速度进行的话，到时间我们只能交付60%的任务。

（4）数据分析，有些任务为什么会比预期多花很多时间？是员工的技术问题，还是管理层有不切实际的期望和压力，或者我们有另外的技术因素没有考虑？

（5）发现项目的风险，要发现什么东西还没有做，它们对项目的影响——例如突然发现还没有考虑项目的国际化。

（6）对于日期驱动的项目，建立和维护一个粗略的进度可行性分析——我们能否在某年/月/日之前交付。当别人都在埋头苦干的时候，管理人员要时不时抬起头来看看。

阿亨：要做到这么多，我们每周8小时看来是不够的！

关心 : 移山之道

移山之道 故事 32 结束语

移山之道 故事 31

移山之道 故事 30 衡量员工工作质量——Test

移山之道 故事 29 扁鹊的三兄弟

移山之道 故事 28 银弹之战

移山之道 故事 27 反动分子阿超

移山之道 故事 26 侵官之害甚于寒

移山之道 故事 25 萝卜白菜，各有所爱

移山之道 故事 24

移山之道 故事 23

移山之道 故事 22

移山之道 故事 21 闭门造车

移山之道 故事 20 persona

移山之道 故事 19 打印预览功能

移山之道 故事 18