大型公司开发软件的流程是怎样的？

像我们经常开发那些出了bug的话客户都会过来杀了你的软件（如SQLServer）的公司，我们的开发是很严格的。在保证功能完成之后，首要的一件事就是，确保软件不会给客户带来破坏。因此除了敏捷开发以外，我们主要做了三件事情来让码农不要在开发的时候太分心搞别的。

第一件事就是你做了一个关键的设计之后，会有一个负责security review的小组来看你的文档，问你问题，根据他们的专业经验指出软件哪里可能是会被攻击的薄弱环节。举个例子，你用了XML做配置文件，如果用户偷偷给你换了一个破坏过的XML，你的程序就会挂。一旦程序进入挂了的状态的时候，是很危险的。如果你试图恢复它然后继续运行，你就得考虑大量的细节，来把你的软件从错误的状态恢复到正确的状态。中间稍有不慎就容易被攻击。所以我们都鼓励说，一旦发生了这些不可逆转的破坏，就让程序自己出dump然后自杀。当然具体到XML这个例子，我们还有xsd文件，用Windows自带的MSXML组件来实现验证一下，所以还算是个小事。JSON就没这个福利了。

第二件事情就是，我们的环境搭得特别科学。譬如说你开发SQLServer2014，那你还要给SQLServer2008打补丁。2008打补丁的时候用的SDK和开发环境可能跟2014有巨大的区别。所以我们有一个Build Team，写了几万行的perl和bat脚本，来使得我们可以做到说，我们只要从2014的branch切换到2008的branch，这些工具就自动变了，譬如说cl.exe就从新的版本指向了旧的版本，库啊什么其他的乱七八糟的也是。如果你刚好用不上Visual Studio的话，只要你把代码从Source Control上搞下来，运行他帮你建立在桌面上的一个快捷方式，就可以打开一个cmd，里面的环境都配置好了，而且不会污染别的cmd。那我们就再也不怕手忙脚乱用错工具来开发导致出现更多问题了。一个人有可能要同时在不同的版本上干不同的事情，因此这是很重要的。因此我们也会把大量的二进制文件checkin进去，因此很多组尝试使用git最后都失败了（啊哈哈哈

Visual Studio组跟SQLServer做法也差不多。但是因为VS要用上一个版本来开发下一个版本（譬如说2010就是用2008写出来的），因此Source Control里面的脚本还要负责编译一个干净的、临时使用的、不在注册表里面捣乱的、热拔插的Visual Studio。你们想，如果我给2010写的代码出了翔，把2008的注册表阉割了，还是把几个文件删了，我再也打开不了2008来改2010，这种事情能被允许发生吗？不能！但是程序总是会出bug的怎么办？所以我们要有特殊的手段来解决这些问题，就是随时编译、checkin一个绿色的、但是功能丝毫不少的Visual Studio。当然这个东西只有Visual Studio组的人才有，而且长得跟正常的VS还是有显著的区别的。不过这样Source Control里面的东西就更大了，但是微软有的是硬盘，而且Perforce和TFS天生就对二进制文件支持的好，没关系，跟git什么的不一样。

第三件事情就是制度的问题了。产品狗在我们这里，责任很大，权力很小。原则上产品狗是管不了我们的，我们之所以听产品狗的话，是因为我们跟产品狗都有相同的目标——把软件做好。所以每当产品狗做了一些奇怪的决定的时候，我们可以很容易的拒绝他。他为了完成他们自己的工作指标，要么就要来说服我们，要么就只能改自己的决定了。因为产品狗和码农之间没有达成一致从而导致软件没按时完成的，产品狗具有很大的责任。我们还有专业的测试团队。测试团队的权力不小。譬如说产品狗提了一个需求，测试可以跳出来说这个功能会给测试带来无比的困难，从而拒绝产品狗的决定。因此产品狗的每一个决定，首先要保证可以被科学的实现出来。当然产品狗自己通常可能不知道什么是科学，所以我们要通过不断的打他的脸来让他明白，什么是科学。

// actually this should be a singleton, anyway I've made it global
Boss theBoss; 

Game* MakeAGame(Manager theProducer, 
                std::list& designers, 
                std::list& programmers)

{
	if (designers.empty())
		return NULL;
	if (programmers.empty())
		return NULL;

	Game* theGame = new (nothrow) Game(theBoss.GetALotOfMoney());
	if (!theGame)
		return NULL;
		
	// do the initializing work
	theGame->SetPlatform(theBoss.currentPhone.Platform);
	theGame->SetGameType(FindMostProfitableGameType());
	foreach (Designer designer : designers)
	{
		theGame->AddDesignDocuments(designer.docsFromElsewhere);
	}
	theGame->bugCount = 0;
	
	// the main loop (each iteration is a release cycle)
	while (true)
	{
		auto thisRelease = scoped_ptr(new Milestone());
		
		int intensity = theProducer.Push(designers, programmers);

		foreach (Designer designer : designers)
 		{
			designer.Press("Ctrl", "C");
			designer.Press("Ctrl", "V");
		}
		
		foreach (Programer programmer : programmers)
		{
			programmer.Hack(thisRelease, intensity);
		}
			
		theGame->bugCount += thisRelease->bugCount;
		if (theGame->IsPlayableWithoutCrash())
		{
			theProducer.Broadcast("Let's ship it!!!");
			break;
		}

		theProducer.CallForDelay();		
	}
	
	return theGame;
}

1. Program Backlog：所有的需求都会存在于一个完整的backlog,里面把需求breakdown成一个个的user story.是执行Agile的源头。可以作为Agile Team的输入。产生Program Backlog的人一般是产品经理或者是一个角色在agile中叫PO(Product Owner)。这个Program backlog要求蛮高，这个一般都是有文档化的东西或者网站管理的。

2. Cross functional team planning game: 当Program Backlog is ready,　Team 在planning game meeting 中进行commit.所有的user story都会被估成story point用来衡量工作量的大小，不用man hour来衡量的. 每个Team的velocity都有一定的bench maker,这是team对PO做commit的根据。

3. 通常是time box,一个sprint持续２周或者３周。但是一般都是固定长度的sprint.

4. 当team向PO做好了commit之后,就是team self-management的过程。一般所有的user stories 都breakdown成一个个的task贴在白板上了。采用daily stand up meeting每天跟进，这个都是没有文档记录的。

5. 当一个sprint做完以后，team要demo给PO，PO一个User story一个User story的验收，每个User story都有验收标准写在Program Backlog里面。当所有commit的User story被PO验收通话后，这个sprint就是成功的。如果有没有通过或者没有做完的就是失败的。

6. 每个sprint结束都要有retrospective meeting. TEAM 自己总结得失再制定AP做improvement.

基本上都是这样一个来回循环的做，在Agile里没有项目的概念，所有一个项目里的user story就要靠Program manager和Product owner 根据release roadmap去做计划。Program manager关注team的进度和产出，Product owner关注质量和具体的scope.在整个过程中，职能经历关注的更多的是团队的cross function 以及团队的成长和稳定程度。稳定是Agile Team的前提，不能经常变来变去，为了形成固定的team velocity.

请问以上agile日常，你看懂了吗？你看懂了的话，肯定是我没说清楚，你应该不懂才对！

类型IBM、微软、华为、BAT等大型公司，他们开发软件的流程，其实就是项目管理流程要包含的软件开发类项目管理流程，使用的方法论无非是IPD、IT-CMMI、SDL（安全开发生命周期）、敏捷项目管理等等，一般将几种方法融合使用，在自己的项目管理平台中实现落地，将各种质量控制活动（例如评审活动，特别是对安全的审核，也就是上面提到的Security Review）融入到项目的各个阶段。

项目阶段的划分，参考下图：

• 大型公司做一个IT项目往往是包含很多小项目并行的，最终组合实现一个商业目标。项目发起的过程不得而知，个人猜测是，公司高层提出想法，论证以后确定需求，划分若干小项目各自实现不同的目标，寻找合适的开发、管理人员开始项目，最后共同满足最初的商业目的。
  

• 大型公司一般不是自己独立开发软件，而是由一个甚至多个供应商（vendor）共同协作。如前所说，接触过的小项目超过5个，包括environment，testing等辅助项目，接近十个。它们由几个不同的软件/咨询公司共同协作完成。比如我来自一家小咨询公司，专做PMO，共事的同事来自Accenture，IBM，TaTa，Cognizant等等不同的咨询公司，可能一家公司负责一到两个项目，也可能一家公司只负责UAT或SIT。
  

• 软件开发不仅仅是写代码，个人认为Business Analyst 和 Project Manager才是项目的灵魂人物。这个program的产出将会用在亚洲许多国家，所以整个工作环境是全英文的，因此程序员们绝大部分来自印度。年轻时候总觉得程序员才是最重要挣得最多的那个，现在发现BA和PM才是，并且他们不一定知道怎么写程序。BA从用户也就是我们服务的公司那里拿需求，转达给Developers。把需求说清楚就是他们的主要工作，也是开发过程中很重要的一环。PM管理整个项目，进度控制，人力资源分配，问题和风险的管理等等。接触到的每个PM都来自不同的国家，不同的咨询公司，大多有10年-20年的工作经验。他们像是Director指明方向，程序员和BA们去具体执行。
  
  这是我平时用的timeline，具体进度用MS project管理， 这张图给management看~ 可见design&build占用的时间很久但是并非项目的全部，SIT,UAT等等测试也非常重要，对于其他一些项目硬件/环境的搭建也很耗时间。这一个个过程都是PM去管理指导的。

有关阿里集团在打造支撑百万用户的分布式代码托管平台，这里分享一篇阿里技术协会的内部文章，本文主要介绍了阿里巴巴集团代码服务团队，在过去一年基于GitLab进行的代码托管分布式改造，希望与大家进行分享与探讨，为云上开发者提供更好的代码托管服务。

一、背景介绍

毋庸置疑，代码是DevOps流程的起点，是所有研发流程的基础；代码托管为代码“保驾护航”，确保代码的安全性、可用性，同时提供围绕代码的一些基础服务，如MR、Issue等等。

阿里巴巴集团GitLab是基于GitLab社区版8.3版本开发，目前支撑全集团数万规模的研发团队，累计创建数十万项目，日请求量千万级别，存储TB级别，早已超过了GitLab社区版承诺的单机上限能力，且增长速度迅猛。

面对这种情况，顺理成章的做法就是——扩容。然而非常不幸，GitLab的设计没有遵守Heroku推崇的“The Twelve-Factor App”的第四条：“把后端服务当作附加资源”（即对应用程序而言，不管是数据库、消息队列还是缓存等，都应该是附加资源，通过一个url或是其他存储在配置中的服务定位来获取数据；部署应可以按需加载或卸载资源），具体体现是：

• Git仓库数据存储于服务器本地的文件系统之上
• GitLab所依赖的三个重要组件：libgit2、git、grit也都是直接操作在文件系统上GitLab

所以GitLab社区版是基于“单机”模式设计，当存储容量和单机负载出现瓶颈时，难以扩容！

二、面对挑战

2015年初，阿里巴巴集团GitLab的单机负载开始呈现居高不下的情况，当时的应对方案是同步所有仓库信息到多台机器，将请求合理分配到几台机器上面从而降低单机的负载。然而这个方法治标不治本：

• 系统运行过程中的数据同步消耗资源和时间，不可能无限制扩充机器
• 这种方案暂时缓解了单机负载的问题，但对于单机存储上限的问题束手无策

2015年中，团队正式启动了第一次改造尝试，当时的思路是去掉对本地文件系统的依赖，使用网络共享存储，具体思考和方案可以参见RailsConf 2016 - 我们如何为三万人的公司横向伸缩 GitLab。

然而由于本地缓存等问题的限制，网络共享存储的方案在性能上出现较明显性能问题，且大都为基于C/C++的底层改动，改造成本出现不收敛情况。而当时集团GitLab服务器在高峰期CPU屡屡突破**95%**甚至更高的警戒值，而高负载也导致了错误请求占比居高不下，无论是对上游应用的稳定性还是对用户体验都提出了严峻挑战。

2016年8月起新一轮改造开始。

三、改造方案

既然共享存储的方案暂时行不通（后续如果网络存储的读写性能有质的提升，未尝不是好的方式），首先明确了唯有分布式或者切片才能解决问题的基本思路。 我们注意到，GitLab一个仓库的特征性名称是"namespace_path/repo_path"，而且几乎每个请求的URL中都包含着个部分(或者包含ID信息)。那么我们可以通过这个名称作分片的依据，将不同名称的仓库路由到不同的机器上面，同时将对于该仓库的相关请求也路由到对应机器上，这样服务就可以做到水平扩展。

下面通过一幅图介绍一下目前集团GitLab在单个机房内的架构。

3.1 各个组件的功能主要是：

1. Sharding-Proxy-Api用于记录仓库与目标机器之间的对应关系，可以看作切片的大脑
2. Proxy负责对请求做统一处理，通过Sharding-Proxy-Api获取信息，从而将请求路由到正确的目标机器
3. Git Cluster由多组节点构成，每组节点内有三台机器，分别为master，mirror和backup。其中master主要负责处理写（POST/PUT/DELETE）请求，mirror主要负责读（GET）请求，backup作为该节点内的热备机器

说明

• master在处理完写请求后，会同步更新此次变更到mirror和backup机器，以确保读请求的正确性和热备机器的数据准确
• 之所以没有采用双master的模式，是不想造成在脏数据情况下，由于双向同步而造成的相互覆盖

3.2 保证方案可用

• 如何确保切片信息准确 Sharding-Proxy-Api基于martini架构开发，实时接收来自**GitLab**的通知以动态更新仓库信息，确保在namespace或project增删改，以及namespace_path变更、仓库transfer等情况下数据的准确性。 备注：这样的场景下，等于每次请求多了一次甚至多次与Sharding-Proxy-Api的交互，最初我们曾担心会影响性能。事实上，由于逻辑较为简单以及golang在高并发下的出色表现，目前Sharding-Proxy-Api的rt大约在5ms以内。
• 如何做到切片合理性 海量数据的情况下，完全可以根据namespace_path的首字母等作为切片依据进行哈希，然而由于某些名称的特殊性，导致存在热点库的情况（即某些namespace存储量巨大或者相应请求量巨大），为此我们为存储量和请求量分配相应的权重，根据加权后的结果进行了分片。目前来看，三个节点在负载和存储资源占用等方面都比较均衡。
• 如何处理需要跨切片的请求 GitLab除了对单namespace及project的操作外，还有很多跨namespace及project的操作，比如transfer project，fork project以及跨project的merge request等，而我们无法保证这些操作所需的namespace或project信息都存储在同一台机器上。 为此，我们修改了这些场景下的GitLab代码，当请求落到一台机器同时需要另一台机器上的某个namespace或project信息时，采用ssh或者http请求的方式来获取这些信息。 最终的目标是采用rpc调用的方式来满足这些场景，目前已经在逐步开展。

3.3 提升性能

• ssh协议的替换 目前阿里巴巴集团GitLab提供ssh协议和http协议两种方式，供用户对代码库进行fetch和push操作。其中，原生的ssh协议是基于操作系统的sshd服务实现，在GitLab高并发ssh请求的场景下，出现了诸如这样的bug：

由此产生的问题是：

ssh协议登陆服务器变慢

用户通过ssh协议fetch和push代码时速度变慢

为此，我们采用golang重写了基于ssh协议的代码数据传输功能，分别部署在proxy机器以及各组节点的GitLab服务器上。由此带来的好处有：

机器负载明显降低

消除上述bug

在ssh服务发生问题的情况下，仍旧可以通过ssh登陆（使用原生）服务器，以及重启sshd服务不会对服务器本身造成影响

下图是proxy机器采用新sshd服务后的cpu使用情况：

• 个别请求的优化和重写 对于一些请求量较大的请求，例如鉴权、通过ssh key获取用户信息等接口，我们目前是通过文本转md5，加索引等方式进行性能优化，后期我们希望通过golang或java进行重写。

3.4 确保数据安全

• 一主多备 如上面提到的，目前阿里集团GitLab的每组分片节点包含有三台机器，也就是相对应的仓库数据一备三，即使某一台甚至两台机器发生磁盘不可恢复的故障，我们仍旧有办法找回数据。
• 跨机房备份 刚刚过去的三月份，我们完成了阿里巴巴集团GitLab的跨机房切换演习，模拟机房故障时的应对策略。演习过程顺利，在故障发生1min内接到报警，人工干预（DNS切换）后5min内完成机房间流量切换。 多机房容灾的架构如下图所示： http://pic3.zhimg.com/v2-3716c090e30a9b82f147dc3659a869d6_b.png 保证准实时的仓库数据同步是机房切换的基础，我们的思路按照实际需求，由容灾机房机器主动发起数据同步流程，基本步骤是：
• 利用GitLab的system hook，在所有变更仓库信息的情景下发出消息（包含事件类型及时间包含数据等）
• 同机房内部署有hook接收服务，在接收到hook请求后对数据进行格式化处理，并向阿里云MNS（Message Notify Service）的相关主题发送消息
• 容灾机房内，部署有消息消费服务，会订阅相关的MNS主题以实时获取online机房发送到主题内的消息，获取消息后调用部署在容灾机房GitLab节点机上的rpc服务，主动发起并实现数据同步的逻辑
• hook接收、消息消费以及**GitLab**节点机上的rpc服务，均由golang实现。其中rpc服务基于grpc-go，采用protobuf来序列化数据。 通过一段时间的运行和演习，已经确定了方案切实可行，在数据校验相关监控的配合下，容灾机房可以准实时同步到online机房的数据，且确保99.9%至99.99%的数据一致性。

3.5 如何提升系统的可用性

• 日志巡检 面对集团GitLab每天产生的大量日志，我们使用阿里自研的监控工具进行日志监控，对系统产生的5xx请求进行采集和报警，然后定期去排查其中比较集中的错误。经过一段时间的排查和处理，5xx错误日志大致可以分为：
• 分布式改造带来的跨分片操作的bug
• GitLab本身的bug
• 高并发情况下带来的系统偶发性故障
• 数据库相关的错误等
• 由于用户量大，场景多，阿里巴巴集团GitLab的使用场景基本覆盖GitLab的所有功能，因此也可以暴露出一些GitLab自有的bug。如Fix bug when system hook for create deploy key（从此，咱也是给GitLab供献过代码的人了）。
• 服务器监控 无论系统多少健壮，完备的监控是确保系统平稳运行的基础，既可以防患于未然，也可以在问题出现时及早发现，并尽可能减小对用户的影响。目前阿里巴巴集团GitLab的监控主要有：
• 机器cpu，内存、负载等基本指标的监控
• ssh、ping等网络检测信息（用于判断是否宕机，后将详述）
• 服务器各个端口的健康检查（80，90xx，70xx等等）
• 异步消息队列长度的监控
• 数据库连接的检查
• 错误请求的监控
• Sharding-Proxy-Api与GitLab的数据一致性校验
• 很自豪的一点是，我们经常可以根据报警信息，先于用户发现问题。
• 单机故障的自动切换 虽然监控足够完备，但谁也不能保证服务器永远不宕机，因此我们在同一组节点中保有一台backup机器以应对服务器故障。会有专门的client定期通过API轮询监控平台提供的机器监控信息，当确认机器宕机时（ssh和ping同时不通，且持续时间超过2min）自动触发机器角色的互换，包括master与backup互换，mirror与backup互换等。通过演习，我们已经具备了单机故障时5min内全自动实现机器切换的能力。
• 机房故障时的切换 即前述的跨机房切换。

3.6 单元化部署

单元化架构是从并行计算领域发展而来。在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作的自包含的安装。而一个分区（Shard），则是整体数据集的一个子集，如果你用尾号来划分用户，那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。

为了实现单元化的目标，我们在最初设计时就往这方面考虑。比如跨机房备份中，消息消费应用需要调用**Sharding-Proxy-Api**获取rpc服务的地址时，尽可能做到数据在单机房内闭环。这样在满足单元化要求的同时，也可以在机房故障时，尽量不影响已进入队列的消息在消费时出现数据断流。

现在阿里巴巴集团GitLab在架构上已经基本具备了单元化部署的能力，这样的情况下，无论是后续与阿里云合作对外提供服务，还是当收购海外公司需要单独搭建新服务时，都不会遇到问题。

四、未来的改进

4.1 偶发的cache大量释放

由于GitLab有大量的IO操作，使得系统占用cache的数值巨大，也正是因为cache，系统的性能得到保证。然而成也cache败也cache，为了确保系统不会发生OOM，我们设定了vm.min_free_kbytes，当cache占用过多且需要继续申请大片内存时，会触发cache的释放，势必会影响释放瞬间请求处理能力（通过日志分析得到，此瞬间的处理能力仅为cache存在时的1/2左右），直接后果是该瞬间的请求堵塞，甚至出现部分502。

为此我们咨询了系统部的同学，根据他们的建议修改了部分内核参数（目前仍没有根治），后续会尝试升级内核的方式，也希望遇到过类似问题或对这方面问题有研究的同学，把你的秘籍传给我们。

4.2 自动化运维

目前集团GitLab的发布主要靠手，在分布式架构下，机器势必越来越多，全自动化的发布、扩容机制，是我们需要完善的地方。

4.3 rpc方案的最终落地

如前所述，只有最终实现了全局的rpc替换，才能将web服务所消耗的资源与Git本身消耗的资源进行分离，阿里巴巴集团GitLab的分布式改造才能算最终结束。

后续

监控及日志数据对比显示，过去一年中阿里巴巴集团GitLab请求量增长4倍，项目数增长130%，用户数增长56%，在这样的增速下，系统调用的正确率却从99.5%提升到了99.99%以上，这些数字印证了我们方案的可行性和可用性。

接下来的时间里，小伙伴们会为继续代码服务的创新而努力，“高扩展、分布式、响应式、大文件、按需下载、流控、安全、数据化、单元化”，有些我们做到了，有些是接下来努力的方向。

现在阿里巴巴集团GitLab的架构，已经足够支撑百万规模的用户体量。在经过阿里工程师、开发者的千锤百炼之下，我们有勇气和信心通过阿里云code（阿里云代码开发服务现可免费使用）为更多的开发者提供代码托管服务，共同打造云上的协同研发生态！

本文作者：billy.lb 屹恒

有关：阿里云 code

这是一款从未在外面推广过的代码托管产品，估计很多人还不知道阿里云有这个服务。阿里云code旨在解决部分中小企业选择内部自行搭建 Git或SVN ，势必会遇到搭建、维护成本高，难于扩展和备份，数据安全和可靠性差的问题。

核心优势——阿里云上基于Git的分布式代码托管，高可用、安全、高性能以及无限容量是其核心竞争力，支持svn仓库的便捷迁移。

目前已面向个人或企业免费提供Git及SVN两种协议模式的代码托管服务：点击免费使用

更多几乎干货请移步：我是程序员 - 知乎专栏

软件和公司都分大型小型。对于软件来说，针对个人的算小型，也就是桌面应用，针对企业组织的算大型。公司么，就是人多人少，有的公司是产品性公司，有的公司是项目型公司。

我比较熟悉的针对金融行业的J2EE软件，通俗来讲，就是给银行保险公司投资公司等用的核心系统。这个领域除了互联网金融，其实电子化率很低，银行稍微高些，其他的保险公司也好，基金公司也好，很多中小型的，甚至真的用excel而已。原则上，和这些公司工作，流程基本上都是：

首先做售前和销售，这个时候多少会演示下系统，有的公司还会给你几个功能尝试下，这个叫POC。然后签合同，合同一般是分步签的，这个不细谈。

签完合同，给客户上课，把基线系统给客户演示，然后客户根据他们自己的需求，提功能需求，这个阶段叫workshop。

然后业务人员针对客户需求，写功能文档，当然，还有一部分非功能要求，叫做NFR，这是由架构师负责的，还有专门的集成部分，因为金融系统大多很多年，通常有十几个系统互相集成， 这些都写完，开始设计。

设计阶段主要分三个部分，概要设计，这个部分是看整个系统是否要大改动，比如我现在正在做一个项目，要把常用框架升级到Spring全家桶，这就在概要设计部分展开。

其次是高层设计，这个会针对每个功能点，详细写下什么地方如何改动。

然后是底层设计，这个部分会写伪代码和功能测试用例，用来给开发中心进行编码。

在开发中心编码的过程当中，还要采用CI的概念进行开发质量管理，直到提交。

代码完成了以后，提交发布，放到测试服务器进行人工测试和自动化测试，直到符合标准。

之后是客户SIT，这是系统集成测试，放到客户环境，和客户其他系统进行对接测试，看看通讯是否成功。

然后是UAT，这是客户的最终用户进行测试，用他们实际业务当中的行为进行操作。同时也是对他们的培训。

之后是上线，上线之前可能还要进行冻结以便进行数据迁移。

然后是保修期，一般1到3个月，这个过程当中，免费修bug。

然后是维护合同，按照合同对软件进行修bug和二次开发。

【谢邀】

企业在使用软件的时候可能会先考虑成品软件，因为节约时间，不需要开发周期，但是成品软件的一大缺点是功能上使用不灵活，不能满足客户大多数需求。因此为了更好的用户体验，大多数企业会选择软件开发公司开发。在开发过程中，有必要了解一下开发的流程，更好的和外包公司做好紧密配合。那么，今天我们就来谈谈大型公司开发软件的流程是怎样的？

一、需求调研、需求分析

这是整个软件定制开发过程中非常重要的环节，是盖房子打地基的环节。需要需求方和软件开发方的紧密配合，包括需求的收集，需求的分析整理，需求的评审，需求的变更管理等过程。很多需求方在选择了软件开发厂商后，就只等软件开发放交付系统，双方没有经过充分的需求沟通而交付的系统中间肯定会出现分歧，导致后期的推拉托现象，交付时也会造成用户满意度较低。确定需求细节时软件能否成功开发的基本保障，因此这一环节一定要足够重视才会验收到好的产品。

二、原型设计、产品设计、界面设计

根据第一阶段的收集整理的需求，进行系统的架构和设计。设计工作一般主要由软件开发方的设计人员完成，界面的设计也在这个阶段。如果是基于软件产品基础上的定制开发，那么需要考虑在现有产品的功能、设计和技术架构下进行设计，结合现有的业务需求，这就要求现有的软件产品需要具有较好的架构和设计，拥有较好的扩展性和二次开发能力，同时需要考虑到个性化的开发不能够破坏现有产品的设计，否则后续产品的升级需要重新整合和开发，成本和工作量非常大。

三、程序编码

这个阶段就开始系统开发了。需要根据前面确定的软件定制开发需求以及系统设计的确定，组织开发人员进行系统代码的编写。需求方常常很难将需求一次性提交完毕，常常会在开发过程中涉及到需求的问题，这中间需要与系统开发方进行设计细节的讨论和调整。一般大调整需要需求方增加薪酬。开发人员需要对需求方提出的问题进行充分理解，并确定到软件需求中，对代码进行合理规范的编写，并且保证质量，确保不会影响软件系统的质量和稳定性、安全性等方面的影响。

四、软件测试

系统开发完成之后进入测试阶段。软件开发人员需要根据开发完成的商品对照第一阶段中确定的需求进行测试，检查系统功能性、性能、安全性等方面整体测试。一般先由软件开发人员测试流程是否走通，再由双方一起进行同时测试。对于测试中发现的问题，一般提交开发人员进行修改，再进行回归测试(针对修改过的问题进行测试和验证)。系统测试是软件定制开发中准备收尾的重要环节，需要双方紧密配合，随时联系，合理规划好时间，保证测试的顺利进行是软件系统开发的根本保障。

五、打包发布

系统开发完成后部署在最终用户的正式运行环境，交付给最终用户使用，同时需要对相关的人员进行培训。这个环节中软件的推广和使用是重点，直接关系到软件的应用效果。软件在正式运行过程中会遇到系统错误、使用问题、功能的完善和修改等，软件开发方需提供相应的服务确保最终用户系统正常稳定的运行。

从以上描述中看软件定制开发整个过程，确定需求和测试阶段是需求方和软件开发方需要高度配合的重要阶段。软件定制开发的周期和复杂程度是由需求方决定的，对于业务需求比较简单的环节可以省略或合并。想要定制软件开发的用户可以先了解，以便后期与开发企业的沟通。

------------------------------------写在前面的吐槽......可以跳过-----------------------------

答主在2016年写了这个答案:写工业级别代码是怎样一种体验？, 当时也比较年轻，基本上是以抱定“工业标准一定是宝贝”的心态写的那个答案，可以说当时答主对aSPICE和ISO26262 part6 的流程推崇备至，然而这些年渐渐有了些新的感悟。

答主这几年也是比较坎坷，公司换了两家，部门换过四次，在中、美、德、英四个国家的汽车软件部门工作过，见识了不同的流程和文化，令我惊奇的是，所有这些公司、部门和项目，有一点是相同的：都是世界前五名的汽车零部件供应商哦，居然从来没有一个项目完全遵循了aSPICE和ISO26262 part6流程...

关注我的不少童鞋也在汽车行业：有一家算一家，甭管您是国内的、国外的，国企还是外企，传统车厂还是新势力，主机厂还是零部件，有哪位能告诉我你们是严格按照这两个流程来开发软件的？我真的很想知道。

这就说明问题了。我开始思考，也许不是这届项目管理不行，而是这些流程出现了一些问题，已经不太适应现在的汽车软件开发，特别是HAD（Highly Assist Driving）大背景下汽车软件的开发了。在此，我想结合我的项目经验，谈一谈我理解的实际的软件开发流程。事实上，我们很多部门已经开始在做这方面的实践，并取得了不错的成果。

-----------------------------------吐槽结束，下面是正文...----------------------------------

×××（一）写在前面 ×××

首先，结合我自己的专业，我想谈的是汽车行业里大型（超过一百万行代码）、重大安全系统（safety-critical system）软件的开发流程。业内对此有已经两个流程标准：ISO26262 part6 和aSPICE。前者现在是发布汽车相关软件必须遵守的标准，而后者基本上只有大众、戴姆勒等几家德国车企才强制要求（从我和他们打交道的情况来看，我都很怀疑他们自己内部遵不遵守这些流程..）。

关于这些流程的扫盲贴可以看这个答案： 写工业级别代码是怎样一种体验？ ， 相关细节这里就不重复了。

我在这里想探讨的，是一种与敏捷开发相结合的V型开发流程。这并不是我凭空生造的，而是我在实际项目中部分实践过的流程，很希望在这里和大家交流。

×××（二）V型流程的弊端 ×××

无论是ISO26262 part6 还是aSpice，它们的核心都是“V型开发流程”，说白了就是个变形的瀑布（Waterfall）流程。

吹到天上，架构设计也要等软件需求文档冻结了才能进行，而单元设计要等架构设计文档冻结才能开始。每一级依赖上一级的完整输出作为本级的输入。讲真，在实际项目里，真的非常容易窝工！一旦软件计划或者资源上有一点变动，比如需求临时变更，或者架构师被领导临时抽调，那真的是产生连锁反应，整个项目后续都受影响，最后就是无穷无尽的加班。

再者，现在市场的实际情况就是，软件需求是永远不可能冻结的！V型流程建立的基础都快没有了。现在HAD功能大量上马，OEM们争分夺秒逐鹿蓝海，别说造车新势力，就是传统主机厂，也是不可能等到功能完全想明白了、写好了再把完整的需求文档给你的。往往都是先搭个框架，有个大致想法，需求就发布了。紧接着就是一遍一遍的沟通、测试、修改，大家都在抢时间，每周都有新功能进来。就这，你还指望软件需求有冻结的一天？！做梦呢。往往是上一版刚冻结，后续还没展开，新需求就又来了，所有人都崩溃。

第三就是“人”的问题。这个问题很影响项目实施，但我从来未见有帖子认真讨论过，所以想多写点。很多关注我的童鞋都是业内人士。我想问问你们，在实际情况里，上图的6到11这些环节中，您觉得那个环节最重要、薪水最高、最有意思、领导最重视、最容易升职/跳槽啊？

毫无疑问是7和8，架构设计和功能单元设计对吧，没悬念嘛。那么哪个环节或者职位最不受重视、薪水最低、最无聊枯燥、最不容易跳槽啊？6软件需求/需求工程师啊，完全没职业发展嘛。大一点的企业甚至干脆外包了对吧，咖喱味的需求有没有？

事实就是，做软件需求工程师和测试工程师的童鞋，但凡有经验、有能力、有机会的，都会努力转成控制工程师或者架构师，这家公司转不了，哪怕跳槽也要转。说句得罪人的话，您公司里的需求工程师，是不是相对来说，都是对产品不那么熟悉、经验不多，或者水平欠佳的同事在担任啊？

然而，要命的是，按照V型开发流原本的定义和初衷，最最重要的职位恰恰就是需求工程师。需求是一个项目的根本，是项目执行的第一级，可以说一切的一切都是围绕软件需求展开的。一个水平欠佳的需求工程师，不到位的理解和水平欠佳的需求文档，往往会给项目带来灾难性后果，有些甚至是后期弥补不了的。我想这一点童鞋们或多或少都有体会。

需求工程师的缺位，更是加重了V型流程的弊端。

×××（三）保留V型流程的核心 ×××

在讨论完弊端以后，为了改进流程，我们要明确一下V型流程的核心，把它们保留起来，取其精华去其糟粕。

就像我在之前文章里论述过的， V型开发流程的核心有两个：1.实现分层次的测试和验证 和2. 建立完整的可回溯性。这两点是一定要保留下来的。否则在软件发布以后，根本就没法通过ISO26262或者aSPICE的验收审核。

分层次的测试，也就是单元测试（Unit Test）、集成测试（Integration Test）和硬件在环测试（HIL Test， Hardware in the loop），这些是必须的，没法省略也没法变动。但是，为了提升流程的灵活性，在文档的完整性和可回溯性上，我们可以适当做一点妥协。V型流程要求每一步骤都要时刻建立完整的文档和可回溯性，然后才能进行下一步骤。根据实际项目经验，我认为，这一要求可以放宽到“在成熟软件发布的时候，具有完整的文档和建立可回溯性”。用通俗的话讲就是从制度或者从流程上允许“先写代码后补文档”的做法，或者说，“文档、代码一起写”。

当然，这种妥协一定有一个前提，就是项目团队有充分的沟通和项目组长有清晰的框架，从我的实际项目经验来看，这是不难做到的。

×××（四）与敏捷开发相结合的V型开发流程 ×××

为了解决传统V型流程的的弊端，我在项目实践中引入了一些敏捷开发的元素，比如Scrum master，Sprint，Kanban Board等等，这里我们暂且先不讨论这到底是“真正的”敏捷开发还是只是借用概念。

这套改进的流程有两个要点：

1.与原有的V型流程在结果上兼容。在成熟的软件发布时，用新流程开发的软件同样具有完整的文档、完整的可回溯性以及完整的分级测试报告。新流程完全不影响原有的项目审核和质量控制。

2.新流程右侧（测试侧）不变，而左侧（设计侧）由瀑布式开发变成了“敏捷式”开发。各个步骤从原来的次第进行变成以Sprints的形式齐头并进，最大限度地提升灵活性。

下面我详细阐释一下新流程。

项目组长扮演Scrum Master的角色，组织例会。例会上需求工程师、架构师、基础软件工程师、应用层工程师（控制工程师）每人阐述本周的进度，对新需求或新修改项达成一致认识。这种认识是通过非正式的形式，比如口头沟通、演示来达成，并通过email和会议记录的形式（而不是冻结的完整文档）明确固定下来。随后组长明确这周的任务，并设置关键结点，形成一个Sprint，每位工程师开始完成自己规划的任务，发现问题快速反馈，这是并发的。

当关键结点到来的时候，再次例会，组长查看进度并根据新需求制定下一个Sprint的任务。这样随着Sprints的进行，最终会形成完整的需求文档、设计文档和代码，同时完成可回溯性文档。随后一切就和传统V型流程一样了：交付集成工程师进行集成，随后进行各级测试。

×××（五）新流程的人员配置 ×××

为了实现这种新流程，软件团队的人员架构也需要做一定微调。项目组长与需求工程师、架构师、基础软件工程师、应用层软件工程师组成一个敏捷开发小组，而软件集成工程师和测试工程师需要在敏捷开发结束后才进场工作，不再属于某个开发小组，而是为所有小组服务。

需要注意的是，这种架构对项目组长提出了非常高的要求。高并行意味着各位工程师在执行自己任务时候可能会有冲突。组长一定要有能力协调好已经发生的任务冲突，并且还要有能力预见未来的冲突；另一方面，由于每个工程师的任务毕竟是模糊定义的（没有冻结的文档），组长要有全局掌控的能力，并和每位工程师流畅沟通并确认工程师已经充分了解自己的任务。

可以说，组长的能力是能否实现新流程的一个要点。不过我的参与过的项目中，这是实际实现过的。而我自己也做过项目组长，新流程并没有复杂到无法实现。

×××（六）新流程的优势与劣势 ×××

可以说，新流程的优势是明显的。首先，新流程灵活性大大增加，窝工情况缓解。每位工程师在每个Sprint的开端就（以“模糊”、非正式的形式）明确了自己的任务——如前所述，这种任务以Email、会议纪要的形式固定，以和组长的沟通来保证正确性——不必再等待自己前级的输出。就算架构师消失一周，其他工程师照样能写自己的代码/文档。架构师消失只会影响他自己的进度，最后只有架构师自己加班而不是拖累全员加班。

其次，新流程不必等待需求文档冻结。客户给一点我们就做一点，客户要改、要加料，研发团队可以从流程上随时奉陪，非常契合现在造车新势力和自动驾驶相关研发的节奏。

最后，新流程一定程度上可以弥补需求工程师的缺位。在String的执行中，任务分配可以比较灵活。原来由需求工程师承担的任务可以分配一部分给其他工程师。比如与客户的沟通、技术谈判，对需求的分析和确认等等，如果需求工程师能力足够，则这是他的本职工作；如果需求工程师能力、经验欠佳（这是普遍情况），则这部分工作可以分配给架构师、控制工程师来完成，而让需求工程师退化为一个把文字打进DOORS系统里的打字员或者文档整理员...（这也是从我们的项目实践里无奈的总结出来的）。

新流程也有着他的劣势。比如，高并行意味着对所有工程师都提出了更高的要求，无论是经验、技术还是团队配合都要求更加严格，这无疑对企业是一个新的挑战；特别是项目组长，更是一定要由经验丰富的员工担任，导致小企业里可能没有足够数量的员工能够胜任组长。然后，组长如果消失了，比如病了、或者跳槽了，对项目会有相当大的打击。

您别说这例子还真发生过。曾经有一次一个项目组的英国组长连续休假三周（不得不说欧洲人假期就是多....）,导致项目进展缓慢，气得客户打电话过来骂人.....不过这应该是企业整体考虑的问题，比如设置第二组长等等。

-----------------------------写在最后---------------------------------

这篇文章我想写给有一定基础的汽车软件从业人员，所以中间如果有解释不够细致的地方还请见谅。也可以留言提出意见让我修改。在此答主也是抛砖引玉，希望和大家共同交流～

话说，这篇文章有一个后续：

你如何理解敏捷开发？

如果你觉得我这个答案不错，也许你会喜欢我的专栏：汽车软件工程师生存手册

Tier1 汽车供应商的一枚小工程师飘过~

比较懒，就拿了个蔚来汽车在mathworks汽车年会的演讲PPT来举个栗子吧~

关注公众号：汽车ECU设计

一个菜鸟汽车程序猿的成长之路~