阅读《构建之法》——第5,6,7章

       第五章：

                 在5.3节的开发流程中，个人或者是小组中，大多都是使用写了再改模式，这也可以更快完成，在前面也提到要降低任务交付时间的标准差，这也能更符合，为何不提倡，而只说对实际用户，解决实际需求来说缺点太大？在团队中，写实际软件过程中，更多的也是分模块来写，并想不出有何缺点。

                 微软的软件团队的模式是什么？他们是如何开发的？

        第六章：

                 敏捷流程在我们的学习过程中就是我们常用的想到什么写什么吗？

        第七章： 

                   在7.2.5中说商业项目要重视市场和用户，技术三第三位，当然这本就是商业在前面，但是没有高深的技术支持如何能更好让项目顺利完成，让用户体验一流的服务，在各种创业大赛中，所谓的商业项目也是来自于一个好想法好点子，难道这不更应该需要技术去实现吗？（顺提第六章的敏捷流程，看完后云里雾里，不懂，是我没抓到核心思路还是因为其他？）。

                 在7.2.2中提到：如果发现你做的事情对项目的远景没有帮助，你应该跟老板提出来。对于这种精神，可以应用到其他工作上，而前提却是老板给你安排的工作，是不是应该先想一想老板为什么这么安排，自己是不是还没发挥出来，是自己原因而没有做到正确的事。

                 “我的责任是把事情做出来，而不是讨好所有人，让他们知道我按照他们的意见做了”我更赞同前半段话，但“我按照他们的意见做了”是不是最终还是要按照别人的建议来做？（7.2.4）

                对于MSF基本原则中的九条原则，第7条说投资质量，我觉得毫无用处，在程序员写代码的时候就已经有对自己代码质量的清楚认识，而不是放在这边而·另外提出来，而且学习所有的经验应该放在最后才更合理。