读《移山之道》后有感 (转载)

rivermen

读《移山之道》后有感

--------------------------------------------------------------------------------

来源：博客堂

　　最近不断有猎头联系我，问我有没有兴趣看看其他的机会，其中包括AutoDesk，Morgan Stanley（软件研发部门），等等。职位都是QA Lead/Manager一类的。不是没有考虑过去微软外面看看。自从2004年秋天离开上海去北京的工程院开始正式作SDE/T（以及现在的测试主管）至今，已经三年了。这三年里面，一直是埋头做公司里面的产品，埋头做自己的事情，埋头学习，从我所在组积累的方法和经验里学习，从接触到的其他组学习。这三年里，再也没有去关心过微软以外的其他地方是怎么做软件的。

　　2004年秋天之前，我在工作中一直接触到国内各种各样的软件公司：2002年冬天的软件开发管理大会，2003年和全球技术中心的同事在各个软件园讲软件项目管理和软件测试，以及自己的编写培训材料，2004年上半年和微软中国的同事一起配合支持北方区的ISV（独立软件供应商）合作伙伴。那段时间里面，一直感受到微软内和微软外之间的碰撞。当时我总结了在各种对外培训、投标、会议等中收到听到的问题，应该说是当时国内做软件的人的普遍问题：

　　市场前景与产品功能
　　　如何进行市场预测和用户需求调查
　　　如何平衡市场前景和产品功能
　　　如何得出产品的Feature List

　　开发流程和团队
　　　如何在资源不足的中小企业中实施开发流程？如何裁剪？做项目时间紧，不能跟着整套流程做，有什么办法可以解决？微软的经验有什么精简的实现方法？
　　　对用户订制的软件应用系统的开发管理。
　　　怎么解决人员流动带来的问题，怎么在架构、设计中加入人员流动风险控制？如何保证极少数核心技术人员的流失或意外事件不给公司造成严重的损失？关键技术人员以离职要求涨工资怎么办？国营软件企业内无法突破工资与奖励的制度瓶颈怎么办？
　　　如何形成企业内知识共享环境？如何积累历次项目的经验？微软的“师徒关系”在团队管理中的应用。
　　　十几年以来，微软的开发流程是怎么一步步进化的？微软组织结构是如何一步步从小到大进化的？微软在软件开发管理方面从失败中获得的经验？
　　　有哪些典型的错误开发方式，并提出可行的解决方案及办法
　　　微软开发流程与CMM的区别？
　　　怎么做变更管理？开发团队管理组织中的决策模型和流程？一个项目被取消的原因和评判标准？

　　开发
　　　开发团队如何划分任务？如何预估和控制进度？
　　　开发团队的管理，如何科学的评估开发人员的级别、绩效？统计哪些指标？
　　　是否一定要Daily Build？
　　　代码库的管理，如何、何时上锁，权限如何控制？
　　　开发后期发现很多或者还有很多Bug怎么办？
　　　可扩展性应用程序的设计方法，思路。

　　测试
　　　测试应从哪些方面考虑？如何选择测试方法与工具（自动化测试/压力测试/性能测试等）？如何进行具体的测试，比如CPU性能？性能测试？有没有测试的实例？
Test Lead怎么考核？Tester的考核与量化管理，数据如何采集？如何培养测试经理？　　　测试经理的培训?
　　　如何提高Test Team的地位？
　　　QA部门何时、何种形式、如何参与到整个项目中？
　　　希望提供Bug管理工具和测试工具。

　　文档
　　　微软如何做需求管理？微软做不做、怎么做用户需求文档？软件项目（而非产品）开发初期怎么做需求文档？
　　　整个项目一共有哪些文档？如何管理文档？文档何时、何种原因可以修改？文档修改后怎么通知所有人？
　　　“需求说明”、“概要设计”、“详细设计”与“Feature List”、“Function Spec”、“Implementation Spec”的区别？其中要定义哪些内容？Function Spec和Implementation Spec要详细到什么程度？希望结合实例讲解文档。

　　PM
　　　PM做不做产品设计？PM是否写代码？PM是否能同时参加多个项目，如果是，有什么成功经验？
　　　PM是否、如何担当产品市场分析、决定产品的技术实现、决定Developer使用的工具和技术路线？
　　　产品达不到客户需求怎么办？PM夹在客户和Developer之间怎么处理两方面的要求？
　　　如何培养一个PM？如何考核PM的工作业绩？

　　其他
　　　希望了解实际的开发管理案例，以及与其他公司的案例比较；详细的行动指南、Check List等工具。
　　　想获得软件企业的管理软件和工具软件。
　　　希望获得面向不同发展阶段、不同规模大小的企业的更有针对性的培训。

　　我是带着这些问题去北京的工程院的。当时我给我的经理的邮件是这么写的：“过去一年多我做了很多开发流程、测试、配置管理等的培训，我很热爱培训工作，能够给中国的软件业者解决困惑他们很久的问题让我觉得非常有意义、有价值、有成就感。培训过程中感觉training skill已经不再是做好培训的瓶颈，而是觉得知识不够用。例如，培训中有一些学员很关心的问题（也是很关键的问题）我自己也找不到很好的答案，例如怎么做单元测试、自动化测试、怎么写好Implementation Spec等。我很想能够再多一些实际的锻炼，在开发、项目中寻找这些问题的答案”。

　　当时我也把这些问题转发给了邹欣。我不敢说这个问题列表对邹欣写《移山之道》有很大帮助，但我看到《移山之道》已经回答了这里面的很多问题。

　　我不知道今天的中国软件行业，带头的公司里，是不是已经都建立了必要的基础架构，例如：缺陷管理，代码库，文档库，测试自动化，等等。2003年，我接触到的还有很多公司在用Word/Excel填写“缺陷单”，还有很多公司没有做daily build，还有很多做测试的人还停留在把黑盒白盒挂在嘴上的阶段。如果有机会的话，我很想看看现在国内软件企业的项目管理水平是什么样子的。是不是还有很多人在争论到底是CMM好还是RUP好？

　　我也很想看看其他的跨国公司是怎么做软件的，比如IBM、GOOGLE、SAP、Adobe、etc。我很想知道EA等是怎么测试他们的游戏的：也用大量的自动化么？怎么自动化？怎么自动化的测试“帝国时代”或Call of Duty 3？Adobe是怎么测试Photoshop的？还有Google呢？

　　今年八月份的时候看到这么一封内部邮件：

　　I worked with a Test Architect here at MS a few years ago who is very highly regarded in the software testing industry … very much top of his game. He left MS about 2.5 years ago for Google to help them create a testing discipline and launch quality assurance practices. He just got in touch with me this morning and has left Google (Looking for another job in the area, but not necessarily MS.) I asked him why he left Google, and he said: “The short version of the Google story is that they don't have the people, the background, or the infrastructure for advanced testing, so my work didn't fare well there.”

　　既然一个如此very highly regarded的测试架构师都对Google的测试摇头了，我也不必去淌这趟浑水了。最合适我的，还是继续呆在微软做我的测试：既然当时我选择做测试的原因是我想要回答我自己心中关于测试的那些问题，既然微软这些年所积累下来的测试方法、经验、教训和内部工具是如此的丰富，我又有什么理由要自己到一个不成熟的环境中去重新探索呢？

　　正如那个Test Architect所评论的，我也相信，虽然Google已经是一个商业上的成功，但就整体软件工程水平来说，微软仍然代表了这个星球上的最高水平，虽然微软自己的方法论和实践不如学院派的理论那么高妙，虽然微软操作系统的名声一直被苹果和Linux压一头，虽然大家都喜欢说微软要用三个版本才能完善一个产品，虽然大家都嘲笑Office里80%的用户只用其20%的功能，虽然微软没有写过航天飞机的控制系统，虽然微软的数据库仍然不能取代IBM的Mainframe在银行里的位置，虽然微软的软件总是延期发布。

　　微软在软件工程上的经验不是一本书能讲的完的，也不是几本书能讲得完的。《移山之道》是一个缩影，是一个很好的入门。看《移山之道》的同时，还可以再看《软件开发的科学与艺术》、《软件开发项目管理》，以及《微软项目：求生法则》（一套三本，红绿蓝）。此外，Steve McConnell的所有著作都值得看。虽然Steve McConnell并不完全是一个微软的人，但微软的实践与他的书里的阐述非常有内在的一致性。举例来说，我自己最近一年以来就从他的《Software Estimation》中受益极多极多。

　　但是，光看这些书是绝对不够的。这些都只是paper knowledge，即便这些书本身来自于作者们多年的摸爬滚打。实践，只有实践才通向领悟。实践，反思，交流，尝试，再实践，然后才能真正达到know-how，否则，只会流于“形似而神不似”（《移山之道》，第319页）。