谈谈我们的开发流程
在这个公司工作五年多了,因为项目不同,角色不同,层次不同,也见识与经历了我们在软件开发中的各个步骤, 花些时间,总结与回顾一下我们的开发流程。
当然,先要说明一下前提:
这发生在前一个release中后段的时候,此时公司中有些人除了做当前的项目,就要开始考虑明年做什么了,所谓既要埋头做事,也要抬头看路。 一般这些人可以分为两类:
这发生在一个release的开始阶段,一些点子已经定下来了(所谓立项) ,team也成立或者选择好了。
那么就需要好好想想这个东西具体做些什么,结合Scrum,这个阶段我们称之为User Story Grooming,就是大家一起头脑风暴,绞尽脑汁想出所有可能需要的功能,需要完成的事。一般的做法是产品设计(PO),architect,leader在一起经过多轮的讨论,但我觉得把整个team都包含进来讨论,或者leader与team有单独的会议来进行一些讨论,会更好一些。
初步的 Story已经准备好了,接下来要做的就是team一起对所有的story进行估计,根据总的Story Point以及优先级,做出release plan。为了便于控制,我们使用了的sprint长度为2个礼拜,但是因为软件规模的关系,2个礼拜要有比较显著的产出不太切合实际,所以我们还会定milestone,一般三个sprint一个milestone。
此时,项目组的branch也已可以开出来了。
这是开发的主体阶段,时间可以占到60%,在计划完成后可以立马开始。每个sprint的成果都会被测试并小范围demo,这个demo的范围一般仅限于本team,所以有点review的味道。然后每3个sprint都会做一次集成到主branch上,集成的质量主要靠自动化测试保证
这里要提一下,虽然scrum不提倡,但我还是觉得在前几个sprint,花些时间做好设计是非常重要的,我们就遇到过几次因为开始没想清楚,后来返工的情况。Scrum在敏捷的同时,给我的感觉是有些急功近利,局部最优,全局却无法保证最优。
主体的开发完成了,不需要啥太大的改动了,接下来的工作,主要就是stabilization了 ,大家也都回到主branch上工作了。是的,敏捷到此为止,我们并不保证前面每个sprint的产出是potential shippable的。我们绝对需要接下来一段时间的稳定。
如果由于某种原因非要做一个较大的改动,需要发一个ECO(Engineering Change Order),为了追踪与风险控制。
此外,因为所有team的代码都在主branch上了,QA会组织一些Bugbash,进行globalization测试,性能测试,系统测试,Workflow测试等。
开始邀请一些客户来试用新版本了,从beta1到beta3,参与人数会越来越多。此时除了一些日常的stabilization工作,主要精力会放在修复一些beta缺陷上。
此时会开出一些新的branch (每个beta会有一个branch),主要模式为:
主branch - QA branch - beta branch
通过这层层控制,保证了beta版本的稳定性。
然后,我们通过监视beta用户论坛,获取用户意见并逐步改进。
RTM为Release To Manufacturing, 就是最终的发布版本。经过三个beta版本的稳定与改进后,我们会新开出一个RTM的branch,作为最终版。所有的change都会经过严格的review,才能进入这个branch,此时,主branch已经开始为下一个release服务了。
优质内容筛选与推荐>>