构建高效软件开发流程和团队

构建高效软件开发流程和团队

1.前言 (2)

2.项目计划 (2)

3.开发文档 (3)

4.编写代码 (4)

5.代码管理 (4)

6.测试 (4)

7.BUG管理 (5)

8.Code Freeze (6)

9.Tech Talk (6)

10.Code Review (6)

11.沟通与交流 (7)

12.后记 (7)

1.前言

本人曾就职于多家公司，但留给我印象最深刻、开发管理最规范的公司是I 公司。该公司总部位于美国硅谷，其开发的产品曾获得PC Magazine的最高五星级的优秀好评。现我根据在此公司中所感受到的经历及自身的一些感想写出来，希望能给大家和其它公司有所借鉴。

2.项目计划

在一个产品发布并使用之后，其中肯定有许多地方不如意和值得改进的地方。客户在使用的过程中会发现一些问题，提出更高的需求，市场也在发生变化，我们的竞争对手也在发展，新的技术不断地产生，这些因素推动着我们的产品不断地向前发展，使它的版本不停地往上增长。这些发展的需求不是一下子提出来的，在客户使用的过程中发现某些不如意不方便的地方，他们会向我们的技术支持人员提意见，而技术支持人员会把这些需求以BUG的形式存入BUG数据库中，其级别一般定义为下一个版本的Feature。有些上一个版本未解决的BUG也可能需要在本版本中来解决。因此当我们来开发下一个版本时，其许多特性已经存在

于BUG数据库中了。当然新版本的特性不是只从BUG中获得，管理层可能从市场的角度来提出新的特性以求领先竞争对手，开发人员本身也可提出某些要求来纳入新版本开发的计划中，如要求对某部分代码进行重构以使其结构更清晰更容易维护，执行效率更高。

每个人把同自己相关的功能模块收集起来，同时预估时间，其中主要包括写文档的时间、开发时间和单元测试的时间，一般要求精确到工作日。这些信息发送给组长，组长再把本小组人员的任务和预估时间发送给管理层，由管理层对此任务及进度进行评估审核，管理层会根据产品发布时间及客户需求、市场因素等方面作出选择，可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同预计的产品发布时间有较大冲突，而且此功能是本版本中必须得做的，则开发小组会被要求重新预估时间，加快开发速度来达到这个要求。

虽然这个开发进度时间是一个大概的估计时间，但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个Status Meeting（一般那时工作效率较低，适合开会），在此会议上我们会根据这个进度来review我们的工作，每个人手上的工作是否按照这个进度在走，是否有人延后了，是否block住别人的工作了。在此会议上每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个会议，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后，如果有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上，那也没有办法，只能修改原先的进度表，因为那是我们的估计与现实发生了偏差，我们必须使我们的进度表符合实际情况，这可以避免许多项目发生最后的20%的工作量会占据80%甚至一直拖后的情况。修改进度表的情况我们曾经发生过，有一次在按照原先的进度执行到将要完成的状态时突然接到通知由于市场及客户的原因要求加入另一项重大的功能，这个功能对我们程序的结构有非常大的影响，因此我们就要重新制定一个进度来满足需求。在这种情况下，产品原先的开发进度被打乱，发布时间也因此推迟。当然这种情况应当尽力避免，尤其在项目后期产生新的需求，若不得已也应重新规划进度，而不是仍旧依照原先的进度去执行，因为老的进度已不能反映现实的情况。

3.开发文档

在项目进度安排中我们已经把写文档的时间也规划进去了，这里虽然是写文档，其实是设计程序，整理一下思路与架构，磨刀不误砍柴工，这样在实际写代码时会流畅很多，节省时间，因此可以说真正有思想性的东西都在写文档这段时间内完成了。当然我们这里的文档格式不象ISO那样规定了条条框框，我们的文档格式相对自由，基本上能随意发挥，但对于几个主要点一般来说是需要说明的。要求写的文档能让他人比较容易地看明白，能把问题讲清楚，能反映你的设计思想。文档的数量也不多，开发文档有两类，一类是Function Spec，另一类是Design Document。

Function Spec中需要写明的是本模块完成的任务，解决什么问题，有什么作用，为什么要这些功能，此外我们还会添加进适用范围，有什么不足，注意点是什么，还有哪些地方在以后可以进行改进。在这个Function Spec中不涉及到任何非常详细的算法。此文档不光给开发人员看，还让QA及其他成员以及后来

的新人能根据此文档来了解此模块的大致功能，同时也会给文档编写者看，他们会根据这些Function Spec整理出一份用户手册，告诉用户此版本中新增了哪些功能，各功能模块有什么作用，如何使用等信息。因此在我们的开发过程中Function Spec是很重要的文档，此文档完成后会抽出一段时间同相关人员及QA 一起review这个文档，让QA了解设计者的意图，同时熟悉新的功能模块，为接下来的测试作准备。如果其中有误解或不明之处，大家会提出来探讨并由开发者修正。

Design Document中主要描述实现此模块所涉及到的主要算法、数据结构、类的层次结构及调用关系。这个文档的阅读者主要是开发人员，包括任何想了解详细实现代码的人，帮助人们理解代码。在某些功能模块比较简单的程序中，此文档所描述的信息会比较少。此文档不象Function Spec要在开始写代码前就编写完成，它可以随着代码编写的进行而增加，但基本上遵循文档先行原则，也就是要增加新的代码或修改代码前若有涉及到文档部分的应先修改文档，然后再修改代码。

4.编写代码

由于我们用JAVA语言进行开发，因此我们借助了Jbuilder IDE工具。关于代码风格，我们基本上套用Jbuilder中自动的代码格式编排，但其中需要改变的是缩进是4个字符，类与类之间间隔2行，方法与方法之间间隔2行，import 类时用完整的类名。写代码时要对类及函数提供详细的注释及说明，基本做到看它们的说明就能知道这个类或函数的功能以及主要算法的实现原理。在开发过程中对主要的模块要编写UnitTest，同时要UnitTest先行，也就是遵循XP规则中的测试驱动原则，当所有的单元测试代码通过时，此功能也就基本上完成了。

5.代码管理

我们采用VSS+SourceOffsite进行版本控制，其中存放了此产品的所有源代码、库文件、文档及release时的安装程序，各个部分存放在不同的目录中。每天早上要求开发人员从VSS中get latest version的源代码，然后进行编译并开始一天的工作。在下班之前理论上要求员工check in所有当天修改的代码，在check in之前要保证编译是能通过的。若有谁check in的代码导致daily build失败则会被要求某些惩罚措施或警告，象微软公司要负责照看当日的每日构建。有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在check in进去可能会导致BVT（Build Verify Test）测试通不过，因为有些代码没有完全完成，而之前的代码能使BVT测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不check in进去，直到全部代码完成能提交BVT测试时再一起check in进去。

每天我们都会做daily build，一般是在凌晨4点进行，那时有个程序会自动从VSS中拉下最新的代码并进行编译。因为我们同美国进行同步开发，因此如果想要把修改的代码进入到这个build中去那就需要在凌晨4点之前把相应的代

码check in进去。若有人check in进去的代码导致编译通不过则会在本步骤中被发现。当编译完成之后自动产生安装包，测试部门将会对这些代码进行BVT 测试，同时对VSS中开发库打上label，如果发现了什么BUG就能根据这个label 知道是哪个时候开始出现这个BUG的。BVT是指Build Verify Test，是对组件中基本功能的测试。这个测试每天都会进行，看新加入的代码或修改是否会影响系统的基本功能，便于及早发现错误。

6.测试

在开发人员完成了Function Spec后，测试部门开始了测试规划，确定需要测试哪些方面，如何测试及进度安排。测试人员需要写许多测试代码，有些测试代码需要集成进BVT测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，使开发人员容易找出问题所在并改正。产品功能是否符合了要求，是否能被发布是由测试人员决定的，因此测试人员也比较辛苦，责任重大。通过了每天的BVT测试，还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能release出去了，如果没有什么问题则会给某些关系较好的用户进行β测试，之后再最终release 出去。

7.BUG管理

由于我们每天进行着测试，因此经常有BUG被测试部门发现，一旦发现了新的BUG，就会被添加进BUG Tracking System中。目前较流行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla等。BUG tracking system是开发人员和QA之间的纽带，开发人员和QA通过BUG tracking system联系着。每个BUG有其类型和级别，预定的类型有Crash-Data Loss, Crash-No Data Loss, Incorrect Functionality, Cosmetic, Feature request等, 级别有P1、P2一直到P6，它们分别代表了重要性及紧急程度，P1的BUG需要很快fix，P5之前的BUG在本版本release之前必须fix掉，若真的不能或不重要则由QA确定并降低优先级进入到下一个版本中去fix。QA发现一个BUG后在BUG Track中增加一个BUG，同时填入相关信息并assign给相应的开发人员，开发人员收到BUG 分析并fix后assign给QA去verify，其中要填上分析的结果以及如何解决的详细说明。若QA对此BUG verify通过则close BUG，否则verify failed并重新assign给开发人员并等待其fix。每星期在Status Meeting上会进行BUG状况报告，主要由QA组长报告BUG的状况，主要是新增BUG数，fix掉多少，还有多少处于open状态，有多少处于等待verify的状态，据此可以了解开发及测试情况。有时在Status Meeting上我们也会进行BUG Review，BUG Review有时是单独一个小组内进行，其主要作用是重新明确每个人头上的BUG以及了解每个BUG的状况，如开发人员对此BUG将作何处理等，以此来了解开发中是否有碰到比较棘手的问题，增加了产品发布风险。在QA增加BUG和开发人员fix BUG的游戏中，BUG的数量曲线图会象股市曲线一样上下波动，但总体趋势一般是前期BUG放量攀升，后期震荡下挫，若到了后期新open的BUG数量一直上升则说明

风险在增大，有可能无法控制，也就是说fix了一个BUG导致了多个新的BUG

产生。在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快，当在fix bug阶段，代码的修改较多，因此代码数量的增幅会降低，依据代码量可以看出开发的状况处于何种阶段。

需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。因此BUG 的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路，但此BUG的verify必须要让测试本模块的测试人员来verify。

8.Code Freeze

当P5之前的BUG都被修复了，这时离产品发布日期也就不远了，一般是2个星期后就能release产品，这时要对VSS中的代码进行freeze，以保证代码库的稳定性。Code freeze阶段一般会把各开发人员的check in和check out 的权限关闭，若在这时仍有BUG报告上来并经讨论确定是重大的且必须在本版本中fix的，则需要经管理层同意并特殊地授予权限，在修改完成后修改者要把修改了哪些文件，影响了哪些文档等信息上报给各部门如QA、build人员、文档编写者等。在code freeze阶段，测试部门在紧张地进行着各种测试，得出各种数据，并决定本版本是否可以release了。

9.Tech Talk

计算机知识更新速度非常快，经常有一些新的术语、新的名词、新的思想、新的技术所产生，如过离开此行业几个月后重新回来就会对这些新的事物不解，而我们平时为了自己的项目埋头苦干可能忘了周围的世界发生了什么。Tech Talk就提供了一个让我们了解新知识和最新发展趋势的机会，让大家把知识共享，共同提高。Tech Talk一般会在项目不是太忙碌的时候进行，主持人会提前一个星期指定某个人去准备一下Tech Talk，一般此人可能对某方面比较感兴趣，然后他会花一些时间去了解这方面的情况，写成一个文档如PowerPoint并上传到局域网内，同时通知大家可以先去浏览。Tech Talk的内容非常广泛，不一定同我们的项目紧密相关，任何新的思想、新的知识（当然一般是限在计算机领域内）都可作为Tech Talk的内容，而在主讲人讲完之后还有一段时间被大家提问，共同对这个话题进行讨论，答疑解惑。当然Tech Talk也可同我们的项目相关，如研究一下竞争对手的产品技术，本公司产品的架构等。研究本公司的产品架构可以使大家对本公司的产品有一个全局的概念，从整体上来看自己的产品，顺便整理一下产品的架构使之更加清晰有条理。平时大家都只注重于自己负责的其中的一小块，在Tech Talk中可以跳出自己的小框框来了解全局，同时这也是新员

工了解公司核心技术整体框架的好机会。每个模块的负责人需要阐述此模块的方方面面，让大家来了解并回答问题。

10.Code Review

当进行工作移交时我们会进行Code Review，在碰到棘手的BUG时也会进行Code Review，Code Review是大家了解其详细实现的一个好机会。在Code Review 之后会对此代码产生亲切感而不是陌生惧怕感，相信很多人在读他人代码时会有非常痛苦的经历，Code Review是减少此痛苦感的好药方。在进行Code Review 前，主讲人会提前发出一个通知告诉相关人员要review哪些代码，这样参与者可以抽出时间提前了解相关代码，对不懂的地方做个笔记以便在Code Review

进行中提出疑问。在我们碰到比较棘手的BUG没有什么思路或大惑不解时，这时找几个相关人员或对此代码也熟悉的人进行一次Code Review，这时形式比较随意，大家可以临时提出问题，让主讲人解答，在这个过程中可能听的人并不会非常快地了解其中的详细过程，但是讲的人在这个过程中重新理了一下思路，对所写的代码被迫重新审视了一遍，在其中可能就会发现出解决问题的办法。在Code Review时有时代码非常多，但可以一个功能模块一个功能模块地从总体到局部，由浅入深层层递进的方式进行。一次Code Review的时间不要太长，但可以分多次进行。Code Review中大家会提出问题和建议，集思广益，多个人共同出主意，有些可能一个人没有想到的问题会被大家发现，互相学习，共同进步。

11.沟通与交流

大部分员工的大部分时间是在公司里度过的，因此公司的生活成了大家主要组成部分。员工之间关系的融洽，交流的畅通显得非常重要，同时大家也不想自己的生活这样枯燥乏味，一直同机器打交道。沟通无处不在，交流随时发生，有许多关系是在工作之外建立起来的。软件公司内是很容易产生各种矛盾的，因为这是由你的工作性质所决定的，比如QA或用户会对你的实现不满意，提出各种要求时，我相信你有时会有所抱怨的，无形之中就产生了对立，发展到后来会有抵触心理。我相信大部分人都会有此感受，这不是你的错，这主要是由我们的工作性质决定的。如果你的工作是把财富带给对方，则对方会非常欢迎你的到来，把你奉为财神爷来对待，同你的关系会非常融洽友好。因此我们需要在工作之外来消除这种对立矛盾的关系，建立一种融洽的工作氛围。我们在平时吃饭的时候饭桌上大家互相聊天沟通。我们建立了happy邮件列表，其中会发一些幽默笑话之类的邮件，给我们紧张的工作增加点轻松的氛围。在下班后大家可以组织一下活动，增加了公司的凝聚力。一个产品发布后组织一下旅游，让绷紧的神经松弛一下，更好地迎接下一个挑战。

12.后记

不同公司有不同的做法，我只是把我认为比较好的流程与管理方式呈现出来，让大家有个借鉴，当然它也不是十全十美的，也不是放之四海而皆准的，如果你觉得某些地方对你有所帮助或值得推广，这是本文最想达到的效果。非常感谢I公司给了我这么美好的经历，也非常感谢I公司的同事们曾给我的巨大帮助，在此衷心地祝福I公司越来越壮大，逐步走向成功！也衷心地祝福我的同事们幸福快乐！

高效研发团队建设的六个步骤

高效研发团队建设的六个步骤 对美国软件工程实施现状的调查结果表明，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。软件开发团队的建设和管理依然是软件项目管理中一个十分主要的问题。 软件项目管理的主体是软件开发团队。一个软件项目管理的好坏，很大程度就体现在软件开发团队的建设和管理上。软件开发团队是软件项目实施的基础，它直接影响和制约着软件项目管理的最终效果。 一个高效的软件开发团队是高质量软件项目或产品的保证。建设高效的软件开发团队，是实现软件项目管理目标的前提和保证。具体的建设措施有以下六点： 1、选拔或培养适合角色职责的人才 软件项目是由不同角色的人共同协作完成的，每种角色都必须有明确的职责定义，因此选拔和培养适合角色职责的人才是首要的因素。 软件项目开发经理要熟悉各种设计方法，愿意听取其他人的意见，并且要很客观地把自己的思想与其他人的意见相比。此外，还要掌握激发团队成员积极性的方法。 系统分析员要熟悉需要的设计方法，掌握系统分析和设计的原则，要拥有完成职责所需的技能和丰富经验。 选拔或培养适合角色职责的人才，特别是合适的软件开发经理是建设高效软件开发团队的最重要的因素。 2 、增强软件开发经理的领导才能 软件开发经理是项目的负责人，负责整个软件项目的组织、计划及实施的全过程，在项目管理过程中起着关键作用。 增强和发挥指导作用 软件开发经理必须以身作则，严格要求自己，起到榜样和示范作用；要明确具体的软件项目质量、范围、工期、成本等目标约束；明确各软件开发团队成员的角色和责任分工，充分发挥团队成员各自的作用。 充分发挥激励作用 在软件开发过程中，由于严格的目标约束及多变的外部环境，软件开发经理必须运用各种激励理论对软件开发团队的成员进行适时的激励，鼓励和激发团队成员的积极性、主动性，充分发挥团队成员的创造力。 灵活授权，及时决策

软件开发项目团队建设

软件开发项目团队建设 近20 年来，许多新一代的软件技术、过程和方法的发展异常迅速，但软件工业仍然是一个人力密集的过程，离工业化生产方式的差距相当遥远，软件开发人员的素质、技术、能力以及软件开发团队建设的好坏，对软件项目的成败有者举足轻重的作用。为了提高软件开发的效率，提高软件开发的质量，减少软件开发的成本，降低软件开发的风险，就必须加强软件开发人员的管理，建立高效的开发团队。 1 软件开发团队在软件开发中的重要性 软件企业与传统工业企业不同，与现代企业的其他行业也不同。其最主要特征就是，企业最主要的“资产”是一批掌握技术、熟悉业务、懂得管理的“人”。软件企业主要的成本是人的成本，软件企业主要的财富积累是知识和经验的积累。因此，软件企业的人力资源管理，是企业最主要的管理内容。软件项目组的管理过程，几乎全部是围绕“人”来进行的管理。而作为被管理对象的“人”本身管理的讨论，则越来越成为软件领域所要讨论的核心问题。软件项目队伍是项目的基本工作单元，队伍的作用非常重要，是顺利实施项目的基础平台，值得花时间研究，探讨与项目成败的关系，以便更好地组建队伍，最大限度地提高工作效率。软件项目管理的主体是软件开发团队。一个软件项目管理的好坏，很大程度就体现在软件开发团队的建设和管理上。软件开发团队是软件项目实施的基础，它直接影响和制约着软件项目管理的最终效果。软件开团队在软件开发中的作用越来越突出。团队管理非常重要，它是项目顺利进行的基础，对于一个球队来说，要大力培养他们的团队精神，要求队员深刻认识自己球队的特点，团队精神能使球队更具有竞争力，可以打败实力相同而没有团队精神的球队。同理，对于软件项目团队也一样，在开发复杂软件的时候，通常每个人开发不同的部分，运行这些软件的设备又可能

团队的软件项目管理和开发流程

团队的软件项目管理和开发流程 1目的 ●用于指导公司的技术中心软件开发工作 ●定义了各部门与技术部的协作接口和流程 ●定义了项目开发流程和管理办法 ●定义了任务开发流程和管理办法 2说明 2.1 范围 本文档只适用于技术中心针对网站及其相关的一般性开发工作。包括： ●网站维护性开发 ●项目开发 本文档不适用于网站运维护性的系统维护工作。不涉及： ●网站的网络安全、权限等 ●数据库的安全、备份等 ●系统环境等 凡网站运维性的系统维护工作请另参见《运维管理规范》文档。 2.2技术中心组织架构 技术中心组织架构图 技术中心组织架构说明 目前技术中心从处理的工作性质分为三大部分：运维、开发和测试。根据需求工作量的大和小，其中开发的工作又细分为两类： ●网站维护开发 ●网站项目开发 根据网站具体的开发工作内容不同，又可将维护开发组和项目开发组的人员细分前台开发人员和后台开发人员。 各小组的职责范围 ●运维组：处理系统维护性的工作，包括系统安装维护、网络安全、数据库调 优备份等。关于运维的工作本文档不再详细说明，请参见《运维管理规范》文档 ●维护开发组：处理网站的日常小问题的修改、新需求的增加（但工作量不大） 等维护性的开发。 ●项目开发组：处理新项目的开发。 ●测试组：负责对维护开发和项目开发进行测试。

●网站前台开发人员：负责对网站前台的功能进行开发。 ●网站后台开发人员：负责对网站后台的用户管理、权限管理、开发、出票等 后台的功能进行开发。 由于人力资源的限制，目前没有专职的网站维护开发和项目开发，在没有新项目时，所有人员都可安排参与网站维护开发的工作。当有新项目时再组建项目组。但有高优先级的维护工作要处理而又人手不够的情况下，项目组的人员必须优先处理网站维护紧急事件。 2.3项目与任务的定义 什么是开发类项目（项目） 满足以下任意一条件进行开发的项目均为开发类项目： ●以前从未开发过的系统； ●不存在或基本不存在可复用的技术、模块，或业务逻辑、体系结构等或者在原产品上 进行大的结构性调整。 ●在公司已有的成熟产品或可复用模块或技术基础上，根据业务需要和客户需求，新增 独立业务模块，且开发工作量超过1人月，如果是2至3人开发工作但超过2星期根据情况也可划为开发类项目。新彩种、新玩法、新产品的开发等都可以划为开发类项目。（此要求没有硬性要求，可以视情况而定。） 例如：网站二期项目、增加福彩七乐彩、增加快乐十分游戏、足彩单场项目、无线项目、安微客服项目等。 什么是维护类开发（任务） ●在现已运行的网站基础上，根据运营的需要或者市场规划的需要，提供补 丁、实现新的需求 ●工作量通过技术部经理评估小于1人月但超过1个小时的。 例如：页面的调整、促销专题页面，日常运营中发现网站的问题等。 3.需求管理 3.1需求来源 需求来源类型： ●技术部提出 ●运营部（包括客服组）提出 ●市场策划部提出 技术部需求

软件开发团队建设

如何建设优秀的软件开发团队 1.引言 软件开发人员的素质、技术、能力以及软件开发团队建设的好坏，对软件项目的成败有者举足轻重的作用。为了提高软件开发的效率，提高软件开发的质量，减少软件开发的成本，降低软件开发的风险，就必须加强软件开发人员的管理，建立高效的开发团队。 2.团队建设的重要性 软件项目管理的主体是软件开发团队，一个软件项目管理的好坏，很大程度就体现在软件开发团队的建设和管理上。软件开发团队是软件项目实施的基础，它直接影响和制约着软件项目管理的最终效果。建设高效的软件开发团队，是实现软件项目管理目标的前提和保证。 当需要开发复杂软件时，通常要求团队每个人开发不同的部分，运行这些软件的设备又可能来自不同的供应商，而事后将软件的不同模块集成在一起，带来的问题会更多。一个软件模块本身没有问题，但是合在一起却可能不能工作。所有这些都需要一个高效合作的团队来共同完成的，所以建立一支工作效率高的队伍非常重要。 3.优秀开发团队的建设 高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作基础之上的，成员共同迎接挑战，有效地计划、协调和管理各自的工作以至完成明确的目标，高效的开发团队具有如下特征： a)人才选拔与职责分配 软件项目是由不同角色的人共同协作完成的，每种角色都必须有明确的职责定义，因此选拔优秀的人才和分配其合适的职位是首要的因素。团队的能力受限于个人的能力，所以首先要保证优秀的人才资源，具有突出能力的个人往往能带动整个团队的快速发展和成长；然后就是职责的划分，俗话说“好钢是在刀刃上”，为团队成员分配合适的职位往往能起到事半功倍的作用，大大提高团队的开发效率。 b)清晰责任与共同目标 清晰明确的目标会激励团队成员把个人目标升华到群体目标，团队的成员愿意为团队目标做出承诺，共同努力实现目标。明确个人的责任之后，团队的每个成员都十分清楚团队要取得什么样的成就以及由此给团队、给个人带来的益处，他们能将个人目标与项目目标有效地结合起来，会积极地完成工作从而为团队带来高效率的开发，为设计出高质量的软件提供了重要的保证。 c)团队凝聚力 团队凝聚力是无形的精神力量，是将一个团队的成员紧密地联系在一起的看不见的纽带。一般情况下，高团队凝聚力会带来高团队绩效。团队凝聚力在外部表现为成员的团队荣誉感，而团队荣誉感主要来源于项目目标。因此，应当设立较高的项目目标，并使团队成员对项目目标形成统一和强烈的共识，激发成员的团队荣誉感。同时，引导团队成员个人目标与项目目标的统一，增大团队成员对项目团队的向心力，使项目团队走向高效。 d)融洽的关系和良好的沟通 团队成员之间高度信任、相互尊重，既关注工作本身，更珍惜彼此之间的友谊，能够共同营造和谐、宽松、友爱的工作环境，使成员在团队中有一种归属感与自豪感。团队要进行开放性的信息交流与沟通，承认彼此存在差异，鼓励不同的意见，并允许自由地表达出来面对冲突和问题。当遇到问题时能及时交流共同商讨解决问题的方案，并

关于软件团队建设

关于技术团队建设 通过最近几年的实践，对于软件开发的最小团队模式，有一些新的理解，和大家共享： ?很多团队，公司在成本压力下，总是希望寻求一个最经济有效的团队组合，这个是可以理解的，也是开发的初衷。 ?最小团队不是指单纯的减少人员，不是把一个需要5个人做的工作压缩为1个人做。 ?软件开发本身存在一个众所周知的弊病，就是只要存在一个能够编码的技术人员，那么软件就总是能够“做”的出来，这也给人一个假象，软件开发的最小团队就是一定数量的“码农”；这个在其他领域比如建筑和制造几乎是不可想象的，究其根源，是因为软件的质量标准过于的飘渺：我的意思是，最小团队绝不是几个“码农”。 ?人员可以合并，但角色不能合并；职能可以合并，但能力不能合并: 换言之,担什么角色就必须能做什么事情,就必须具备相应的能力. 总之,我对最小团队的看法,最小团队就是最少的角色,而这些角色不能再削减,但人员还是可以以兼任的 方式来合并角色,不过在兼任过程中要注意不能有名无实,同时需要具备胜任该角色的能力. 三要素 软件时开发的三个基本要素是：管理，业务和技术。 管理：除完全以单人方式进行的开发不在本文讨论的范围，2人以上就存在一定的团队管理，人员的协调，工作的安排，流程的部署，进度的监督等等，加上必然存在的客户管理，“鸟无头不飞”，说的就是管理者的必要性。 业务：很简单，软件做了半天是为什么而做，产生什么效益和结果，这个都需要业务来完成，业务来自于需求，深化为设计，由测试加以验证, 最后接受者是客户。 技术：更容易理解，没技术能叫软件开发？软件开发首先是技术活，但广义上来说，需求分析，系统设计和开发管理这些也都属于技术的范畴，只要需要方法论的地方就需要技术。 所以做软件先考虑其三大要素，是管理是否成熟，业务是否明确，技术是否过硬，就能知道软件是否能够顺利完成。 角色 下面我们从3个基本要素的基础上讨论下，探讨下我心目中的最少角色。 ?管理体系 n 项目经理：兼顾客户管理和团队管理2大职责，在小团队中，这两种管理几乎不可能再拆分。 ?业务体系

强势的软件研发团队组建

强势团队人员需求及描述 团队中包含：研发部经理（即技术总监）、leader、项目经理、项目助理、系统分析、框架设计、产品经理、高级软件工程师（主程）、初级软件工程师（辅程）、UI设计、美工、DBA测试工程师、实施工程师等，他们的大致职责描述如下。 1. 研发部经理（技术总监） 对系统方向和团队中一些决策性的事进行管理，包括日常事务，虽然他不需要编码，但能担 任技术总监，他经历了设计开发，产品的实施，并对系统的战略性发展都有相当的见解，对整个系统的所有流程都面面具道，不单单局限于技术层面，因为他需要主导整个团队运作。 可以跟客户交流需求、根据需求分派任务。 2. Leader 管理项目组成员、技术难点分析，编写详细设计文档，技能特色很突出，有创新能力，不是什么都是从网上拿下来一改就用的，其它方面都可以讲出一二，对行业内的动态都很关注，有一定的交际能力。可以跟客户交流需求。 3. 项目经理 项目经理负责分配资源，确定优先级，协调与客户和用户之间的交往。总而言之，就是尽量 使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完 整性和质量。懂开发，知识面广，针对项目，对系统进度的控制，风险评估进有把控，根据反馈的客户需求，分派具体工作内容，项目中日常事务调配，人员配置，具有一定的的沟通 能力。可以跟客户交流需求。 1

3.1 项目助理 对会议、文档、日常事务的跟踪进行管理，这不只是助理一职，这个职务在整个项目中，启着至关重要的位置，她贯穿于团队中每个职务之中，其它职务是针，她就是一根线，她可以对项目中每个人的工作进度监控、总结和传达任务。 4. 系统分析、框架设计 对系统进行构架设计、技术评估、开发环境，编写概要设计文档与设计规范文档，对各类技术点进行分析，要求技术全面，并掌握熟练，有丰富的项目经验，在各种环境下，给出最佳的解决方案。①业务分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何交互。通过描述一个或几个用例的需求状况以及其他支持软件的需求来获取系统功能某一部分的规约。还要负责用例包并维护该用例包的完整性。②构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口。因此，与其它角色相比，构架设计师的见解重在广度，而不是深度。 5. 产品经理 对系统功能需求分析、用户体验设计，编写需求文档，如果我们接到任务，我们的产品需要做哪些功能，产品经理必须给出需求，将功能项目实际的列举出来，不但要知道自己做什么样的东西，还要了解我们做出来怎么用，分析产品在实际运营中的一些需求，制定项目的功能开发阶段，现在一般的开发团队中还没有这个职位，其实这个职位对一个产品的好坏影响很大，我们在产品开发完成后，常常遇到一个问题，就是产品刚出来就感觉已经落后了。 6. 高级软件工程师(主程) 软件工程师负责完成设计师的设计意图，根据设计文档编写代码；根据设计文档编写单元测试代码，根据测试报告BUG己录修订BUG完成包或子系统的开发。熟练相关开发技术例如：JAVA, C#(.net) ，C++,C,汇编，3D方面等，负责项目的核心模块开发，编写模块设计文档，不需要培训就可以直接进入开发状态，是团队模块开发引领者和衔接者，一般经历过几个项目的人都可以担当。 7. 初级软件工程师(辅程) 懂java, C#(.net) ，C++，C能开发一些简单的模块，在技术上需要提高，现在大部程序员都喜欢写后台代码，逻辑思维强，写服务、API 代码比较好，做小型项目外包都没问题。 8. UI 设计、美工 界面设计人员通过以下方法来领导和协调Web 界面的原型设计和正式设计：获取对Web 界面的需求（包

构建高效软件开发流程和团队

构建高效软件开发流程和团队 1.前言 (2) 2.项目计划 (2) 3.开发文档 (3) 4.编写代码 (4) 5.代码管理 (4) 6.测试 (4) 7.BUG管理 (5) 8.Code Freeze (6) 9.Tech Talk (6) 10.Code Review (6) 11.沟通与交流 (7) 12.后记 (7) 1.前言 本人曾就职于多家公司，但留给我印象最深刻、开发管理最规范的公司是I 公司。该公司总部位于美国硅谷，其开发的产品曾获得PC Magazine的最高五星级的优秀好评。现我根据在此公司中所感受到的经历及自身的一些感想写出来，希望能给大家和其它公司有所借鉴。 2.项目计划 在一个产品发布并使用之后，其中肯定有许多地方不如意和值得改进的地方。客户在使用的过程中会发现一些问题，提出更高的需求，市场也在发生变化，我们的竞争对手也在发展，新的技术不断地产生，这些因素推动着我们的产品不断地向前发展，使它的版本不停地往上增长。这些发展的需求不是一下子提出来的，在客户使用的过程中发现某些不如意不方便的地方，他们会向我们的技术支持人员提意见，而技术支持人员会把这些需求以BUG的形式存入BUG数据库中，其级别一般定义为下一个版本的Feature。有些上一个版本未解决的BUG也可能需要在本版本中来解决。因此当我们来开发下一个版本时，其许多特性已经存在

于BUG数据库中了。当然新版本的特性不是只从BUG中获得，管理层可能从市场的角度来提出新的特性以求领先竞争对手，开发人员本身也可提出某些要求来纳入新版本开发的计划中，如要求对某部分代码进行重构以使其结构更清晰更容易维护，执行效率更高。 每个人把同自己相关的功能模块收集起来，同时预估时间，其中主要包括写文档的时间、开发时间和单元测试的时间，一般要求精确到工作日。这些信息发送给组长，组长再把本小组人员的任务和预估时间发送给管理层，由管理层对此任务及进度进行评估审核，管理层会根据产品发布时间及客户需求、市场因素等方面作出选择，可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同预计的产品发布时间有较大冲突，而且此功能是本版本中必须得做的，则开发小组会被要求重新预估时间，加快开发速度来达到这个要求。 虽然这个开发进度时间是一个大概的估计时间，但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个Status Meeting（一般那时工作效率较低，适合开会），在此会议上我们会根据这个进度来review我们的工作，每个人手上的工作是否按照这个进度在走，是否有人延后了，是否block住别人的工作了。在此会议上每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个会议，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后，如果有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上，那也没有办法，只能修改原先的进度表，因为那是我们的估计与现实发生了偏差，我们必须使我们的进度表符合实际情况，这可以避免许多项目发生最后的20%的工作量会占据80%甚至一直拖后的情况。修改进度表的情况我们曾经发生过，有一次在按照原先的进度执行到将要完成的状态时突然接到通知由于市场及客户的原因要求加入另一项重大的功能，这个功能对我们程序的结构有非常大的影响，因此我们就要重新制定一个进度来满足需求。在这种情况下，产品原先的开发进度被打乱，发布时间也因此推迟。当然这种情况应当尽力避免，尤其在项目后期产生新的需求，若不得已也应重新规划进度，而不是仍旧依照原先的进度去执行，因为老的进度已不能反映现实的情况。 3.开发文档 在项目进度安排中我们已经把写文档的时间也规划进去了，这里虽然是写文档，其实是设计程序，整理一下思路与架构，磨刀不误砍柴工，这样在实际写代码时会流畅很多，节省时间，因此可以说真正有思想性的东西都在写文档这段时间内完成了。当然我们这里的文档格式不象ISO那样规定了条条框框，我们的文档格式相对自由，基本上能随意发挥，但对于几个主要点一般来说是需要说明的。要求写的文档能让他人比较容易地看明白，能把问题讲清楚，能反映你的设计思想。文档的数量也不多，开发文档有两类，一类是Function Spec，另一类是Design Document。 Function Spec中需要写明的是本模块完成的任务，解决什么问题，有什么作用，为什么要这些功能，此外我们还会添加进适用范围，有什么不足，注意点是什么，还有哪些地方在以后可以进行改进。在这个Function Spec中不涉及到任何非常详细的算法。此文档不光给开发人员看，还让QA及其他成员以及后来

ERP项目实施中的团队建设

ERP工程实施中的团队建设 有很多关心ERP或正准备实施ERP的朋友都会问这么一个问题：“到底怎样才能成功地实施ERP工程呢？其中有哪些关键要素呢？”这的确是一个很大的话题，可能三天三夜都细说不完。其中包括诸如工程“一把手”工程、高效先进的实施方法、明确的实施目标与范围、有效的计划控制与时间管理、不断进行阶段性工作总结、必要的风险控制与应急措施等等大家比较熟知的内容。但其实还有一点尤为重要，却也非常容易被忽视的一个因素就是人——工程的团队建设。我们知道，在一个企业中，参与到ERP工程实施的成员都是由各个相关部门的关键人员共同组成，而这样一支由不同业务部门、不同业务背景、不同素质的人共同搭建的临时队伍怎样才能在共同认同一个工程目标、一个工程的工作方式的前提下，按照紧迫的工程实施计划共同完成好艰巨的ERP建设任务呢？这也正是ERP工程的团队建设的重要性，它也将从很大程度决定工程实施在多大程度上的成功。 企业ERP系统是通过信息技术这一手段把优秀的、规范的管理固化下来，同时也通过信息技术的革新带动管理的进一步优化。在这其中，信息技术与企业管理是有机结合的，并相辅相成，进而达到合理配置企业资源、降低成本、提高生产效率，最终加强企业的核心竞争力，以实现利润最大化。那么ERP工程的实施必然会涉及到企业管理的方方面面，譬如：销售管理、财务核算管理、采购管理、存货管理、生产管理、人事管理、成本管理等等。而这些管理又是通过企业的各个组织单元或各个部门互相协同来完成的。即，企业实施ERP工程绝不是企业信息技术部门可以独立完成的，它必须是由企业实行各项管理职能的相关部门与企业IT部门共同来完成的。这也是为什么人们总是说“ERP工程是一把手工程，ERP工程需要企业各相关部门的共同参与”的缘由了。其实，说到底这就是一个围绕着人的话题。一切以人为本！ 考核与激励并存 一般而言，ERP工程实施的参与者，除了IT人员外，其他人员一定是自身的岗位工作与工程工作齐头并进的。于是关键问题就在于，如何保证这些人能对工程工作非常投入而且保证工程工作的顺利开展。这就必须要将其所担负的工程工作纳入到其绩效考核中去，让他意识到工程工作并不是可有可无的，是与其本职工作同等重要的。工程工作完成的好坏也是直接与其个人收益挂钩。但光有考核也是不行的，这样只会对实施者产生被动无奈甚至抱怨的感觉，如果工作量超负荷实施者很容易造成破罐破摔的心理。因此，还需要有激励的手段，如：高层领导直接关注、单独设立工程奖励基金、升职、延长带薪休假、给予培训深造的机会等等，这些手段的运用会很好地激发实施者的工作热情与上进心。这样，实施者就会从被动无奈中转变成主动投入，而且将会对工作发挥创造性作用，如果这方面进展得较为顺利，那么这支队伍已具备了一个良好的基础环境。 增强团队凝聚力与个人成就感 ERP工程组毕竟是一个临时搭建的组织，它只为工程目标而存在，因而不可能成为一个长期的部门，因此，参加ERP工程实施的人员对工程组明显缺乏归属感。又由于ERP工程的实施存在着许许多多“知与行”的矛盾，甚至有的工作将会反复，每个参与实施的人都可能随时遇到挫折，如果这样的情绪不及时进行调整，在队伍中弥漫，工程实施可以说是“风中之烛”，有随时熄灭的危险。如果发现这支队伍中有这样的问题，需要及时进行调整，沟通思想、组织活动，拉近人与人之间的距离。譬如说利用业余时间开个沟通会或者组织去户外进行集体游玩，

软件研发部岗位职责

技术部门岗位职责2 软件研发部 2.1 部门职责 1.应用软件开发方向规划; 2.应用软件开发工具选购; 3.软件系统整体方案规划; 4.应用软件系统开发设计; 5.软件系统测试规划实施; 6.应用软件系统项目评审; 7.应用软件项目疑难问题处理; 8.应用软件疑难故障分析处理; 9.软件人力资源组织/考评; 10.应用软件开发团队组织; 11.应用软件工程师集训学习; 12.应用软件体系框架设计与定制; 13.应用软件技术积累与探索; 14.应用软件开发技术规范编制; 15.应用软件的技术资料管理; 16.应用软件知识产权等相关文档编制; 17.应用软件的鉴定、认证； 18.应用软件的质量体系认证。

2.2 部门经理职责 1.全面负责软件研发部日常管理工作； 2.规范软件体系设计，监督相应的设计开发过程； 3.负责建立软件系统资源库，实现资源重用； 4.负责软件研发团队建设和技术人员的招聘、培养与考评； 5.制定和落实部门项目研发开发计划，总体掌握研发进度。 6.确定软件部技术研究方向，组织人员对关键技术进行攻关和积累； 7.指导/评审/公司项目软件部分的开发活动； 8.解决公司产品线中相关的技术难题，提供技术支持； 9.统筹协调软件研发部与其它部门的关系； 10.负责相关技术资料的整理； 11.负责相关知识产权等技术文档编制； 12.完成公司交办的其它工作。 2.3 部门副经理职责 1.协助经理完成日常管理工作; 2.完成分管的方面技术工作； 3.经理不在时，代经理处理部门事务； 4.按计划推进自己负责项目的实施； 5.参与指导/评审/公司项目应用软件部分的开发活动； 6.协助经理进行团队建设、人员培养和考评； 7.负责相关技术领域的技术积累和整理；

软件开发团队建设的思路探讨

龙源期刊网 https://www.wendangku.net/doc/2b17270560.html, 软件开发团队建设的思路探讨 作者：黄龙洋 来源：《硅谷》2015年第01期 摘要随着信息时代的到来，软件被广泛应用在各种生产、管理领域，极大的提高了工作效率以及我国各个行业的信息化水平，因此，我国非常重视软件开发工作，并投入了大量的人力、物力与财力，一定程度上推动了我国软件产业的快速发展。在软件开发过程中，加强团队建设可提高软件开发效率，缩短软件开发周期，因此，本文对软件开发团队建设思路进行探讨，以期为提高软件开发水平，规范软件开发流程提供有效的参考。 关键词软件开发；团队建设；思路 中图分类号：F4 文献标识码：A 文章编号：1671-7597（2015）01-0181-02 调查发现，部分企业开发软件过程中不重视团队建设，导致软件开发效率低下，无形之中增加了软件开发成本，不利于企业的长远发展。因此，企业开发软件之前应将团队建设当做重要工作去抓，为软件开发工作的高效进行奠定坚实的基础。笔者结合多年软件开发实践经验，探讨软件开发中团队建设的思路。 1 软件开发中团队建设的重要性分析 软件开发涉及很多专业内容，部分内容比较繁琐而且工作量比较大，靠个人完成功能强大软件的开发几乎是不可能的，因此，需要团队成员间的相互协作，共同完成软件的开发。 团队建设在软件开发工作中的重要性不言而喻，原因在于：团队成员协作可显著提高软件开发效率，尤其在明确各成员开发任务后，各成员各自完成代码编写任务，避免彼此间的干扰，确保软件各模块编写有条不紊的进行。同时，团队协作有助于攻坚克难。软件开发过程中难免会遇到一些困难，团队成员共同探讨、积极寻找积极措施，依靠大家的力量，使解决问题的效率大大提高。另外，团队开发软件时，可形成互帮互助的良好氛围，而且，团队成员在和谐、轻松的环境中完成软件的开发，错误出现的机率会大大减少，提高软件开发效率与质量。 2 软件开发中团队建设思路 为确保软件开发工作的高效进行，软件开发工作正式实施前应建立一支高效率、高素质的团队，并确保团队与客户以及团队成员间能够进行良好的沟通，确保设计人员能够充分理解客户需求，编码人员能够准确体会设计人员的意图，最终确保软件开发工作的顺利进行。那么软件实际开发过程中团队建设究竟应注意哪些问题呢？接下来逐一进行详细的探讨。 1）组建团队，明确规范。

强势的软件研发团队组建

一、强势团队人员需求及描述 团队中包含：研发部经理（即技术总监）、leader、项目经理、项目助理、系统分析、框架设计、产品经理、高级软件工程师（主程）、初级软件工程师（辅程）、UI设计、美工、 1.研发部经理（技术总监） 对系统方向和团队中一些决策性的事进行管理，包括日常事务，虽然他不需要编码，但能担任技术总监，他经历了设计开发，产品的实施，并对系统的战略性发展都有相当的见解，对整个系统的所有流程都面面具道，不单单局限于技术层面，因为他需要主导整个团队运作。可以跟客户交流需求、根据需求分派任务。 2.Leader 管理项目组成员、技术难点分析，编写详细设计文档，技能特色很突出，有创新能力，不是什么都是从网上拿下来一改就用的，其它方面都可以讲出一二，对行业内的动态都很关注，有一定的交际能力。可以跟客户交流需求。 3.项目经理 项目经理负责分配资源，确定优先级，协调与客户和用户之间的交往。总而言之，就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。懂开发，知识面广，针对项目，对系统进度的控制，风险评估进有把控，根据反馈的客户需求，分派具体工作内容，项目中日常事务调配，人员配置，具有一定的的沟通能力。可以跟客户交流需求。

3.1项目助理 对会议、文档、日常事务的跟踪进行管理，这不只是助理一职，这个职务在整个项目中，启着至关重要的位置，她贯穿于团队中每个职务之中，其它职务是针，她就是一根线，她可以对项目中每个人的工作进度监控、总结和传达任务。 4.系统分析、框架设计 对系统进行构架设计、技术评估、开发环境，编写概要设计文档与设计规范文档，对各类技术点进行分析，要求技术全面，并掌握熟练，有丰富的项目经验，在各种环境下，给出最佳的解决方案。①业务分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何交互。通过描述一个或几个用例的需求状况以及其他支持软件的需求来获取系统功能某一部分的规约。还要负责用例包并维护该用例包的完整性。②构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口。因此，与其它角色相比，构架设计师的见解重在广度，而不是深度。 5.产品经理 对系统功能需求分析、用户体验设计，编写需求文档，如果我们接到任务，我们的产品需要做哪些功能，产品经理必须给出需求，将功能项目实际的列举出来，不但要知道自己做什么样的东西，还要了解我们做出来怎么用，分析产品在实际运营中的一些需求，制定项目的功能开发阶段，现在一般的开发团队中还没有这个职位，其实这个职位对一个产品的好坏影响很大，我们在产品开发完成后，常常遇到一个问题，就是产品刚出来就感觉已经落后了。 6.高级软件工程师（主程） 软件工程师负责完成设计师的设计意图，根据设计文档编写代码；根据设计文档编写单元测试代码，根据测试报告BUG记录修订BUG，完成包或子系统的开发。熟练相关开发技术例如：JAVA, C#(.net)，C++,C,汇编，3D方面等，负责项目的核心模块开发，编写模块设计文档，不需要培训就可以直接进入开发状态，是团队模块开发引领者和衔接者，一般经历过几个项目的人都可以担当。 7.初级软件工程师(辅程) 懂java, C#(.net)，C++，C能开发一些简单的模块，在技术上需要提高，现在大部程序员都喜欢写后台代码，逻辑思维强，写服务、API代码比较好，做小型项目外包都没问题。

技术研发团队建设方案

技术研发团队建设方案 关于技术研发团队建设方案大家了解过多少呢？可能很多人都不是很清楚，下面就是XX分享的技术研发团队建设方案范文，一起来看一下吧。 组建一支以Java 技术为主导的研发团队。 由于之前的研发团队，没有根据CMMI 的标准流程进行软件研发，导致开发出的产品不能满足客户的需求，从而给 公司造成不可挽回的损失。 现要求组建一支严格按照CMMI 标准流程规范执行的软件研发团队，同时产出高品质的软件产品。 总目标：组建一支高效的并严格遵守CMMI标准的软件研发团队。 形成阶段：在六月初，能够形成一个5~6人的队伍，并完成组建的初期相关工作。具体工作包括： 1.与王总讨论并确定团队要求 ①确定主要技术方向，及与技术总监的合作方式。 ②明确组建团队的目的。 ③确定组织架构。 2.招募人员组成核心组①提供人员职责及岗位需求给HR ②面试符合要求的应聘者 3.定义团队的工作范围及目标 ①确定团队日常工作的来源？

②上下游部门的协作方式？ ③团队主要工作的input及output？ 4.人员技能识别 规范阶段：六月初到八月初这段时间，争取完成团队 从形成处的振荡到规范的一个过程。具体工作： 1.确定团队运作指南 ①确定软件研发流程②日常工作规范③团队愿景④团队文化⑤管理理念 ⑥软件开发品质政策 2.团队培训 ①根据CMMI 思想进行软件研发流程培训②相关技术培训 3.定义成员角色和职责①让团队成员明确自己的角色，并确认自己的工作范围。②明确自己工作的输入是什 么输出是什么？③每个角色之间的衔接及合作方式。 4.确定人员绩效考核方式。 产出阶段： 八月份之后，在规范的基础上进一步的改进流程，引入 相应的管理机制。 1.评估团队 2.流程的改进包括：引入bug管理机制。 引入SDP项目进度管理系统。 引入CodeReview机制进行代码品质保障。 部门日常管理的信息化。 3.软件开发项目管理 4.业绩

硬件部团队建设方案(嵌入式组)

硬件部嵌入式团队建设方案(初稿) 一、调试软件 目前各类调试软件众多，Delphi，C#，QT等语言开发的皆有。为了后续调试软件的维护及知识储备，调试软件现在须向QT靠拢。 1)QT4.5以后增加了LGPL许可，因此不存在版权风险。 2)QT基于界面组件开发，开发快、难度小，也能满足调试软件的开发需求。 3)QT具备良好的跨平台性，以后的产品也可能采用QT来做GUI，调试软件 采用QT也算是为做后续的技术储备。 二、开发规范 目前CPU选型已做规范，在高端系列、通用系列以及低端系列都提供了选型范围，因此相应的嵌入式软件也要有相应规范。 ◆开发工具 1)MCU已提供配套的开发套件时，可选用MCU厂商提供的开发套件。 2)与MCU平台无紧密关系时，推荐使用eclipse。 ◆开发语言 1)常规情况下采用C/C++作为首选开发语言。 2)特殊应用场景，采用其他小众语言需经过硬件部团队建设推进小组评审。 ◆支撑工具 1)IDE应集成SVN插件，代码置于SVN工作副本内。 2)推广使用代码静态分析工具、代码格式化工具及文档生成工具。

◆过程规范 1)代码风格应统一，代码须具备一定的注释量。 2)各节点须输出相应的过程文档。 3)软件质量(checklist)、风险及技术部门内部评审。 三、知识体系建设 知识体系建设在培养新人、团队沉淀以及提升开发速度、质量方面具有重要意义，也有利于个人及团队的长远发展。硬件部嵌入式团队知识系统建设主要分为应用层面、系统层面、平台层面及经验库等方面。 ◆应用层面 1)字符串匹配(正则)，JSON、XML等数据交换格式及IO API封装等。 2)嵌入式数据库(Sqlite等)。 3)协议开发指导文档及例程(TCP/IP、Modbus、Bacnet、自定义协议等)。 4)编码思想、软件架构、校验算法、日志系统等。 ◆系统层面 1)操作系统驱动框架(Linux、Ucos)。 2)常见外设驱动(LCD、RF、RS485、IIC、SPI等)。 3)Bootload、kernel、filesystem等。 ◆平台层面 1)STM 32 系列开发指导、经验教训及开发组件(库)输出。 2)Freescale MKL系列开发指导、经验教训及开发组件(库)输出。 3)STM8 MSP430 系列开发指导、经验教训及开发组件(库)输出。 ◆经验&教训库

敏捷团队建设

敏捷团队建设 --明阳天下拓展培训最近很多人都问我，有没有适合的人可以推荐给他们公司，他们正在招人，面试了很多个，但有经验的开发人员太难找了。有一个朋友在问我要人的同时，他手下的一个开发人员反而问我有没有好的机会，他想跳槽。 不久前一份报告称，中国本地软件企业面临的最大问题之一，就是高级技术人才的缺乏。造成这种问题的原因，主要是由于本地软件企业的人才培养机制和管理机制的欠缺。人才大量涌入外资企业和频繁的流动，导致了各类有经验人才的欠缺。 每个人都会梦想自己的理想工作。做技术的开发人员要求的更是简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。这些东西，很多时候就是一个人决定离职的因素。 有的公司认为开发团队是成本中心，所以给他们买最便宜的桌椅——而恰恰是开发人员们一天都依赖于这样的桌椅为公司创造价值；有的公司觉得自己的一套软件不停的实施就能不停盈利——而开发人员最厌烦的就是做重复性工作；有的公司要求开发人员必须上班打卡——好的，那开发人员绝对不会晚下班一分钟。有的公司从来不举行内部的技术交流和培训活动——而开发人员希望的技术提高绝不仅仅是只靠读书能够完成的。

公司要依靠软件来盈利。而要开发一个成功的软件项目，人的作用是第一位的。而个人的力量相对于整个团队来说，又是微不足道的。稍微有点规模项目的成功都是集体努力的结果，而不是靠一两个英雄程序员能够完成的。为了能够保持一个稳定和高效的团队，建设一个吸引开发人员的环境和氛围是所有公司的管理人员们应该考虑的一件事。一个核心的产品开发人员离职，很可能使得当前的项目或订单陷入瘫痪，这目前已经成为了影响许多中小公司存亡的大事。 我所在的公司不仅仅以敏捷过程著称，同时，它以其特有的文化和团队氛围吸引了一大批高水平的开发人员。他们不仅仅是认同敏捷而聚在一起，更多的是，他们向往着这种平等、自由、轻松、快乐的空气。 人与团队 在公司一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在公司内部，人与人之间是完全平等没有级别区分的。这种平等的文化，就使得人与人之间的交流不会因为等级差距而丧失。同时公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。 项目成功的一个重要因素就是交流。保障团队内外顺利交流是项

科技创新团队建设方案

科技创新团队建设方案 一、明确科技创新团队定义 团队是指有一定的互补技能,愿意为了共同的目标相互协作的个 体所组成的正式群体.科技创新团队是以学科领军人物为核心,以科 研骨干为主体,专业人才和科研辅助人员相配套,优势互补、团结协作,稳定从事基础研究、应用研究、高新技术研究、关键技术攻关、 技术集成与示范推广等的紧密型创新研究群体. 二、创新团队的特点 有引领学科发展的领军人才.一个优秀的科技创新团队必然要有 一个领军人物,这个领军人物必须具有较强的战略思维能力、学科透 视与把握能力、组织协调能力和合作精神,具有良好的学术道德和社 会责任感,能够发挥较强的凝聚和领衔作用,并已经取得优秀业绩或 具有明显的创新潜力. 有明确稳定的研究目标团队.要有明确的研究目标和相对稳定的 研究方向,要紧密围绕国家发展战略需求和国家中长期科技发展规划、区域经济发展战略和转型升级的需要,开展基础、应用和高新技术及 产业化研究等. 有较为深厚的学术积累.有良好的科研工作基础和发展潜力,以重大科研项目为载体,已经或能够获得重大科技成果和学术成就. 有结构合理的学术梯队.团队内部具有合理的专业知识结构、职 称结构、学历结构和年龄结构,甚至包括个性结构,能够保持持续的 创新活力和发展能力. 有良好的文化氛围和团队精神.团队内部具有和谐的氛围,能够进行知识交流和有效沟通,同时团队成员具有以淡泊个人名利为主的协 作精神.

宁波市2010年开始开展科技创新团队的建设工作.目前,宁波市科技创新团队分为二个层次:第一层次创新团队和第二层次创新团队.从今年评审情况看,第一层次主要是高校研究单位. “十二五”期间,我市力争培育建设30个左右创新人才集聚,产学研紧密结合,具有综合性科技攻关、攻克关键共性技术难题、开发战略性产品、培养中青年创新人才能力,并在我市产业转型升级中发挥重要作用的企业重点科技创新团队 三、创新团队建设的核心内容 1、依托单位（申报单位） 从重点企业中遴选（重点从高新技术企业、科技型企业及省、宁波市及本市工程技术中心中培育）；鼓励企业与高校科研机构开展 科技合作.依托企业有行之有效的管理制度并能提供持续的经费保障、. 2、团队组成 创新团队人员:首席专家（或带头人）、核心人员、其它人员,创新团队规模:创新团队应具备合理的人才规模和结构.从事研究开发 的工程技术人员应在8人以上,且来自企业的成员不少于二分之一；有合理的专业和年龄结构. 首席专家（职称、学术水平、组织协调能力、年龄）:创新团队首席专家应具备履职所需的良好素质、在科研一线工作,有较高的学术造诣；有良好的政治素质和较强的组织协调能力；有充沛的精力 领导团队开展工作；身体健康,年龄一般不超过65周岁. 核心成员:核心成员应具有副高以上职称或硕士以上学历,是各级政府科技进步奖获奖成果或发明专利的主要完成人； 其它人员:半数以上成员应具有中级以上专业技术资格或三分之二以上人员具有大学毕业学历；团队成员学科交叉、专业多样、能 力互补,无侵犯他人知识产权等科研不端行为. 3、创新能力

软件开发项目团队建设

软件开发项目团队建设 近 20 年来，许多新一代的软件技术、过程和方法的发展异常迅速，但软件工业仍然是一个人力密集的过程，离工业化生产方式的差距相当遥远，软件开发人员的素质、技术、能力以及软件开发团队建设的好坏，对软件项目的成败有者举足轻重的作用。为了提高软件开发的效率，提高软件开发的质量，减少软件开发的成本，降低软件开发的风险，就必须加强软件开发人员的管理，建立高效的开发团队。 1 软件开发团队在软件开发中的重要性 软件企业与传统工业企业不同，与现代企业的其他行业也不同。其最主要特征就是，企业最主要的“资产”是一批掌握技术、熟悉业务、懂得管理的“人”。软件企业主要的成本是人的成本，软件企业主要的财富积累是知识和经验的积累。因此，软件企业的人力资源管理，是企业最主要的管理内容。软件项目组的管理过程，几乎全部是围绕“人”来进行的管理。而作为被管理对象的“人”本身管理的讨论，则越来越成为软件领域所要讨论的核心问题。软件项目队伍是项目的基本工作单元，队伍的作用非常重要，是顺利实施项目的基础平台，值得花时间研究，探讨与项目成败的关系，以便更好地组建队伍，最大限度地提高工作效率。软件项目管理的主体是软件开发团队。一个软件项目管理的好坏，很大程度就体现在软件开发团队的建设和管理上。软件开发团队是软件项目实施的基础，它直接影响和制约着软件项目管理的最终效果。软件开团队在软件开发中的作用越来越突出。团队管理非常重要，它是项目顺利进行的基础，对于一个球队来说，要大力培养他们的团队精神，要求队员深刻认识自己球队的特点，团队精神能使球队更具有竞争力，可以打败实力相同而没有团队精神的球队。同理，对于软件项目团队也一样，在开发复杂软件的时候，通常每个人开发不同的部分，运行这些软件的设备又可能来自不同的供应商，而事后将软件的不同模块集成在一起，带来的问题会更多。一个软件模块本身没有问题，但是合在一起却可能不能工作。所有这些都需要一个高效合作的团队来共同完成的，所以建立一支工作效率高的队伍非常重要。 2 软件开发团队的建设内容 高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作基础之上的，成员共同迎接挑战，有效地计划、协调和管理各自的工作以至完成明确的目标，高效的开发团队具有如下特征： （1）具有明确清晰的共同目标。高效的开发团队对要达到的目标有清楚的理解，并知道目标的重大意义和价值。清晰明确的目标会激励团队成员把个人目标升华到群体目标，团队的成员愿意为团队目标做出承诺，共同努力实现目标。项目经理及团队成员对于实施什么样的项目；为什么要实施这样的项目；团队的工作范围有哪些；实施项目的主要目标，包括时间要求、成本指标、质量性能参数等；完成项目的重要交付成果及其衡量标准，以及实施项目的制约因素及假设前提等问题有着共同的认识与一致的理解。有了明确清晰的目标，团队的每个成员都十分清楚团队要取得什么样的成就以及由此给团队、给个人带来的益处，他们能将个人目标与项目目标有效地结合起来，会积极地完成工作从而为团队带来高效率的开发，为设计出高质量的软件提供了重要的保证。项目团队参与充分的策划活动，对于如何实现项目的目标，包括采取的步骤，应用的工具、