读《移山之道》 去“移山”

 

   软件工程课老师让我们选一本教材，分别是《代码大全》、《快速软件开发》、《移山之道》 。作为初入茅庐的人，对三本书没有先验知识的情况下，对比了这三本书，最后选择了《移山之道》。

· 为什么我选择《移山之道》？

   1. 《移山之道》名字读起来霸气外漏，所有人很喜欢物超所值，尤其是中国人，看着名字，好像是讲方法的，”道”是个很高深的问题，浅可达到方法，深可达到哲学。加上老师推荐，这本书应该不会差，所以首先名字吸引 了我。

   2. 看着厚厚的《代码大全》，里面教你如何写代码，如代码布局、注释、测试等等，在原本时间不是很充裕的时候我果断放弃了。而《快速软件开发》虽不是很厚，但是对比《移山之道》还是不行，而且移山之道有插图，很不错的插图，看起来颇有意思。

   3. 当然快速对这些书时，发现《移山之道》是以愚公移山为背景，模拟场景，同时语言颇具独特，网络用语、文言文、歌词、现代诗等应有尽有，看起来很诱人。

     基于以上三点，我选择了《移山之道》。当然我们是来学习的，不是看热闹的，也对此书表示怀疑，我们上软件开发，作为教材这本书靠谱么，噱头搞那么大，学不到东西时间岂不是白费了。就这样半信半疑的开始读了此书。

     由于软件工程其实是一门最注重实践的学科，脱离了实战，再好的方法都是浮云。软件工程在继续，书也在读，实战和阅读中都遇到不少问题。下面就简要谈谈我的问题、以及我的想法。

搜索引擎里搜“软件工程中最大的难题”，很多情况下搜到的都是沟通问题，起初我感觉也很疑惑，但是通过一起daily scrum，一起讨论问题，个人基本上都有个人的想法，一旦想法出现偏差，最后都会反映到代码里，产品里面。

     同时在第二章“白话MSF方法论”时提到MSF（Microsoft Solution Framework）有8个基本原则，第一条就是 推动信息共享与沟通（Foster open communications） 可见信息沟通在MSF也占有很重要的位置。

· 那么如何解决？

      当然我们可以借助TFS进行帮助，如TFS里面所有的信息都是保留的，公开的，就像银行账户里的资金流动记录，是不可以删除的。这个外在客观的限制，确实实现了代码和bug的公开。当然除了TFS这种强有力的公开沟通工具之外，我们还有办公软件email,可以发邮件，可以预约会议，电话，以及daily scrum ，也可以通过communicator 聊天工具进行沟通。但是这些都是工具，如何解决其实还很大一部分依托于PM（项目经理）

   从这幅图可以看出PM是一个纽扣，是上层老板，客户以及团队的枢纽，一旦任何一个环节出现沟通出错，就会导致工程无法进行，因此PM在团队中起着举足轻重的地位。

  但是PM坐在核心的位置，会不会危险系数很高？ 其实，一个良好的开发团队，就应该降低团队的风险，避免团队中出现不必要的沟通问题。这时我认为前期的计划是很关键的一个步骤

       前期的计划是完全按照用户需求，完全按照可行性，完全按照团队的规模，团队的水平定位的，一旦前期能够有合理的定位，合理的计划，就要按着计划一步步走下去。前期的计划是大家共同达成的共识，而且最后会分配成Task 导入到TFS的Work Item。只要前面的计划合理而有效，那么后期的开发就很容易了，只需要按照Work Item进行工作，可以只看这些小的work. 但是PM在这里就不能闲着没事，这时要做好团队的沟通，时刻观察每个程序员的状态，观察他们的进度，观察他们遇到的问题，站在高层，保证团队的整体进度，保证团队的整体工作效率。

       当然项目经理不能对工作进行简单分解，虽说简单分解会造成工程管理的方便，但其实这种共层这种工程管理方式看似方便，似乎也很符合模块层层细分的“工程方法”，其实是最低级的。因为一旦有问题就必须从头开始推倒重来。

        项目经理不能强拉硬套，感觉自己是经理，就很牛，就可以那上级对下级的态度对程序员进行高要求，一旦达不到就当众羞辱等等。项目经理我认为应该站在地位的最底层，但是思想的最高层。地位的最底层，可以让大家一有棘手的问题，就可以提出，而不必害怕项目经理，让程序员做到真正的自己，而不必考虑其他因素。这样，PM掌握了第一手程序员的状态，便于协调、预防问题、解决问题。思想的最高层，PM要懂得最优化，要懂得一个问题的严重性，一个问题所产生的影响，甚至是几个问题产生的影响。时间和进度怎么优化这个函数，只有这样，才能把问题看透，才能分配任务的优先级，快速而又合理解决问题。

· 考核指标太刚性了，怎么办？

      程序开发的工作因为具有复杂性和不确定性，工作难以量化等原因，导致开发人员的具体进度往往是预估，是以个人经验、个人能力预测等多种因素影响的，具有很大的不确定性，单纯的从进度去考量开发人员“进度”指标，可以说是不公平的，尤其是我们刚刚踏入软件工程，对开发不是很熟悉，但是进度往往是我们的管理层（老板）和项目经理决定，做技术层面对进度的决定权不大。而进度恰恰是由在第一线工作的程序开发人员来完成的，有可能项目要求一个比较模棱两可的进度要求，而项目团队不得不接受。 网上有不少统计数据，比如在美国本土的软件开发项目中，有超过70%的项目延期，近31%的项目因为进度原因而不得不终止或放弃。

因此完全固化的进度考核容易引起人员疲劳、士气低落、主动性降低，从而影响项目团队的稳定性。

如何解决呢？

       在《移山之道》这本书中衡量员工工作质量中（DEV）中其主要衡量两个指标

（1） check in 的质量，也就是签入破坏构建的次数

（2） 功能是否按期完成，如果延期，是否提前交流

      为了团队的整体利益，我们肯定要努力按时完成计划，必须体现刚性的一面，但是如果DEV确实态度很认真，任务没有完成，如果延期，那么肯定要有一个合理的机制，其实也就是交流和协调的问题。当一个问题跨不过去，那么应该及时想PM报告，让PM初步评估这个任务的优先级，影响如何。如果优先级高，及时找其他人员帮忙解决。当然平时开发人员也应该做些软件开发培训等。

结合书本和实践说了两个比较常见的疑惑下面就谈谈这本书中一些有意思的东西

· 问渠那得清如许，唯有源头活水来？

     作者在此书中旁征博引，引用的东西虽不能一个一个查询是否正确，但是每次读到时候，感觉一种现代的软件工程和中国哲理结合起来，或者给我的感觉是中国文化之博大精华，在软件工程中都能体现的淋漓精致。

开篇，作者就直接引用了朱熹的《观书有感》“问渠那得清如许，为有源头活水来”。

    不是很理解，因为前八章都是VSTS与MSF基础， 书的“源头”是什么？书的“清如许”。 其实VSTS 是微软多年开发经验的一个工具，MSF是一个方法论，照着这种理解，估计就很容易了，MSF既然是方法，那应该是源头，只有高层的方法务实，可行而且有效，那么就会有源源不断的活水。而且可以把VSTS看成“水渠”，按照“水渠”寻根问底，追朔源头，便可找到MSF。 微软在IT行业当老大也很多年，总结的产品团队开发经验和教训应该是经过无说验证的，所以这个源头应该是很纯的，经得起时间考验。

    英语文中有 you can move mountains 作为创造奇迹的表征，中文中有愚公移山之传说。作者软件工程的具体实施比作移山之艰难。但是移山又是人类进步的阶梯，要想富，先修路，把道路清空，把前面的大山移走，意味着软件工程的开发是多么有意思，趣味无穷。在这万千艰难中，作者给了的“法子”是两个东西：MSF和VSTS。前者，是思想理念，后者则是方法工具。

     此书确实有创意，但是由于刚接触软件开发，书中很多问题，很多话都没有感觉。所以不敢妄下评论，但是网上评价都很好。书中作者写了这句话：“我曾向大学软件学院推荐这本书，得到反馈是，这本书“太活了”，不宜用于教学。”呵呵，可能确实太活了，里面谈古论今，里面“谈情论事”，里面“引诗用典”，里面“中西结合”。历史扯上了，爱情扯上了，歌词扯上了，名人扯上了，国外扯上了，最后核心的东西是软件工程。如果，高校引用了这本教材，让教师们情何以堪呀？

     最后一点很触动：这本书的作者竟然在业余时间把这本书完成的。平时作为项目开发经理，大家知道肯定很忙，真不知道作者的时间是怎么挤出来的。表示好奇，表示钦佩。

 

by Haifeng Liu

转载于:https://www.cnblogs.com/OMG-Team/archive/2011/10/10/2205361.html