看完了老师的《移山之道》，发现跟自己的预期有很大的区别，下面就谈谈我看完这本书的感想以及一些收获。

　　总体来说，移山之道并不是一本单纯的介绍VSTS或者技术方面的书，而是一本有关方法论甚至有一些哲学意味的书。

　　邹老师以情景剧的方式组织书的学习林俊德心得体会方式很新颖，很能吸引着人看下去，这是本书的一个很大的特点，也是优点。

　　另一个令我印象深刻的地方是书中的一些失败开发的例子，比如典型的学生团队的开发流程，简直就是真实情况的写照。

　　我觉的这本书对软件开发的学习十分有帮助，通过这本书我还了解到了开设软件工程课的意义——我们不是为了技术或

　　者完成任务而开发一款软件，我们是为了更好的满足客户需求和让更多的人更容易的生活、工作而开发。当然，

　　开发的过程中要有良好的沟通，共同的愿景才行。这也是这本书试图教会我们的软件开发经验。

　　还有一个让我印象深刻的地方是软件测试。我们以前写的小程序基本都是没有经过什么测试的，就是找一些最基本的

　　数据<或者直接是老师给的数据>进行测试，根本就经不起推敲。在《移山之道》中看到了测试数据应该遵守的原则，

　　感觉测试真是一个十分重要的环节。至于这一点，我还有一些别的感受：win8，我尝试安装使用了win8的DP，CP，RP，

　　RTM版本，如果没有这些测试改进，win8的体验真的是十分的糟糕的。像DP和CP版，Modern<Metro>应用很容易崩溃，而且

　　传统应用也是经常的崩溃，甚至资源管理器都定期的No response。但是到Rp就有很大的改观了，RTM就基本没有这些现象出现

　　了。我想这就是测试的重要作用吧。没有完整的各种测试，发布出的产品就很难得到认可。

　　看完这本书我有以下几条问题要提： 　　　　　　1、我们一直在谈创新，假如我在一个自己创业的团队中，需求并不是很清楚，同时别人也很少的做过类似的项目，

　　那么我应该怎样去完善需求，怎样很好的规划出具体的进度以及重要的时间节点？

　　　　　　2、怎样通过一个有效的办法确定一个Bug的重要程度？我们知道，修改一个Bug时别的Bug处有可能会产生相应的改变，

　　修改了某个Bug可能有的Bug的出错原因就发生了改变，也就是说，如果出现了一些Bug，应该先修改那些Bug会比较

　　有效率？怎样调整他们的优先级？

　　　　　　我自己尝试给出了问题1的答案：

　　　　　　尽量缩短需求分析的时间，尽量完成基本核心功能，然后尽量拉长软件测试的战线，多测试，少加功能。这样可以赢得一些

　　比较看重核心用处的高粘性用户，只要有一些忠诚的用户，做出来的产品就挺成功的