《202X年大中小构建高效软件开发流程和团队》由会员分享,可在线阅读,更多相关《202X年大中小构建高效软件开发流程和团队(8页珍藏版)》请在金锄头文库上搜索。
1、大中小构建高效软件开发流程和团队在一个产品发布并使用之后,其中肯定有许多地方不如意和值得改进的地方。客户在使用的过程中会发现一些问题,提出更高的需求,市场也在发生变化,我们的竞争对手也在发展,新的技术不断地产生,这些因素推动着我们的产品不断地向前发展,使它的版本不停地往上增长。这些发展的需求不是一下子提出来的,在客户使用的过程中发现某些不如意不方便的地方,他们会向我们的技术支持人员提意见,而技术支持人员会把这些需求以BUG的形式存入BUG数据库中,其级别一般定义为下一个版本的Feature。有些上一个版本未解决的BUG也可能需要在本版本中来解决。因此当我们来开发下一个版本时,其许多特性已经存在
2、于BUG数据库中了。当然新版本的特性不是只从BUG中获得,管理层可能从市场的角度来提出新的特性以求领先竞争对手,开发人员本身也可提出某些要求来纳入新版本开发的计划中,如要求对某部分代码进行重构以使其结构更清晰更容易维护,执行效率更高。 每个人把同自己相关的功能模块收集起来,同时预估时间,其中主要包括写文档的时间、开发时间和单元测试的时间,一般要求精确到工作日。这些信息发送给组长,组长再把本小组人员的任务和预估时间发送给管理层,由管理层对此任务及进度进行评估审核,管理层会根据产品发布时间及客户需求、市场因素等方面作出选择,可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同预计的
3、产品发布时间有较大冲突,而且此功能是本版本中必须得做的,则开发小组会被要求重新预估时间,加快开发速度来达到这个要求。 虽然这个开发进度时间是一个大概的估计时间,但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个StatusMeeting(一般那时工作效率较低,适合开会),在此会议上我们会根据这个进度来review我们的工作,每个人手上的工作是否按照这个进度在走,是否有人延后了,是否block住别人的工作了。在此会议上每个人都要报告自己的进度,同时还要报告上个星期做了什么,正在做什么,以及下个星期打算做什么。通过这个会议,会让你觉得有人在监督你,无形之中迫使你不断地督促自己不要使任务延
4、后,如果有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上,那也没有办法,只能修改原先的进度表,因为那是我们的估计与现实发生了偏差,我们必须使我们的进度表符合实际情况,这可以避免许多项目发生最后的20%的工作量会占据80%甚至一直拖后的情况。修改进度表的情况我们曾经发生过,有一次在按照原先的进度执行到将要完成的状态时突然接到通知由于市场及客户的原因要求加入另一项重大的功能,这个功能对我们程序的结构有非常大的影响,因此我们就要重新制定一个进度来满足需求。在这种情况下,产品原先的开发进度被打乱,发布时间也因此推迟。当然这种情况应当尽力避免,尤其在项目后期产生新的需求,若不得已也应重新规划进度,
5、而不是仍旧依照原先的进度去执行,因为老的进度已不能反映现实的情况。 3.开发文档 在项目进度安排中我们已经把写文档的时间也规划进去了,这里虽然是写文档,其实是设计程序,整理一下思路与架构,磨刀不误砍柴工,这样在实际写代码时会流畅很多,节省时间,因此可以说真正有思想性的东西都在写文档这段时间内完成了。当然我们这里的文档格式不象ISO那样规定了条条框框,我们的文档格式相对自由,基本上能随意发挥,但对于几个主要点一般来说是需要说明的。要求写的文档能让他人比较容易地看明白,能把问题讲清楚,能反映你的设计思想。文档的数量也不多,开发文档有两类,一类是functionSpec,另一类是DesignDocu
6、ment。 functionSpec中需要写明的是本模块完成的任务,解决什么问题,有什么作用,为什么要这些功能,此外我们还会添加进适用范围,有什么不足,注意点是什么,还有哪些地方在以后可以进行改进。在这个functionSpec中不涉及到任何非常详细的算法。此文档不光给开发人员看,还让QA及其他成员以及后来的新人能根据此文档来了解此模块的大致功能,同时也会给文档编写者看,他们会根据这些functionSpec整理出一份用户手册,告诉用户此版本中新增了哪些功能,各功能模块有什么作用,如何使用等信息。因此在我们的开发过程中functionSpec是很重要的文档,此文档完成后会抽出一段时间同相关人员
7、及QA一起review这个文档,让QA了解设计者的意图,同时熟悉新的功能模块,为接下来的测试作准备。如果其中有误解或不明之处,大家会提出来探讨并由开发者修正。 DesignDocument中主要描述实现此模块所涉及到的主要算法、数据结构、类的层次结构及调用关系。这个文档的阅读者主要是开发人员,包括任何想了解详细实现代码的人,帮助人们理解代码。在某些功能模块比较简单的程序中,此文档所描述的信息会比较少。此文档不象functionSpec要在开始写代码前就编写完成,它可以随着代码编写的进行而增加,但基本上遵循文档先行原则,也就是要增加新的代码或修改代码前若有涉及到文档部分的应先修改文档,然后再修改
8、代码。 4.编写代码 由于我们用JAVA语言进行开发,因此我们借助了JbuilderIDE工具。关于代码风格,我们基本上套用Jbuilder中自动的代码格式编排,但其中需要改变的是缩进是4个字符,类与类之间间隔2行,方法与方法之间间隔2行,import类时用完整的类名。写代码时要对类及函数提供详细的注释及说明,基本做到看它们的说明就能知道这个类或函数的功能以及主要算法的实现原理。在开发过程中对主要的模块要编写UnitTest,同时要UnitTest先行,也就是遵循XP规则中的测试驱动原则,当所有的单元测试代码通过时,此功能也就基本上完成了。 5.代码管理 我们采用VSS+SourceOffsi
9、te进行版本控制,其中存放了此产品的所有源代码、库文件、文档及release时的安装程序,各个部分存放在不同的目录中。每天早上要求开发人员从VSS中getlatestversion的源代码,然后进行编译并开始一天的工作。在下班之前理论上要求员工checkin所有当天修改的代码,在checkin之前要保证编译是能通过的。若有谁checkin的代码导致dailybuild失败则会被要求某些惩罚措施或警告,象微软公司要负责照看当日的每日构建。有时我们编写的代码涉及到多个文件,而且此改动是比较复杂需要花费多天的工作量,如果现在checkin进去可能会导致BVT(BuildVerifyTest)测试通不
10、过,因为有些代码没有完全完成,而之前的代码能使BVT测试通过,而且这些代码基本上不会涉及到他人,在这种情况下可以不checkin进去,直到全部代码完成能提交BVT测试时再一起checkin进去。 每天我们都会做dailybuild,一般是在凌晨4点进行,那时有个程序会自动从VSS中拉下最新的代码并进行编译。因为我们同美国进行同步开发,因此如果想要把修改的代码进入到这个build中去那就需要在凌晨4点之前把相应的代码checkin进去。若有人checkin进去的代码导致编译通不过则会在本步骤中被发现。当编译完成之后自动产生安装包,测试部门将会对这些代码进行BVT测试,同时对VSS中开发库打上la
11、bel,如果发现了什么BUG就能根据这个label知道是哪个时候开始出现这个BUG的。BVT是指BuildVerifyTest,是对组件中基本功能的测试。这个测试每天都会进行,看新加入的代码或修改是否会影响系统的基本功能,便于及早发现错误。 6.测试 在开发人员完成了functionSpec后,测试部门开始了测试规划,确定需要测试哪些方面,如何测试及进度安排。测试人员需要写许多测试代码,有些测试代码需要集成进BVT测试,有些可能需要进行单独的测试,目的都是为了使产品符合要求,使开发人员容易找出问题所在并改正。产品功能是否符合了要求,是否能被发布是由测试人员决定的,因此测试人员也比较辛苦,责任重
12、大。通过了每天的BVT测试,还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能release出去了,如果没有什么问题则会给某些关系较好的用户进行测试,之后再最终release出去。 7.BUG管理 由于我们每天进行着测试,因此经常有BUG被测试部门发现,一旦发现了新的BUG,就会被添加进BUGTrackingSystem中。目前较流行的BUGTrackingSystem有TestTrack、ClearQuest、Bugzilla等。BUGtrackingsystem是开发人员和QA之间的纽带,开发人员和QA通过BUGtrackingsys
13、tem联系着。每个BUG有其类型和级别,预定的类型有Crash-DataLoss,Crash-NoDataLoss,Incorrectfunctionality,Cosmetic,Featurerequest等,级别有P1、P2一直到P6,它们分别代表了重要性及紧急程度,P1的BUG需要很快fix,P5之前的BUG在本版本release之前必须fix掉,若真的不能或不重要则由QA确定并降低优先级进入到下一个版本中去fix。QA发现一个BUG后在BUGTrack中增加一个BUG,同时填入相关信息并assign给相应的开发人员,开发人员收到BUG分析并fix后assign给QA去verify,其中
14、要填上分析的结果以及如何解决的详细说明。若QA对此BUGverify通过则closeBUG,否则verifyfailed并重新assign给开发人员并等待其fix。每星期在StatusMeeting上会进行BUG状况报告,主要由QA组长报告BUG的状况,主要是新增BUG数,fix掉多少,还有多少处于open状态,有多少处于等待verify的状态,据此可以了解开发及测试情况。有时在StatusMeeting上我们也会进行BUGReview,BUGReview有时是单独一个小组内进行,其主要作用是重新明确每个人头上的BUG以及了解每个BUG的状况,如开发人员对此BUG将作何处理等,以此来了解开发中
15、是否有碰到比较棘手的问题,增加了产品发布风险。在QA增加BUG和开发人员fixBUG的游戏中,BUG的数量曲线图会象股市曲线一样上下波动,但总体趋势一般是前期BUG放量攀升,后期震荡下挫,若到了后期新open的BUG数量一直上升则说明风险在增大,有可能无法控制,也就是说fix了一个BUG导致了多个新的BUG产生。在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快,当在fixbug阶段,代码的修改较多,因此代码数量的增幅会降低,依据代码量可以看出开发的状况处于何种阶段。 需要指出的是我们对BUG的定义比较广泛,一些新功能也可以作为BUG被提出,只不过这些BUG级别比较低,让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身,因为他可能会找出一些BUG,有些是其他开发者的,有些可能是此开发者本身的,把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路,但此BUG的verify必须要让测试本模块的测试人员来verify。 8.CodeFreeze 当P5之前的BUG都被修复了,这时离产品发布日期也就不远了,一般是2个星期后就能release产品,这时要对VSS中的代码进行freeze,以保证代码库的稳定性。