目前的团队开发流程

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

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

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

3.针对每一个记录在bug tracking系统的defect，在提交变更代码之前需要在team内部做一次review。仿照PSP（Personal Software Process）的方式，建立了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.

搞不好就变成了为了review而review，为了白盒而白盒。

100%语句覆盖地自动测试???我只能说这个GUI太简单了……某些Dialog非常复杂……当然这个和设计有关

review和unit test是绝对必要的，尤其是你们系统足够复杂。
可以在review和UT的上动动脑筋，提高效率。

mock1234，你的推测很准。 其实如此频繁code review也是不得已而为之，基本上这套软件产品从设计开发之初就没有一套针对developer的自动化回归测试套件。



同意，其实我的问题就是tdd如何构建在大型遗留系统中，特别是各模块众多，且各部分已经十分成熟。说服管理层？首先各版本目前的缺陷率在一个可接受范围内，其次本来开发维护流程就是已经是剪裁的up（迭代开发，增量发布 . . .），再去推动一个暂时效果不明显的tdd?? 呵呵。

至于gui的自动化测试，技术上可行，但好像成本有点高。


是，不同的人对与一个复杂的系统有不同理解层次，特别是开发人员有时看问题有盲点，如问题理解的不够全面，没有控制 change scope.

这样的系统很多，和我们目前的系统类似。
在已有的条件下，对原来系统的修改有的时候变成不可控的

我也想知道有哪些好方法！！！！！！

我只知道：
（1）UI的自动化测试，建立这些脚本时是很费劲，但对于你们这种已经开发了很长时间了，产品基本定型了的场景，还是值得的。因此，能自动化的，就自动化。当然复杂的Dialog还是手工测试。
（2）后台业务逻辑部分，充分利用 unit测试代码（如junit），这也适合产品基本定型的。
（3）改一个 defect 的质量如何，关键还是 “人”。改之前，先写个方案，让 懂业务和技术的“大师”级过目。因此，这样你的项目培养保留有这么几个“大师”，就顺利多了。千万别指望2000元/月的程序员能给你带来很多期望