需求阶段
会在grooming会议上讨论什么需求该做，什么不该做。
对于需求评估可以采用MVP（minimum viable product，最小可行产品）思想：先造出一个最简单的能用的产品，再根据用户的反馈逐步升级，最终变成用户想要的产品。
在日常工作中安排自己的任务可以采用四象限法：根据紧急程度和重要程度划分出四个象限，把要做的事情放进去，以此来决策事情的先后顺序。一个高效的占比应该是大多数时间在处理重要但不紧急的事情，一旦事情变成了紧急就容易因为紧张而犯错，每天大部分时间都在处理重要且紧急的事情是很不健康的
开发阶段
现在的后端开发得益于云原生技术的发展已经跟几年前有了很大的区别。
云原生下的开发，一个最大的区别就是部署的形式不同。传统虚拟机上的服务开发是在物理机或者更底层上虚拟出多个虚拟主机，然后在每个虚拟主机中安装软件和依赖，并且虚拟机要专门的运维人员维护，非常麻烦；而开发云原生的后端程序，容器是从操作系统中虚拟出来的，所有容器共享宿主机的系统，在部署的时候，应用和其依赖的系统是整体打包成一个镜像的，后端开发不再依赖运维人员创建程序的运行时环境。
另一个改变就是维服务，将模块拆到不同的服务中去，拆分的粒度更细，可以让每个模块独立的扩容/缩容
云原生也让我们的开发环境逐渐云化
测试阶段
测试应该是伴随开发全过程的，每写一段代码都要测试。
在实际的工作中，一般至少要三套环境：
- 功能环境用于开发和测试功能
- 集成环境用于把不同的功能合并到一个测试
- 回归环境用于验证新功能对老功能有没有影响
发布阶段
在发布过程中，除了出问题要快速定位，还要做一些常规检查：
- 发布负责人通知各个相关人员，观察各个服务的发布状态
- 变更服务的相关RD要按照规范检查日志，监控，响应线上的告警
- 关注用户的反馈
实际发布使用的是滚动发布，这种方式对用户的体验最平滑，同时公司也有强大的流量控制能力能够平滑的切换流量。
运维阶段
观察线上监控和日志
故障发生之后要及时止损让服务恢复功能，其次要让服务的上下游感知到出了问题，最后才去定位和修复问题
