第二阶段的实训已经结束了，将近一个月的第二阶段实训让我收获颇多，也丰富了我的一些专业技能。
我在团队中担任的是网站开发任务，前期参与需求分析制定。在需求分析中我们组员在某些功能的要求和规定上有很大的分歧，比如事件这个模块是需要还是弃用。我当时的想法是事件模块我们都不知道是什么作用，对此没有明确的开发方向，我们为什么要启用事件这个模块呢？最后的讨论结果是放弃事件这模块，把事件的某些功能以更好的方式加入到新闻和文章中。然后到了概要设计阶段，我设计了专家角色的用例图。参与了各角色的功能模块图的制定。讨论UI界面的布局并给出了自己的意见。在详细设计阶段，我负责了新闻，文章和组团信息回复的类图的设计，也对数据库的设计给出了自己的一些建议。在详细设计阶段我对我们的网站有了基本的开发方向，我们将采用分层开发的模式，每个开发人员将负责几个特定的功能，然后从详细设计开始负责自己的那几个功能实现，一层一层地写下来。到了编码阶段，我根据详细设计文档中的类图，在数据库中写好了自己负责的那几项功能的存储过程。然后再在FTS中一层一层，一个一个地去写自己的方法，并在类的开头和每个方法前加上代码注释。此代码的编写人和创建时间，以便自己和他人的使用和维护。事实证明代码的注释真的很有效，后期我们要调用他人的方法的时候，很容易的就找到了，并且很方便的使用。最后在界面层，我负责了后台母版页的编写。在界面层，是我的弱项，以前接触的不深，也没怎么去学习。可以说，我在界面层的编写是边学边做的，调用方法很简单，但是想要很漂亮和正确地将此方法表达在界面上，对于我来说确实很困难。一些控件的使用和布局，我都是查阅资料后才能很好的使用。
在这个项目中，我们团队整体很融洽，可以说每个人都是项目进行下去必不可少的一环。刚开始分组的时候可以说是很幸运，我们小组六个人实力都很平均，每个人能力都差不多，但又都有各自的优点和擅长的方面。单个人来看，我们都不能独自完成此项目，但组合起来，力量就不一样了。我们的项目经理能让每个人发挥自己的长处，并且避免自己的缺点放大。对我来说，我会常规的代码编写和逻辑判断，但是对于比较复杂的逻辑判断和数据库的设计，我则是头大，或者需要很长的时间才能弄出来。我也就扬长避短，那些复杂的逻辑判断，通过我的要求，项目经理将这些转给其它的小组成员。他将其它的比较适合我的方法交付给我去编写实现。我们团队中开发人员需要经常沟通，一些方法需要制定标准，有了标准，才能在实现后能方便的使用他人的方法。
一个团队中首先需要建立互相之间的信任，一个有凝聚力的、高效的团体成员必须学会自如、迅速、心平气和地承认自己的错误、缺点并且求助，还要乐于认可别人的长处，承认对方的长处超过了自己。如果我们队员之间彼此适当说出“我办砸了”、“我错了”、“我需要帮助”、“你在这方面比我强”这样的话，就明显地建立了这种信任。否则，如果队员之间不允许其他人在任何方面超过他，那么后果就是团队成员彼此之间都不会敞开心扉来坦率承认自己的弱点和错误，会逐渐走向衰落。其次要有良性的冲突，团队合作中的成员往往最怕起冲突。我们当然要采取各种措施避免团队中的冲突。因为冲突可能对团队的凝聚力产生影响，以及一些人的自尊在冲突过程中可能受到的伤害。这种通过避免破坏性的意见分歧来巩固自己的团队的方法考虑并不周全，因为这种做法很可能扼杀建设性的冲突，将需要解决的重大问题掩盖起来。但是随着时间的推移，这种未解决的问题就会变得越来越棘手。一个好的团队要做的事情，是要学会识别和避免这种“虚假和谐”，甚至适当引导和鼓励一些建设性的冲突。不能就不同意见而争论、交换未经过滤的坦率意见的团队，他们所做出的决策往往是欠考虑的。最后是需要互相监督，互相负责，这样的团队才能抗住压力，一步一步走下去。