谈谈我们的开发流程

在这个公司工作五年多了,因为项目不同,角色不同,层次不同,也见识与经历了我们在软件开发中的各个步骤, 花些时间,总结与回顾一下我们的开发流程。

当然,先要说明一下前提:

  1. 我们做的是产品开发,一年一release,而不是项目定制开发
  2. 这是一个产品的持续开发、重构与维护,而不是从头搭建一个产品 
2009年以前,我们采用的是十分严格的瀑布开发模型,在项目初期就能拿到非常详细的spec,但2010年开始推行Scrum,流程有所改变,但就我们的软件规模、与用户的交互程度,很难实现真正意义上的敏捷。所以,我觉得我们的流程可以描述为“总体瀑布,局部迭代”,当然,这个局部可以占60%以上的时间。

 

萌芽

这发生在前一个release中后段的时候,此时公司中有些人除了做当前的项目,就要开始考虑明年做什么了,所谓既要埋头做事,也要抬头看路。 一般这些人可以分为两类:

  1. 产品设计师, 通过市场调查报告,竞争对手分析,或者纯粹个人创意想出一些点子来。或是新增功能,或是细分已有功能从而细分市场等等
  2. 架构师,leaders,在代码第一线发现的一些问题(原有设计、代码问题),或是在开发过程中遗留下来的一些任务(如时间不够而先用了一个workaround),主要是一些Technical Debt, 也包括一些如代码移植,组件更新(如VS升级)等等。

 

酝酿

这发生在一个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-beta2-beta3

开始邀请一些客户来试用新版本了,从beta1到beta3,参与人数会越来越多。此时除了一些日常的stabilization工作,主要精力会放在修复一些beta缺陷上。

此时会开出一些新的branch (每个beta会有一个branch),主要模式为:

主branch - QA branch - beta branch

  1. QA将一些重要的缺陷标为beta
  2. 开发修复后check in到主branch,并integrate到QA branch,然后将该change标为CCB(change control borad) 
  3. 该change会通过一个特定的process被review,被approve后会自动integrate到beta branch。

通过这层层控制,保证了beta版本的稳定性。 

然后,我们通过监视beta用户论坛,获取用户意见并逐步改进。 

 

RTM

RTM为Release To Manufacturing, 就是最终的发布版本。经过三个beta版本的稳定与改进后,我们会新开出一个RTM的branch,作为最终版。所有的change都会经过严格的review,才能进入这个branch,此时,主branch已经开始为下一个release服务了。

 

 

posted @ 2010-10-30 19:47  lzprgmr  阅读(1303)  评论(2编辑  收藏  举报

黄将军