一、敏捷与精益
敏捷：尽快交付有价值的东西；响应变化。
现在Devops是一个更大的口袋，把精益、敏捷都装起来。
1.1 精益
精益的核心：聚焦价值流动，让软件的价值流动越顺畅越好。
1）推迟开始、聚焦完成；2）不轻易开始一件事情，一旦开始，就希望尽快搞定。3）更多关注流动效率（快速的把原始需求变为用户可用的功能），而不是资源效率（团队是否每个人都在忙）。比喻：马路上摆满了车，就很堵，流动效率低。
桶仓效应：跨职能团队流动效率高、资源效率低；部门强资源效率高、流动效率低。
流动效率最高的是消防队：消防队负责快速响应；不会有人质疑说消防队没有着火的时候太闲了。因为如果消防队一直做各种事情，如果着火了，就会影响响应速度。
医院的流动效率低，对于单个人，从挂号到回家，中间每个环节都要等。但私立医院会更多考虑流动效率，让等待的时间变低。
scrum的门槛高：跨职能团队、时间盒迭代式开发。
精益讲究从现状出发，先把现状透明化，把当前价值流程透明化，抓住痛点持续改进。
有的时候部门领导会说，不行，你们这个方法太理想化了。那就可以选择低起点：先用看板把价值流程可视化出来；让团队成员聚在一起。这种方式把问题可视化出来，团队中的人就会看到，并且想办法去解决问题。然后再反馈到管理层。
有的团队之前被敏捷伤害过，比如做敏捷失败了，那么可以不拘于角色名字：需求的代表、流程运作代表、技术的代表。
流式开发模式，没有一个sprint backlog，所有的todo都在backlog里面；产品保证backlog不为空，然后开发有时间就去backlog拿用户故事。更能够响应变化，scrum中一个迭代内的需求需要保持稳定；但这种流式开发模式，只要不是在做的用户故事，都可以发生变化。
适用于大量零散但实效性强的需求，比如production support。
精益书籍推荐：何勉《精益产品开发》
二、精益看板方法核心实践
站会：假定所有的工作项都在看板上，从右到左过卡片，有问题就说，没有问题就过。效率远远高于scrum站会的三段式更新。风险用红条标注。
关注以下核心内容：需求中断、重点需求、长时间没有进展的、瓶颈（大量用户故事在测试阶段）、阻碍（什么阻碍，哪些人在跟进）
限制在制品：减少库存；正在进行中的任务都是浪费，越多则浪费越大。一个人有大量的事情在doing状态，这就是浪费；大家都很忙，但什么东西都交付不出来。需求分析中最多只有6个，开发过程中只有5个。这种方式逼着团队去正视问题，比如很多时候这个用户故事要等QA、这个用户故事要等BA、这个用户故事要等第三方团队。要把这些问题解决，而不是绕着走，再拿一张新卡其实就是绕着问题走。限制方法很多：比如泳道限制、token 限制等，token限制比如每个人只有3个token，只能工作在3件事情。泳道是水平的。
kanban：拉入新工作的信号。类似停车场的停车卡，一旦有车出去，停车卡还回来，就又可以停车了。
