精益、敏捷、看板 VS DevOps，你pick谁？一文搞懂它们的区别和联系！
最近收到读者的留言，提到敏捷、Scrum、看板、精益三者不冲突，有些敏捷方法不是非此即彼，可合用。在《为什么我建议你用看板方法去构建敏捷团队，而不是Scrum！》一文中，也并不是说我们就只能用看板，完全不建议用Scrum，只是看板方法更加轻量，是一种渐进变革方法，使用起来更容易被团队接受。
看板方法当然可以与Scrum结合，毕竟任何一个方法或实践都有它适用的场景，在《DevOps是什么？为何能风靡全球（三）– DevOps落地实践的道法术器》一文中，我们也说过运用方法论可以使用 Why-How-What 的“黄金圈法则”，首先要理解方法的目标和要解决的问题，其次才是原则和相关实践。看板方法与Scrum的站会配合使用，可能对大多数团队来说就是比较合适的，敏捷中的“面对面沟通”实践可能对现在大多数团队来说并不具备实施条件。
基于这个话题，我们继续聊下，敏捷、精益、看板、DevOps等方法之间，到底有什么区别和联系呢？
笔者之前的一系列文章也详细介绍过，可点击文章末尾的合集标签查看。这里简要描述下各自的目标和概念：
++敏捷++
敏捷（Agile）是一种软件开发方法，强调快速响应变化、客户合作、团队协作和持续交付有价值的软件。敏捷方法通过迭代和增量的方式来开发软件，敏捷方法注重灵活性和快速反馈，以便快速适应需求变化。著名的实践包括Scrum、极限编程（XP）等。
++精益++
精益（Lean）是一种源自制造业的管理方法，强调消除浪费、持续改进和最大化价值。在软件开发中，精益开发意味着快速识别和开发有价值的功能，同时避免过度开发和浪费资源。精益方法注重最小化可行产品（MVP）的迭代和反馈，以便快速学习并做出调整。精益实施的五大原则，包括识别客户价值、分析价值流、流动、拉动和尽善尽美。
++看板++
看板（Kanban）方法来源于精益生产，在很多方面，看板都是建立在精益的基础上的。注重工作流动，限制在制品，建立拉动系统，关注系统整体的优化而不是管理个人的绩效，根据数据做出决策，并以渐进的方式不断改进。看板可应用的领域很广，不仅可以应用于IT行业，还被营销机构、人力资源、媒体和设计服务、客户支持、产品开发和教育等领域应用。
在软件开发中，看板方法通过可视化的方式来展示任务状态、工作量和进度，以便团队成员更好地协作和沟通。看板方法注重工作项的可视化和限制在制品（WIP）的数量，以避免过度工作和资源浪费。
++DevOps++
DevOps起初是为了解决开发和运维之间的协作问题，吸纳敏捷、精益等优秀方法，已经发展为优秀的软件交付方法论，并在持续演进。DevOps致力于提升软件交付效能，改善软件从业人员的工作和生存环境，帮助提升组织效能。DevOps运用先进的技术、工程和文化手段，实现平台、流程、人的有机结合，注重持续改进，通过持续提升软件交付效能和员工幸福感，不断为客户创造价值，也帮助公司提升团队效能和组织效能。
++敏捷、精益、看板、DevOps之间的联系++
看板方法起源于精益，DevOps则是敏捷开发和精益生产思想的一种演进^[1]^，四者之间的联系如下，供参考：
或许有人认为敏捷宣言囊括更多，甚至认为精益也属于敏捷的一部分，因为精益实践也匹配敏捷宣言。不过，根据Bob大叔的《敏捷整洁之道：回归本源》一书^[2]^，精益属于敏捷的观点是错误的。笔者对此观点深表认同，我们不能过于神化敏捷或者神化精益，要控制某一个方法论就能囊括一切的冲动。
++结语++
如果再加上研发效能呢？研发效能的概念是：更高效、更高质量、更可靠、可持续地交付更优的业务价值的能力。敏捷、敏捷、看板、 DevOps是方法、手段，提升研发效能才是目标啊！
参考：
[1] https://book.douban.com/subject/35103584/
[2] https://book.douban.com/subject/35083518/