敏捷 VS 精益 VS 看板方法

• 精益方法多用于企业管理，是面向全局性的战略级方法，而敏捷和看板方法多用于产研团队，是面向组织级的。我们通常把敏捷⽅法和看板⽅法视为精益⽅法的⼦集，因为它们都是精益思想的具体实例，具有部分共性，比如都反映了“关注价值”“⼩批量”和“消除浪费”等概念。
• 看板方法适用于局部改善，它更关注如何找出团队的瓶颈，并逐个消除瓶颈来提升效率，对组织结构不会有任何影响，所以实施阻力小。但是敏捷是面向组织全体的，对产品团队的项目制组织结构有要求，需要改变原来职能型的组织结构，以项目制的方式，把产品、开发、测试、运营等组成一支为业务目标负责，可以端到端交付的团队，敏捷更注重最后交付的结果。

价值观

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划
• 虽然右项有价值，但我们更重视左项

原则

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
• 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
• 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
• 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
• 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
• 工作的软件是首要的进度度量标准。
• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
• 不断地关注优秀的技能和好的设计会增强敏捷能力。
• 简单——使未完成的工作最大化的艺术——是根本的。
• 最好的构架、需求和设计出自于自组织的团队。
• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

最佳实践

• 稳定的团队：我们需要稳定、有默契的团队，即在很长一段时间内团队成员是固定不变的。
• 可预见的速率：我们需要在一个迭代当中形成团队的速率，方便知道下一个迭代我们可以做完哪些工作。
• 单件流：我们需要集中精力一次做好一件事情，所以不欢迎并行任务。
• 质量内建：我们需要在每一个环节保证好自己的质量，不让质量问题留到下游。
• 日事日毕：我们需要把任务粒度拆分成至多1天，以方便每天知道我们的工作进展。
• 设有紧急停车带：我们需要给紧急任务加上紧急停车带，以便分析紧急任务的插入情况。
• 滚动迭代：我们需要通过迭代交付来完善我们的产品。
• 持续改进：我们需要通过回顾和总结，不断强化我们的团队能力。
• 尽早交付：我们希望尽早交付版本，更快得到用户反馈，以便于更快满足用户所需。