XP 与持续集成解决了软件工程不接地气的一面；所有的软件工程实践的产出, 都没法与产品的代码建立起直接的关连。也就是说，所有的软件工程的实践都没法及时的反映出产品代码的现况。
Scrum DevOps
Scrum 又将软件开发拉回到软件工程般不接地气的场景；从 Backlog 的管理、站立会议、到回顾会议，都没法及时的反映出产品代码的现况。许多人都会说，这不是 Scrum 不接地气，而是团队的 XP、持续集成上的问题。但大多数实际的情况是，Scrum 使得不想写代码、甚至是不会写代码的一群人，也能对团队进行辅导、指指点点。
远离代码的敏捷教练与软件工程的顾问是一样的；都只是会引导着团队离代码越来越远, 离用户越来越远、离市场越来越远。
DevOps 让我们认知到，我们是可以有个软件架构的思维、方法，能在软件开发的阶段就能预期、评估出软件产品在运维时的状况。也就是说，是先有了这样的软件架构的思维、方法的诞生，才有了 DevOps。
然而, 同样的历史又再度的重演；DevOps 又再度使得不懂架构设计的、没进过机房的一群人，在对着团队进行辅导、指指点点。使得 DevOps 只是场加入了运维人员的 Scrum 大戏；也同样没法及时的反映出产品代码的现况，更不用说是持续交付、持续部署。
不要远离代码、更不应对软件架构是无知的; 代码、软件架构才是在软件这行的我们, 所应具备的 Common Sense。