人工智能无法加速软件交付

速度从来都不是目标

提升工作效率的首要意是为了更早获取反馈。当你发现你令人惊叹的新功能并未让用户感兴趣时，可以立即停止开发。

微軟的 Word 是当今最强大、功能最齐全的文字处理软件，但已经没什麽人专门用他了。他们都在用功能少得多的谷歌文档。这说明谷歌选择的功能必然更具吸引力，或者说更少的功能让软件变得更好用。

如果在二十年前问别人，他们会告诉你微軟 Word 在同类软件中拥有不可撼动的地位，但现在它只占有 3.9% 的市场份额，而谷歌文档占 9.6%。

当你更看重反馈而非速度时，就会让反馈循环来主导整个软件交付流程的节奏。以这个节拍来设定节奏，能为你留出关键余地去处理反馈，并做到敏捷理念所倡导的核心：快速调整方向。

把反馈当作节拍器、为整体工作节奏定调的组织和团队往往能够主动找出并消除所有打乱节拍的工作。他们规划团队架构，以最小且经过精心设计的依赖关系来开展工作，简化变更审批流程。

Elite 团队是一家大型医疗保健企业旗下的软件团队，他们每六个月发布一次病人管理系统，决策支持系统的测试周期为两周，如果发现问题还要再加两周，如此循环往复，直到某个版本测试通过为止。

即便有着这样的过往，他们还是设计开展了为期六个月的工作计划，每三小时就能创建一个可部署的软件版本。他们遵循了一套非常强大的技术实践，但削减掉的内容或许比新增的更为重要。

频繁反馈和决策敏捷性才是核心优先事项。那些已经通过持续交付等实践解决了吞吐量 / 稳定性权衔的团队，对单纯追求速度的执念会更低，他们更愿意去挖掘更有价值的发展机会。

小团队更优。大多数深知沟通与协调复杂度的软件团队都会把人数控制在 6 至 12 人的规模区间，也就是所谓的"两张披萨"团队。如今有了人工智能，我们应当考虑打造"一张披萨"规模的团队，甚至更小。