谈谈我们的开发流程
在这个公司工作五年多了，因为项目不同，角色不同，层次不同，也见识与经历了我们在软件开发中的各个步骤， 花些时间，总结与回顾一下我们的开发流程。
当然，先要说明一下前提：
- 我们做的是产品开发，一年一release，而不是项目定制开发
- 这是一个产品的持续开发、重构与维护，而不是从头搭建一个产品
萌芽
这发生在前一个release中后段的时候，此时公司中有些人除了做当前的项目，就要开始考虑明年做什么了，所谓既要埋头做事，也要抬头看路。 一般这些人可以分为两类：
- 产品设计师， 通过市场调查报告，竞争对手分析，或者纯粹个人创意想出一些点子来。或是新增功能，或是细分已有功能从而细分市场等等
- 架构师，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
- QA将一些重要的缺陷标为beta
- 开发修复后check in到主branch，并integrate到QA branch，然后将该change标为CCB(change control borad)
- 该change会通过一个特定的process被review，被approve后会自动integrate到beta branch。
通过这层层控制，保证了beta版本的稳定性。
然后，我们通过监视beta用户论坛，获取用户意见并逐步改进。
RTM
RTM为Release To Manufacturing, 就是最终的发布版本。经过三个beta版本的稳定与改进后，我们会新开出一个RTM的branch，作为最终版。所有的change都会经过严格的review，才能进入这个branch，此时，主branch已经开始为下一个release服务了。
