前言：认识周俊是在第五空间学习中心几年前的DevOps Master培训课堂上，课前为了帮助大家做好预习，我设计了《持续交付》一书的150多道导读问题并发给学员。让我印象非常深刻的是，周俊在整个学习过程中，多次来找我交流问题的细节，并整理了详尽的答案文档分享给同学，自己也毫无意外地以高分通过考试。非常感谢他在工作繁忙之余应我之邀，详细总结了自己一路来的心得与收获，希望能为像他一样的 IT 经理人带来收获和感悟。

—— 许峰，第五空间DOM讲师

跳丸日月！今年，距我踏上 IT 管理岗已10年有余，也是我从事软件行业的第16个年头。我是周俊，一个左手技术、右手管理的 IT 经理人。先后从事过软件测试开发、软件测试、软件开发、项目经理、软件研发部门经理等不同岗位。在多年的工作中坚持学习，在第五空间先后获得了PMI-PMP、PMI-ACP、ITIL 4 Fundation、DevOps Master认证等。虽说我从事IT管理工作的时间比作为软件工程师的时间要长，但由始至终，我从未放弃过对技术的热爱，并始终坚持与部门成员保持统一语言，即 “技术语言” 的交流。

这篇文章主要写给像我一样奔忙在IT技术和管理道路上的小伙伴。文中围绕了多年来对我工作及生活上帮助最大的三个知识体系：PMP、Agile以及DevOps。借此文，回顾并分享这十多年来我在工作中的些许心得体会，希望能够激发大家的共鸣。如果你正头疼与不同背景的干系人如何沟通；如果你的项目还没有敏捷化；如果你每次的软件发布都如临大敌、如履薄冰。那么，我相信读完这篇文章后你会有些收获。

PMP —— 夯实基础架构

如果把身体比作一台计算机裸机，思维比作软件，那么在第五空间学习的PMP的课程对我来说无疑是一次里程碑意义的软件升级，即使在刚学完PMP的前几年中我还不自知，但整套知识体系潜移默化地影响着我的工作和生活。PMP中的所学加之后来一段项目经理的经历发挥了巨大作用，尤其是在沟通管理和风险管理方面，感谢PMP朱宏强教练。

作为部门的领导者，对内要和部门成员沟通，对外要和各个职能部门、业务部门沟通，沟通渠道级数增长。沟通是一门艺术，往往，同样的话换个方式表达，甚至换个顺序表达，都能达到不同的效果。

图片来源：fellow.app

在和员工的 Annual Appraisal 或者平时的沟通中，我觉得 GDD（Good、Difficult 以及 Differnt）是一种比较好的交流模板，也是我这几年来一直在使用的。它不但增加了沟通的有效性，也降低了冲突发生的概率。

Good：通过表扬来破冰，可以很快打破尴尬的气氛，重点聊员工上一阶段做得好的地方，即便没有达到目标要求，但如果比之前有改进，都可以提出来给予认可，要聊得细致一些。当然，这也就需要管理者平时多关注和了解员工，否则最终只能聊空话。

Difficult：通过表扬来打开员工的心扉，接下来就可以聊些不足的点了，只对事不对人，因为事情有难度，所以做得不够好，才会有挑战。（这和Effective DevOps文化中的不追责不谋而合）这样员工也更容易接受你的建议。

Different：结合上面的两点，好的继续保持发扬、有欠缺的则指导员工或者让员工自己思考如何改进。以上的内容都可以作为每次正式交流的重要输入，持续检查和改进。

关于风险管理，PMP 给到我的收获远不止于方法论，更培养了我时刻保持风险意识。多年来，我向老板汇报的周报与月报中，都会留有专门的位置描述风险：可能和已经发生的风险、风险影响、风险的级别、风险的应对策略以及最终结果。

不止工作，在我的生活中也有许多项目管理的实战：大到房屋的装修，小到一次旅行的规划，完全不需要也不可能刻意对照着 PMBOK 去照做每一个输入、输出、过程和工具，但核心要素已经深刻印在脑中，潜意识地使用，这也许算 “忘掉功法才是最厉害的功法” 的初境吧。

Agile —— 重要的转折

学习敏捷完全是因为几年前和智利同事一起进行的产品研发中所遇到的现实问题倒逼。虽然打着产品研发的旗号，但很遗憾，我们仍然坚定地走在项目型开发的道路上，采用传统的瀑布方式进行开发。即便在那时已经看过不少朋友在发关于敏捷相关的文章，知道敏捷方法论更适合产品型开发，但因为之前从未使用过，也从未系统学习过，所以不了了之了。

在做了许久的前期准备后，作为开发部门的我们终于收到了来自智利业务部门厚达 340 多页的如工具书般的第一期需求文档，之后就是双方一轮又一轮的 Q&A，文档也修改了足足 50 多版，依据 PMP 中项目估算的经验外加拍脑袋加持，总算是把软件设计、工作量及工期估算等给定下来了。接下来就是为期9个月左右的开发，而开发过程中很少和对方就业务细节进行深入交流讨论，因为文档已经很细致了。如此，终于在 7 个月左右的时候给对方第一次演示了成型的软件。几天的演示，反馈不错，但随后业务部门提出了大量的修改和调整意见，有些是在我们开发阶段产生的新灵感，但还没有落实到文档；有些则是在演示期间迸发出的火花；或是潜在客户提出了原本没有的功能需求。于是，文档又经历了不小幅度的修改。我们被要求在尽量不影响工期的情况追加新的调整。此刻我们才发现，因为前期的设计不够灵活，导致有些功能的追加是破坏性的，完全不符合开闭原则，同时，在对之前代码进行重构、扩展的时候，发现技术债也开始显现。虽然一期的开发完成了，但团队的士气受到了不小的打击，大家经常挂在嘴边的话就是 “要变更怎么不早说，浪费我的时间”。

想着这样的痛苦很可能会在二期、三期及后续重复经历，我感觉一定要改变现状，但又无从下手，此时，敏捷就像一根救命稻草一样又闪现在了我的脑海中，于是乎联系第五空间的丹丹，参加agile培训，在接受了系统的 ACP 理论知识培训后，感觉真的是应对我们当时问题的一剂良药：

“项目过程中，业务人员和开发人员必须在一起工作。”；“无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。”：我们的问题不正是过于依赖文档，而忽略了和业务团队的实时交流嘛。

“要不断交付可用的软件，周期从几周到几个月不等，且越短越好。”：软件还可以在这么短的周期内发布？这打破了我的认知。

“要做到简洁，尽最大可能减少不必要的工作。”：300多页文档中的功能难道都是必须的重要功能吗？有没有可能先专注重点功能交付？

“团队要定期反省如何能做到更有效，相应地调整团队的行动。”：这不和PMP中的 PDCA 契合吗？我们一直忙于开发，而忘了回头来看看并总结自己走过的路。

图片来源：sysaid.com

敏捷是一种文化，需要大家认同才能成功实施，在我学习完 ACP 的理论知识后，立即现学现卖，向部门同事进行了浓缩版（缩水版）的培训，并且为另外两名有项目管理经验的小伙伴也报名参加了第五空间的敏捷培训。同时，我也赶紧向身处智利的业务团队进行“洗脑”，给他们讲我们现在遇到的一系列问题（此时，PMP给到我的沟通技巧就派上用场了），进行敏捷转型才是正路，并给对方介绍了我的所学，甚至将Jira中的敏捷项目都创建好吗，就等对方一起来尝试了。在沟通中，竟然发现对方团队一个在中途加入并负责和我们技术协调的 IT Leader 有 Scrum Master 背景，经过这位兄弟帮我们从中斡旋，我们终于在整个产品的三期研发开始尝试性地使用敏捷开发模式。

虽然两个团队身处地球两端，但我们尽最大可能按照规范化敏捷的要求进行：晚上或早上8点进行 Sprint 中的三个重要会议，而每天的站会则是由两边团队分别站会后再统一汇总，有点类似 scrum of scrums。关于迭代：第一周进行 Planning Meeting，并着手开发，两周开发完成；第三周在UAT环境进行演示本轮迭代的成果（Review Meeting）以及根据演示反馈的小幅调整和问题修复；第四周生产环境发布，同时开启下一轮迭代的 Planning Meeting，同时在第四周末进行本轮迭代的 Retrospective Meeting。这样，我们保证了三周一个发布的良好节奏。

实践证明，我们当初的转型决定是正确的，产品开发从三期开始我们共经历了十多个成功的 Sprint，双方团队的感觉都越来越好。虽然项目在后期完全转交给了智利团队，但这段转型的经历对我的思维升级起到了重要作用，在后续的其他产品研发中，我们也继续学习和推广推敏捷开发的经验。

DevOps —— 打破壁垒

敏捷打通了业务与开发之间的壁垒，而DevOps则打通了开发和运维之间的壁垒。作为一个开发出身的管理者，这一点我深以为然。DevOps 也是我“升级”之路上的一个重量级 Service Pack。

在我听 DevOps 一词之前，已经在不自知的情况下进行着毛坯版 DevOps 持续集成部分流水线的搭建。最初的契机是为了提高代码质量而和 Sonarqube 进行集成，从手工编译，手工执行脚本向Sonar推送扫描请求开始，逐步演化为：获取代码、恢复依赖库、编译、单元测试、Sonarube 扫描，都靠BAT脚本串联在一起，每天定期执行一次，虽然非常原始，但在一段时间之内也提高了开发效率，单元测试和Sonar能给到开发人员快速反馈，能在项目进行集成测试之前发现很多潜在的问题！

正式听到 DevOps 一词，还是在 ACP 的培训中，讲师和我们介绍说 DevOps 是很难考的一门，但考完后前途光明。从讲师对 DevOps 的简单介绍，我感觉已有的 Sonarqube 集成脚本就有那么点 DevOps 的味道，但还很粗糙，不成体系，为何不系统地学习一下呢？

于是乎果断联系第五空间参加DevOps Master培训。讲师是国内知名的 DevOps 专家-许峰老师，也是技术和管理出身，深入浅出地给我们讲解 DOM 的知识体系，有技术相关，更有文化相关。在学习的过程中，除了 DOM 本身要求的几本书之外，我还阅读了《凤凰项目》、《Continuous Delivery with Windows and .NET》。前者用小说的方式揭示了管理现代IT组织与管理传统工厂的共通之处，而后者则是特别针对我当时工作中的技术栈。有了理论加身和技术细节的支持，重新将之前BAT版本的持续集成流水线结合现代化工具改进成了如下模样。

聊到 DevOps 就不能不说和它紧密相关的 Cloud，在最近两三年的新项目中，我们都首选将应用部署在云上，而非传统的本地数据中心，整个发布流程借助云服务来完成。下面以一个简单的真实应用为例：

应用到的服务包括：Azure Active Directory 做单点登录；App Service 承载应用站点和后台服务；Azure SQL Database 存储数据；Azure Storage Blob 存放图片、文件等；监控和埋点则使用 Application Insights。

代码存储在 Azure DevOps 中，持续集成和持续发布的流程如下：

要说明的是，这个项目数据库的管理我们使用 Visual Studio Database Project，发布 dacpac 文件然后命令行部署目标环境，这是一种基于 State 的数据库发布方式，还有一种则是基于 Migration 的发布方式，区别可以在 Database Delivery – State based vs Migration based 一文中看到。

Test环境部署

• qa 环境进行API测试和UI自动化测试
  

• 这个环节没有人工测试的干预
  

• 开发人员本地分支 Dev Custom branch 进行开发，完成后 Pull Request到 develop 分支
  

• 流水线对 PR 进行预合并（期间进行单元测试），同时将站点部署到 qa 环境（图中d/qa）
  

• qa 环境测试通过后，整个 Pull Request 到 develope 分支才算真正完成
  

• develop 分支的合并完成后，会触发测试环境（图中-d）的部署，同样也需要走单元测试和后续测试并在完成后需要人工测试

UAT环境部署

• 测试环境通过验证后，就可以按需向 UAT 环境进行部署
  

• 开发人员从 develop 分支向 master 分支提交 Pull Request
  

• 期间也需要进行单元测试、API 测试等。因为此时的生成产物和前一阶段的并不一样。之后同样需要人工验证

Production环境部署

• UAT 环境通过验证后，可以按需向 Production 进行产品的最终发布
  

• 此时只需要有权限的人在流水线中点击生产发布任务即可
  

• 发布所使用的 Artifact 和 UAT 环境的一致
  

• 发布之后会自动进行 API 测试和 UI 自动化测试

当然，并不是所有有应用都适合这样的场景，不同的应用可能会有不同的价值流和相应的部署流水线。比如有些遗留项目我们还是采用 Azure 的 IaaS 服务，即虚拟机的方式进行部署，虽然整个部署流程没有上面实例项目中那么优雅，但也是尽量最大化自动部署。

写在最后

回顾过往，我觉得作为一名 IT 管理者，很重要的一点是保持成长型思维。不断学习并不断实践，通过实践来巩固和增强理论知识，将原本离散的知识连成线并结成网，形成自己的知识体系。

像敏捷所要求的一样“拥抱变化”，积极接受新生事物、新生理论；像 DevOps 所要求的不断消除浪费，做到 DRY。像 PMP 中所提到的和他人高情商地沟通。。。这样，就能在我们固定的 ”硬件“ 基础上，不断进行 “软件” 的升级！

说了这么多，我的“软件”升级之路，还要感谢第五空间提供的专业的系统知识体系培训，第五空间值得你信任~