团队建设的前提

n 相似的群体背景

n 有效的人际沟通

n 合理的激励机制

n 险恶的外部环境

众志成城

团队建设的基础

n 心理互补需要

n 行为互动需要

n 自我超越需要

相互共同与认同：团队建设的关键

二、团队成长过程与其机制

团队成长的基本过程

1.         建设阶段

² 寻求共同目的

² 凝成利益群体

² 推荐领导班子

2.         成长阶段

² 明确主辅关系

² 沟通合作默契

² 行动协调一致

3.         成熟阶段

² 铸造群体灵魂

² 增强群体活力

² 提升群体等级

4.         转型阶段

² 变革求得生机

² 内外融为一体

² 共创新的天地

成功的工作团队之基本特征

² 各成员在心理上相互依赖和认同

² 各成员在行为上相互配合和制约

² 各成员对该群体都有一种归属感

² 各成员由一共同目标凝集在一起

心理和行为默契：团队力量之源

成熟团队的外在表现

² 统一规范的团队标识

² 高层大力倡导与倾心支持

² 成员构成流动有序

² 人格力量的相互吸引

² 轻松随意的交往方式

团队成长的心路历程

² 交往中相互接纳的愿望

² 性格上相互猜疑的倾向

² 行为上相互冲突的表现

² 心理上相互理解的渴望

² 工作中相互协作的产生

² 情感上相互依赖的加深

三、团队建设的方法与模型

团队建设：培养团队精神

u 流行换位思考

u 从“我”到“我们”

u 处处体现“双赢”策略

u 从奖励个人到奖励群体

u 信息、知识、经验的共享

团队合作能力的培养

u 极力突破自身的心理障碍

u 创造轻松活泼的团队气氛

u 相信并寄希望于其他队员

u 寻找团队成员积极的品质

u 设法上队员理解和支持你

团队成员亲密接触

团队建设的星系模型

和而不同，既聚又离

团队建设的舰队模型

聚而不死，分而不散

团队建设的雁群模型

群体领导，个人负责

参考：

1， 一流团队建设指南：http://wenku.baidu.com/view/57231d254b35eefdc8d333f7.html

　　很显然：在代码提交前，用第二群眼睛检查一遍，防止bug混入。这是对其最常见的理解，是对代码审查的好处的最广泛的认识。但是，依我的经验来看，这反倒是它最不重要的一点。人们确实在代码审查中找到了bug。可是，这些在代码审查中能发现的绝大部分bug，很显然，都是微不足道的bug，程序的作者花几分钟的时间就能发现它们。真正需要花时间去发现的bug不是在代码审查里能找到的。

　　代码审查的最大的功用是纯社会性的。如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。

　　还有一个非常重要的好处。代码审查能传播知识。在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。

　　当然，没有什么事情能简单的做下来的。依我的经验，在你能正确的进行代码审查前，你需要花时间锻炼学习。我发现人们在代码审查时经常会犯一些错误，导致不少麻烦——尤其在一些缺乏经验的审查者中经常的出现，他们给了人们一个很糟的代码审查的体验，成为了人们接受代码审查制度的一个障碍。

　　最重要的一个原则：代码审查用意是在代码提交前找到其中的问题——你要发现是它的正确。在代码审查中最常犯的错误——几乎每个新手都会犯的错误——是，审查者根据自己的编程习惯来评判别人的代码。

　　对于一个问题，通常我们能找出十几种方法去解决。对于一种解决方案，我们能有百万种编码方案来实现它。作为一个审查者，你的任务不是来确保被审查的代码都采用的是你的编码风格——因为它不可能跟你写的一样。作为一段代码的审查者的任务是确保由作者自己写出的代码是正确的。一旦这个原则被打破，你最终将会倍感折磨，深受挫折——这可不是我们想要的结果。

　　问题在于，这种错误是如此的普遍而易犯。如果你是个程序员，当你遇到一个问题，你能想到一种解决方案——你就把你想到的方案作为标准答案。但事情不是这样的——作为一个好的审查者，你需要明白这个道理。

　　代码审查的第二个易犯的毛病是，人们觉得有压力，感觉非要说点什么才好。你知道作者用了大量的时间和精力来实现这些程序——不该说点什么吗？

　　不，你不需要。

　　只说一句“哇，不错呀”，任何时候都不会不合适。如果你总是力图找出一点什么东西来批评，你这样做的结果只会损害自己的威望。当你不厌其烦的找出一些东西来，只是为了说些什么，被审查人就会知道，你说这些话只是为了填补寂静。你的评论将不再被人重视。

　　第三是速度。你不能匆匆忙忙的进行一次代码审查——但你也要能迅速的完成。你的同伴在等你。如果你和你的同事并不想花太多时间进行代码复查，你们很快的完成，那被审查者会觉得很沮丧，这种代码审查带来的只有失望的感觉。就好象是打搅了大家，使大家放下手头的工作来进行审查。事情不该是这样。你并不需要推掉手头上的任何事情来做代码审查。但如果中途耽误了几个小时，你中间还要休息一会，喝杯茶，冲个澡，或谈会儿闲话。当你回到审查现场，你可以继续下去，把事情做完。如果你真是这样，我想没有人愿意在那干等着你。