阅读了构建之法的四、五、六章之后，我对以团队为基础的软件工程这门学科有了更深的了解。学习这门专业，我们从最开始的单人编程，经历以两人为组的的结对编程，通过在大学学习期间所结合的几人团队的分工合作提高我们个人的团队素养。构建之法的这几章内容让我再一次对团队编程有了更深入的了解。
现在回想起刚开始和另一个同学结对编程做的一个随机生成四则运算的小程序，这里由于我们结对编程的目的是进一步扩展程序的功能，而在前一阶段两个人分别使用了c++和java编程，于是两个人第一步做的是统一我们的编程语言。最后，我们选择了数组应用较为简单的java，于是两人闷头开始着手去做。经历了详细的设计思路分析和总结，我们开始了我们的编码，于是问题也就产生了。由于之前他的习惯是用拼音来定义参数而我则会更偏向于英文字母，（这里并没有觉得他这样做的不好的感觉）而结对编程是以两人一人编码，一人速检，二者交替的形式进行。一开始没有什么问题，到了编程将过一半，我们在程序的后半段要调用大量参数，然后就是一会拼音一会英文，这样的感觉给本来就觉得编程枯燥的我们带来了极大困扰，于是就不得花了一段时间去重新定义参数。与之相似的还有代码行的规范，代码的注释。以前一个人写代码没觉得什么，两个人一起做后才发现自己的编码很乱，于是本来效率应该提升的结对编程被我们硬生生将时间拖长了一倍。第四章讲的是两人合作。主要的点有代码规范、极限编程和结对编程，也讲到了与别人交流的一些技巧。看了第四章才真正被点醒，我们的结对编程所浪费的时间就是因为看似小小的代码规范问题导致。于是在后来的编程过程中我们每次在讨论完设计思路，定义好程序框架后，第一件要做的事就是定义各参数和可能会定义的函数。不过在代码注释方面，由于总是急于程序功能的实现，于是往往被忽略，这一点在以后的编程之中应得到注意。
第五章讲团队和流程。而我们在最近的学习中恰好组成了队伍，我们的队伍应该能算做团队的，我们有一个比较大的目标，也有各自的分工，但并不明确。在团队模式上，我们应该只能算是一窝蜂模式。因为每个人不清楚自己到底要干什么该干什么，于是开始变得松散然后大家毫无积极性。这里书中明确的指出组建一个好的团队这件事，已经不是计算机科学的事情了，也不仅仅是软件工程的事情，考验的是队伍负责人的组织领导能力和组员们的交流合作能力。的确，我们就是缺乏这种组织和交流管理的能力，因此这需要我们加强团队合作与管理，团队不是一个人的团队，软件工程也不是一个人就可以实现的工程，难道我们的不会是机器，而是和人打交道。
敏捷流程和团队开发是第六章的重点，这与老师布置给我们的实验内容相仿，书中提到的开发流程正是我们要去学习和实现的，而在实际的开发过程中，并没有一开始想像的那么美好。事实上如果我们的团队真的做到了书中的大部分要点，一定会有极大收获。事实上和团队中的每个人都有关系，就拿每日战力会议来说，刚开始其乐融融，大家你一言我一语，一段时间后各中原因开始涌现，今天你有事，明天我有事，总之各种原因取消站立会议。刚开始没觉得什么，慢慢地由于没有阶段性的总结和目标大家都不知道该干什么或者说不想去做了，于是团队就产生了问题，而像老师说的那样，大家都是同学互相之间也都不好提议，于是问题就更严重了。总结几点原因：1.没有一个明确的管理者。2.没有严格的团队制度。3.不够重视，应付了事。
这几章的内容明确的谈了谈软件开发过程中团队的运营，我们应当认真对待以后的每一次团队训练，发挥自己在团队中应有的作用，向成为一名成熟的团队成员的方向积极进取。