本期主题
云:多即是少?
在主流云服务提供商提供的核心功能日益趋同的当下,竞争焦点已经转移到他们能够提供的附加服务上,这就鼓励了云服务商以惊人的速度发布新产品。为在竞争中取得优势,很多新服务还在存有瑕疵、功能尚不完整的阶段,就被匆匆推向市场。过分关注速度以及产品扩张,常常导致这些由收购或仓促打造而来的服务缺陷频出,文档质量差,难于实现自动化,以及与服务商自己的其他服务不能完整集成。团队在尝试使用云服务提供商承诺的功能却经常遇到问题的时候,会感到挫败。考虑到在选择云服务提供商时,通常都是由组织高层基于各个不同维度进行决策,我们建议实施团队:不要假设你们的云服务提供商的所有服务都能确保相同的质量,应该对关键功能进行测试。如果你们的产品上市时间能够容纳额外的运维开销,可以考虑替代的开源解决方案,或者使用多云策略。
保护软件供应链
组织应该抵制冗长的人工检测和需要审批的象牙塔治理规则。相反,自动化的依赖保护(依赖漂移适应度函数),安全性(安全策略即代码)和其他治理机制(运行成本纳入架构适应度函数)可以保护软件项目中重要但不紧急的部分。这个关于策略、合规性和治理即代码的主题在我们对话中多次出现。我们看到自动化不断提升的软件开发生态系统的自然演化:与自动测试、持续交付和基础设施即代码的持续集成,以及如今的自动化治理。云成本、依赖管理、架构结构等以往人工流程的自动化呈现出一种自然演进的态势;我们正在学习如何让软件交付中的所有重要方面自动化。
打开机器学习的黑匣子
通过使用模式匹配、反向传播和其他众所周知的技术,机器学习通常貌似能解决人类所无法解决的问题。然而,尽管这些技术功能强大,但许多模型本质上令人费解。这意味着机器学习所计算的结果,无法用逻辑推理来解释。所以,当需要了解决定是如何做出,或存在将偏见、抽样、算法或其他偏差引入模型的风险时,人们就会一筹莫展。现在我们看到,诸如假设分析之类的工具,以及道德偏差测试这样的技术正在涌现出来。这些工具和技术可以帮助我们发现模型的局限性,并预测模型的输出结果。尽管这些在可解释性方面的改进,是朝着正确方向迈出的一步,但理解深度神经网络,仍然是一个遥不可及的目标。因此,在选择机器学习模型时,数据科学家开始将可解释性视为第一要务。
软件开发是一项团队运动
技术雷达诞生之初,我们就提醒不要使用那些会分隔开发团队、阻碍反馈及协作的工具和技术。通常,当新的专业人才参与项目后,为避免陷入“常规”开发的混乱局面,从业者、供应商和工具会要求某一些开发工作必须在隔离的环境中完成。我们反对这种观念,也在不断寻求新的方法使软件开发重回团队协作。在构建诸如软件之类的复杂工程时,反馈是至关重要的。随着项目不断提升对专业人才的需求,我们努力让他们融入常规的团队协作和反馈互动中。我们特别不提倡“10倍工程师”的理念,更喜欢专注于创建和赋能“10倍团队”。我们已经看到这在如何将设计、数据科学和安全融入跨功能团队,并获得成熟的自动化支持方面发挥了作用。下个阶段应致力于引入更多治理方法和合规行为。
相关洞见
贡献者
Vol.21
技术雷达由ThoughtWorks技术顾问委员会编制撰写,成员包括:
下载
点击下载最新一期和过往版本