看板方法

简介

看板（Kanban）一词源自日本，最早由丰田公司的大野耐一在1953年提出并应用于制造业。它最初是作为精益生产实践的一部分，通过可视化管理来优化流程。敏捷开发借鉴了看板的这一理念，将其应用于软件项目管理中，使得研发过程更加透明和可控。

可视化管理

看板的最大优势在于其可视化特性。通过看板，团队可以清晰地看到项目的进展，包括已完成的工作、正在进行的任务以及未来可能需要处理的用户故事（User Stories）。看板为团队提供了一个直观的工具，帮助他们了解工作状态，提升沟通效率。

沟通与协作

看板不仅是团队内部沟通的重要工具，还可以用于向上级汇报项目进展。每天的站会（Stand-up Meeting）围绕看板展开，团队成员可以快速更新任务状态，讨论遇到的问题。看板上不仅有用户故事和Bug，还包括诸如重构、搭建测试环境等不直接产生业务价值的任务，这些任务通过不同颜色的卡片进行标识，确保所有工作的透明度和可追踪性。

Scrumban 方法

过渡与融合

Scrumban 是一种混合敏捷框架，最初设计为从Scrum向看板过渡的方法。它结合了Scrum的结构化框架和看板的灵活性，旨在优化工作流程和提高效率。团队继续使用Scrum的“冲刺”（Sprint）来组织工作，同时利用看板面板进行任务管理和监督。

工作管理

在Scrumban中，用户故事被列在看板面板上，团队通过设置在制品限制（WIP Limit）来控制工作量，避免过多的任务积压。每日例会确保团队成员之间的紧密协作，并及时解决任何阻碍。此外，通过设定规划触发因素（例如当在制品数量低于预设限制时），团队可以灵活地规划下一步工作，保持高效运作。

精益模型

提高效率

精益软件开发的核心目标是提高过程效率，消除浪费。这一理念源于丰田公司的制造工业，主要思想是分析和优化所有流程，以减少不必要的步骤和资源消耗。虽然许多精益工具最初是为了制造业设计的，但其核心概念对软件开发同样适用。

关键概念

拉式系统（Pull System）：
- 在拉式系统中，每个任务完成之后，下一个任务会自动从前一个环节提取。这种模式基于客户需求驱动，而不是市场预测，减少了过度生产和库存积压的风险。
最小化未完成工作：
- 精益模式强调减少未完成的工作和半成品，因为这些通常被认为是浪费。通过这种方式，团队可以更专注于当前最重要的任务，提高交付速度和质量。
价值流图（Value Stream Mapping）：
- 价值流图是一种工具，用于识别和消除软件开发过程中的浪费。它帮助团队从开发者或最终用户的视角审视整个流程，找出低效环节并加以改进。

精益软件开发模式从一开始便侧重于提高过程的效率。它最初来自丰田公司的制造工业，其主要思想是分析所有的流程，以查明和消除浪费，不断提高效率。为了达到这个目的，精益模式提出了一些概念和实用的工具。大部分的工具在制造业使用而不能直接应用于软件开发。精益软件开发经常提及两个概念。一个是拉式系统（pull system）。在拉式系统中，一个流水线上的任何一个环节的任务完成后，都会从前一个环节自动提取下一个任务。该模式以客户的需求而不是市场预测来推动工作进程。另外，通过精益模式可以最小化未完成工作及半成品的数量，它们通常被认为是开发过程中的浪费。除了拉式系统，价值流图（value stream mapping）也经常被应用于软件开发过程中。价值流图能够有效地识别过程中的浪费。
对于软件开发而言，在开发者或者最终用户的视角上观察软件开发过程，并发现和消除无益于快速交付的行为，即为精益的软件开发。

持续交付

持续交付是经典的敏捷软件开发方法（如XP、Scrum）的自然延伸。以往的敏捷方法并没有过多关注开发测试前后的活动（如前期的需求分析、产品的用户体验设计、产品的部署和运行维护等），然而伴随着敏捷的很多思想和原则在前后端领域的运用和升华，我们在持续交付这个新的大概念下看到了敏捷方法和更多实践活动的结合和更大范围的应用。
持续交付所描述的软件开发，是从原始需求识别到最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺畅流动，能够以较短的周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，需求分析、产品的用户体验和交互设计、开发、测试、运维等角色密切协作。持续交付也需要持续集成、持续部署的支持。持续集成是指个人代码向软件整体部分交付，以便尽早发现个人开发部分的问题；持续部署是指集成的代码尽快向可运行环境交付，以便尽早测试；持续交付是指尽快向客户交付，以便尽早发现生产环境中存在的问题。
持续交付的前提是持续部署，持续部署和持续交付之间的一个区别在于，部署可以很频繁，然而实际交付给用户使用则可能根据计划进行，比部署的频率低。要实现产品的持续部署，还需要自动化构建流水线（build pipeline）。以自动化生产线作比，自动化测试只是其中一道质量保证工序，而要将产品从原料（需求）转变为最终交付给客户的产品，自动化的生产线起着核心作用。特别对于软件产品，多个产品往往要集成在一起才能为客户提供服务。多个产品的自动化构建流水线的设计也就成了一个很重要的问题。
产品在从需求到部署的过程中，会经历若干种不同的环境，如QA环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，以及产品在不同环境中的具体部署，都需要完善的工具支持。缺乏这些工具，生产流水线就不可能做到完全自动化和高效。

DevOps

DevOps（Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（Quality Assurance,QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作，由持续交付演变出了DevOps，即开发端和运维端的全程敏捷思维。传统运维人员和开发者之间的目标是有差异的，开发和运营原本有着不同的目标，开发人员希望快速提交产品，运营人员希望产品的更合理化、高性能、高可靠等，减少维护成本，开发者和运维人员之间目的上的差异就叫作“混乱之墙”。

图 x.x DevOps

其它敏捷方法