读《移山之道》这本书差不多用了一个星期的时间，感觉还是收获了一些知识的，以前只是会简单地编个小程序（虽然现在也是这样），但看过这本书之后我对软件开发这个概念的认识度有了从一片模糊到了解大体概念的转变。但是毕竟用一周时间读透这么一本完整的书不是一件简单的事情，我也只是了解到了一些皮毛，在阅读的过程中也遇到了很多问题，一些基本的问题在后面的学习中已经解决了，有的还在困扰着我。
（1）在书中了解到了一个术语叫 Work Item，但书里并没有提到一个vs里出现过的叫做issue的Work Item，这是什么情况呢？
经过了解发现，这本书里讲到涉及到vs的都是vs2005，由于版本较老，没有issue这个Work Item，而现在的高一点版本的vs则有issue。我没有较多的实践用过这个Work Item，但据我查资料所了解这个Work Item实际用起来还是挺方便的，预估风险以应对敏捷开发里的突发状况等等。
（2）关于敏捷开发，前期的设计很重要，开始可能会写的非常简单，但经常在后期代码增多时发现简单的方法已经不能用了，会出现不一致的情况。之后可能还要重写，比较繁琐。当然解决这个问题的方法无疑是在下手之前先考虑周全，但是这个看似简单的方法几乎没有人能百分之百做到，感觉比较不好把握。
（3）结对编程是一类创新型的编程方法，一个独立的工作由两个人一起合作完成，这种方法有利也有弊。
益处很多，比如
1）结对编程让我们在有partner的前提下更有信心，有人和自己并肩作战。也更有动力，不能被同伴落下，不能拖同伴的后腿。
2）由于是两个人一起完成，所以思维更加多元化，方法也比较多，可以在众多选项中选择最好的那个，提高编程的质量。
3）结对编程能够更有效地交流，相互学习和传递经验。
Every coin has two sides.结对编程的益处这么多，那有什么弊端呢？
我想经历过的程序员都知道，这种编程方式需要双方进行深入的沟通交流，交流的好了才能保证代码的质量，但是万一双方不是适合彼此的partner，问题就大了，从来不沟通 交流，又或者两个人的思维习惯变成习惯差异大，自己做自己的又做不好，去合作又找不到合适的方法，确实很揪心呢。
不过这种问题也很好解决，因此我们应该要学着去结合双方的思维和能力，去一起解决问题。
（4）这本书只要瞄过一眼的就知道，整本书是讲故事为一条线来展开的，刚接触的时候还觉得很新鲜，读到中间会觉得有点为了讲故事而讲故事，很牵强的与知识联系到一起，但是读到最后就变得豁然开朗，回顾整本书，如果没有这个故事，那可能有一大半的东西理解不了也记不住，总之这种方式还是挺吸引人的，也能让人更好的学习。但是这种方式是不是能让大部分的人接受呢？我认为可以做一些调查，征集大家的建议，好的地方继续发扬，需要改进的地方加以修改，或许效果会更好吧。
（5）最后一个问题是我没找到答案的，也思考了很久。TFS中为什么不允许Dev自己添加任务呢？有什么限制的地方？