江苏龙网

  1. 首页 > 人文 > >

微软的软件工程现代化转型

微软的软件工程现代化转型
文章图片
现代软件工程创造了一种文化、工具和实践 ， 专注于开发高质量、安全和功能丰富的软件服务 ， 以实现微软的数字化转型 。 微软核心服务和工程（CSEO ， 前身为微软内部IT ， 服务微软内部客户）团队正在实施现代软件工程愿景 ， 以创建一种文化、工具和实践 ， 致力于开发高质量、安全和功能丰富的服务 ， 来实现微软的数字化转型 。 现代软件工程计划正在帮助CSEO痴迷于客户 ， 加快新功能的交付 ， 并提高工程效率 。 1：到目前为止的旅程
截止2020年1月 ， 微软向云计算的迁移使CSEO能够提高开发流程的整体敏捷性 ， 并为由约1400个组件所组成的约600项服务 ， 提供新的云技术 ， 这些新技术只需较少的专业技能就能使用 ， 还可快速访问其它基础架构 。 这样就可以按需扩展环境和资源 ， 进一步使工程师能够更快地响应不断发展的业务需求 。 但是 ， CSEO仍然需要解决几个结构性问题 ， 包括基本软件工程基础上团队之间的不一致性 ， 比如编码标准、自动化测试、安全扫描、遵从性、发布方法、封闭的构建和发布等等 。 CSEO确实预料到了这一点 ， 因为有些团队的项目组合中包含多达40%的遗留代码 ， 这些代码由打包在一起的大型组件组成 。 这使得存储、扩展、可用性和操作的管理变得困难 ， 因此CSEO已开始通过实施组织范围的服务评审来推动一致性 。
CSEO缺乏集中的通用软件工程系统和相关实践 ， 意识到无法继续以联盟的方式发展软件工程系统 ， 于是CSEO投资了一个中央“基础”团队 。 这个团队的宗旨是在基于MicrosoftAzureDevOps的公共软件工程系统上进行创新 ， 同时推动整个组织在设计、编码、工具、测试、构建和部署服务方面的一致性 。 CSEO通过为每个服务领域定义愿景、确定季度优先级以及通过定义的冲刺（sprint）节奏执行这些策略 ， 为自己的服务带来产品工程思维 。 由此产生了通用软件工程系统和可提高开发人员效率的一致性以及跨团队移动性 。
CSEO需要通过结合行业领先的可访问性、安全性和合规性开发实践来降低代码中的风险 。 实现合规性一直是非常具有挑战性 ， 这迫使CSEO从原有的流程和工具中改变 ， 并积极应对这些领域的技术债务 。 不过 ， 采用新方法的速度很慢 ， 并且由于必须清除的技术债务数量而产生了摩擦 。 这妨碍了CSEO针对代码提交设置自动策略 ， 从而确保“清洁”前进的努力 。 CSEO需要努力实现以无摩擦的方式 ， 交付易于访问、安全且合规的软件和服务 。
CSEO还缺乏一致的遥测和监视水平 ， 无法获得有关服务运行状况、功能、客户体验和使用模式的关键洞察 。 如今 ， CSEO每月平均要运行11万张支持工单 。 但是 ， 还必须进行更深入的分析 ， 以找出预防和持续补救的机会 。 还有一个机会可以使当前端到端的流程完全自动化 ， 只有由于工具之间的差距而尚存一些手动方面的问题 。 CSEO正在推动LiveSite文化 ， 以便能够全面监测服务运行状况 ， 主动发现问题并快速系统地补救事件 ， 同时关注根本原因以确保持续改善服务质量 。 针对服务健康状况建立了CSEO范围内的通用度量 ， 例如检测时间、缓解时间 。 CSEO团队在服务评审会议上讨论这些问题 ， 这推动了文化变革 ， 提高了可能导致事故（如过期安全证书）的问题的可见性 。 通过执行综合监视和从各种数据源引入数据的能力 ， 遥测能力得到了提高 。
CSEO正在实施一种统一的方法来发射遥测数据 ， 管理遥测数据以及有关业务流程、应用程序和基础结构的洞察 ， 以促进交叉关联 。 使用正确的工具 ， 系统应支持每个应用程序和服务的基本监测方案 ， 并跨不同应用程序启用指标和交叉关联 。 这将：
--产生更多切实可行的见解 。
--不需要学习和维护多个完全不同的遥测解决方案 ， 只需很少或没有开箱即用的集成 。
--向工程和业务团队提供通用实践 ， 以改善服务、基础架构和业务流程的运行状况 。
为了解决以前对供应商的高度依赖 ， CSEO实施了一项新的员工战略 ， 从而增加了全职员工的招聘并带来了更多的内部工作 。 这使CSEO能够改变并现代化其提供服务的方式 ， 此外这一战略使得任何供应商的交付都必须有全职员工监督 。 CSEO的策略要求拥有交付服务或合同的开发人员对供应商交付的质量承担端到端的责任 ， 并确保他们遵守流程、标准和法规要求 ， 包括安全性、可访问性和隐私 。 此外 ， 随着增加招聘人数 ， CSEO还为所有团队实施了通用的招聘标准和通用的入职计划 ， 以确保所有新员工都接受有关所有关键工具和技术的一致培训 。 2：现代软件工程愿景
微软的数字化转型要求CSEO以更高的速度、更高的质量、可靠性和安全性来提供功能和解决方案 。 CSEO正在对构建、部署和管理服务的方式进行现代化 ， 以尽可能快地将新功能交到用户手中 。 CSEO正在重新审查工程流程的每个部分 ， 并以微软首席执行官萨蒂亚·纳德拉（SatyaNadella）所概括的方式建立现代软件工程实践：“为了向我们的客户提供移动优先、云优先的体验 ， 我们将实现工程流程现代化——痴迷于客户、数据驱动、速度导向、注重质量 。 ”
为了确保工程师以客户为先、为中心 ， CSEO通过使用通用工具收集反馈 ， 从而使微软工程师对客户体验有深刻了解 。 CSEO正在与遥测技术结合使用和查看此反馈 ， 这将有助于工程师们了解用户如何使用产品以及可能出现的问题 。 CSEO希望实施更高保真度的服务和业务流程监测 ， 以便在客户甚至意识到问题之前就对问题发出警报并加以解决 。 CSEO希望使工程师能够开发可靠和安全的服务 ， 并通过简化从提交代码到部署的过程、同时在软件构建和发布线中无缝集成合规性检查 ， 来减少部署的前置时间 。 CSEO是微软商业产品的第一批客户 ， 这使CSEO能够识别并满足在以云为中心架构中运营的企业的软件工程需求 。 CSEO与微软的产品工程团队不断合作 ， 创造了一个良性循环 ， 使微软的产品（例如AzureDevOps和Azure服务）更加适合企业使用 。
CSEO建立了一种文化 ， 以支持现代软件工程实践和快速交付新功能 ， 并且通过阶段性发布的方式 ， 更快速地向客户交付经验证的新功能 ， 以及通过紧密集成的反馈循环和提供定期发布来完善这些新功能 ， 从而使微软业务能够更快地做出响应 。
虽然提高速度对于数字化转型至关重要 ， 但不能对可靠性产生负面影响 。 连续的数据收集、健康信号的监测、主动检测以及快速修复 ， 这些对于确保减少停机时间并创造高质量的客户体验也至关重要 。 实施现代软件工程实践是一项长期的过程 ， 需要对思维方式、文化和工具进行根本性的改变 ， 包括：
--转向现代云架构；通过组件化整体应用程序来构建微服务；在中央存储库中发布API、NuGet和类似版本 ， 以实现集成；确保超过90％的自动测试覆盖率；与其它团队合作 ， 采用依赖关系并与他们的服务集成 ， 而不是试图复制它 。
--持续集成经过测试的代码 ， 并且仅从代码的主分支进行部署 。
--通过将产品保持在可发布的状态（releasablestate） ， 从固定节奏发布转变为持续集成/连续交付 ， 并通过自动部署管道（pipeline）对故障做出快速响应和实现快速发布 。
--使用环形部署模式（ring-deployment）进行生产环境的实验 ， 而不要进行用户验收测试（UAT）并依赖于专用的UAT环境 。
--LiveSite文化 ， 可以全面监测服务健康状况 ， 主动识别问题 ， 引入自我修复机制 ， 快速修复重大事件 ， 直接与最终用户联系 ， 专注于根本原因以确保服务质量的持续改善 ， 并将关注范围从服务健康扩大到业务流程健康 。
--积极管理已确认的技术债务并保留相应的工程资源 ， 以能够在其产生计划外的工作或影响服务质量之前解决它 。
2.1投资现代软件工程
CSEO建立了强大的基础 ， 具备用于服务组合管理的通用工具和平台 ， 并将这些数据与事件管理、遥测和常见指标仪表板（如事件运行状况和合规性仪表板）集成在一起 ， 每月在CSEO全服务回顾中审核 。 此基础使CSEO能够通过着重于安全性和合规性等基本能力 ， 进而从客户的角度实施更好的事件管理和服务健康 ， 来推动改善CSEO服务总体体验的通用做法 。 在此基础上 ， CSEO对现代软件工程实践和技术的持续投资 ， 反映了微软的愿景并支持微软的文化变革 。 CSEO投资的三个主要支柱是：痴迷客户、快速交付、软件工程生产力 。
2.2痴迷客户
CSEO致力于提高服务和LSI（livesiteincident）管理的效率 。 CSEO正在合并服务管理平台 ， 推出标准的事件管理流程 ， 并根据关键指标持续评估改进的情况 。 随着CSEO朝这个方向努力 ， CSEO对业务流程健康有了更好的理解 ， 并正在扩展工具和流程以改善对业务流程运行状况的监测 。 业务流程可以涵盖从现代到传统再到第三方的多种服务和技术 ， 例如从供应商处购买服务后提供有关该服务付款状态的透明度 ， 这需要跨多个系统的集成和代理商的手动工作来支持该过程 。 CSEO正在通过对跨多个服务和技术的关键业务流程进行更深入的了解 ， 从而在服务和业务健康状况之间架起一座桥梁 。 这使CSEO能够收集和聚合数据 ， 以提供服务和流程健康的整体画面 。 CSEO正在积极主动地检测流程瓶颈 ， 以帮助减少响应时间 。 CSEO正使用端到端流程监测 ， 以将可见性扩展到单个服务之外 ， 这确保了整个业务流程的有效运行 。
2.3使用遥测平台
CSEO使用的是基于AzureMonitor的统一遥测平台 ， 该平台可帮助实现服务质量的持续改进 。 该平台与诸如Kusto、AzureCosmosDB、AzureApplicationInsights和LogAnalytics等异构数据源集成 ， 以收集、处理和发布来自应用程序、基础结构和业务流程的数据 。 统一的遥测平台可帮助获取端到端视图 ， 并生成有关CSEO服务管理的可行动的见解 ， 还能通过常见的可视化来更好地检查原始数据和ApplicationInsights数据 ， 以用于确定团队、LiveSite、以及服务评论的相关性 。 CSEO正致力于交付高度相关的洞察 ， 用以聚合组件服务、客户体验和业务流程的健康状况 。 这将产生上下文数据 ， 这些数据不仅可识别事件 ， 还可识别根本原因和建议的下一步操作 。 CSEO正在使用业务流程监视（BPM）通过跟踪多个服务和业务组的成功交易和客户影响来监测真实可用性和性能 。
CSEO必须将服务健康状况与业务流程健康状况联系起来 ， 并确定问题的优先顺序 ， 以便工程师能够以减少业务负面影响的方式解决这些问题 。 CSEO积累的经验包括端到端业务流程运行状况的可视化 ， 以及通过分析遥测数据来检查业务流程底层服务的运行状况 。 CSEO正在模板化业务流程监测的可视化 ， 并且正在扩展这些模板以简化其它相关指标的可视化 。
CSEO还简化了面向工程师的服务健康和工程基础数据流 ， 并减少使用的仪表板和工具的数量 。 CSEO正在使用内部工具作为所有服务负责人的关键存储库 ， 以查看服务运行状况和其它相关KPI 。 该工具的集成通知工作流程会在服务达到定义的阈值时通知服务负责人 ， 从而可以更方便地将任何需要的补救工作按优先顺序排入重点待办列表（backlog）中 。
2.5拥抱LiveSite文化
提高CSEO服务和流程的规模和灵活性 ， 要求CSEO将更多的注意力放在改善客户体验上 ， 以融入微软的企业文化 。 CSEO正在建立LiveSite文化 ， 并通过痴迷客户、数据驱动、多学科团队等追求卓越 ， 团队通过诚实的观察、持续的学习和可衡量的改进目标来拥抱潜在的失败 。 CSEO在整个组织范围内进行live-site回顾检查 ， 在此期间对事件进行事后审查、考察长期补救计划 ， 并通过现代软件工程标准指导服务团队 ， 以帮助在本地进行有力的审查 。 CSEO基于标准化和可行动的报告进行检查与审查 ， 这些报告中包含有关中断或故障的领先指标并基于遥测、综合监测和其它数据分析 。 CSEO还在努力扩大这些审核范围 ， 将业务流程监测产生的可量化的业务影响考虑在内 。
2.6利用客户反馈来推动发展
CSEO通过反馈回路机制将客户体验放在软件工程流程的中心 。 反馈循环可作为由假设驱动的产品改进的基础 ， 这种改进方式基于实际的情绪和使用数据 。 通过使用与MicrosoftOffice产品套件相同的工具 ， CSEO使反馈提交尽可能容易 。 "发送微笑"功能可跨多个渠道和关键用户接触点自动收集反馈 。 CSEO还将此工具用作集中式数据系统 ， 用于存储、分审和分析反馈 ， 然后将其聚合到可操作的洞察中 。 CSEO提供最佳实践、培训和工具 ， 以帮助工程师理解这些反馈 ， 并鼓励采用反馈循环和实验方法 ， 例如功能发布（flighting）和环形周期部署 ， 帮助衡量产品变更的影响 。 有了这些基本组件 ， CSEO探索将反馈数据与相关遥测相关联的方法 ， 以便可以更好地了解产品可用性问题以及服务问题对客户的影响 。 CSEO还使用受控部署来消除对UAT环境的需求 ， 不过这会降低整体交付速度 。
2.7快速交付
为了痴迷于客户 ， CSEO在各个方面都获得并保护了客户的信任 。 但要推动这一目标 ， CSEO的主要重点必须是服务质量 。 CSEO在跟踪交付指标 ， 以便在确保服务可靠性的同时 ， 缩短从吸收客户需求到可用性和反馈的交付周期 。 CSEO正在通过检查交付管道（pipeline）中较早的问题并提供一种快速进行实验并降低风险的方法 ， 来帮助工程师实现这一目标 。 CSEO正在构建反馈循环机制 ， 以确保能够在部署新功能时理解用户体验 ， 并且如果客户反应或服务运行状况信号不如预期的那么好 ， 将执行自动回滚 。
为了痴迷于客户 ， CSEO还必须提供高质量的服务 。 CSEO缩短了从收到客户要求到解决方案交付到客户手中的准备时间 。 缩短交付周期 ， 使得CSEO能够在提供安全、兼容、可访问、可靠和高质量服务的同时 ， 提供和接收反馈 ， 这对于建立与客户的信任至关重要 。 CSEO工程师不断检查管道中较早的问题 ， 从而能够快速进行试验 ， 同时降低了发布过程的潜在负面影响 。
2.8集成安全性、可访问性和基础
CSEO提倡“左移”过程 ， 其中的工作应尽早在开发过程中进行 。 这使CSEO避免了冲刺和冲刺之间的技术债务负担 。 CSEO还在开发人员工作流程中部署了“闸门” ， 以简化的方式建立安全性并通过静态和动态安全性工具自动提供服务 ， 以确保持续合规性 。 CSEO将在扫描过程中发现的bug记录在AzureDevOps中 ， 以便开发人员可以在那里直接修复它们 ， 而不必首先从安全工具中进行分类 。 此外 ， CSEO计划应用机器学习功能 ， 以便实时发现这些错误 ， 并在构建时立即采取措施 。 这使开发人员可以使用与功能错误相同的工程系统进行分类、划分优先级和跟踪 。
CSEO有一个独立的供应商 ， 负责评估应用程序中的可访问性 ， 但这在开发过程的后期发生 。 为了进一步向上游推进 ， CSEO推动在开发过程中采用可接入洞察工具 ， 并将公开与可接入功能相关的Bug作为管道工作流的一部分 。
此外 ， CSEO通过将基础设施集成到任务管道中 ， 使工程团队能够利用正在部署的防护 ， 并且正在推广持续集成的实践 ， 以便所有生产环境中的版本（包括热修复程序）均来自主版本并持续应用所有适用的合规步骤 。 每个发布请求都必须具有成功的构建 ， 以确保主版本处于可用状态 ， 并且始终可以为进入生产环境而做好准备 。 在主版本中维护高质量代码将最大程度地减少构建失败 ， 从而最终降低投入生产的时间 。
2.9安全地部署到客户
CSEO在创建一个环境 ， 使团队在构建想法和原型之前先对其进行测试 ， 并且CSEO实际上专注于以一种快速失败、安全失败的思维方式来鼓励客户接受有风险的创新 。 CSEO提高对客户服务更新速度的关键 ， 是以一种一致、精简且流程化方式向客户提供安全部署 。 增量式暴露和性能标签是通过受控部署向用户部署新功能的关键 ， CSEO可以迅速开始接收客户反馈 。 CSEO通过利用服务指标（例如交付流水线中的等待时间和故障）在流程中进行检查和平衡 ， 从而捕获性能下降并在超过预定义的阈值时启动自动回滚 。 实现安全的部署实践 ， 结合精简和良好管理的管道 ， 是实现持续集成、持续部署（CI/CD）模型的两个关键元素 。
2.10启用代码重用
虽然数量很少 ， 在CSEO的服务中不到5% ， 但CSEO仍在支持使用本地服务器和加入域的Azure虚拟机的应用程序 。 这导致需要不断修补服务器、升级软件并执行基本的基础设施维护任务 。 这也阻碍了CSEO扩展应用程序以适应增长的能力 。 CSEO将继续进行投资 ， 以将这些应用程序转换为基于MicrosoftAzure平台即服务（PaaS）和基于软件即服务（SaaS）的解决方案 ， 从而利用Azure的规模和可用性 。 CSEO通过提供体系结构指南和工具以实现该目标 ， 包括迁移数据、将现有功能重构为API ， 并通过重用他人已经发布的API来构建轻量级应用程序等 。
促进数据和代码重用以更快地构建解决方案并与面向服务的体系结构保持一致 ， 这要求开发人员可以轻松地发布和发现API 。 CSEO通过创建一套通用的开发一致性API准则以及一个用于发现的中央目录和搜索体验 ， 来构建API经济 。 CSEO正在根据API准则集成验证 ， 并使团队能够将API发布集成到AzureDevOps管道中 ， 并且正在定义并提供一组常见的API运行状况分析 。 CSEO还将继续致力于实现“内源”式增长的实践 ， 来实现API外部代码的共享 。 这将帮助将现代软件工程实践扩展到微软内部的其它组织 ， 在这些组织中业务主导的工程或“影子IT”正在出现 。 3：工程生产力
CSEO正在基于最新的Azure工具（例如AzureDevOps）在通用工程系统中为工程师提供一流的统一标准和实践 。 一致的开发环境使CSEO工程师可以在项目和团队之间平稳过渡 。 改进的自动化、一致性和集中式工程系统 ， 使软件工程师能够更好地专注于开发的核心角色 。 这也减少了入职培训的时间 ， 并使CSEO工程师在整个项目中更加灵活 。
3.1提高一致性
CSEO正在创建和支持标准 ， 以规范CSEO组织实践 ， 同时继续让团队在这些边界内进行自我管理 。 这有助于确保CSEO拥有更精简的团队和更高效的工程师 。 这些标准包括使用以下内容：
--AzureDevOps中常见的工作项分类和路径结构 。 通过标准化工作项分类和区域以及迭代的路径结构 ， CSEO允许工程师通过提供一致的机制将每个团队的工作与CSEO目标和优先级联系起来 ， 从而专注于工程 。 CSEO正在促进从AzureDevOps进行CSEO范围的查询 ， 以提供可交付成果 ， 例如合规性、可访问性和交付计划 。
--生产环境的命名标准 。 拥有针对不同环境（开发、测试、生产和类似环境）的标准命名约定 ， 将使它们易于区分 ， 并允许整个组织中基于特定于环境的策略自动化 。
--AzureDevOps标签的标准提供了一种用于标记相关项目的轻量级方法 。 为此 ， CSEO创建一组有限的标签并补交化 ， 这些标签与常见迭代路径结合使用 ， 从而提供一种跟踪一段时间内完成进度的简便方法 。
3.2集成开发人员工具
CSEO在开发环境中直接访问组织要求和推荐的代码分析和合规性工具 ， 从而帮助实现“左移”目标 。 CSEO开发人员通常可以通过几种方式来了解需要安装的工具 ， 例如从团队的OneNote或Wiki ， 或者通过搜索公共市场扩展来进行搜索 ， 这往往使他们脱离了主要的开发环境并且非常耗时 。 CSEO在投资自助服务功能来管理访问、设置策略、并对AzureDevOps工件（例如区域路径、工作项和代码库）进行更改 ， 使工程师可以轻松创建、更新或淘汰服务、组件和订阅 ， 从而最大程度地减少了管理此类资源的时间 。 CSEO正在通过跨工具的关键工作流的自动化来简化用户上载和管理工件 ， 以提高工程效率 ， 同时确保跨工具数据的完整性和合规性 。 对于这项工作的任何投资 ， CSEO与VisualStudio、VSCode和AzureDevOps团队以及许多其它团队紧密合作 。 CSEO希望扩展“左移”目标 ， 在部署周期的早期就检查Azure服务设计的优化以及配置优化的建议 ， 以便及时调整配置、避免不必要的Azure成本 。
3.3轻松发现资源
CSEO不断与工程师核实工程系统运行状况 ， 并针对其它微软产品组进行基准测试 。 调查反馈表明 ， 寻找与工程相关的资产一直是一项挑战 。 CSEO正在努力地以简单可靠的方式共享功能并减少冗余设计 。 CSEO希望可以在一个中心位置轻松找到最佳实践 ， 这将有助于工程师从汇报的角度了解需要使用的端到端流程和工具 ， 以保持应用程序正常运行 。 CSEO通过投资来应对许多此类机会 ， 例如建立API经济、扩展服务运行状况 ， 以及为服务运行状况数据部署通用报告工具 。 此外 ， CSEO正在建立一种机制来管理和维护端到端的软件工程流程文档 ， 并定义一种在组织内发布、维护和发现软件工程最佳实践的方法；影子IT组织也可以使用它 。
3.4通用设计系统
CSEO正在利用微软的产品设计系统 ， 来设计外观及功能与其它微软产品一样的解决方案 。 CSEO希望能够满足当今消费者对产品质量的期望 ， 这意味着应该对每个用户界面（UI）和用户体验（UX）进行设计 ， 使其具有可访问性、响应能力以及熟悉的行为、状态、运动和视觉造型 。 在复杂但通用的组件（例如标题、导航菜单和数据网格）上 ， 这可能意味着每个需要相同组件的CSEO团队的工程时间将成倍增加 。 为此 ， CSEO正在投资：
--一致性和CSEO特定模式的最低要求：为了更好地使每位CSEO工程师都能有效地提供高质量的体验 ， CSEO正在开发一套高质量的共享UI组件和UI/UX指南 。 为了为所有客户提供服务并满足可访问性要求 ， CSEO在指导和组件方面的重点是自适应Web/桌面（最小为320px） 。 CSEO正在提供工程资源和指导 ， 以达到一致性的最低要求 ， 并争取在CSEO核心应用程序中100％采用该最低要求 。
--UI工程和可访问性效率：通过将基本的辅助功能构建到每个组件中 ， 例如ARIA（可访问的富Internet应用程序）标签、对比度和制表符顺序 ， CSEO使设计和实现一致的可访问产品变得更加容易 。 CSEO还将为每个组件提供辅助功能指南和最佳实践 ， 目的是通过使用预构建的组件和样式来提高效率并减少工程工作量 。
3.5入职培训计划
使新聘人员了解CSEO的工程技术不仅很重要 ， 这样能够具有良好的入职整合体验 ， 而且对于确保CSEO文化变革势头也至关重要 。 由基础小组设计的为期三天的介绍课程可帮助新员工从高层次理解CSEO组织 ， 提供有关CSEO文化、技术和现代工程实践的关键概念 ， 其中包括为期两天的Azure培训 。 CSEO提供90天的自定进度的入职培训课程 ， 以根据地理位置、职位和团队进行调整 。 此外 ， 在首次入职培训之后的30天 ， CSEO将提供另一轮培训 ， 以确保对CSEO组织的具体了解 。 补充培训还包括：
--项目经理和工程师日 ， 用来突出并庆祝CSEO的转型进展 。
--为项目经理开设的特殊课程 ， 旨在教育新员工对CSEO项目经理的期望 。
--敏捷培训 ， 介绍敏捷Scrum并加深对敏捷概念的理解 。
--建立交流和讲故事技能的沟通培训 。 CSEO正在试行“通过讲故事的影响力”培训课程 ， 以帮助员工找到有说服力的关键信息 ， 为利益相关者提供相关见解 ， 并培养如何在即席对话中发挥影响力 。 4.结论
【微软的软件工程现代化转型】CSEO正在微软内部实现现代软件工程的愿景 。 CSEO正在倡导“LiveSite优先”的文化 ， 使用数据提供服务和业务流程运行状况的信号 ， 来告知客户与新想法和新功能有关的快速迭代 。 CSEO通过转向“DevOps”模型来支持这一点：标准化流程和自动执行策略控制着持续集成和持续部署的过程 。 这种文化以及支持该文化的工具和活动 ， 增加了对工程流程的可见性 ， 提高了服务质量和交付水平 ， 并提高了对客户体验的洞察力 ， 所有这些确保了CSEO不断改进和调整服务范围 ， 以便支持现在和将来的数字化转型过程 。 （文/宁川）


    推荐阅读


    上一篇：温州商报|一条毛巾用了好几年，温州80岁老人眼睛长了虫

    下一篇：钱江晚报|72岁老太太吃了一口这个，导致两处致命伤！六科室专家紧急抢救