有哪些软件相关的公司，开发流程比较规范？
之前我在微软上海的sqlserver工作的时候就感受到了他们十分严谨的气氛，一般来说，我们做一个软件之前都会planning和investigation，大概占用1/3的时间，研究得差不多了，然后才开始干正事。然后就会开始用agile里面scrum的那套方法，而且在【每次】代码checkin之前，都要有两个人review通过了才行，review没过就按照comment改，如果强行checkin的话系统会群发邮件。
至于daily build要到开发了差不多一半的时候，功能基本都写完了才会开始，这个是给test用的，不是给dev用的。
至于test，会跟dev一样，从项目的planning阶段就开始参与我们的设计，并且他们会思考如何对我们即将要完成的东西做自动化测试。测试时全程参与的，而不像某些著名公司一样，快写完的时候才开始。
到了项目的后期，feature基本做完了，几乎都在修bug的时候，会进入一个feature freezing的阶段。这个时候PM如果要提新的需求，就会queue进一个叫做design changing request的表里，每个星期全组都要开会讨论，到底是现在做呢，还是下个release才做。
我们的项目组有上千个人，所以把所有代码merge在一起也是一件很艰难的事情。因此每个feature team都要定期从main branch上面下载代码来做本地merge，提前发现问题。当轮到我们最终把自己的feature提交到main branch的时候，大概会有两个星期的时间，这个时间我们可以自由操作main branch，别人不能动（只能下载）。但要求是要把整个sqlserver的所有自动化测试用例都通过才行。否则的话，过了这个时间窗，没做完就干掉，排队等下次。如果最终checkin了进去，但是别人发现你break test了，就会把你的代码reverse掉，你仍然要排队等下次。
我们的delivery是按照【你写的代码进了main branch】来算的，如果千辛万苦怎么写都过不了test进不了branch，那根白做了没有任何区别。
你要是想体验一下的话可以过来试试（逃
你是想了解管理流程，还是技术流程呢？如果是技术流程的话，Qt Project还不错。http://qt-project.org/
缺陷跟踪器(bug tracker)在 https://bugreports.qt-project.org/
代码评审网站(gerrit)在 https://codereview.qt-project.org/
CI结果在 http://testresults.qt-project.org/ci/
项目所有代码在 https://github.com/qtproject/
相关信息：http://qt-project.org/contribute
Qt Project的CI现在覆盖Windows, Linux, OS X, Android, iOS等，全部自动集成，规模应该是够大了，我不知道还有其它项目能做成这个样子。CI代码也是开放的，基于Jenkins。我们这10来个人，我们这开发流程用了好几年了。
这段时间在重新用Python搭建公司里面的这套，我们的开发是用Git，周边写一些脚本来自动化。
1 nightly build和测试，包括regression(debug/release), coverage testing, valgrind testing。如果发现问题脚本发邮件给相关人员。
2 merge server，这是我以前没见过的，我们做了一个小的服务端，开发人员每次merge代码都是通过脚本提交一个branch，这个merge server做的工作就是做代码merge，编译，跑regression, 如果没问题就代码改动就进入master。否则就报告出来，这个merge被block。避免很多手工活。
3 CI, ci跑的是一个更大的测试集，可以监测到每次merge 引起的cpu/memory 的变化，如果有问题需要review。
4 Rails写的内部网站展示所有上面的测试和merge的情况。看见@vczh 讲了微软的开发流程，我也讲讲我们这边吧。我在上海ibm的编译器组，我们团队包括了加拿大的主体部分，美国的C++ Runtime部分，北京的一小部分z/OS，上海的AIX/Linux C/C++编译器前端，C/C++/Fortran编译器后端部分。由于我们团队跨国跨地区，所以我们需要一个非常严谨的开发流程来保证。我们本身采取的是Agile开发模式，具体来说就是Scrum那一套。由于我们是编译器项目，类似@vczh的sqlserver，我们也会有Plan与Investigation，当然这些是VP级别的大佬来操作的，而这些事情都是比较宏伟的，以C++为例，我们会有C++11的支持计划，我们会首先实现C++11的哪些特性呢，接下来会实现哪些呢，这些特性与编译器实现难度有关系，更重要的是与我们的Clients需求有关系（由于我们编译器的Clients基本上都是大企业用户，那么我们不可能不理）。那么VP制定好计划后，从具体事情来说，我们会有Task，一个Task又会有若干个Story。从时间来说我们就会有若干个sprint，那么在后面提交代码这是非常必要的，你需要指定你的代码针对的是哪一个Plan与Sprint。而由于编译器是一个高度复杂的项目，在提交代码前，一定会首先跑核心用例测试，而这个核心用例测试是一个Failure都不能出现。如果出现了Failure，对不起，请修改代码。随后，如果你的代码难度很大的，改动了编译器核心的代码（比如我上次修改了我们C++的Parser产生式），那么这时候在提交代码的时候，你需要勾选上你的Team Leader，再勾选上两个加拿大本部的资深Developer，等他们都Review通过后，你的代码才会被系统Check In进去，否则你的代码无法Check In进代码仓库。如果这些都完毕后，随后我们会有Regression测试，如果你的Regression测试都过了后，你才算系统通过，否则你需要解决Regression。随后过了一周，我们会开Code Review大会，你需要讲解你这样改代码的理由。然后会检测你的代码风格是否符合IBM Compiler的代码开发标准，以及你的代码是否还有潜在的风险（如我以前解的一个Defect什么都过了，但是在Code Review发现会有z/OS以后潜在的风险，即使现在没有出现，也需要修改代码来避免）。而我们会有BPI人员定期进行Merge Code，建立Branch，拉代码入PTF Line，Freeze Code等，以及发布前会有Release Manager等来进行全程控制等，而Tester来说也会全程参与整个开发周期，跑测试用例，报给相应的developer，自动化测试等。而我所说的只是我们团队开发流程的冰山一角，总的来说，如@vczh所说，如果你想体验正规开发流程，可以去他们那里的团队，而我们IBM这边也是相当正规规范的。 :-)我也来说说我们这里的开发流程，我觉得也算是比较规范的。分两部分，一部分针对bug的，另外一部分是针对项目的。
如果是bug的话，稍微简单一些，主要的流程如下：
1， 在bug系统上面接手该bug，并分析原因，将root cause添加上；
2， 根据分析，修改代码，并做基本的单元测试
3， 将修改的代码的webrev、分析以及测试过程和结果发到内部的code review邮件列表中（基本上都是team里的其他人）
4， 有人有意见就要回，没有的话在发送相同的内容到外部的code review邮件列表中（这其中包括了一些相关的懂该bug的工程师，范围更大）
5， 外部的code review 通过之后，就是做regression test，两个平台要分别作测试，产生出的结果要保留以备后面使用
6， 测试都通过了，那么就可以提rti了，这步还有个难题，该bug对应产品的rti owner会根据webrev、分析、测试以及comments来决定是否同意
7， 反复的沟通，同意后就可以push代码了
对于项目来说，在外部code review之后要发到更大的邮件列表中来review，其他部分基本相同。听说华为是通过各种会，各种codereview保证代码质量的；叹为观止系列~
所以规范和方法论真的重要么- - 你反对你们的流程只是因为执行有问题，建议评估一下自己团队的能力，选一个简单易用的~
我们是小团队，TDD，任务管理工具用的Worktile 让工作更简单；对我们团队而言，严格规范意味着花式作死，通常就是每个人负责自己的一大块，在worktile里同步进度就好推荐阅读：
Git软件开发过程
开发流程很规范，通常意味着这家公司/团队已经进入成熟期，发展机会不多了。
当然，我并不是在说流程的坏话。规范的流程很重要，尤其是利润有限，必须厌恶风险的时候。
这个得介绍下我带的团队：
我并不太喜欢规范这个词， 开发流程应该符合那个组织、那个公司的规范呢？ 我选择更好更高效更合适的开发流程。
用图来简介下我指导的马拉马拉技术团队：
基于WIKI的信息积累、分享:
带动一个团队写WIKI真不是件容易的事情，还得自己先动笔。
APP版本保持低的崩溃率
0.2％日用户的崩溃率并不算特别好的成绩，但对于跑步类的APP, 并仅3人专职的测试小组来说，还是值得高兴的。
大多的系统我们做到提交测试的版本没有P0(阻断重要流程)的BUG
使用Jenkins 来持续集成，并保证单元测试成功
跑完单元测试，使用Sonar进行代码分析
wordpress 的代码质量不高。
团队要求代码重复率不能超过3％，(第三方代码不算) 代码复杂度不能高。 单元测试的覆盖率因为技术原因并没有全部统计上来。
多个独立的运行环境：
产品看: demo ; 测试看 test ;
平台架构：
微服务的架构
还有一些工具就不贴了。如Postman
一个离开同学曾经的自我评价
好的环境，应是可以帮助人员成长，发挥人员创造力。
----------------------------------------------------
我的文章:
如何有效讨论问题 - 左撰 - 知乎专栏
假设与行动
左文建：如何评估软件研发团队（组织）的成熟度？
海康威视
开发超级规范，各种规范，还有代码评审
推荐你了解一下深圳市逻辑思维软件有限公司
众所周知，整个移动app设计和开发都是一项庞大的工程。想要开发一个相对较优秀的app。至少3到6个月的时间。但是长沙网开亿面网络科技有限公司，具有专业的开发团队为产品质量保驾护航，团队的配合默契非常高，这就直接导致了开发时间大大减少。虽然我不知道题主所说的开发流程规范是个什么标准，但是我可以说一下我们公司开发app的一个流程是怎么样的，只能说智者见智 仁者见仁。
首先，如果要做一款app，必须要前期进行沟通，初步表明此款app要实现的效果，属于哪个类型的app。在功能和实现价值基本敲定的情况下，开始进入项目评估阶段。这个时候产品经理会根据之前商定的功能进行价格和工期的评估，确立一个初步的项目排期。在系列的前期工作得到客户认可的情况下，签订合同正式开始项目。项目开始各个部门就开始项目的碰头会议，设计部门开始设计UI（产品界面）和UE（用户体验），针对产品开展创意设计，形成初步的效果图，经过首次客户的确认。
在根据交流的具体结果进行二次修改，最终与客户确认高保真视觉图，开始进入研发阶段。经过工程师的一段时间研发，产品基本成型，正式开始测试。测试合格，确认没有bug后与客户进行沟通，开始验收。由客户进行测试，提出修改意见。
客户验收合格满意后，开发者会将app交付客户，客户根据APP预估的访问量、用户数量等来进行服务器的选择，服务器可以自己购买管理，也可以购买后托管，也可以直接租赁。
这就是我们公司制作一个app的大致流程，下面就具体的说一下每个步骤是怎样做的，可以让大家更直观的看到。
二、产品立项
工作概述：产品立项阶段亦称为准备阶段，该阶段主要基于需求大纲通过针对性的市场调研、用户访谈及竞品分析，尽可能的评估产品的核心功能，方向定位、目标用户群、成本投入和市场前景。在决策层评估通过的条件下，组建虚拟开发小组，协调资源，明确项目负责人及产品计划上线时间等事项。若为甲方需求的项目，可省略市场调研及商业价值评估的相关内容。
市场调研，竞品分析：通过针对性的市场调研和充分的竞品分析，测算产品市场前景和风险成本。
收集需求，排优先级：收集各业务市场部门反馈的需求意见，做典型用户的深度访谈，组相开发设计运营人员头脑风暴，明确产品核心功能和开发需求优先级。
组建团队，定负责人：依据产品定位和投入资源，组建合适的虚拟开发小组，指定项目负责人，团队相互熟悉各个岗位人员。
定期碰头，制定计划：商定项目相关人员定期碰头会，保持团队所有人最新需求信息同步，初步制定产品各个阶段完成时间节点。
三、需求分析评审
工作概述：基于产品定位和运营策略，与产品各需求方进行深度的需求沟通，将抽象繁杂的需求整理分析成可落地执行的方案，召开需求评审，排定各功能点的开发优先级，规划产品各个版本迭代的功能计划表，设计产品原型，撰写产品需求说明书，与设计开发团队沟通确定各阶段的完成时间节点，明确产品实际上线时间，与市场运营团队沟通上线运营计划方案等。
需求分析，原型设计：与市场业务运营同事深度沟通，形成初步的需求大纲，功能列表，组织团队全员头脑风暴，分析需求的真伪及紧迫性，确定需求开发优先级，制定产品功能迭代计划表，设计产品原型初稿及页面结构图；
需求评审，确定方案：由产品经理牵头召开需求评审会议，向开发团队详细讲解产品逻辑流程和交互细节，评估技术实现的可行性。对不明确的需求做二次需求更新；
需求文档，开发周期：依据需求评审结果，修改设计最终版原型及交互，标注原型及撰写产品需求说明书，管理后台数据相关数据统计等需求，技术根据需求文档反馈每个阶段的完成时间节点。
四、UI界面设计
工作概述：基于原型交互稿及产品PRD文档设计产品页面效果图，与产品沟通确定详细的交互细节及效果。与需求业务方确定完善效果图设计最终版，依据开发需求进行效果图细节标注，设计产品icon及应用市场审核宣传材料，配合市场运营部门设计产品运营活动页面等。
用户分析，设计梳理：收集相关资料分析目标用户的使用特征、情感、习惯、心理、需求等，基于3W法明确使用者，使用环境及使用方式；
素材收集，确定风格：在深度熟悉产品整体业务流程和商业需求的基础上，确定页面主辅色，制定交互方式，操作与跳转流程、结构、布局、信息和其他元素；
界面设计，规范输出：设计产品页面、图标、ICON，皮肤及一些界面交互的表现。与前端开发沟通，明确切图命名及标注规范，输出最终设计稿。
UE测试，整体复盘：产品测试阶段包含UE测试，负责测试页面的还原度及交互的易用性，针对设计稿和需求文档提出测试反馈优化意见。产品上线发布后，全面复盘本次设计架构和细节，总结设计经验和优化迭代建议，并撰写相关的分析优化报告。
五、程序开发
工作概述：分为用户端、服务端两类开发。其中用户端开发，主流有iOS和Android，依据需求文档和设计稿，实现前端页面的交互效果，与服务端确定数据交换接口协议。服务端开发依据需求文档，设计数据库表结构，评估核心复杂功能的实现方案，撰写开发设计概要文档及反馈重要功能。
六、测试验收
工作概述：参考产品需求文档和开发设计概要，撰写产品测试用例，召开用例讲解会，对产品全方位的进行测试，将测试不通过的内容反馈给开发，判定bug严重程度和跟进修复进度，评估产品上线发布的可行性，协助产品和业务人员撰写产品验收报告。
这样，一个app的制作流程就完成了。长沙网开亿面网络科技有限公司有专业的研发团队和售后人员，在当地有很高的业界口碑，价格也是非常实惠，总之选择网开亿面是您的不二选择。
可以参考一下：Ceelog/Simple-RD-Spec
Simple-RD-Spec
适用于中小型团队的简单研发管理规范
1. 概述
研发管理的最终目标是满足业务需求，实现用户或商业价值
研发团队通过持续交付和维护高质量的软件服务来达成上述目标
2. 研发过程管理
2.1 需求
- 需求应该由业务的利益相关方提出
- 需求必须经过需求评审，和业务利益挂钩，明确回答“是什么”和“为什么”
- 需求应该进入需求池，实现全生命周期管理
- 需求必须有优先级，优先实现优先级高的需求
- 需求可能发生变更，变更后的需求必须重新经历全部或部分生命周期
2.2 开发
- 开发必须经过技术方案评审，和需求挂钩，明确回答“怎么做”
- 代码库必须使用版本控制系统
- 代码提交记录应该遵守团队统一的规范
- 代码风格应该遵守团队统一的规范
- 软件设计应该遵守 SOLID 原则，提高可维护性
- 代码应该通过单元测试，提高软件质量
- 代码合并到主干之前应该经过 code review
2.3 测试
- 测试必须经过用例评审，和需求规格、技术方案挂钩，确保“所得为所需”
- 软件缺陷应该进入缺陷池，实现全生命周期管理
- 软件缺陷必须有优先级，优先修复优先级高的缺陷
- 软件缺陷可能被忽略，如果它造成的损失足够小
3. 附则
- 典型的互联网企业，业务利益相关方包括监管、用户、客户、老板、市场、销售、运营、产品、设计、开发、测试、运维
- 本规范主要以开发的视角梳理研发流程，提升业务参与各方的协作效率
在华为待过，也在中小型互联网公司待过。对于大型团队来讲，主要是 Jira + Git + Jenkins + Docker（K8） 来搞定开发流程。通常团队里有专门的 CI 人员来维护这套研发流程，同时有 QA（近两年这个岗位基本都被撤了）来经常督促代码的质量门禁以及自动化测试用例的配置与建设。在版本不同的阶段会有不同代码质量要求，比如在第一个正式版本，可能只要求60%测试覆盖率，但在商用版本，可能就要求保持在80%的测试覆盖率。code review 也是强制性的，主要是核心开发骨干进行 review。
后来转到中小软件公司开发团队后，觉得自建开发工具链太费时了，而且太重了，需要额外的机器、人员、时间来维护这套东东，最重要的是跟不上我们快速的开发节奏（需求有时候一天3变）。所以就换了类似 CODING 这类研发流程工具。国内的产品虽然在功能上没有国外的产品那么强悍，不过毕竟纯天然支持中文，而且功能基本都有，有些项目管理上的交互我觉得更加适合中国开发者。
总的来讲：基本的开发流程都是 需求 - 编码（同时测试人员会开发测试用例）- 开发人员本地自验 - 代码门禁 - code review - Alpha 环境验证（开发人员、测试人员）- Beta 环境验证（开发人员、测试人员）- Gamma 环境验证（测试人员）- 生产环境（运维人员）。
想和大家分享一下我司的开发流程的。
我们从去上线了Worktile7.0版本，可以完美适配敏捷开发。
首先，Worktile的所有需求以看板或表格的方式展示。
还可以甘特图的形式展示。
最重要的是，Worktile有敏捷开发专用的【迭代】组件，可以一目了然的看清当前迭代的进展。
任务看板的属性支持自定义。
有时候一个需求需要拆分成多个子需求，这时就需要子需求或者关联其他任务。
同时，支持属性自动同步，例如更改了任务A的某个属性，任务B中的这个属性也自动同步变更，例如迭代、负责人等。
对了，之前还写过一篇文章，详细介绍我们是如何做产品需求管理的：《产品需求管理经验分享》，想了解的可以去看看。
当然，以上只是Worktile的部分功能，有兴趣的朋友可以戳「Worktile」免费注册试用下。
