通过两周的时间，我大致看完了《构建之法》，对此提出以下几点问题：
1、在第二章个人开发流程中对比了大学生和工程师分别完成项目的各个阶段所花时间的占比，得出现象工程师在“需求分析”和“测试”这两方面花的时间明显比大学生高，而在具体编码的时间却更少，从而得出结论：从学生到职业程序员，并不是更加没完没了地写程序——花在写代码的时间反而少了许多。
提出问题：我认为从学生到职业程序员，随着编程能力的提升，职业程序员在写具体代码中能更加轻松的实现，但是大学生由于各项能力的不足，花的时间明显更多。我认为这样的比较不太合适，由此并不能证明大学生在成为的职业程序员的过程中，花在代码上的时间就一定更少。
2、在第三章中，提出了团队的软件流程TSP，TSP对团队成员的要求很多，其中提出理性地工作，反对个人需要灵感和激情，认为这只属于业余爱好者。职业人士只有每天持续的工作才会有所成就。
提出问题：对此说法，我并不是很认同。据我所知，现在公司很多程序员每天干着同样的工作，如果年轻时没有到达一个好的地位，老了时思维没有年轻人那么活跃，后面可能面临失业的情况。所以我觉得在工作时应该保持激情，不断学习新出现的知识，灵感也是不可或缺的，因为这可能是你走向的成功的另一种方法。
3、第四章中提出了结对编程的概念，结对编程的好处很多，如可以提高设计和代码质量，可以给工作带来很大信心以及可以互相交流经验，促进学习等。
提出问题：结对编程虽然有诸多好处，但对于两个人的不同的能力要求很高，如果两个的能力一样高或一样低，该如何分配项目中的任务等一系列的问题，所以结对编程的风险也是很大的，我们该如何权衡这种好处和不足呢？
4、第六章的敏捷流程中提出Scrum/Sprint成功实施的关键在于Scrum Master，这个角色事实上就是一个项目经理。
提出问题：在一个团队中的成员，如果有这种能力的人很少，那么这样的人在团队中的角色应该是Scrum Master还是应该作为技术人员专心完成项目或者这样的团队不适合用敏捷流程，如果不适合敏捷的话，他们该用怎样的流程来开发项目。
5、第八章中谈到了需求分析，一个软件团队必须了解和挖掘出软件利益者的需求才能动手开发项目。
提出问题：如果团队所挖掘的需求和软件利益者的需求有一定差距，但这个需求可能是团队认为所必须的，可能会带来更大的收益，这就与客户的需求起了一定的冲突。这种情况是该完全按照客户的要求来做还是应该和客户进行沟通交流，试图说服他们。
原文地址：https://www.cnblogs.com/cxfff/p/11566913.html