构建高效软件Software开发流程和团队(Team)1. 前言本人曾就职于多家公司
但留给我印象最深刻、开发管理最规范标准
公司是I公司
该公司总部位于美国硅谷其开发产品曾获得PC Magazine最高 5星级优秀好评现我根据在此公司中所感受到经历及自身
些感想写出来希望能给大家和其它公司有所借鉴2. 项目计划在
个产品发布并使用的后其中肯定有许多地方不如意和值得改进地方客户在使用过程中会发现些问题提出更高需求市场也在发生变化我们竞争对手也在发展新技术不断地产生这些原因推动着我们产品不断地向前发展使它版本不停地往上增长这些发展需求不是下子提出来在客户使用过程中发现某些不如意不方便地方他们会向我们技术支持人员提意见而技术支持人员会把这些需求以BUG形式存入BUG数据库中其级别般定义为下个版本Feature.有些上个版本未解决BUG也可能需要在本版本中来解决因此当我们来开发下个版本时其许多特性已经存在于BUG数据库中了当然新版本特性不是只从BUG中获得管理层可能从市场角度来提出新特性以求领先竞争对手开发人员本身也可提出某些要求来纳入新版本开发计划中如要求对某部分代码进行重构以使其结构更清晰更容易维护执行效率更高每个人把同自己相关
功能模块收集起来同时预估时间其中主要包括写文档时间、开发时间和单元测试时间般要求精确到工作日这些信息发送给组长组长再把本小组人员任务和预估时间发送给管理层由管理层对此任务及进度进行评估审核管理层会根据产品发布时间及客户需求、市场原因等方面作出选择可能某些功能由于时间紧急会被推迟到下个版本中去若预估出来时间同预计产品发布时间有较大冲突而且此功能是本版本中必须得做则开发小组会被要求重新预估时间加快开发速度来达到这个要求虽然这个开发进度时间是
个大概估计时间但我们要尽力按照这个开发进度来执行每个星期 5下午我们有个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 Ver
y Test)测试通不过有些代码没有完全完成而的前代码能使BVT测试通过而且这些代码基本上不会涉及到他人在这种情况下可以不check in进去直到全部代码完成能提交BVT测试时再起check in进去每天我们都会做daily build
般是在凌晨4点进行那时有个会自动从VSS中拉下最新代码并进行编译我们同美国进行同步开发因此如果想要把修改代码进入到这个build中去那就需要在凌晨4点的前把相应代码check in进去若有人check in进去代码导致编译通不过则会在本步骤中被发现当编译完成的后自动产生安装包测试部门将会对这些代码进行BVT测试同时对VSS中开发库打上label如果发现了什么BUG就能根据这个label知道是哪个时候开始出现这个BUGBVT是指Build Very Test是对组件中基本功能测试这个测试每天都会进行看新加入代码或修改是否会影响系统基本功能便于及早发现
6. 测试在开发人员完成了function Spec后
测试部门开始了测试规划确定需要测试哪些方面如何测试及进度安排测试人员需要写许多测试代码有些测试代码需要集成进BVT测试有些可能需要进行单独测试目都是为了使产品符合要求使开发人员容易找出问题所在并改正产品功能是否符合了要求是否能被发布是由测试人员决定因此测试人员也比较辛苦责任重大通过了每天BVT测试还有些性能测试、兼容性测试、灾难测试等需要在产品发布前进行在完成这些测试的后由测试人员决定本产品是否能release出去了如果没有什么问题则会给某些关系较好用户进行β测试的后再最终release出去7. BUG管理由于我们每天进行着测试
因此经常有BUG被测试部门发现旦发现了新BUG就会被添加进BUG Tracking 
中目前较流行BUG Tracking 有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需要很快fixP5的前BUG在本版本release的前必须fix掉若真不能或不重要则由QA确定并降低优先级进入到下个版本中去fix.QA发现个BUG后在BUG Track中增加个BUG同时填入相关信息并assign给相应开发人员开发人员收到BUG分析并fix后assign给QA去very其中要填上分析结果以及如何解决详细介绍说明若QA对此BUG very通过则close BUG否则very failed并重新assign给开发人员并等待其fix.每星期在Status Meeting上会进行BUG状况报告主要由QA组长报告BUG状况主要是新增BUG数fix掉多少还有多少处于open状态有多少处于等待very状态据此可以了解开发及测试情况有时在Status Meeting上我们也会进行BUG ReviewBUG Review有时是单独个小组内进行其主要作用是重新明确每个人头上BUG以及了解每个BUG状况如开发人员对此BUG将作何处理等以此来了解开发中是否有碰到比较棘手问题增加了产品发布风险在QA增加BUG和开发人员fix BUG游戏中BUG数量曲线图会象股市曲线样上下波动但总体趋势般是前期BUG放量攀升后期震荡下挫若到了后期新openBUG数量直上升则介绍说明风险在增大有可能无法控制也就是说fix了个BUG导致了多个新BUG产生在量化开发进度中也可以用代码数量曲线图来粗略呈现在有大量新功能增加时可能代码量增加会较快当在fix bug阶段代码修改较多因此代码数量增幅会降低依据代码量可以看出开发状况处于何种阶段需要指出
是我们对BUG定义比较广泛些新功能也可以作为BUG被提出只不过这些BUG级别比较低让它们进入到下个版本中去实现因此BUG创建者也可以是技术支持人员、市场人员甚至开发人员本身有关开发人员本身他可能会找出些BUG有些是其他开发者有些可能是此开发者本身把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似BUG时有个借鉴和思路但此BUGvery必须要让测试本模块测试人员来very. 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般此人可能对某方面比较感兴趣然后他会花些时间去了解这方面情况写成个文档如PowerPo
并上传到局域网内同时通知大家可以先去浏览Tech Talk内容非常广泛不定同我们项目紧密相关任何新思想、新知识(当然般是限在计算机领域内)都可作为Tech Talk内容而在主讲人讲完的后还有段时间被大家提问共同对这个话题进行讨论答疑解惑当然Tech Talk也可同我们项目相关如研究下竞争对手产品技术本公司产品架构等研究本公司产品架构可以使大家对本公司产品有个全局概念从整体上来看自己产品顺便整理下产品架构使的更加清晰有条理平时大家都只注重于自己负责其中小块在Tech Talk中可以跳出自己小框框来了解全局同时这也是新员工了解公司核心技术整体框架好机会每个模块负责人需要阐述此模块方方面面让大家来了解并回答问题10. Code Review当进行工作移交时我们会进行Code Review
在碰到棘手BUG时也会进行Code ReviewCode Review是大家了解其详细实现个好机会在Code Review的后会对此代码产生亲切感而不是陌生惧怕感相信很多人在读他人代码时会有非常痛苦经历Code Review是减少此痛苦感好药方在进行Code Review前主讲人会提前发出个通知告诉相关人员要review哪些代码这样参和者可以抽出时间提前了解相关代码对不懂地方做个笔记以便在Code Review进行中提出疑问在我们碰到比较棘手BUG没有什么思路或大惑不解时这时找几个相关人员或对此代码也熟悉人进行次Code Review这时形式比较随意大家可以临时提出问题让主讲人解答在这个过程中可能听人并不会非常快地了解其中详细过程但是讲人在这个过程中重新理了下思路对所写代码被迫重新审视了遍在其中可能就会发现出解决问题办法在Code Review时有时代码非常多但可以个功能模块个功能模块地从总体到局部由浅入深层层递进方式进行次Code Review时间不要太长但可以分多次进行Code Review中大家会提出问题和建议集思广益多个人共同出主意有些可能个人没有想到问题会被大家发现互相学习共同进步11. 沟通和交流大部分员工
大部分时间是在公司里度过因此公司生活成了大家主要组成部分员工的间关系融洽交流畅通显得非常重要同时大家也不想自己生活这样枯燥乏味直同机器打交道沟通无处不在交流随时发生有许多关系是在工作的外建立起来软件Software公司内是很容易产生各种矛盾这是由你工作性质所决定比如QA或用户会对你实现不满意提出各种要求时我相信你有时会有所抱怨无形的中就产生了对立发展到后来会有抵触心理我相信大部分人都会有此感受这不是你错这主要是由我们工作性质决定如果你工作是把财富带给对方则对方会非常欢迎你到来把你奉为财神爷来对待同你关系会非常融洽友好因此我们需要在工作的外来消除这种对立矛盾关系建立种融洽工作氛围我们在平时吃饭时候饭桌上大家互相聊天沟通我们建立了happy邮件列表其中会发些幽默笑话的类邮件给我们紧张工作增加点轻松氛围在下班后大家可以组织下活动增加了公司凝聚力个产品发布后组织下旅游让绷紧神经松弛下更好地迎接下个挑战12. 后记区别公司有区别
做法我只是把我认为比较好流程和管理方式呈现出来让大家有个借鉴当然它也不是十全十美也不是放的 4海而皆准如果你觉得某些地方对你有所帮助或值得推广这是本文最想达到效果非常感谢I公司给了我这么美好经历也非常感谢I公司同事们曾给我巨大帮助在此衷心地祝福I公司越来越壮大逐步走向成功！也衷心地祝福我同事们幸福快乐！
最新评论