2018-11-18 20:16:57 27 Views
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 更新的速度,而在于他们开发这些更新时采用的流程。
微软的 Office 经历了同样的转变,即从几年一次的大型发布,转变成了按月定期发布所有平台新版本的做法。这涉及到业务模型、组织结构、工程角色、工程基础架构和流程的变化,以及产品和代码本身的重大变化。这个过程持续了十年之久,而且仍在进行。
在 Office 中,由于我们不能简单地缩减现有的流程,所以我们在一开始就采用了这个流程。我们需要从单个工程师开始到领导层进行转变,这种自下而上的流程有很大的不同,而且需要公司内部结构的重大改变,以及单个工程师日常工作方式的变化。
我们总结出了“5C”方针(即持续规划、持续集成、持续稳定、持续部署和持续洞察),并进行传达。这些元素是一个循环计划,首先将功能分解为更小的组件以方便安全地集成,同时保持完全稳定,快速部署(每天或更快地部署到数千台桌面、设备或服务中),生成遥测和洞察,然后再反馈到计划过程中。
对于采用敏捷开发流程的人来说,这些元素一点都不陌生,我们只是在前所未有的规模度和复杂度上尝试了这一点。
微软的“Windows 即服务”战略是对的?
与此同时,Windows 也采用了“Windows 即服务”的战略。他们也在对组织和流程进行根本性的改变(实际上因为在建立另一种验证流程之前就解散了大部分测试组织而导致他们声名狼藉)。然而,从根本上说,他们采取的方法看起来更像是压缩和缩短现有流程而不是彻底进行转变。
最大的区别在于 Windows 将继续允许将带有缺陷的部分和不完整功能纳入构建中,然后再通过一个单独的过程和周期来稳定它们。
我的观点是,在任何大型流程中只有少数几个关键点具有强大的支撑作用,可以产生正确的反馈信号。如果你做对了,这些支撑点可以为公司的各个团队和工程师以及领导提供明确的信号。而在我们的实际情况中,它推动了我们的这种持续部署稳定和可用的构建模型。这点要求为个人团队和大量工程工具的构建提供了许多创造性的策略,而且易于沟通,也相对容易衡量。这本质上是一种信仰飞跃(相信我们经过了严格的审查和讨论),可以为整个组织带来令人难以置信的创造力。
如果你不强制执行这一点,那么很容易导致个人工程师和团队中出现“公地悲剧”,而且他们还不知道他们的不稳定性和不完整性将导致其他团队的成本和开销上升。实际上,即使在之前的大型发布工程战略中,我们也常常为这些成本付出沉重代价,而且没有强制实施重大战略变革的商业模式。转向多平台、服务和订阅业务是激励人心的变革。
Windows 团队已经就他们的与众不同提出了很多论点,但我认为他们将持续面临这些问题,直到他们实现持续稳定(并开发交付所需的工具和基础设施)。这需要从每个工程师开始。如果工程师不理解这是日常工作职责的一部分,那么你就失去了支撑点。那么替代方案的推进就会演变成施加痛苦的过程,这会破坏工程师的精神状态,而不是启发他们的创造力。
上一篇: 独角兽公司的当下
下一篇: 人工智能综合认定防作弊