软件开发团队的基础设施建设.docx

软件开发团队的基础设施建设.docx

《软件开发团队的基础设施建设.docx》由会员分享，可在线阅读，更多相关《软件开发团队的基础设施建设.docx（6页珍藏版）》请在冰豆网上搜索。

软件开发团队的基础设施建设

CompanyDocumentnumber：

WUUT-WUUY-WBBGB-BWYTT-1982GT

软件开发团队的基础设施建设

软件开发团队的“基础设施”建设

一．软件团队

自软件危机爆发以来，人们开始用软件工程来试图解决这个问题，提出了各种各样的开发理论,开发模式。

软件开发的艺术性，和不可预知性，使得各种开发理论，开发模式,总是有其局限性，终始无法精确的用工程的手段来量化开发过程。

软件是科学与艺术的结合，理论与实践的结合。

作为一种智慧产品，软件开发基本上是一种智能的投入，是软件开发团队的智慧结晶。

在软件中凝结的智能愈高，软件的价值就愈高，能被市场接受的价格就愈高。

完全按工程组织来完成软件开发，基本是不可能完成的任务。

在看似平静的表面下面，软件开发其实是充满着各种风险，不可预知，和躁动不安的。

按开发计划完成软件是世界上最困难的事情之一。

虽然你有着那么多的开发经验，技术资源，开发模式，但是你不能完全的依赖它们，每一个软件都有它的独特性，都需要你特别的付出和关注。

你不要指望事情就能按你预想的那样一帆风顺的进行。

你需要关注，特别的关注，直到它的诞生。

因此有人说：

与其说软件的开发是可依进度或功能切割的项目，不如说是一种第六感。

有时候它的确是这样。

也正因为软件诞生的艰辛，所以它的诞生也具有震撼性。

一个伟大的软件产品，总是震撼着市场，震撼着心灵，将是人们全部的焦点所在，顾客将带着钞票抢着购买。

公司也将因此成为行业中的个中翘楚。

这就是软件的魅力。

一个高效率的开发团队会将这一切变为可能。

微软的成功，促使人们更多的开始关注小的开发团队的使用。

软件开发团队是为一个软件产品,或者一个项目的开发而组合在一起的组织.软件开发团队首先是为目标的存在而存在的.

对一个软件开发团队首先要解决的问题是:

应该由那些角色来组成团队．在传统上组建一个开发团队时，习惯上是找一个主管，几个主力程序员，加从其他部门调来，或者现招几个程序员，就算做是一个开发团队，就期望他们能按时按质的拿出东西，运气好的话，他们可以搞定，大多数时候，项目不是严重超期，就是永无出头之日，最后只有下马的命运.

一个先天不足的团队，很难期望他们能按时按质的拿出产品。

参照微软项目团队组成，一个软件开发团队应该由如下角色组成：

项目经理，系统设计师，程序员，测试人员，用户教育培训人员。

项目经理对整个项目的成败负责，需要关注项目的进度，与客户的沟通交流，理解客户需求，项目经理更多的是作为用户和开发人员之间沟通的桥梁．因此对项目经理，不仅要求在技术上能够解决项目中发生的各种问题，也能预见到项目的各种潜在风险，并规避风险，更重要的是做为产品的代言人，能阐述清楚产品的用途，特色给潜在客户，也能明白，清晰的理解客户的需求描述,并和客户在需求问题上达成一致或折中．系统设计师和主力程序员一起对整个产品的架构，设计负责，确认开发语言，制定开发规范，预先架构中的潜在问题，解决开发中遇到的技术问题和测试问题．程序员分为主力程序员和一般程序员，主力程序员将承担更多的责任，协助系统设计师的设计工作，并具体指导一般程序员的开发工作，主力程序员一般由有多年项目经验的程序员担任．测试人员负责产品的测试工作，从方案设计就开始参与并撰写测试计划，测试人员也应包括几种：

能写测试代码的，完全不懂计算机,只做用户测试的．其测试的侧重点不同。

用户教育培训人员撰写用户使用文挡，产品说明书等，用户教育培训人员是一个项目很容易被忽视的角色，但事实上，在一个大项目中，他们的身影绝对重要，这部分工作，没有专人来做，必然的分摊到程序员身上．程序员很难有时间，有心情来完成这些东西，不但会影响程序员的专注，也使文挡的质量很差．特别是在项目的后期，程序员的专注是非常重要的．我们看微软的项目管理，角色可以重叠，合并，但程序员与其他角色是绝对不会重叠，合并的。

将团队划分为几种角色，目的就是要他们各司其职，相互倚重，共享前景.一个团队如果没有明确的职责分工，没有规划，没有分工合作，只会让事情乱做一团，遇到问题，人人推委，最终导致团队信誉整体下降。

项目经理虽然对项目的成败负责，但是项目经理不可能面面俱到.因此保持出了问题有人负责处理的原则，是非常重要的．懂得分工与授权，项目经理才能＂解放＂自己，团队成员也才会遇事不躲，主动承担并处理问题。

二．人员建设

团队划分出各种角色后，应明确各个角色的素质要求和技能要求，一个不适合的人处于一个不合适的职位上，是一个双输的选择。

团队建设上应避免把团队建设成为一个大箩筐，什么东西都可以装。

开发团队要进人，就应该严格的按照岗位要求，招合适的人。

在严把进人关的基础上，团队还应该逐步的，有计划的把不合适的人员替换掉．这个岗位不适合他，应该还有更适合他的岗位，而勉强呆在原位，不仅对团队，也对他不公平．当然在中国这个人情化社会里，要做到这一点很不容易．特别是工作多年的同事，同时可能也是朋友,要做做这一点更难。

管理者也要克服掉人情关。

过不了人情关，很难成为一个合格的管理者。

大家听说过木桶理论：

一个木桶所能装的水不是由最长的那根木条决定的，而是由最短的那根木条决定的。

对这个理论应用到软件开发领域就是：

一个软件开发团队开发出的产品品质最差是由能力最差的人决定的，所能开发出来的最好的产品品质是由能力最强的人决定的。

通俗的理解是，一个开发团队开发出来的产品品质就是由最差和最好的人来决定的，也就是团队成员决定的。

一个产品的现状往往能很准确的反映出一个团队的现状。

产品的品质也就是团队的品质。

这就是为什么有的产品叫好又叫座，而有的产品缺无人问津，甚至中途夭折，产品品质最终是由人来决定的。

而当某个团队请到一个牛人指导时候，其产品品质往往有大幅度的提升。

而某个产品很糟糕的时候，回头看看他的开发团队，通常是整体表现为能力欠缺。

因此软件开发团队想要开发出好的软件产品，首先要做的就是挑战团队成员自身的局限。

团队成员的自大，高傲，拒绝合作，敌视，盲目自信都不利于团队的成长，更不利于自身的成长。

而一个开放的心态，虚心的态度，崇尚交流的风气将更利于团队成员相互接受，互助合作，更容易完成任务。

当团队形成注重成长的风气后，产品品质将会得到不断的提升，团队成员在自身成长的同时，也会带动其他成员的成长，这是有示范效应的。

当最短的木条和最长的木条都在开始长长的时候，木桶能装的水就是在增加，而对于开发团队来说，就是能开发出品质更高的产品，他所能解决的问题域更广，经验更丰富，更懂得如何去开发出一个好的产品。

团队是不停的发展变化的，成员的新增，辞职是不可避免的。

对于新进员工，应有一个"入模子"的过程。

联想柳总总结出来的"入模子"过程，很形象的说明我们就是要把新进员工的身上打上自己的标记，让大家有共同的语言，共同的行事规则，共同的理念，共同远景。

团队文化，氛围如果不能影响新进员工进入共同频道，这个团队建设就是失败的，不能延续的，迟早会出问题。

要形成自己的氛围，理念不是一早一夕就能作到的，团队建设者应更多的关注到这个问题上来。

这是形成团队战斗力的关键。

也是凝聚团队的关键。

对不能溶入共同频道的人，应坚决的予以清除。

三．职业生涯规划

堡垒往往是从内部被攻破的，软件开发团队也会在发展过程遇到因为内部问题而邦分崩离兮。

最重要的内部问题，我认为是团队成员的职业生涯规划问题。

一个团队，其管理者职位总是少数，而目前各个公司没有明确的职业生涯规划，只有走上管理之路，才能有大的发展，也就造成了千军万马过管理这条独木桥。

人的趋利性就使人们只向升职一条独木桥上钻。

聪明的人开始团结领导，能干的人寻找其它机会,程序员开始投简历，最终团队走向没落。

因此员工的职业生涯规划不能走千军万马过管理这条独木桥之路，而是要条条大路通罗马。

在国外的一些软件开发企业里，程序员一样可以拿到相当于副总裁，高级管理人员才能拿到的薪水,这样程序员才能安心的解决计算机问题，而不是去解决人际问题。

软件开发团队不同其他团队，软件开发中有越多的老战士在第一线作战，产品成功的概率就越大。

而我们往往做的是把一个技术好手提升为管理者，再招上十个八个人，来开发一个漏洞百出的产品，导致技术得不到延续，管理也是一塌糊涂的结果。

团队成员都能专注于做自己的事情，则这个团队的开发效率将越来越高，产品品质越来越好。

我认为微软软件开发的成功，也就在于此，一个有着数十年软件开发经验的团队和一个刚刚建立的团队开发出来的产品当然是不可同日而语。

《软件开发的科学与艺术》一书中提到，微软ＮＴ４前的产品经常会导致无故重启，死机，但是现在微软的产品越来越少看到这种现象，主要原因就是微软大量的程序员开发经验越来越丰富，测试经验越来越丰富的结果。

可见团队的延续性是多么重要；团队成员的专注是多么重要。

而这种专注就取决于管理者如何来解决团队成员的"前途"问题。

团队成员的发展途径，我认为可以有如下几个：

行业专家，技术专家，设计师，架构师，系统分析师,高级程序员，项目经理,产品经理。

团队每个人都将有足够的选择机会。

完全可以根据自己的特色选择。

喜欢管理的可以向项目经理，产品经理看齐，喜欢技术的可以专注于技术，走技术专家，设计师，分析师之路。

最终形成百花齐放的格局。

在技术上也可保持连续性，并可不断的加深技术底蕴。

最终技术，管理都将得到大的发展。

四．团队交流

一项统计数据表明，一个软件开发团队即使没有高深的技术背景，没有突出的项目管理能力，只要其内部交流通畅并以务实态度解决问题，一样可以开发出优秀的产品。

软件开发团队的内部交流是很重要的，是建设一个有战斗力的团队所应充分重视的。

团队内部交流包括两方面：

技术交流和思想交流。

软件开发团队作为一个技术类团队，技术是团队的立足之本。

技术高超的人会逐渐赢得团队成员的敬意，并成为团队中的权威，崇尚技术者的偶像，并影响团队决策,技术走向。

在我所工作过的两个团队，他们有着截然不同的风格，一个团队崇尚技术，狂热的追捧着新技术，总是选择最前沿的技术，对所选择的技术誓死扞卫，不惜与贬低该技术者决裂，对技术天才则是发自内心的崇拜，团队中随时可见以技术为主题的热烈讨论，争论。

而另一个团队则恰恰相反，受其领导者的影响，团队很少关注新技术，总是在不厌其烦的研讨需求，设计，至于使用什么技术来实现，并不是那么重视，技术高手的作用也不是那么明显，团队成员的技术交流则明显不足。

技术作为软件开发团队的基础没有的到体现，当然技术也就成为了这个团队发展的制约所在。

团队成员的技术交流不但可以增进团队成员之间的友谊，更能拓宽成员的技术视野，迅速提高成员的技术水平，对一些基础，模糊问题的探讨，可以使其清晰，问题明确，并达成一致意见。

团队技术交流的方式有多种：

技术研讨会，主题讲座，技术培训，代码评审等。

技术研讨会可以就一项技术细节或开发中遇到的问题进行集体探讨，最后形成集体决议，用于指导以后的开发工作。

而主题讲座则是为拓宽技术视野，主题讲座可以内部进行，也可以外部请专家。

在我公司某个团队一直有这样的传统，每个人都要选择一个主题进行内部讲座，主题可以是开发经验，心得，技术专题等等，实践下来效果很好。

技术培训则主要是做一些基础性培训。

中国的程序员在大学中一般没有得到开发方面的基础培训。

进入企业后必须进行基础性的培训。

代码评审是直接对某个程序员的代码进行公开评审，共同发现代码的问题，特别是思维误区，在代码评审中有多年开发经验的程序员也会被抓到严重错误。

建筑师以砖石来构建房屋，程序员以代码来编织产品。

代码的优劣直接影响到产品的品质。

一个没有受到良好技术培训的程序员编织产品就象一个没有建筑经验的建筑师来构建房屋，都是岌岌可危的。

而团队充分的技术交流可使是成员得到最大限度的相互培训，共同提高技术水平，相互提醒编程误区。

团队成员的思想交流一直是我所重视，关注的一个方面。

现代的企业，人员流动很大，软件开发团队同样如此，如果仅仅将团队成员看成是同事关系，上下级关系，是不够的，这样的关系是表面化，形式化的。

而对于一项优秀的产品开发来说，更需要的是战友，挚友关系和对共同目标的认同。

以同事加上下级关系组建的团队在前进过程中，很容易受到外界的诱惑，使团队成员轻易的离开。

而要形成战友，挚友的关系，思想交流是必不可少的，深度恳谈是很有效的一种手段。

在我所经历的一个项目，项目产品经理是一个很有经验的领导。

定期组织相关人员到茶楼座谈，一般主题为公司，项目内部的问题，到茶楼座谈气氛很轻松，没有明显的等级界线，大家都可以畅所欲言，随着谈话的深入，话题不再仅仅局限于公司项目的，而是渐渐深入到人的内心想法，人生，理想，发展等等深层次的话题。

而项目经理也将自己对产品的理解，人生感悟，工作经验等等拿出来和大家一起交流。

这样的座谈经常可以从下午下班开始一直持续到深夜。

团队的凝聚力在一次次的交流中不断的得到加强。

而同事，领导之间因为这样深入的交流，能相互理解，相互支持，相互认同。

思想交流要解决的另一个重要问题是：

工作是为谁干的问题。

员工往往有这种意识，我是来打工的，你要我干什么就干什么。

至于能不能把产品作好，卖的出钱，产生利润，不关我的事，事不关己，高高挂起。

这样的思想很普遍，对团队的危害也很大。

程序员一定要形成这样的意识：

工作不仅仅是为公司工作，也是为自己工作，你付出了时间，精力，也收获了经验，感悟，成长，经历，人际关系这些可贵的东西。

如果你采取事不关己，高高挂起的态度，事实上也是在放弃成长，放弃获得经验，资历。

而仅仅获得了可怜的工资。

所以我们在团队建设时，注重培养团队成员对产品的"拥有感"和"努力工作是为自己成长"的意识。

管理者也要注意，你需要的不是一个雇员，而是一个合作者。

这是一个双赢的选择。

下面将谈到团队的延续性问题。

有位哲人说，我看的更远，是因为我站在巨人的肩膀上。

团队的发展也是站在前人的肩膀上的。

团队的文化，技术，思想，经验应该得到延续,让未来者能看的更远。

所以团队建设要注重技术沉淀，思想沉淀，文化沉淀。

这些都是团队的宝贵财富，是团队成员花费了大量的时间，心血得到的,是团队的精华所在。

很多团队不太重视这方面的建设，没有将好的技术，好的思想总结，提炼，流传下来，茫茫碌碌过后，发现是一场空，得到了什么，感悟了什么，失去了什么，都不知道。

当然也就注定是一个没有生命力的团队。

五．工具应用

工欲善其事，必先利其器。

软件开发团队开发中会涉及到很多工具的使用：

编译器，项目管理工具，文字工具，源代码管理工具等等，用那些工具，如何使用都是有思考价值的。

工具是思想的体现，思想是工具的源泉。

Rational的ROSE套件是面向对象设计思想的体现，所以只熟用ROSE套件工具，而不理解其背后面向对象思想的精髓，将始终是得其形而不能得其神的。

很多程序员只是将工具用的烂熟，却不能理解其精神实质，所以只能是个程序员，而不能成长为设计师。

设计师总是在观察世界，设计着工具产品，而程序员则总是在追寻着工具。

明白工具的位置是很重要的。

不能把工具当成全部。

善于利用工具，编制工具是一个成熟团队所应具备的能力。

在开发过程，会有大量的事情需要人去处理，如源代码工程编译，单元测试，模块测试，代码复查，数据生成转换等等，这些工作即烦琐，又耗费时间，而利用工具来完成则既快捷又准确，更能节省大量的时间，精力。

在我们的软件开发中，对所有源代码做一次集成编译，需要花费至少半天时间才能准备好，首先要通知每个程序员编译出某个版本，然后拷贝到某个指定地点，如果某个程序员不在，或者有其他急事，时间还将拖的更久才能完成全部编译。

在我们编制了一个自动编译工具后，事情就变的简单了，指定编译时间，编译工具就可以自动的取得所有源代码，并编译出目标代码，整个过程只需要20分钟。

还可以同时管理多个工程。

工作效率得到了极大的提高。

再加上编译后自动备份功能，我们随时可以找到以前的某个版本。

在软件开发过程的各个阶段，都可以引入相关的工具。

需求分析阶段，可以引入需求管理工具，使所有的需求可控，并根据版本开发计划，及需求的紧急程度，确定需求是本次版本实现，还是下一版本实现，或者是不与实现。

在分析阶段可引入RationalRUP的分析设计模型，使用Rational的工具来管理分析设计文档。

在编码阶段就需要太多工具了，编译器工具，编译器辅助工具，源代码检查工具，单元测试工具，资源泄露检查工具，性能效率分析工具，自动编译工具，源代码管理工具等等，在测试阶段需要自动测试工具，压力测试工具，性能测试工具，测试问题管理工具等等。

六．综述

上面从软件团队，人员建设，职业生涯规划，团队交流，工具应用等五个方面探讨了软件开发团队的"基础设施"建设。

这些问题是建设一个有战斗力团队的基本问题，不关注团队的根本建设，而只期望得到满意的结果，是很难如人愿的。

而我们探讨这些问题，就是让团队能更有效率，更专注于目标，更能成就一个伟大的产品。