大中小构建高效软件开发流程和团队模板.doc

大中小构建高效软件开发步骤和团体

在一个产品公布并使用以后，其中肯定有很多地方不如意和值得改善地方。用户在使用过程中会发觉部分问题，提出更高需求，市场也在发生改变，我们竞争对手也在发展，新技术不停地产生，这些原因推进着我们产品不停地向前发展，使它版本不停地往上增加。这些发展需求不是一下子提出来，在用户使用过程中发觉一些不如意不方便地方，她们会向我们技术支持人员提意见，而技术支持人员会把这些需求以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，它们分别代表了关键性及紧急程度，P1BUG需要很快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放量攀升，后期震荡下挫，若到了后期新openBUG数量一直上升则说明风险在增大，有可能无法控制，也就是说fix了一个BUG造成了多个新BUG产生。在量化开发进度中也能够用代码数量曲线图来粗略展现。在有大量新功效增加时可能代码量增加会较快，当在fix bug阶段，代码修改较多，所以代码数量增幅会降低，依据代码量能够看出开发情况处于何种阶段。  

    需要指出是我们对BUG定义比较广泛，部分新功效也能够作为BUG被提出，只不过这些BUG等级比较低，让它们进入到下一个版本中去实现。所以BUG创建者也能够是技术支持人员、市场人员甚至开发人员本身。相关开发人员本身，因为她可能会找出部分BUG，有些是其它开发者，有些可能是此开发者本身，把这个BUG添加进BUG库中能够帮助开发人员在以后产生新问题时或类似BUG时有一个借鉴和思绪，但此BUGverify必需要让测试本模块测试人员来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企业越来越壮大，逐步走向成功！也衷心地祝福我同事们幸福愉快！