你瞧瞧后端开发吧！

为什么要有流程

瀑布模型

根据需求，讨论团队想法->协作开发需要统合各人安排->交付、测试、修bug等的安排->发布和运维阶段
有一说一后两个不是很懂。
瀑布模型，感觉主打的一个保险，一步步来，效率低。

敏捷开发

** 待做：了解一下敏捷开发的具体提出过程 **
“以小团队快速迭代”？莫名联想到工作室做游戏，先上demo再搞正式。虽然也有筹集资金的意思就是了
暂时回顾...怎么感觉这更像“有哪些流程”的部分？

果然还是实际的看起来有感觉啊

有哪些流程

好吧，细讲更像，确实

需求阶段

不要浪费时间讨论不应该存在的问题
意外的，站在客户增添活消减需求是需求阶段的一件重要工作。

经典的“重要”和“紧急”双项指标。不过王道就是有王道的好处啊.......
不过时间占比建议倒是第一次见，大部分是分布在重要但不紧急，防止变成紧急且重要，忙中出错。接下来是重要且紧急，无可奈何，再然后是不重要不紧急，用来给脑子休息的？
我是超级救火员

开发阶段

这配图居然是真货
总觉得以前是很需要网速的，但如今的微服务架构普及，越来越感觉到时代的进步让我们能够舍弃一些东西。
“别上魔法数字”即给一些数字以常量代替，赋予直观意义。

测试阶段

** 待做：《Google软件测试之道》 **
功能环境：单独功能开发和测试
集成环境：多功能集成测试，确定相互间影响
回归环境：确保新旧功能无影响

发布阶段

直接发布模式：同字面意思直接更换新版本。简单低成本；发布过程中断服务，且出问题直接干倒全用户；适用于非核心业务服务、测试环境部署时。
金丝雀发布模式：先给部分用户更新，进行测试。相对还是比较简单，能够先验证一些新版本功能；但发布过程依旧会中断服务，且不能发现用户量大才能发现的问题；依旧适用于非核心业务服务、测试环境部署等。
滚动发布模式：对每个实例都通过金丝雀的方式逐步放大流量。可以充分验证服务功能，发布过程用户体验不中断；但流程略复杂，对发布系统要求高，且速度慢，还需要新老版本能兼容；适用于发布系统能力强，自动化程度高。
蓝绿发布模式：先让部分完全承担流量，交替承担。发布快，流程简单；对机器要求高......

运维阶段

略！

怎么优化流程

DevOps：循环编码→交付→测试→运维→编码......
虽然能了解要优化那些无价值的等待时间，但实际听不懂具体如何操作。