移山之道

使用标签浏览

• beta
• 编辑
• 出版
• 读后感
• 封面设计
• 目录
• 内容
• 征稿

• 移山之道 故事 32 结束语

  大牛 这是我从网上看到的故事，所以肯定有水分—— 话说二战时美军在太平洋上某个小岛修了机场，岛上的土著们看到美军士兵头戴钢盔，身背步话机，嘴里不停地叽里咕噜。然后，神奇的大鸟从天而降，鸟肚子里拉出一箱箱货物，土著们也时不时能分享到一些香烟、口香糖等新鲜玩意。战后美军撤了，只留下空空的机场和瞭望塔。土著们后来经常举行庄严的仪式，仪式中一位土著爬到瞭望塔上，把椰子壳绑在脑瓜上，模仿美军的样子，朝空中喊叫，希望神奇的大鸟能和以前一样从天而降。大鸟终究还是没有来，于是另外的土著用椰子树和野花扎了一个色彩斑斓的飞机模型来模拟大鸟的降落。 阅读全文 发表于 2009年9月24日 14:11 作者 关心 | 2 评论 归档在：移山之道

• 移山之道 故事 31

  它山之石（Stone）项目结束了，项目的成员都得了三天假。阿超实现诺言，和大牛一起请小李吃饭……饭后推门出去，大牛有事先走，外面已经暗下来了，小李建议到桥边走走，他们走过了王屋桥。 明月别枝惊鹊，清风半夜鸣蝉。 稻花香里说丰年，听取蛙声一片。 七八个星天外，两三点雨山前， 旧时茅店社林边，路转溪桥忽见。 阿超：你还记得中学学过这首词么？当时老师让我们分析中心思想。你们文科班的肯定对此有深入研究吧。 小李：我早就忘了，不过你一说我就想起来了，辛弃疾的词用典太多，我不喜欢，你也是用典不少…… 阿超和小李都笑了。 阅读全文 发表于 2009年9月21日 14:10 作者 关心 | 0 评论 归档在：移山之道

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

  项目终于结束了，移山公司的员工和实习生工作质量如何？ 阿亨说，还记得我当时立下的规矩—— 绩效考核最重要的指标：发现的bug的数量 后来我的测试团队发生了一些很有趣的事，也导致了我的衡量标准一再发生变化。听我一一道来。 以bug数量为核心的政策出台后，我发现大家工作都很努力，但是有些人找到一些鸡毛蒜皮的小问题，也一个一个的单独发bug，另外一些人则是报一个bug，然后把一些相关问题都列在上面。还有就是别人已经报告了问题，但是相似的问题还是被不同的人报了上来。 所以我做了修改： （1）一个问题只报告一次，后面重复报告的bug，不但不计入总数，还要倒扣分。 阅读全文 发表于 2009年9月18日 14:07 作者 关心 | 3 评论 归档在：移山之道

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

  果冻说：我听说了萝卜和白菜的故事，其实类似的事儿古代早已有之，请看一段关于“扁鹊的三兄弟”的古文： 王独不闻魏文王之问扁鹊耶？曰：‘子昆弟三人其孰最善为医？’扁鹊曰：‘长兄最善，中兄次之，扁鹊最为下。’魏文侯曰：‘可得闻邪？’扁鹊曰：‘长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，镵血脉，投毒药，副肌肤，闲而名出闻于诸侯。’ 扁鹊是这么说的：“俺大哥治病是看病人的神色，病还没有表现出来他就把病给治了，所以他的名声不出家门。俺二哥治病是在病人稍有不适的时候，就把他们搞定，所以他的名声不出巷子。而我扁鹊看病用的是疏通血脉的针、有毒副作用的汤汁、埋入肌肤之内的草药。所以我的名声反倒传遍了各个诸侯国。” 阅读全文 发表于 2009年9月15日 14:04 作者 关心 | 0 评论 归档在：移山之道

• 移山之道 故事 28 银弹之战

  阿超和果冻到河曲数码做讲座，下午回到了移山公司，发现公司门口有一些人围着议论纷纷。 小芸：今天在会诊的时候，二柱为了一个bug 和大牛争执了起来，双方都坚持自己的意见。后来二柱说，那好，我用一颗银弹解决这个问题 – 不修改！。大牛也不示弱，说我也有银弹，我用两颗银弹来保证一定要修改！。二柱说那我用三颗。大牛说，我用我的所有银弹。。。 然后两人拍案而起，互相瞪着眼睛说 - 光说有什么用，要不要出去练练？ 结果两人就出来就在楼前的草地上扭打在一起…… 我们费了好大劲才把他们拉开。他们都回家去了。 果冻蹲在草地边仔细看了看，说：的确是有大型哺乳类动物扭打的痕迹。 阅读全文 发表于 2009年9月11日 14:02 作者 关心 | 2 评论 归档在：移山之道

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

  在最后的稳定阶段，阿超不断地把事情推到下一个版本，二柱和果冻都不耐烦了 - 为什么不拼一下，把所有事情在第一版搞定？ 阿超说：有两种做法 – 1） 根据事情的轻重缓急，安排大部分事情在下一个版本作。正因为我们对项目，团队，商业模式有信心，我们才把很多事情安排在以后的版本中。 2） 拼一下，把所有事情搞定，后果是大家都累得够呛，出现了burnt-out 的情况，然后人也走了，没有人有兴趣做下一个版本。 二柱：我记得当年我们公社组织修水利的时候，大家都拼了老命，有几个前辈都牺牲了，才把水库修好。。。难道这些不是有价值的么？ 阅读全文 发表于 2009年9月7日 13:59 作者 关心 | 0 评论 归档在：移山之道

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

  昔者韩昭候醉而寝，典冠者见君之寒也，故加衣于君之上，觉寝而说，问左右曰：“谁加衣者？”左右对曰：“典冠。”君因兼罪典衣与典冠。其罪典衣，以为失其事也；其罪典冠，以为越其职也。非不恶寒也，以为侵官之害甚于寒。 ——《韩非子·二柄第七》 九条：（来找阿超）我最近新建了不少bug，今天发现它们的状态都变成了closed，本来要测试的bug 都变成了关闭状态，我还用测试么? 阿超：是别的测试人员替你测试了么？ 九条：没有，从记录上看是果冻修改了这些缺陷，然后把状态变成resolved，过了两天他又把状态变成 阅读全文 发表于 2009年9月3日 13:57 作者 关心 | 0 评论 归档在：移山之道

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

  项目进行了一段时间，TFS上也积累了不少数据。大拴做了“数据挖掘”，整理出来一些统计信息。在头碰头会议上汇报。 大牛：哇塞！看起来UI组的这位哥们是冠军呀，他的bug数量约等于所有其他成员的总和。 二柱：那是有客观原因的，你可能不知道他的工作量是最大的。 阿亨：那也不能因此产生这么多小强，而让整个团队的进度停下来吧。 二柱：别人工作得这么辛苦，我倒是不太忍心再批评他。阿超，其实我觉得我们应该鼓励成员多做贡献，错误总是难免的，但是你知道他上星期完成了两个功能，明显比别人快多了。别的同事和他一比，就慢多了。 阅读全文 发表于 2009年8月31日 13:54 作者 关心 | 0 评论 归档在：移山之道

• 移山之道 故事 24

  问： 每次里程碑结束后，我们给客户汇报的的时候，客户总是会惊讶地说，某某功能不是我们当初商量的那样啊，而PM却也同样一脸诧异地说，不对啊，当时咱们就是这么说好的啊，有文档为证。客户不干了，威胁不加/不改xx功能就如何如何，这时PM该怎么办? 大牛：我们在合同里要写明到底我们要交付的是什么，这就要看PM的分析和说明能力了。有时要对客户说“不”。同时，我们在需求说明中也要从用户的角度去描述问题和解决方案，这样用户才能了解他们最终会得到什么。 问：项目开发中后期，Dev lead用工具一统计，乖乖，足足xx万行代码，xx千个存储过程，可是每到给客户演示时，却不时出现程序的各个功能相互不配合，不能自圆其说的尴尬场景，Dev 阅读全文 发表于 2009年8月27日 13:49 作者 关心 | 0 评论 归档在：移山之道

• 移山之道 故事 23

  在这一次的头碰头会议上，平时不主动发言的阿亨也说话了。 阿亨：开发的同志们，你们手里有那么多小强，为什么都揣着掖着，不舍得修复，让测试人员有事情做？测试人员反映因为现有的小强没有被修复，有越来越多的小功能点不能进行测试，我们都要没事做了。 大拴：我们的开发任务很重，必须先把新功能全部实现后，再修复旧的小强。 阿亨：这是不对的，我们有些小强在你们手头很久了，看似举手之劳，为什么不尽快修复，让我们测试组能继续完成测试？ 二柱：我们都是按优先级来进行，开发新功能的优先级远大于修复小强。 阿亨：但是有些开发人员手里头有二三十个小强，难道数量不是一个考虑因素？ 阅读全文 发表于 2009年8月24日 13:45 作者 关心 | 0 评论 归档在：移山之道

• 移山之道 故事 22

  阿超：我好像有几天没有收到每日构建（Daily Build）的报告了。 小飞：已经有一阵子 Daily Build 没成功了。 阿超：哦？我们上课的时候不是说过“每日构建”的重要性么？ 小飞：我同意在我们有时间的情况下，我们要做每日构建，但是当我们忙的时候，我们的确实没有时间去管构建的问题。 阿超：这么说还是应了那句话——在理论上，理论和实践是一回事，而在实践上，理论和实践是两回事。 阿超指着窗外，河对面的工地。 阿超：他们在建楼房吧。 小飞：对，据说是软件学院的新大楼。 阿超：那，他们的脚手架自从搭好了之后，就没有垮下来过吧。 阅读全文 发表于 2009年8月20日 13:42 作者 关心 | 0 评论 归档在：移山之道

• 移山之道 故事 21 闭门造车

  荔荔：我今天真失败！在办公室里坐了10个小时，但是真正能花在开发工作上的可能只有3个小时，然后我的工作进展大概只有两个小时！ 阿超：那你的时间都花到哪里去了？ 荔荔：就是我们以前说的 “我没看见你在写软件，你到底在忙什么” 上面列出来的破事儿。每一件随机事情看起来都是挺重要的，我就放下手里的开发工作。但是好不容易做完了，刚想进入状态，又一件随机事情来了…… 阿超：你要厚着脸皮，说 “不”。 当场景、功能都计划好的时候，要给员工足够多的时间，让他们投入到工作中去，而不要经常打断他们。 要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。由于MSF鼓励沟通，TFS也设置了不少提示（Alert）自动报告全体成员项目个方面的情况，因此团队的E-mail会特别多。在这种情况下不要整天被E-mail牵着鼻子走。在Outlook上设置好邮件规则，按下面的规则把邮件自动分类到不同的邮件夹中： 阅读全文 发表于 2009年8月17日 13:40 作者 关心 | 0 评论 归档在：移山之道

• 移山之道 故事 20 persona

  大牛和小飞在讨论一些界面的时候吵了起来。 大牛：这个界面对于一般用户来说太复杂了。一般人根本搞不懂。 小飞：我们这个界面是针对有很多经验的用户，就像卖石头的吴石头，他搞石头生意有那么些年了，他应该对我们用的术语比较熟悉，而且会用电脑，我们并不针对初次使用我们系统的用户，或者对奇石生意有了解，但是对电脑一窍不通的人，就像石头他爹。 大牛：不对，我们要针对那些对奇石生意有了解，但是对电脑一窍不通的人，我们有一些功能是为这些用户设计的。 小飞：不对，我们主要的用户是对石头生意很了解，并且对电脑的使用很熟悉。而且这也符合所谓“Persona”的要求。 阅读全文 发表于 2009年8月13日 13:37 作者 关心 | 0 评论 归档在：移山之道

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

  荔荔：我听了这么多方法论，是不是所有的好功能都是一步一步根据用户需求，按照用户场景设计，然后可用性测试等等步骤之后得来的？ 阿超：有人说：功能本天成，妙手偶得之——我有一个来自微软的故事。 约摸在1985年，微软的一个叫Steve Hazelrig的工程师正在写Mac Excel版本的打印功能，那时候激光打印机很贵，而且离办公室也不近。他懒得经常跑到打印机那儿取打印纸，检查打印效果，就写了一个小程序，把要输出打印的图像显示在屏幕上，还有一个放大镜功能可以把局部放大以检查每个像素的位置及效果。这时一个PM路过看到了这个小工具，说，这么酷的东西，为啥不做成一个功能呢？所以后来微软的编辑软件都有“打印预览”这一功能。然而，用户们并没有正式地要求这一功能。 阅读全文 发表于 2009年8月10日 13:34 作者 关心 | 2 评论 归档在：移山之道

• 移山之道 故事 18

  在头碰头会议上： 阿亨：我们一起做项目都是大家一起上，项目管理的书也看了，但是说实话，我觉得和实际差得太远。你说我们每周有8小时用于管理，这8小时里我们都要干什么？ 阿超：这就牵涉到项目管理人员在项目中的角色问题，在一个多层次的团队中，以前的管理人员事实上是扮演一个“抄表员”的角色。他们总是不停地问各个员工：“你干完了吗“？然后把个人和小组的进展逐级上报，上级要是问到一些细节，管理人员又得回头来问各个员工，再上报上去。 现在有了TFS，所有的项目进展的数据都一览无遗，管理人员就能从“抄表员”的角色中解放出来，把精力放在如何能更有效地推动项目的进展的方面。例如： 阅读全文 发表于 2009年8月6日 13:31 作者 关心 | 0 评论 归档在：移山之道