查看原文
其他

这届 Windows 不行,是因为微软不卖“软件”改卖“服务”?

Terry Crowley CSDN 2018-11-24

最近 Windows 版本质量的问题,即 Windows 10 2018 10 月更新的诸多 Bug 再次引发了有关提供“Windows 即服务”的意义的讨论。在发布 Windows 10 的时候,微软宣布了一件大事:称这是“Windows 的最后一个版本”。从今往后,Windows 将持续提供一系列添加新功能的发布,而不再延续每 3 年左右发布一次大版本的做法。


错乱的 Windows 10 是因为微软的开发流程出现问题


此前,外媒 Arstechnica 发布了一篇名为《Microsoft’s problem isn’t how often it updates Windows—it’s how it develops it》(CSDN 进行了编译《微软“作死”Windows)的文章,在这篇文章中,作者 Peter Bright 在文章中尝试探讨 Windows 出现的重大问题的原因。他在文章中提出的观点是,问题不在于 Windows 更新的速度,而在于他们开发这些更新时采用的流程。他的讨论中有很多的推测和天真的想法(关于软件开发的想法),但是我认为他的基本诊断是正确的。

我想说通过一些 Bug 来尝试诊断一个庞大而复杂的过程本身就是有问题的。这不禁让我们想起去年当苹果的发布质量上出现了备受瞩目的 Bug(2017 年苹果发布会 上,新机 iPhone X 的 Face ID 人脸识别失败)时,舆论界的惊涛骇浪层出不穷。这就像说全球变暖是个问题,并用死亡谷的温度作为证据。没错,我们是有全球变暖的问题,但是你需要更好的证据,更好地理解整体模型和系统,才能真正做出令人信服的论证。

今年夏天我发表了一篇文章(https://hackernoon.com/taking-office-agile-455f243e0978),其中描述了微软的 Office 经历了同样的转变,即从几年一次的大型发布,转变成了按月定期发布所有平台新版本的做法。这涉及到业务模型、组织结构、工程角色、工程基础架构和流程的变化,以及产品和代码本身的重大变化。这个过程持续了十年之久,而且仍在进行。这可能是我在微软时做过的最艰难的事情。

当你在大公司从事一些艰难的工作时,有时很难看出你的努力导致了什么样的改变。对于这种转变,我恰好有机会观察到另一家正在经历相同转变的组织的改变过程,因此可以做一些很有意思的比较。这就像是一个“平行时空”,通常这类的比对是不可能做到的。

在 Office 中,由于我们不能简单地缩减现有的流程,所以我们在一开始就采用了这个流程。我们需要从单个工程师开始到领导层进行转变,这种自下而上的流程有很大的不同,而且需要公司内部结构的重大改变,以及单个工程师日常工作方式的变化。

我们总结出了“5C”方针(即持续规划、持续集成、持续稳定、持续部署和持续洞察),并进行传达。这些元素是一个循环计划,首先将功能分解为更小的组件以方便安全地集成,同时保持完全稳定,快速部署(每天或更快地部署到数千台桌面、设备或服务中),生成遥测和洞察,然后再反馈到计划过程中。

对于采用敏捷开发流程的人来说,这些元素一点都不陌生,我们只是在前所未有的规模度和复杂度上尝试了这一点。


微软的“Windows 即服务”战略是对的?


与此同时,Windows 也采用了“Windows 即服务”的战略。他们也在对组织和流程进行根本性的改变(实际上因为在建立另一种验证流程之前就解散了大部分测试组织而导致他们声名狼藉)。然而,从根本上说,他们采取的方法看起来更像是压缩和缩短现有流程而不是彻底进行转变。

最大的区别在于 Windows 将继续允许将带有缺陷的部分和不完整功能纳入构建中,然后再通过一个单独的过程和周期来稳定它们。

我的观点是,在任何大型流程中只有少数几个关键点具有强大的支撑作用,可以产生正确的反馈信号。如果你做对了,这些支撑点可以为公司的各个团队和工程师以及领导提供明确的信号。而在我们的实际情况中,它推动了我们的这种持续部署稳定和可用的构建模型。这点要求为个人团队和大量工程工具的构建提供了许多创造性的策略,而且易于沟通,也相对容易衡量。这本质上是一种信仰飞跃(相信我们经过了严格的审查和讨论),可以为整个组织带来令人难以置信的创造力。

如果你不强制执行这一点,那么很容易导致个人工程师和团队中出现“公地悲剧”,而且他们还不知道他们的不稳定性和不完整性将导致其他团队的成本和开销上升。实际上,即使在之前的大型发布工程战略中,我们也常常为这些成本付出沉重代价,而且没有强制实施重大战略变革的商业模式。转向多平台、服务和订阅业务是激励人心的变革。

Windows 团队已经就他们的与众不同提出了很多论点,但我认为他们将持续面临这些问题,直到他们实现持续稳定(并开发交付所需的工具和基础设施)。这需要从每个工程师开始。如果工程师不理解这是日常工作职责的一部分,那么你就失去了支撑点。那么替代方案的推进就会演变成施加痛苦的过程,这会破坏工程师的精神状态,而不是启发他们的创造力。

原文:https://hackernoon.com/windows-as-a-service-f666206233f5

作者:Terry Crowley

译者:弯月,责编:屠敏

微信改版了,

想快速看到CSDN的热乎文章,

赶快把CSDN公众号设为星标吧,

打开公众号,点击“设为星标”就可以啦!


征稿啦

CSDN 公众号秉持着「与千万技术人共成长」理念,不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件,更有「技术头条」专栏,深度解读行业内的热门技术与场景应用,让所有的开发者紧跟技术潮流,保持警醒的技术嗅觉,对行业趋势、技术有更为全面的认知。

如果你有优质的文章,或是行业热点事件、技术趋势的真知灼见,或是深度的应用实践、场景方案等的新见解,欢迎联系 CSDN 投稿,联系方式:微信(guorui_1118,请备注投稿+姓名+公司职位),邮箱(guorui@csdn.net)。


推荐阅读:


文章已于修改

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存