梳理和总结下团队中的开发流程和一些我认为重点关注的细节。
背景
在资源有限的小团队：
- 团队规模较小，资源比较有限
- 开发流程较为简单
- 基础设施不完善
- 团队直接的沟通比较方便和直接
规模较大的大团队
- 团队规模大，数量对
- 开发流程完善，相对于的也较为复杂
- 基础设施较为完备
- 多团队或者跨团队沟通
团队的开发流程
通常大致的开发流程如下：
- 需求收集（可能来自产品自身迭代、用户临时需求、缺陷等）
- 产品规划版本需求范围，出交互
- 交互评审
- UI设计出UI稿
- UI评审
- 开发测试评估工时，大致确定版本发布时间
- 启动会
- 开发
- 送测（多轮）
- 发布
- 复盘
其实不管是什么团队，软件开发通常都是上述的流程，不过不同团队规模之间，其每个环节之中的细节也不一样，而且每个团队之间同样存在差异。影响其中的原因在于，一个是团队规模，一个就是所谓的基础设施，然后就是团队整体的风格。
而我认为，整个开发流程，主要关注三个方面：效率、风险和质量，下面我就梳理一下整个开发流程中，我认为需要重点关注的内容。
产品需求和迭代
不同团队产品在一开始出需求和迭代进行版本规划时，会有不同的差异，同时也会存在一些问题。
软件开发通常以版本迭代为一个周期，产品在进行版本规划时，一般会准备相应的需求，并确定大致版本的周期，这里通常分为以需求来确定版本周期以及版本周期来确定需求范围两种情况，它们之间的差异主要是看业务和公司情况，两种方式并不是说哪种更好，而是适合不同的情况。
- 以需求来确定版本周期，通常在需求为核心的前提下，来定义版本的时间范围，例如重要功能期望尽快上线，或者存在紧急需要处理的需求时。这时候以需求为核心，版本周期的时间不会太长。
- 以版本周期来确定需求范围通常都是产品或者市场在提前规划好了时间后，在这个时间周期内，需要完成哪些需求，这更像是一种偏正常的规划，什么时间上线哪些功能都处于一个计划中。
通常这个环节属于一个版本迭代开发前的准备阶段，用以确定迭代的需求范围、时间。并且这个阶段的准备在开发团队的上一个迭代快要结束时，就应该准备好了。这里的需求不仅仅是新功能，还包括上个版本的遗留问题、技术优化、质量优化等
产品、UI评审
在产品大致规划好某个版本迭代后（通常这个阶段版本负责人和测试那边也会参与讨论），并且等产品的需求交互文档出来后，在上一个迭代的末尾则可以拉上开发和测试等相关人员进行需求评审。
在评审时，通常产品会提前将交互、UI稿交由开发进行查看和了解需求，并且在存在问题时，可以提前和产品进行沟通讨论。
通常我们使用的figma可以对交互和UI在线进行标记和评论，可以简单的在上面进行评论让所有人看见，对于有疑问的或者有误的可以指出并让产品解答补充细节或者改正，如果有复杂问题的，则可以直接标记并找产品进一步沟通。这样在正式开启需求和UI评审时，开发已经理解和熟悉了需求，并且一些明显问题也已经提前沟通，提高评审会议的效率，并且也提高了交互、UI评审的通过率。
如果评审通过，则进行下一步的排期，如果评审不通过，则评审失败，预约下一次评审。
通常评审通过后，则开发、测试会给出一个大概的开发估时，以便确定和产品所定义的迭代周期是否大致一致，如果不一致则讨论需求的简化或者删减，或者迭代周期延长。
版本负责人
版本负责人在不同公司可能有不同的说法，其实本质上就是协调把控一个版本的进度是否符合预期，他不一定是开发负责人或者产品，也可以是某一个开发人员。
通常它在版本的需求收集阶段，例如产品需求收集和迭代的周期规划时就已经参与，他基本上属于全程参与整个迭代周期之中，包括后续的版本复盘。
它通常有以下职责：
- 参与版本迭代的建立，包括版本需求范围、任务拆解、版本时间节点等
- 对迭代的进度把控，保证版本迭代的顺利进行
- 在各团队之间进行协调沟通，例如产品、测试、开发团队，甚至是和当前迭代无关的其他团队
- 评估和识别风险，并及时调整和规避
- 对版本进行总结、复盘
例如：
- 在产品初始阶段，和产品一起讨论沟通需求范围，确定大致的产品周期
- 确定迭代中各个阶段的时间节点，例如需求评审节点、开发节点、送测和发布节点，并对其进行记录，以把控迭代进度
- 迭代进行时，积极和开发、测试确定时间节点是否存在风险，例如是否有延期的可能，期间是否发现了一些问题，需要和产品、测试进行沟通协商
- 送测管理、发布管理等
- 迭代结束后的复盘，例如缺陷数量、延期时间、迭代中出现的问题总结等等
为什么会有版本负责人？，版本负责人有一些几个好处：
- 沟通效率：指定负责人并明确人的职责，在各团队间达成共识，避免出现一个迭代多个“负责人”，但是都只负责自己团队的部分，而无法关注整个迭代，导致不同团队之间对于其他团队的进度和风险没有一个明确的认知，这样会影响各个团队间的沟通效率。
- 提高迭代开发效率：将一些迭代过程中的职责进行抽离，例如送测、发布、迭代进度的记录等等，专门有人对这些事情进行关注，这样可以更好的把控整个迭代的节奏和风险，提高迭代开发的效率。其实这些事情对于开发和测试来说是一件非核心必要的事情，也就是我有这个责任心我就可以做，但是我不做，也不会有人说什么，不能依赖人的主动性，而是依赖于制度。
- 避免管理任务过重：避免在多个迭代同时进行时，一个人负担多个版本负责人，从而导致其身上的管理事务太重，因为版本负责人原则上谁都可以胜任（通常开发会好一点）
版本开发启动
通常，在版本负责人的推动下，明确了需求，对需求、UI进行评审后并各团队确认无误后，则可以开始拉上各方进行最后的确认，包括需求、各个阶段的时间节点等。
这里比较重要的是迭代中各个阶段的时间节点和开发之间对各个需求完成的时间节点，以便开发之间确认自己的前置任务的完成时间（例如前端需要联调时的后端接口何时能提供等），由开发之间以及负责人在会议之前进行协调和确认。
技术方案和评审
在开发正式进入开发前（最好是需求评审完成后），如果某个需求较为复杂，可能开发会自行输出一个技术方案，并进行技术方案的评审，开发在需求评审之后就可以考虑需求的复杂度，来决定是否需要进行评审，他可能不仅仅是技术上的，也可能是业务上的（例如业务改造）
是否进行技术评审目前并没有硬性的标准，我个人倾向的是由开发人员进行决定，这更多的依赖于开发人员的经验，经验丰富的人可以帮忙进行评估一下。单纯的依靠工时来确定，也并不准确。
技术方案评审本身是非常有必要的：
- 面对一些复杂技术问题、复杂业务或者涉及到多个团队间的业务修改时，有一个份技术方案来让多个开发人员进行评估，以尽量避免考虑不周、设计过渡或者方案不合适等问题，也就是所谓的集思广益。提高产品质量。
- 而复杂业务和大的业务改造涉及到的团队比较多，例如测试和后台，这样就需要一个技术方案会议对该业务的实现同其他团队达成一致，避免后续的沟通成本。
测试用例和自测
通常测试在每个迭代时，都会输出一份当前迭代需要的测试用例。这个基本上是常规操作，这里主要提一下送测质量问题。
测试流程本身是用来验证开发完成的功能是否出现bug，送测质量影响了测试本身的流程，同时也是迭代中最常见的风险点，这里提一下开发和测试之中常见的一些问题。
- 测试功能的主流程是否没有问题：主流程是指整个功能是否同需求描述一样完备，例如某个功能入口连进都进不去或者没有作用，那测试对于这一个功能的测试基本上是无法进行下去的。
- 边界问题：这里指在需求中并未提及和识别到的边界场景的处理
- 开发和测试理解不一致
边界问题和开发和测试理解不一致的问题会在送测章节细说。这里说一下和自测本身相关的问题。
通常为了保证送测的质量，通常开发在完成功能开发后，会进行自测，这通常是最好解决送测质量的问题，然而这里的问题在于如何进行自测？
- 自测本身是比较耗费时间，如果全部按照测试本身的测试用例去走一遍，那开发走完一遍自测的时间会非常长
- 开发自己完整自测了一遍，然后测试再走一遍，虽然能保障质量，但是就效率本身而言非常低效。
- 第一次送测和后续缺陷修复时的送测，能够统一对待吗？
所以，通常来说，在自测时会用一下几个策略：
- 为了避免测试进行过程中，某个功能测试进行不下去的问题，测试会将功能核心流程，通常也叫主流程的测试用例标记出来，这些用例在每一个送测阶段，开发都需要保证其能够通过
- 同时为了效率和质量的平衡，开发在第一次送测试，会走完重要的测试用例（p0：主流程和p1：重要），并进行尽可能多的覆盖所有的测试用例，而在后续阶段的送测时，只需要过主流程和本次修改所影响功能的测试用例即可。
通过以上两点，通常可以防止在第一次送测时，缺陷爆炸，同时在后续的送测时也能够避免阻塞测试的情况。虽然开发在第一次时所需要自测的工作量也不小，但是由于第一次的送测质量本身对迭代是否可以顺利进行至关重要，所以在评估效率和质量时，仍觉得是有必要的。开发也需要预留这一部分的时间。
当第一次送测，出现缺陷爆炸（非技术方案设计缺陷或者需求问题时），那么后续基本上很难补救，基本上延期是大概率的，因为当该次送测出现大规模缺陷时，那么后续的第二次送测基本上仍要将其视为第一次送测，因为缺陷太多，影响的功能太广，基本上等同于整个迭代的测试用例都要再重新过一遍了。这和排期时第二轮、第三轮测试工时的定义是相悖的。
送测
送测流程
当开发完成并且自测通过后，就可以准备送测流程了
个人倾向的送测形式是需要一个标准的流程来进行的，因为在送测阶段，我们需要：
- 明确送测的阶段和节点，避免开发阶段和测试阶段出现混淆，测试是否开始、测试是否结束、测试是否通过等
- 送测时需要开发通知给测试的一些必要信息，包括测试环境、影响范围、注意事项等
- 送测阶段的历史记录，方便回溯和查看
关于这一个阶段，可能团队规模较小时，没有一个标准的规范流程去做，例如开发直接将项目发布到测试环境后，告知一下测试，测试就直接进行测试了。这通常无法满足上述的一些要求：
- 消息通知本身信息比较弱，每个人习惯可能也不一样，消息格式也不一样，很难统一，则可能丢失送测的关键信息
- 开发阶段和测试阶段容易混淆，这也是因为消息通知本身太弱了。
而规模大一些的团队，可能会通过一些书面形式或者一些工作流来明确送测流程（看公司的基础建设），虽然看起来是繁琐了，但是其实所谓的繁琐是相对的，相比于流程带来的复杂度，其提高的效率和便利性（这里指复盘之类的信息查看）反而是更重要的。
除了送测流程之外，这里再提一些送测阶段可能出现的一些问题：
- 测试环境稳定性问题
- 送测打回
- 开发和测试的分歧：边界问题和开发、测试需求理解不一致
测试环境稳定性问题
测试环境的稳定性指，单我们在送测后，需要保证测试同学在进行的环境可用且不能被随意修改。
很常见的就是测试在进行时，开发可能修复了一些缺陷，然后就直接更新到测试环境中去，也可能是开发发现了比较严重的问题，直接进行了修改然后在测试环境就发布，此时测试同学正在测试某个功能，突然可能就发现某个功能不可能用或者异常了，然后就报了个缺陷，这种情况后面是很难说清楚或者排查出来的，而且极其浪费时间，影响效率。并且可能阻塞测试进行。
所以，通常我们会要求在测试进行中时：
- 测试环境和开发环境分开，准备多个环境隔离开发和测试
- 为了防止测试环境被随意改动，有条件时，在测试期间会利用流水线之类的工具锁定测试环境应用的版本。
送测打回
送测打回通常是指在送测一开始，测试在进行初始的主流程验证时未通过或者一轮测试结束还存在缺陷未处理的情况时，测试会将整个送测给打回，开发后续会修复完缺陷后，再次进行送测。
如果本轮测试没有要处理的缺陷了，则整个迭代的测试就通过了，可以准备发布了。
开发和测试的分歧：边界问题和开发、测试需求理解不一致
这种情况，本质上是需求不清晰导致或者开发测试理解不到位从而产生的分歧，通常更多的时候需要进行沟通来解决。同时也会以需求交互稿来作为唯一的标准来进行评判。
边界问题则让需求补齐交互需求稿，理解问题则和沟通清楚在下一轮送测时进行改正即可。
缺陷分类
通常缺陷为了后续复盘之类的统计，会将缺陷进行简单的分类，在一个适度的情况将缺陷按照严重程度分为：
- 次要缺陷
- 一般缺陷
- 严重缺陷
- 致命缺陷
除了缺陷之外，通常还存在优化、改进项，它不归纳于程序bug，而是对应用的一些优化和改进项目，通常类似UI和交互的改进或者性能的优化等。
而除了对缺陷进行分级，还会对缺陷进行分类，例如功能和需求不符、交互，低级缺陷是将一些缺陷进行归类：
- 功能和需求不符
- UI问题
- 方案设计
- 未自测
- ….
缺陷本身的创建也存在一些规范，例如标签（新建、打回、无效）、格式、备注必要的信息、复现方式、日志信息等等，方便开发人员定位复现以便更高效的解决。不过这一块就涉及到测试团队本身的定义和规范了。
缺陷状态
通常我们使用一个项目管理工具来管理我们的缺陷，例如TAPD、jira这种，他们通常以项目或者迭代为单位来管理该项目和迭代中的缺陷。通常缺陷有几个常见的状态：打开-处理中-已处理-关闭
通常当一个迭代中开发进行送测时，需要将所有的缺陷状态都处理为“已处理”的状态，才可以进行送测，特殊情况下，至少要严重及以上等级的缺陷都处理掉才可以送测。而发布的要求则是所有的缺陷都处理完并由测试验证通过后，才可以进行发布。
发布流程
当测试通过，没有发现缺陷或者和产品团队协商后，不影响发布，则可以进入到发布流程。
- 准备好发布的应用，该打包的打包、该准备更新配置的准备更新配置，确定需要发布的内容和范围。有条件的则按照发布流程，例如流水线去走即可。
- 发布后验证，确定上线没有问题
简单来说就上面两步，不过不同的公司的发布流程不一样，复杂度也不同，比较值得注意的主要有下面两个方面：
- 预发布，如果基础建设比较好的，则会进预发布，并对预发布的内容进一步先进行验证，待验证没有问题后，则会将预发布的内容推送到正式环境。
- 发布过程中出现问题的处理方式：在发布过程中可能出现一些问题，此时对于这些问题能解决自然解决最好，如果不能解决，那么则需要和产品测试进行沟通讨论，看是否影响本次发布，如果不影响，则会作为缺陷，在下一个版本出来，如果影响，则能解决则尽量解决，无法解决，则会慎重考虑延迟发布。
复盘
在迭代正式发布上线后，则由迭代负责人总结整个版本中出现的问题、风险、缺陷以及迭代中出现的亮点，将相关人员聚在一起进行复盘，通常复盘内容包含了从需求梳理开始到发布的所有阶段，例如需求质量、是否延期、缺陷是否太多、送测发布过程是否顺利等等。
如果整个迭代比较顺利进行下去了，那么也可以考虑不进行复盘。
迭代大小的规划
在开发过程中，我遇到的比较多的一个问题在于迭代大小的规划非常容易过大，往往一个版本所涉及的功能和需求非常多，且设计到了多个团队（主机、c++），这往往会带来一些问题：
- 需求太多，整个迭代周期太长，对迭代的把控也更加的困难，往往一个环节出现了问题，很容易导致整个迭代进度受到影响，此时协调起来也更加困难，对风险的把控也更加困难
- 需求太多，送测内容也非常多，从而导致一次送测，其缺陷也可能非常多，从而导致开发周期和送测周期都非常长，从时间效率来看也很低下
- 如果涉及到多个团队协作，那么团队之间协作和管理起来会更加困难，协作起来效率低下
故此，通常建议每个迭代的周期不宜过长，从经验来看，大的版本迭代往往更难以把控，且也更加容易出现问题，故不如将其拆分为两个甚至更多的小版本进行迭代，分而治之，一步一步的去完善。通常两个礼拜一个迭代版本时比较合适的（不过看具体产品）有点像敏捷开发的影子。
关于敏捷开发和瀑布式开发：整体上我们更像是瀑布式开发，每个阶段都划分好，只有上一个阶段完成后，才会进入下一个阶段，这也是由于我们的项目本身已经比较成熟，处于迭代过程。而对于新项目，则可能会一开始考虑敏捷开发的方式，小步快跑，循环迭代。其实无论是敏捷还是瀑布，还是看时机的需求进行决定，不同的侧重来决定当时的实施策略，也不是一味的按部就班的按照流程就来。
质量保证
在开发过程中，质量问题可能出现在开发的方方面面，例如需求、开发阶段、送测阶段等等
产品需求、交互质量
通常交互稿和UI稿由产品团队和UI团队来编写，通常这里的质量问题更多的是需求交互的质量：
- 需求描述的清晰易懂，功能描述、逻辑流转之间是否清晰
- 需求是否考虑的周到全面，是否合理
- 需求的边界问题是否考虑清楚
- …
上述的需求问题，通常只要在需求评审时以及评审之前，开发仔细了解以及和产品的沟通中大部分都能够解决，评审本身是一种制度，来保证需求质量以及让开发、测试团队之间对需求的理解保持一致，不过这都是人在做事，每个人对待同一事务都是存在差异的，评审也是尽可能的做到这一点。
而在产品交付需求给开发、测试进行评审之前，产品团队内部也会进行再一次的审查，以便减小流入到需求评审环节的错误。
通常在需求评审完毕，开发正式进行开发后，需求交互稿就会被锁定，不会再进行更改。其一是让开发、测试有一个定稿的文档进行开发对照，其二则是当开发、测试在出现需求理解不一致时，需求文档稿也是唯一标准。
需求变更
如果在开发过程中，发现了需求的不合理之处或者产品就是想要临时变更某个需求，这对于开发节奏来说影响是非常大的，可能会影响到排期，甚至已经完成了这一部分需求的开发了。所以对于开发中途的需求变更，除非是非常重要且团队能够接受排期影响的前提下，否则是尽量不在开发中途去临时对需求进行修改的。
code review
通常在迭代过程中，当代码合并到当前迭代的主分支时，通常会生成一个MR来交由另外一个开发人员进行代码审查来保证代码质量。
这里只提一下几个点吧：
- 不要改动了非常多的文件代码后再提交一个MR，这样对于别人理解这个MR时会比较困难。
- 尽量提交MR的人和review直接当场看了，有疑问当场提，通常效率是最高的。
延期问题
导致延期的可能原因有很多，包括内部原因：迭代规划不合理、质量太差导致（需求质量、送测质量）资源不足等等，还有外部因素：临时需求、紧急问题处理等
这些只能具体问题具体分析了。外部因素更多的考验是负责人的协调和沟通的能力。不过，上面所提到的所有点，其实目的本质上是为了了解开发中可能出现的问题，提前识别风险并规避风险，从而让项目迭代能够按时并高质量的交付。
总结
在规模较小和规模较大的团队待过后，我重新认识了不同团队开发流程间的差异，并且也深刻明白了不同团队间的开发流程需要基于每个团队的不同情况去制定和优化，并非一味的照搬，需要因地制宜，逐步的改进优化，适合自己团队的才是最好的。