目前的团队开发流程

我所在的团队是以二次开发和维护一套大型件产品为主。不谈项目与产品的区别，只说目前的开发流程。看看大家对这种开发方式有什么建议。

1.产品有多个版本，以不同的分支并行开发。处于开发阶段的一般都是最高版本。每当发布小版本，则该小版本所有的defect item 都需要在高版本中拷贝一份(譬如clearquest clone)，以便高版本中也进行修改。这样使得修正过后的代码与高版本branch同步，同时意味着高版本也修正了这些defect. 当然需要重新在高版本中再进行测试和验证。

2.因为产品有很多用户，所以很多时候需要考虑的是向后兼容性，而不是发现个defect则不管三七二十一修正了是。如果改动的影响较大，则考虑将该defect推迟至最高版本修复。至于目前，尽量让客户接受以变通方式来绕过这个defect.

3.针对每一个记录在bug tracking系统的defect，在提交变更代码之前需要在team内部做一次review。仿照PSP[url=http://en.wikipedia.org/wiki/Personal_Software_Process]（Personal Software Process）[/url]的方式，建立了review checklist.譬如有一项就是，该defect 是否真的需要在当前版本 fix.

4.每一次的版本发布，需要整理所有已修复的defect,然后基于time line挑选出最紧急和必要的项。QA也只会去测试包含在该发行版的defect, 唔，回归测试也是必需的。

5.在产品发布后，记录信息以供将来参考和回顾。如defect rate, productivity, good practice.

很明显客户与管理层非常重视产品质量，所以为了提高团队的开发质量，团队做了很多的努力，譬如建立代码团队审查制度，尽量做到no review no checkin,还有开发人员必须做unit test。

问题还是有的，很重要的一个就是生产率的降低。很多的时间都耗在了review,unit test - 其实并不是严格意义上的单元测试，因为这是一个遗留的大型平台软件系统，很多模块没法用mock。典型的就是GUI的bug :(. 因为有这样的手动"单元测试"要求，导致测试很繁琐，开发人员是非常的反感。

题外话，目前的工作基本不涉及严格意义上的需求和设计，有的只是理解defect，安全的解决defect,可别inject一个新的defect. Oops, 这是我们的核心KPI.