一个测试老鸟的工作总结（2）——研发流程之我见_项目管理_非技术区_程序员俱乐部

      从一个执行层面的测试做到测试主管这个级别，当你手下管理多个项目和测试人员时，流程成为你必须要考虑的事，一般公司也很少有自己独立的SQA部门进行过程管控，如果是弱矩阵式的组织架构的模式下，基本QA/QC作为一个质量部门存在于公司内，而过程管控流程制定一般也分摊到项目管理者或质量部门中。那我们今天就来讨论一下软件研发流程这个话题，对于大多数普通的人员来看，流程是否完善规范，也是看一家公司的软件研发是否正规的主要标准。对于国内的软件企业，我们一般常见的几种开发模型有：

1. 边做边改模型：没有规格说明，没有相关的设计，得到客户需求直接进行编码形成版本，随着客户的需要一次一次不断的修改；也就是我们早期所说的作坊式软件开发模型
2. 瀑布模型：相信也是现在传统软件研发使用最广泛的开发模型，软件生命周期被计划、需求、设计、编码、测试、维护六个阶段进行划分，自上而下以固定次序衔接着进行一轮迭代。
3. 快速原型模型：在需求阶段建立一个快速模型让客户或客户代表以此原型进行需求评论，细化需求，等原型满足用户需求后再进行软件的开发，常见的是那种客户前端和研发后端相分离的组织里，产品运营产品经理，UI设计及客户体验或QA验收作为一个客户代表团队，前端后端QC测试作为一个实现团队分部合作的项目中比较常见这种开发模型也算是弥补了瀑布模型的需求开发风险不明确的风险缺点
4. 增量模型：又叫演化模型，在此模型中软件各阶段并不直接交付一个可运行的完整产品，而是交付满足客户需求一的个子集的可运行的产品，整个产品被分解成若干个构件，研发人员逐个构件进行交付，迭代的完成整个软件产品，我们常说的敏捷开发就主要以这种开发模型发展改良为主
5. RUP：这个模型是由rational公司提出的一套开发过程模型，是一个面向对象软件工程的通用业务流程，主要适合大型的商业软件项目，是一整套系统的方法论，对应的它有一整套工具集和规范标准进行辅助，因为其复杂度和适应性，国内很少有企业进行项目实践
6. IPD模型、螺旋模型、智能模型等等：因适用性的问题在这里就不一一说明了，网上相关的介绍文章有很多

      介绍了那么多通用工作流程，主要并不是想去比较哪个流程孰优孰劣，而是觉得每个流程都有其可取之处，只有适合之说而没有好坏之分。就拿我们普遍认为小作坊式的边做边改模式，你不可否认其工作的便利性和灵活性，初创公司在没有用户及资源基础或非矩阵式组织内人员不多的情况下，这种工作方式是最适合不过的了。

      我们通常开始关注并优化工作流程基本都是这样的开始的，当公司规模逐步变大，人员组织越来越多越来越复杂时，原来那种口头交互边说边做的方式可能越来越不能满足工作需要，怎样优化一种新的协作方式选取一种适合公司的工作流程，成为了解决组织变化的重要手段。而最具认可和知名度的如CMMI那些适合大型项目的过程模型来套用，一方面有很多公司的实践可以借鉴而对于接项目或对外合作又比较有利。而对那些成熟的软件过程模型体系不深入了解的话，往往只能按先例公司照猫画虎，过程改进一旦教条，文档化形式化仪式化的过程一旦形成，本来对于大组织的灵活性缺失的特点会越发明显。当过程或产品已经按流程适应和变化后，一个恶性循环就形成了。人的惰性会加剧这种情况的变化，只要勉强能应付，那么很多人都会选择拒绝改变的，不管是产品的重构还是研发过程的重构甚至下沿到组织结构的重构，当代价和风险呈现在你面前时，相信很多人都会退却的。当公司终于无法容忍这种内部消耗时，组织的变化在所难免，扁平化的强矩阵型组织化整为零，于是敏捷过程管理的理念如xp、scrum被广泛引入，而对于普遍缺乏专业project master情况下，而团队人员个体素质又参差不齐，加上管理人员或产品上急功近利的强调“敏捷”和“灵活”而产生的需求变更的低成本错觉；等等等等，最终大家可能发现转了一圈，我们又回到了小作坊式的工作流程上，回到了原地。我们在讨论和比较各种流程的优缺点，在讨论什么样的组织结构更适合项目开发，如果我们反过来看的话有没有想过，其实我们把因果关系搞错了。

      我们错把工作流程或组织结构的选取作为了优化工作的手段，所以我们去借鉴去寻找去套用去实践那些我们觉得适合我们的工作流程。但我们有没有想过，这些其实是结果，而不是过程，我们错把因果颠倒了这才是我们没有找到适合自己的工作流程的最主要原因。在我看来所有的工作流程所应具有的属性是被动的、妥协的，是无可奈何的产物。当我们不假思索的协作方式出现障碍了，我们被动的形成了各类的工作流程来补全我们的合作方式。流程正确的形成顺序应该是，当一家公司组织越来越大，协作沟通成本越来越高，我们被迫着改变我们的工作方式，这种改变有成功的，也有失败的，但反复成功的工作经验墨守成规，于是流程形成了，这个时候我们把那些适合行文定规，工作流程的确立是所有这些动作的最后一步。如果我们把工作流程的优化和制定当作优化组织的过程和工具，借鉴别人的最佳实践，水土不服的现象经常可以看到，因为了解你自己的人永远只有你自己。所以我们可以看到一个结论，优秀的组织形成了优秀的工作流程；而不是优秀的工作流程造就了优秀的组织。人事人事，人的因素永远多于你对事的依赖。找到一个优秀的一劳永逸的工作流程来解决你人的问题永远是不靠谱的想法。

      就拿我们验收阶段测试（系统测试）的内部统一后来流程演化来说吧，你可以看到一个完善的工作流程是怎么在日常工作中一点点形成的：原来公司因为有集成测试，相对系统测试还算简单，因为出现几次线上事故，所以对验收阶段的测试要求越来越高，而产品运营的介入和演示要求，使我们这个阶段的测试流程化需求越来越高。不完美的敏捷开发加入又让我们的系统测试越来越凌乱，于是，我们有了冒烟测试和打回的机制，为了满足项目经理的实时测试覆盖情况的需求，我们加入了冒烟测试报告和阶段测试报告，为了提高报告效率，测试报告自动化生成工具产生了。为了提高系统测试介入时间和效率（注：验收测试我们不做自动化）我们对提交的代码按需求进行了模块的划分。为了保证开发和测试的版本控制同时为了统计和定义项目过程改进中的regulation bug和reopen bug；我们在这个测试阶段定义了dev版本和QA版本两种版本内容；最后一步步我们为了方便新员工熟悉这些一点点演变而来的工作流程，我们对其文档化最后的流程就变成了这样：

      上述流程成文基本是我们做了几个月自然形成的，其中实践中作为多次修改，上面只是附了最简单的流程图，而详细的规定项目成员已了然于胸，流程只是给新员工讲解和提醒之用。所以还是那句话，没有最好的流程，只有最适合自己的流程；项目中的研发流程最佳实践永远优于借鉴和套用。