通读《构建之法》，提出五个问题
1. P8 虽然已经开始上课好几周，但在这次通读本书难免还是会去想，软件工程是什么
- 从书上知道软件工程是一个过程，把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上。
软件是一个逻辑概念的产品，在开发的时候，进度的可见性很差，为了改善，提出了软件工程。
在软件工程中，优化了团队协作、拔高了效率。
2.P69 从代码复审到结对编程是否是团队优化的体现
- 在不提成本问题时，团队中若是一人独立设计，在复审环节，复审者的工作量巨大甚至免不了争吵。
若以结对编程的形式，从设计到复审都不再处于一种唯一的状态，相互可以督促、大大提高效率。
在我看来，结对编程是代码复审的优化，一次提高效率的进步。
3.P93 开发流程是否是团队模式的进化
- 毋庸置疑的一个成功的软件的诞生少不了一个优秀的团队，从设计初期到最后的运营。
从我们很小的时候，就知道众人拾柴火焰高。
而我在通读过程中，开发流程更像是在团队模式的一种细化，像是一张优化的电子列车时刻表。
在整个软件向前推动的过程中，时刻表在不停的优化，协调每个人员的工作。
所以开发流程不是团队模式的进化，而是细化。
4. P114到底敏捷流程是如何的敏捷
- 敏捷流程主要是三个步骤：找出完成产品需要做的事情，决定当前的冲刺需要解决的事情，冲刺。
但从步骤上看，我似乎只是觉得很有规划。
在进一步的阅读中，一个敏捷的团队需要成员做到自主管理、自我组织、多功能型，这三点是现在很多从事我们这个行业的人员所欠缺的，通过走敏捷流程似乎是对每个成员的考验和修炼。
所以敏捷流程也是一个团队的共同进步，每个人都在分享中进步。
5. P143 需求分析是不是该被放在设计的核心第一步
- 在我看来，在很多时候，甲方都是乙方的噩梦，即程序员在完成每个客户要求时都还要随着客户的想法的改变做出适当的改变。
完成客户的每个要求、每个改变都是我们努力的初衷。
为了减少乙方的工作量，所以我们最好从心底了解甲方，目前比较流行的几种是焦点小组、深入面谈、卡片分类、用户调查问卷、用户日志研究、人类学调查等多种方法来获取用户需求。
我认为作为乙方应该不只局限于完成一个甲乙两方的一纸合同，更应该让甲方满意，留下口碑，所以需求分析是设计核心的第一步。
