会员登录
会员注册俗话说“三个臭皮匠胜过诸葛亮”，但实际工作中出现的常常是“三个诸葛亮不如一个臭皮匠”。
您的软件开发团队有这样的一些问题吗?
日程安排一团糟、功能不合适、到处都是系统错误，而原因就是左撇子不知道右撇子在做什么……
一想到要出下一个版本，就觉得头晕想吐。
神出鬼末的缺陷，杀之不尽的缺陷，无止境的加班。
对计算机完全失去兴趣，萌生转行的念头。
……
Oh my god!这就是软件开发吗?
在谈软件开发团队之前，我们先看看优秀的团队，都具备怎样的一些特点?
英明的领袖
优秀的个人
严明的纪律
良好的沟通
一致的目标
协调的行动
良好的团队氛围
良好的习惯
……
您的团队有这样的特点吗?
软件开发团队管理有自身的特殊性，它更强调：
激发大家的潜能和创意。
让每一位成员有机会成为“牛人”。
充分发挥“牛人”的作用，并让牛人和其他团队成员和谐地工作。
让每位成员投入到创造性的工作中，享受成功的愉悦。
软件开发团队是一个种很特别的团队，很容易形成群众领袖，这种领袖并不是公司任命的，而是在实际工作中通过突出的工作表现，在所有成员的心目中自发形成的，这些人就是我们常说的“牛人”，这些牛人是最让公司又爱又恨的人了，如何让管理好这些牛人，如何让牛人们和谐地工作，这是软件开发团队管理的一大难点。
微软可以说是牛人如云了，微软的团队管理有什么秘密呢?
图1：微软的开发模型
推动开放式沟通
几乎90%的团队问题，都可以归结为沟通问题，沟通管理已经成为团队管理中最泛滥的一个词语了。这里又有一个新名词：开放式沟通。
“开放式沟通”具备以下的特点：
即时、主动
需要沟通时马上进行沟通，感觉到有问题时马上进行沟通，事后诸葛亮是为人所不齿的。
有效
用最直接最有效的方式沟通，抓住要害，准确表达，尽量简短。
形式多样
用尽可能多的最合适的方式沟通，面对面谈话、邮件、msn、QQ等，哪种方式最有效最直接，就用哪一种。
参与
强调人人参与，人人都要主动沟通，同时也要主动去和每一个人沟通。团队每一位成员都参与到每一个活动中。
包容
认真聆听各方面意见，鼓励不同意见。
直接、坦诚
说话不需要拐弯抹角，不需要诸多粉饰，用最直接最坦白的话来表达。
对事不对人
不戴有色眼镜看人，所有的沟通都是为了把事情做好。
为共同的前景工作
简单的说就是大家的目标要一致，并一起为这个共同的目标努力工作。
所有伟大的软件必定有一份宏伟的前景文档，该文档描述了软件将会带来什么社会价值、经济价值，开发本软件的目的是什么，本软件应用的范围、领域，本软件能解决什么业务问题，本软件有什么特性等等。
如果达不到以下任何条件之一，都不能算“为共同的前景”工作：
这个前景是大家一起来制定并一致通过的;
团队中的任何一个人在任何时候都能清晰地说出本项目的前景的大致内容。
用前景来指导工作，明确工作的重点，明确工作的方针，用前景来解决工作中的分歧。
很多人都会喊团队需要有一致的目标这样的口号，能不能做得到?以上三点就是检验的标准。
赋予小组成员权力
“在最优秀的小组里，不同的个人会在不同场合下体现出其领导能力，他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导，因为如果这样的话，这个人就无法和其他人融为一个整体，而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。”
——Tom DeMarco 和 Timothy Lister
微软的团队是没有固定的领导的，因为任何人都是领导，每位成员都有不可替代的作用，每位成员在自己专长的领域中担当领导的作用。
清晰的责任和共同的职责
测试一下大家对这点的理解，如果你的团队中出现这样的问题，这样处理是否合适?
项目进度推迟、项目预算超出计划，公司领导把项目经理叫去，严厉的批评了一顿，而没有责备过任何其他项目成员。
软件发布出去后，发现严重的缺陷，公司领导把测试人员叫去严厉批评，也没有责备过任何其他项目成员。
你们的团队中，有没有这样的情况：
只有项目经理为项目的进度、预算劳心劳累，其他人都在“安分”地完成“本职”工作，不会主动过问其他情况。
出现问题时，谁是问题责任人的皮球会被踢来踢去，没有人愿意承担责任。
为什么有这样的问题呢?应该如何处理呢?是责任定得不够清晰吗?
团队的每一位成员，肩负起自己所在领域的责任，团队的每一位成员共同对最终解决方案负责，同时鼓励小组成员对非他们直接负责的领域作出评论和贡献。
软件开发团队中，有项目管理、需求分析、设计、编码、测试等各个领域的人才，每领域的负责人对自己的工作负责。
另外一个方面，软件是团队共同劳动成果，所有人对最终的解决方案负责，最终解决方案只要有问题，就是整个团队的责任，最终解决方案取得优异成绩，就是整个团队的功劳。软件开发团队，是一个“一荣俱荣、一损俱损”的团队，只有这样才能把全部人的利益扭在一起。
了解了微软的这个原理后，大家对前面提到的问题是否有了答案?
关注交付的业务价值
客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子。看上去可笑，但这样的情况却经常发生在我们的身边。关注交付的业务价值，意思就我们工作中的每一份工作产品，都应该是需求驱动做出来的，这样才能保证我们最终做出的软件就是客户所需要的东西。这个原理有以下几层意思：
小组成员要对客户的需求有一致的充分的理解;
要让客户积极参与到项目过程中去，随时了解小组的理解和客户的需要是否一致;
需求驱动地完成所有工作，保证最后的软件产品符合客户的需要。
保持灵巧，预测变化
软件是智力型创造性活动，保持灵活、适应变化是软件开发的最高境界了，笔者认为这条原理是最难把握的一条了。
这个原理主要体现在以下方面：
软件开发过程
微软采用的不是RUP，也不是XP，而是类似于螺旋形的阶段式分版本发布。微软会把软件分成若干的版本发布，除了平时我们见到的Beta版、Release版，其实在Beta版之前还会有若干的内部版本。
每个版本都包含相对完整的功能，都能实现部分业务价值。每一个版本就是一个开发周期，每个周期包含远景、计划、开发、稳定、部署五个阶段。这样的一种开发模型，能很好地适应需求变化，发现设计、编码缺陷，优化设计，更容易控制软件质量，便于随时做出商业决策。
设计方案
执着于优雅设计的人士，可能很喜欢做出完美无缺的设计，关注于业务的人士，可能更关注于尽快要拿出软件。我们追求的是适度设计，而不是过度设计，如何做出一个简单的而又适应变化的设计，是对软件设计高手们的一大考验。
质量投资
“质量第一”是很多软件公司的口号，而且仅仅是口号而已，你们的项目有这样的一些问题吗?
代码没有经过简单的冒烟测试，甚至不进行是否通过编译的测试，就直接提交。
为了赶时间不写设计或者写了不能指导编码的设计文档。
开发进度推迟，测试时间被压缩，为了保证软件发布的时间，在不充分测试情况下交付软件，更甚者不测试软件，直接让客户测试。
开发过程中发现的问题，只要能不解决的就不解决，进度优先!
测试中发现的易用性方面的缺陷，因不会严重影响使用，一律不解决!
质量投资要求我们有零缺陷的意识，零缺陷意识要贯穿在全部的工作中，包括：
零缺陷文档
计划、需求、设计等开发过程中产生的文档，要用一次写好的决心来编写，所有文档都应该发挥它的价值，而不是为了写文档而写文档。要让相关的小组成员对该文档发表意见，重视他们的意见并修改文档。