创业公司，业务为王，速度制胜。但是很多创业公司却面临着研发流程混乱，效率低下，研发迟迟跟不上业务的节奏。前方，业务在市场上攻城掠地。后方，研发迟迟跟不上节奏，让人干着急。本文从创业公司实践中出发，详细介绍如何打造高效的研发体系，支撑业务快速发展。
不管是敏捷模型还是传统的瀑布开发模型，研发的源头都是需求。需求的好坏，直接决定了后面开发、测试团队的工作是否有价值。
在需求阶段，产品、开发、测试相关同学来进行需求评审，需求评审主要以下几个方面进行：
高效研发团队的一大特征就是不要把技术团队简单当资源使用，而且让技术团队觉得是在一起做一件有价值的事，所以首先就要讨论清楚为什么做这个需求？不仅仅是次简单的任务派发。
讨论清楚需求的价值是什么？是为了让大家觉得这件事情有意义。一般需求的价值可以归类于 提升收益 和 降低成本。很多团队中存在业务、产品和技术同学沟通不清楚需求的原因就在这里。大家的观点不在一个维度上，业务的观点在业务拓展、收益上，产品的观点在需求、产品功能上，技术的观点又在产品特性，功能实现上。如果大家的焦点都在"钱"上，提升收益，或者降低成本，那么沟通上可能更加容易达成一致。
在需求评审会上，产品、技术详细评审需求是否完整，产品功能的正常场景是什么？是否形成闭环；异常场景是什么？是否考虑周全？
需求评审后，开发和测试负责人，分别编写技术方案和测试用例。技术方案评审，开发负责人拉上涉及到其他系统的负责人一起讨论，技术方案中必须要有 业务流程图 和 时序图，业务流程图是为了梳理开发对业务的理解，是否和需求一致。时序图是了梳理本次需求涉及的系统交互。技术方案评审通过后，确认工作量和交付时间，反馈给产品。
测试用例评审，测试负责人拉上产品、开发一起评审。测试用例是对业务逻辑的一次梳理，从测试角度来理解这次需求，看看是否有场景遗漏，补充业务场景的完整性。测试用例评审通过后，用例会分成两块 核心用例 和 一般用例。
在高效的研发体系中，开发是需要完成 核心用例 自测才能提交测试。关于开发是否需要自测这个问题，大家有不同的观点和看法。本文认为开发自测是个非常良好的习惯。一方面，开发自己完成需求的部分测试工作，也清楚自己完成的工作质量。另一方面，避免到了测试手里，连核心场景都跑不通，再打回给开发修复 bug，其中反复沟通，着实降低了整体研发效率。
测试阶段，开发主要工作是修复 bug 或者做其他需求。测试主要工作是执行测试用例，提 bug 和验证 bug。很多场景下，开发修复一个 bug，就会通知测试进行验证。测试一整天就在忙于部署测试环境，验证 bug，效率非常低下。在高效的研发体系中，测试和回归是有时间约定的。比如：早上 9 点半约定提测，测试进行第一轮测试，然后集中提 bug 到 bug 管理系统，开发收到指派 bug 后，开始进行修复。下午 3 点，约定第二轮回归测试，测试对已经修复的 bug 集中进行验证，有问题，测试再次提交 bug，指派给开发。下午 7 点，约定第三轮回归测试。在这样的体系下，开发专注于修复 bug，到了约定的时间，测试集中测试，减少了不断提测、部署环境浪费的时间。在测试阶段，测试和开发不断沟通、反复部署环境，等待环境重启，是最浪费时间。
测试通过后，产品和视觉会进行验收。验收完成后，开始进入真正的发布阶段。良好的发布策略是分批分布，先发布一台，并观察日志，看看是否有问题，避免发布引起故障。确认没问题后，再批次发布剩余的机器。发布完成后，开发和测试会在线上进行功能的验证，并持续观察线上访问日志 5 分钟左右，确保上线后功能完成没问题。如果有问题，可以迅速回滚到上一版本，避免造成线上故障。
高效的研发体系，关键在于各个团队的沟通协作的高效。在需求阶段，深入讨论为什么做这个需求，这个需求的价值是什么？产出一份需求评审文档。在开发阶段，讨论技术方案和测试用例，并产出核心用例交给开发自测。开发完成自测，再提测，避免普通体系中，开发写完代码就提测，再被测试打回，反复多次。在测试阶段，约定时间提测和回归，避免了不断提 bug、部署环境、验证 bug 带来的时间浪费。在发布阶段，分批发布、和持续关注线上日志，避免发布引起的故障。
黄辉权（武彻），技术 VP@杭州兑吧网络科技有限公司。负责架构、基础运维、质量团队。前阿里巴巴技术专家，阿里钉钉 smartwork 项目 & 技术负责人。对互联网技术架构、性能优化、团队管理有丰富的经验。
今日荐文
点击下方图片即可阅读
企业的应用架构到底该怎么演变才能合了 CEO 的愿？
今年，架构师关注的技术点有何不同？从云计算、大数据、微服务、容器，到现在的人工智能，架构师应该怎么做？这里推荐一场会议，为你总结了 100+ 国内外技术专家现阶段的架构实践，点击“阅读原文”，看看对你有何启发。
