我们也算是经过了一次软件开发的人了，在Alpha阶段过程和结果都不太理想，我们在写事后诸葛亮会议的时候也感慨了很多，在小组会议的时候也讨论了很多，为了完成这次作业，我又翻了翻《构建之法》这本书。这本书给我的感觉还是和第一看的时候一样--与众不如。我们平时的那些专业课书少不了概念和代码，这本书让我很意外的没有看到什么代码示例
这时我已经产生了第一个问题：这本书是让我们学什么的？我通过这本书的学习之后我能充当好一个什么样的角色？是一个技术人员，还是一个leader（分配者）？开发一个软件，是什么更重要呢?技术吗？还是合作模式，合理分配，亦或管理，对市场的感知和分析？如果我技术不好，这个团队还需要我吗？（这真是我的心声啊，我这技术......）
第二个问题：一个初级工程师想要成长要掌握这么多的知识，我们在大学四年是否可以完成这些东西的学习呢，我们的精力和时间都是有限的，要怎么分配呢，怎么平衡这些和学校课程和个人爱好，这些东西都是必备吗？初级工程师想要成长就一定要这些全会吗？
在书上看见了列出的不适合结对编程的项目情况，那么第三个问题来了
第三个问题：有没有不适合结对编程的人呢？比如那些一直想要做领航员的人，这样会不会造成结对中的不公平？驾驶员想要用汉堡包式的方式告诉那个领航员互换角色，可是那个领航员假装听不懂的样子的时候又要怎么办呢？又或是在两人的合作中，一个人一直假装听不懂建议，打马虎眼时，又要怎么办呢？
第四个问题：书本中第五章列举了很多团队模式：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式等等，那么哪个会是最高效的团队模式呢？是有一个最理想的最高效的模式，还是这几个模式中适合自己团队的才是最好的呢？
第五个问题：我们之前花费了很多的时间做好了充足的市场需求分析，可是在实现中发生了冲突要怎么办，比如deadline要到了，我们的一部分需求功能没有实现，我们是要舍弃这些功能，还是有向老板再请求一些期限，如果我们项目的杀手功能实现起来遇到了瓶颈，我们要放弃杀手功能吗？
关于自我评价连接表：