最近聆听了一场由孙敬云老师分享的ECUG大会演讲，收获颇丰。在大学时期，我们学习的软件工程课程只涵盖了瀑布模型，而实际工作中，我一直采用Scrum方法，却未曾有足够的时间去深入学习整理这部分知识。在此，我想记录下这次演讲的内容，并分享个人的思路。以下内容部分来源于孙老师的分析PPT。

软件工程之路

1.1 软件工程的演进

大学课程似乎只带我们领略到了1980年的软件工程风貌。之后的历程需要我们走出校门，在社会的大熔炉中淬炼学习。从瀑布模型开始，软件工程经历了不断的演化与革新。进入90年代，Scrum逐渐崭露头角，近年来极限编程也开始受到关注。进入2000年后，持续集成（CI）和敏捷开发成为热门话题，而Kanban方法虽然可能不再那么火热，但在市场上仍有一定的影响力。到了2010年，持续交付、DevOps和真正的Scrum理念逐渐普及。

1.2 瀑布模型

关于瀑布模型在此不做详细叙述，仅谈谈其几个痛点：产生客户价值周期长、部门间存在壁垒、无法及时响应需求变化以及价值流动不可见。

1.3 敏捷开发

敏捷软件开发是一种能快速应对需求变化的开发能力。它强调程序员团队与业务专家之间的紧密协作、面对面的沟通，以及频繁交付新的软件版本。其特点是紧凑而自我组织型的团队，能够很好地适应需求变化的代码编写和团队组织方法，更注重软件开发过程中人的作用。

通俗地说，敏捷开发更注重沟通、快速产出新版本，并更适应需求变更，适合小团队开发。左图是需求池的概念，如jira中的backlog，将大量客户的需求中优先级最高的7%作为首要实现的目标。右图展示了迭代和反馈的重要性。

敏捷开发中有敏捷宣言，以下是其中的几个核心原则：

个体和互动高于流程和工具。

工作的软件高于详尽的文档。

客户合作高于合同谈判。

响应变化高于遵循计划。

1.3.1 Scrum实践

---

敏捷之旅：三大核心会议与极限编程实战

1.3.2 计划会议：蓝图初绘，共谋策略

在敏捷开发的旅程中，计划会议是启程的第一步。在这场会议中，产品负责人、Scrum大师和整个Scrum团队齐聚一堂。他们从Backlog中挑选出这个Sprint要攻克的User Story，深入解析其需求，确保每个团队成员都心领神会。团队还会对User Story进行细致评估，衡量其大小并赋予相应的Story Point。遇到复杂的任务时，他们会考虑是否将其拆分为更小的Sub Task。明确这个Sprint的目标和交付成果。每一环节都凝聚着团队的智慧与决策力，为冲刺阶段的成功奠定基础。

日常站会：轻触即发，快速响应

每日站会是团队日常的脉搏。会议时间严格控制在15分钟内，团队成员们分享自己的进展、下一步计划以及遇到的难题。每个人的发言都简短而精炼，确保信息的及时传递与更新。团队在这里进行高效的沟通，共同解决遇到的问题。这是一个迅速响应、传递信息的地方，确保团队的步伐协调一致。

评审会议：验收成果，共鉴辉煌

评审会议是展示团队努力的舞台。在这一阶段，产品负责人、Scrum大师和团队成员们展示他们的成果，按照User Story的顺序演示新功能。面对反馈和建议，他们虚心接受并记录下来。如果还存在障碍和挑战，团队会将其加入Backlog进行后续处理。这是一个评价任务完成与否的重要标准，确保每个故事都能得到圆满的交付。

回顾会议：复盘得失，探寻卓越之路

回顾会议是团队的反思与总结。在这一环节，Scrum团队审视这个Sprint的数据和成果，寻找优缺点并进行深度分析。他们运用头脑风暴寻找解决方案并投票决定下一阶段的改进方向。这是一个提升效率和质量的关键环节，推动团队不断向前发展。

---

极限编程（XP）实战攻略：四大核心价值的实战应用

极限编程是敏捷开发中的佼佼者。与传统方法不同，它更强调适应性和面对困难的勇气。它的基础价值观包括交流、朴素、反馈和勇气。实战中，可以从四个方面入手改善项目：强化沟通、从简做起、积极反馈和勇于面对事实。记住XP的四大核心价值：沟通是关键、简洁至上、善于接纳意见并勇于重构。通过遵循这些原则，团队可以更好地应对各种挑战并取得成功。

---

思考你的团队是否敏捷？五大指标揭示真相

要判断你的团队是否敏捷，可以从以下五个方面进行自我评估：团队成员是否清晰知道目标？是否能预测结果并充满信心？是否主动承担责任并做事？是否愿意持续改进？如果对这些问题的回答是肯定的，那么你的团队已经走在敏捷的道路上。否则，可能需要重新审视团队的合作方式和敏捷精神的实践程度。

---

DevOps模型：构建高效软件交付流水线

DevOps模型强调的是开发、测试和运维之间的紧密合作。通过建立自动化流程，实现软件的高效交付。DevOps模型的核心是建立一条完整的IT服务供应链，通过自动化工具实现稳定的价值交付。在这个过程中，不固定需求管理和工具链，专注于持续稳定的交付价值。通过这种方式，团队可以更快地构建、测试、发布软件，从而提高软件质量和用户满意度。

---

第一部工作法：清晰的工作流驱动成功

在追求软件开发的卓越之旅中，第一步工作法是建立清晰的工作流。工作流自左向右，涵盖从开发到运维再到客户的全过程。这个过程包括计划、编码、构建、测试、发布、部署、操作和监控等环节。针对这些环节的实际操作方式多种多样，其中工作日志是一种有效的实践方法，同样适用于敏捷开发。理解并优化工作流，是提升软件开发效率和质量的关键。通过自动化和团队协作，实现高效稳定的软件交付。通过上文提供的数据和工作流程，我们可以进行深度的阶段性分析，并从中获得宝贵的洞见和行动指南。

一、任务管理与工作流程分析

1. 平均前置任务等待数：这一数据指标为我们揭示了任务之间的依赖关系以及潜在的瓶颈。通过这一数据，我们可以判断任务分配是否合理，是否存在某些任务长时间等待前置任务完成的情况。对此，我们可以考虑优化任务分配，减少等待时间，提高团队的工作效率。

2. 手工比例：这一数据反映了自动化程度的不足。高手工比例可能意味着存在大量的重复性工作或者流程中存在可以自动化的空间。我们可以考虑引入自动化工具或流程优化来减少手工操作，提高工作效率和质量。

二、版本控制与分支策略

当前存在多种版本控制和分支策略，包括GitFlow实践、tag版本实践等。建议采用GitFlow+Tag的方式进行版本控制，以触发多环境下的pipeline自动化流程。

1. GitFlow实践：采用develop、feature、hotfix、release、prod等分支进行实践，适合版本并存的团队。这种方案具有灵活性高、代码隔离好的优点，但可能会显得较为繁琐。

2. Tag版本实践：基于版本打tag的方式进行版本控制，适合小版本滚动升级团队。该方案简单易行，但对多环境的支持不是很好。

三、流水线规划

流水线的规划是CI/CD的重要组成部分，可以使用Jenkins的pipeline或Gitlab的pipeline。建议包括自动和手动两个阶段。

1. 自动阶段：包括代码检测、单元测试、制品、集成测试、性能测试、安全测试等。这一阶段主要依赖于自动化工具和流程，旨在确保代码的质量和稳定性。

2. 手动阶段：包括验收测试、部署线上等。这一阶段需要人工参与，以确保最终产品的质量和符合业务要求。

四、Scrum+XP+DevOps流程整合

为了在实践中有效结合Scrum、XP和DevOps，建议将流程分为四层：需求池管理、Scrum流程、CI/CD和持续交付质量。

1. 需求池管理：参照Scrum中的需求池概念，对需求进行有效管理和跟踪。

2. Scrum流程：遵循Scrum框架，包括迭代、会议、实践等，确保项目的顺利进行。

3. CI/CD：通过代码版本控制触发CI和CD的构建，实现代码的持续集成和持续交付。

4. 持续交付质量：通过发布编码标准、测试驱动开发、代码审查等方式，提升代码质量，确保团队的持续交付能力。

第二工作法（反馈流）向我们展示了CI/CD的持续反馈流程。这就像一个动态的生命线，反映出我们的Pipeline的工作流程以及历史构建记录。在这张图中，顶部的“表头”象征着我们的Pipeline流程，每一行则代表着我们的历史数据。通过这张图，我们可以清晰地看到在哪个阶段出现了错误的高峰，从而进行针对性的改进。测试部分是流程中的关键一环。如果我们的团队不重视包括单元测试在内的测试环节，那么这个反馈机制的价值就无法得到充分发挥。在DevOps的理念中，我们推崇测试驱动开发，确保我们的开发过程始终围绕着质量展开。我们还可以查看制品的状态，例如Java的jar包、Docker的镜像等。通过这些反馈，我们可以知道这些制品所在的story的当前状态。这就是我们的第二工作法——反馈流的核心内容。

---

版本控制规划蓝图

我们采用基于Tag的版本控制策略，推荐使用GitFLow结合Tag的方式，构建出稳健的版本控制体系。这种方法不仅灵活多变，还能确保代码库的管理更为有序。

快速失败流水线的重要性

在流水线实施中，我们倡导“快速失败”的理念。当流水线中的某个环节未能达标时，应立即中断后续环节的运行，以该环节的失败作为整个流水线的最终结果。Jenkins的Blue Ocean界面直观地展示了这一理念，确保我们迅速识别问题并作出响应。

可视化反馈平台的力量

借助Jenkins的原生可视化支持，我们能够实时了解CI/CD的状态。这使我们能够像对待产品一样对待我们的团队——不断学习、尝试和优化。可视化反馈平台让我们的团队能够在不断迭代中快速成长，同时允许并鼓励团队成员从错误中学习，但避免重复犯错。

质量保证的全方位策略

3.8.1 CI/CD的质量保障

通过集成测试、性能测试和安全性测试等良好的测试流程，结合自动化流水线，我们可以显著提高代码质量。这不仅在部署前确保了代码的稳定性，而且在部署后也能通过自动化测试和验收测试来验证其性能。

3.8.2 环境与配置管理的精细化

利用配置中心来管理不同环境下的应用配置，可以避免因配置混淆导致的线上问题。

3.8.3 制品库管理的规范化

推荐将预发布和生产环境使用同一制品库，而开发和测试环境使用另一独立的制品库。在两个制品库之间，需要人工审核和同步以确保流程的可控性。

流程控制的优化与改进

CI/CD的流程控制是关键。由于单节点Jenkins在同一时间只能有一个pipeline构建，因此建议搭建分布式Jenkins集群或使用GitLab等工具进行pipeline构建的调度和并发处理。在pipeline的测试中，可以根据条件并行执行分支，提高构建效率。

数据收集和监控的全面性

服务上线后，我们需要通过日志监控和中间件、流量、物理硬件的监控来确保服务的健康运行。推荐使用ELK方案进行日志分析以及Prometheus+Granfa进行基础环境监控。

容灾策略的构建与完善

随着应用复杂度和用户量的增长，我们需要实施容灾配置并定期进行混沌工程演练。服务部署方式应逐步进化为更高可用性的模式，确保在意外情况下服务的持续运行。

紧急事件处理的准备与响应

没有服务能够达到100%的可用性。面对黑天鹅事件，我们应快速响应以降低损失。当线上出现故障时，我们有明确的流程和策略来迅速定位问题、修复并恢复服务。这样不仅能减少损失，还能增强团队的应急响应能力。预案为先，应对事故未然之端

在事故尚未发生之际，我们应居安思危，未雨绸缪。全员参与容灾演练，积极准备应对可能出现的危机。通过混沌工程的实践，不断提升服务的可用性和健壮性，以迎接未来的挑战。

事故一旦降临之际，沟通与行动需并行不悖。Ops与Dev需及时相互通报情况，共同面对问题。双方向上级汇报工作进展，为决策者提供清晰的事实依据。主管领导将根据具体情况判断是否需继续向上级汇报，以寻求更多支持。

事故处理过程中，首要任务是止损，遏制事态恶化。随后深入调查事故原因，寻求根本解决之道。若已有预案，Ops主管需在十分钟内做出决策，迅速进行回滚操作。若无预案，Ops主管需携手Dev主管共同决策，制定回滚及补救方案，确保系统恢复稳定。

事故处理之后，反思与定级至关重要。Ops需及时通报事故处理结果，让相关部门了解事故走向。在事故发生的二十四小时内，主要责任部门将牵头进行案例分析，对事故进行定级评估。此次经验将成为我们宝贵的教训，为未来防范事故提供有力的借鉴。

本文源自纳兰小筑，如需进一步交流或评论，请追溯原文查看。让我们共同关注、探讨，不断提升应对事故的能力，确保系统稳定前行。