现代化商业社会的变化速度非常快，不确定性很高，经常需要在信息不完备的情况下做商业决定，这已经是一个商业社会的常态。从软件的角度来讲，只有实现快速、可控、可预测的交付，才能更好的实现整个公司和商业组织的商业价值。

敏捷开发实践原则

1. 敏捷是 DevOps 的一部分

敏捷和 DevOps 都是为了应对不确定性，二者是密不可分的。敏捷主要关注需求、研发、测试；而 DevOps 更多是关注研发结束后，如何部署和监控，发现问题并反馈修改。

2. 敏捷工具的重要性

敏捷宣言中有一种思想是『工具并不重要』，但这是有问题的，并不适用大型团队的研发场景。从 ONES 的实践经验来看，工具在研发过程中可以发挥很大作用。如果整个团队的信息是记录在纸上或者在 Excel 上面，进行度量数据就会有很大难度。因此，研发团队需要结构化的方式去存储和管理相关的数据，这有利于团队进行信息分享、回溯、聚合决策总结等工作。

ONES Project 支持敏捷看板，可视化工作流程

3. 所有任务和问题都应该被记录到系统中

在研发过程中使用系统的一个优点是不会有遗漏，所有想法都可以保存并得到跟进，所有问题的处理过程及结果都可以查询，这对于软件研发来说是很重要的。ONES 在实践中发现，一些大型的公司（比如西山居、虎牙直播等）都愿意使用系统来管理研发过程。而也有一些公司在推进系统时觉得学习成本高、使用麻烦，依旧使用表格或其他手段记录数据。但这些方式容易遗漏信息，也不利于团队成员间的信息分享。

4. Story > Backlog > Sprint

在整个产品规划过程中，Story、Backlog、Sprint 可能分别是由不同的人来负责的。Story 可能指向产品总监，这是在产品上有一定决定权的人；Backlog 可能需要产品经理、项目经理或者是研发负责人共同负责。这就需要一些工具来帮助团队进行研发协作。

5. 沟通、总结、改进

产品迭代阶段结束，并不意味着研发工作结束了。版本发布上线以后，还需要及时做沟通、总结，并探讨如何改进。精益理念曾提到，发布不是结束，只有当用户真正使用到这个功能时，这个功能才算开发完成，才真正实现了它的商业价值。

DevOps实践原则

更小、更频繁的变更

不言而喻，更大的变更会积攒到一个更大的问题，修复成本可能更高，停机时间可能更长。在 ONES 内部，一周或者是三天是一个比较好的变更周期。

尽可能自动化

自动化的优点是可重复、更精准，无随机错误。人力无论做任何操作，下一次都可能是不一样的。而自动化会使工程师从枯燥的操作当中解放出来。更重要的一点是，自动化可以快速验证代码有没有问题，最好的状态是提交的代码可以在五分钟之内得到反馈。

尽快修复持续集成的问题

如果持续集成出现了问题，一个小时去修复与一周之后去修复，效率是完全不同的。同时，对于外部的业务部门来说，研发看起来几乎是黑箱的。所以使产品随时保持一个可用可演示的状态，对整个软件研发团队，对于公司内其他团队，都是一个非常重要的建立信心的手段。

分工是把双刃剑

分工使得每个人可以专注于更少的事情，效率有所提升，但是局部目标容易偏离整体目标。所以需要所有的团队成员从全局考虑，将“用户成功使用到这个功能”做为最终目标，这样每个人做出的决策在全局看来才是最优决策。

持续改进

DevOps不是一蹴而就的事情，必须坚持量化数据、做好对比、持续改进，这是需要长时间践行的事情。