软件团队
程序员是知识的权威和信息的瓶颈 --《实例化需求》
软件开发在大多数时候是一项团队活动，而因很多人在描绘团队时喜欢用球队来进行类比，尽管两者之间具有极大的相似性但是如果仔细分析就会发现不同。
球队其实是建立在具有若干高水平(明星球员)球员的基础上，战术围绕这些球员设计，在比赛中某个球星的发挥就可以帮助球队取得胜利。如果球队没有球星只有整体，虽然可能稳定地生存，却没法去争取更大的成功，因为缺乏超越平均水平的因子。
软件开发则无法围绕某位明星程序员设计，因为这不是一场只有90分钟的比赛，而是场可能长达几周或几个月的活动。漫长的周期、庞大的工作量都聚焦在某一个或几个程序员身上将带来不言而喻的问题，团队随时都有瘫痪的风险。所以软件团队和球队不一样，也许赛艇这项运动才更加合适类比，它要求参与者同进退，只要有成员的步调不一致，带来的后果就是整个团队的混乱。
软件团队也是这样，团队产出才是衡量一个团队效能的标准，而非某一位明星程序员的产出。如果不能帮助团队获得更大的收益，那么明星程序员的贡献也仅仅是干好了自己份内的工作而已，并没有太多值得称赞之处。因此软件团队一定会寻求使整个团队齐头并进，稳扎稳打的工作方法。
软件开发围绕团队中的每个人展开，每个人都是是团队中的最关键因素和限制因素，经年累月的工作容易造就领域专家，也更容易造就"独裁者"。不少团队还在人为地给程序员之间建造壁垒和沟壑，例如，“一个萝卜一个坑”式的工作分配或者“之前干啥现在也干啥”的工作分配，迫使程序员只能专注于狭窄的知识领域，从导致了下面的问题：
- 团队协作离散
- 知识孤岛
- 重复地发明轮子
最糟糕的是过度依赖引发的团队知识信任系统的崩塌，团队不敢将工作交付给其他人，当知识沟壑大到一定程度，他人也不会有信心来修改代码，看似只差一个任务就能完成，却永远无法交付，因为负责这段代码的老兄生病住院了！
上面这些问题原因在于团队缺少知识循环机制，每个人变成了“知识黑洞”，知识一旦进入某个结点就如同进入黑洞一般，外面人的既不了解黑洞内部，也不敢进入黑洞一探究竟，看似高手云集却只能各自为战。
分享与汇聚
软件是在头脑中创建的 -- 《程序员的思维修炼:开发认知潜能的九堂课》
软件并不是在集成开发环境(IDE)或其他工具上设计出来的，它是在我们的大脑中想象和创造出来的。一个人对于软件设计的想法再丰富也只是一个人的想法，这样的想法不表达出来影响团队只会有两个结果，要么被自己认定不够成熟重回脑细胞要么被自己遗忘。
知识循环系统的建立意味着团队变成为一个可以汇聚个人思想的有机主体，它可以接纳每个成员大脑中的想法，无论成熟与否。任何想法通过每一个团队成员的大脑知识循环，使得个体的思想在团队的大脑中汇聚、碰撞、升华和凝练，最终个体的思想不会再是原始的火花而是集体众人拾柴火焰高的火堆，由个体思想升级为集体智慧最显著的特点是个体对于思想的记忆时间和完备程度得到了增强，因此思想和概念是需要在团队中分享和交流的。
分享帮助团队产生集体智慧，同时也帮助团队成员树立信心。对于个人成长，分享的过程是重新整理个人思路的过程，更重要的是通过讲述或者书写，可以体系化地发现知识的漏洞，加深个人对知识的理解，而从团队获得反馈则弥补个人思考的片面性。通过交流、沟通与反馈，个人信心的增强同时带来了团队成员之间信任的加深，因为分享增强了对对方工作的理解和认知，既有了信心又有了知识的保障，团队可以更加顺畅地将工作流转起来，而不用担心各种各样的意外了。所以归结起来就是两句话：
- 相信大众智慧是最佳方案
- 相信充分参与是最佳执行力
引导与激励
授之以鱼不如授之以渔
原理阐述总是简单的，一旦落地就需要团队中的每个人付诸行动。通过适当的引导和激励，遵循一些基本原则，可以让团队氛围改变得平缓而富有实效。
- 轻松的气氛可以为分享增色，牢记团队分享不是培训或教导，而是一次让精神愉悦的沙龙；
- 建议固定时间和地点，这样便于团队形成习惯；
- 由谁来分享完全出于自愿的，分享的内容团队可以进行引导，例如：技术雷达，但不要强制规定；
- 一旦决定分享就必须认真准备，因为分享是讲述你自己的经验而不是他人的，所以你必须对自己负责，当你认真起来，听你分享的人才能从你的分享中汲取并给予反馈；
- 每次分享结束可以简单地提醒“下次谁来分享”，尽量让团队成员自荐；
- 团队应当尽量让老员工分享基础，那样容易能吸引新员工参与，让新员工分享较难的内容，并让老员工辅助，这样容易发现知识体系中的缺漏；
- 激发团队分享热情可以从树立一块分享墙开始，着重描述分享者和分享话题，例如一份历史分享记录和一份未来分享提醒，既能帮助团队成员了解分享信息，又可以对外展示团队建设的成果。
