构建之法第三章讲述的是如何去评价一位软件工程师。首先，类似于艺术创作，一件好的作品一定是经过一位好的艺术家倾注自己的灵感和情感所创作出来的。同样的，一个好的软件也需要一位好的软件工程师倾注他的智慧和汗水才能得以诞生。首先作为初级的软件工程师，我们做软件工程所必须具备的，肯定是我们在软件工程方面相关的知识的积累，这是一切的基础。有了知识之后呢，就应该动手，而动手的过程，就是一位软件工程师经验累积的过程。再然后，有了足够的经验，我们就会开始思考，在经验的基础上，从更深层次的方面去了解一个软件或者说一项软件工程。我觉得，这是我从书中所学到的作为一位软件工程师成长所需要的必经之路。
构建之法第四章讲述的是两个人的合作。对于一个软件工程来说，众所周知的，它不是一个人的工作，它需要一个好的团队去完成这项艰巨的任务。而如何组成一个团队合作就是从如何组成一个两人合作开始。首先，要合作的话，就需要代码的规范，制定相应的规则，比如在变量的定义方面，用拼音还是用英文单词，需要两个人进行统一，否则，两个人做的软件就很难整合到一起，或者说，两个人甚至都不能看懂对方的代码。有了规范之后，就能够进行结对编程。在我看来结对编程的目的在于，为了更好地进行代码的复审。组合两个人各自好的观点和思想，摈弃两个人的不足，两个人也可以帮助对方发现代码中的不规范和错误的内容，所以结对编程是一种不间断性的复审。最后，在两个人的组队当中，既然是合作，我们就应该把团队推向两个人优点集中的方向，就需要两个人更好地交流和沟通，以自己好的方面去影响对方，这样才能更好地进行结对编程。
构建之法第五章中我影响最深的就是，什么是团队。团队是一群乌合之众聚在一起就叫团队了吗？或者说，一群做相同工作的人在一起工作就交团队了吗？结果显而易见，并不是。首先，团队是有一个集体的目标的，而团队中的所有人都在朝着这个目标努力拼搏。其次，团队成员有各自的分工，互相依赖合作，共同完成任务。这样才能称之为团队。
构建之法第六章则是想我们详细介绍了敏捷流程。根据我的理解，敏捷开发换言之就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。首先，从敏捷两字中我们可以直观的得出，我们要尽快地完成自己的软件开发的项目。然后，它是一个短期的开发过程，这样我们就能迎合用户的需求，跟上需求的变化，对软件进行改进，从而利用这种变化来提高对用户的竞争优势。在我看来，最主要的就是团队和个人都应该时时总结如何提高团队效率，并付诸行动，这是推动敏捷开发进步的主要动力。而一个团队要转变成敏捷流程，就需要自主管理、自我组织、多功能型。其实就是，团队的人员要学会交流，每天就应该对个人对团队做出总结，每个人都有自己负责的区域，这样才算得上是一个敏捷的团队。
从之前的两次冲刺来看，我觉得自己就有很大的不足。首先，我缺乏一个团队的意识，只管自己所要完成的内容做到尽善尽美就可以了，并不关心团队的发展，也缺少和组员之间的交流，这是我最大的弊病。通过对这几章的学习，我明白了什么是团队，我应该和团队成员一起合作朝着共同的目标去努力，而不是单干，因为那并不能使一个团队良性地运作和发展，更别说能够合作处好的软件工程项目。我觉得我就应该好好学习敏捷开发的内容，在一个团队的项目开发中，每天都要总结个人的收获，更重要的是每天也要总结团队的发展和收获，这样才能使一个团队良性地运转，使个人更好地在团队中发挥作用。