对迭代交付的理解
大部分情况下，客户并不知道或者说不清楚自己具体想要什么，就像汽车出现之前，人们对于更快速度的追求可能是一匹更快的马。因此需要用最短的时间给客户提供一个产品原型，该原型专注解决客户的核心诉求，客户在使用过程中会逐渐明确自己想要什么，然后再提供另外一部分明确的诉求。
根据认知理论，在进行coding的研发阶段，研发团队对需求的认知处于较低水平，但随着需求交付工作的进行，对需求的认知理解随之升高。因此将需求交付拆分成多个小的部分，一次交付一部分，这样可以充分发掘研发团队对需求的认知理解，从而交付更好的产品。
传统软件交付是将功能部署和功能发布耦合在一起，部署即发布，但这两者不是一定需要耦合在一起。功能部署是技术决策，当功能开发、测试和验收完毕就可以部署到生产环境；而功能发布则是业务决策，业务根据市场、客户的需要通过特性开关等便捷安全的方式（不会涉及功能变更）让新功能可见、可用或者不可见、不可用。蓝绿部署、灰度发布和A/B测试是保证平稳功能变更的有效手段。
对精益开发的理解
敏捷产品开发，并不只对流程的管控，还包含Scrum、TDD、XP等工程设计，因此敏捷是一个集合概念。但敏捷都是围绕业务目标开展的，一是尽早地交付价值，一是灵活地应对变化。相比较而言，精益产品开发是结合敏捷的思想，同时又兼顾资源利用率，聚焦价值流动，获取产品研发产出投入比的最大化，从关注资源利用效率转变到关注客户价值流动效率。
准时化和自动化是丰田生产方式的两大支柱，对应软件研发中的Scrum和DevOps。前者主要着眼于按需生产、降低浪费、实现零库存，后者着眼于关注点分离、提升内建质量、实现高周转率。
端到端的客户价值交付意味着不仅研发阶段需要实现敏捷，其他阶段也需要敏捷，比如产品概念设计、需求分析、交付运营、售后反馈等阶段。因此需要实现规模化敏捷，需要通过目标分层的方式对齐不同团队之间的目标（目标由粗到细分别是：顶层愿景，商业目标，产品条线，交付功能，用户故事，细化任务），及时识别出不同团队之间的上下游关系和依赖。一般敏捷看板仅关注用户故事和细化任务层面，更粗粒度的比如交付功能、产品条线和商业目标的关注不够明确，业务/产品经理不能直观地从敏捷看板上知道某一个交付功能的状态，需要整合多个用户故事才能知道交付功能的状态。因此需要结合用户需求地图和敏捷看板，前者关注项目/产品的整体价值流，后者关注某个迭代的用户故事交付状态。
每个产品需要维护一个用户故事地图，表明产品的全貌，每个业务块有哪些不同优先级的用户功能，然后每一次迭代从不同的业务块中选择对应优先级的用户功能进行价值交付。
对精益看板的理解
精益看板不强调迭代的概念，关注的是价值持续不断的流动过程，而这些价值大部分应该来源于团队外（也就是团队的价值存在于团队之外），比如业务需求、关联协作需求、技术改进、临时任务，工作量占比大概为40%、20%、20%、20%。
一个典型的精益看板包含七个大的阶段，需求池、就绪池、设计、实现、测试、待发布、发布。其中设计、实现和测试三个阶段又分为进行中和完成两个状态。基本可以映射到软件研发的现有阶段，但关键在于三个点，一是每个需求点要基于INVEST原则进行拆分，以保证需求是可独立开发、独立交付、独立测试的。二是如何保存待发布阶段的需求点实现，不同于汽车配件可以独立放置，软件代码一般是通过GIT特性分支进行保存，但需要定期将新的修改合并到特性分支，并进行回归测试以保证功能的正确性（这也是微服务设计中推荐进行服务独立拆分的原因，降低功能间的相互影响，可独立存放）。三是每个阶段需要控制在制品的数量（精益看板的核心），让有限的资源专注于一定数量的在制品，从而提升内建质量和交付速率。并且从整体上协调各阶段资源的分配，控制并行需求的个数，保证各环节的资源利用率保持在合理的水平。
对精益效能的理解
为提升团队效能，其中比较关键的因素是提升团队的交付速率（由在制品数/前置时间得出，也可使用累积流图），其原则是暂缓开始、聚焦完成。类似于春节期间的高速路口规划，临时减少或者关闭入口，同时开放或者增加出口。对应到软件系统研发则是PO需要控制进入某个迭代的需求的总量（注意不是个数），然后SM让团队成员按照优先级以用户故事的粒度进行交付。这里需要注意的是不能任由成员选择自己擅长的或者简单的任务进行完成，因为任务只能体现生产端的工作项，只能被完成，用户故事才能体现用户价值，才能被交付。
从资源利用效率和价值流动效率两个方面衡量一个团队的交付水平。前者的量化指标包含月工作时长，代码产出量，测试用例执行个数等；后者的量化指标包含用户价值的前置时间（从需求提出到上线交付的时长），价值有效流转时间效率比（实际有效交付时间/前置时间），发布频率，平均故障修复时间、变更失败率。因此团队在回顾会上需要分析和可视化端到端的用户价值流动过程，取出明显不增加价值的中间环节，减少并行在制品的数量，缩短待交付在制品的前置时间，同时预留10%的缓冲资源以应对不确定性。
对Scrum的理解
实施站会需要注意几点。会前，确保看板反映了团队的最新状态和紧急问题。会中，看板上按从右至左的顺序关注和处理阻碍价值流动的问题，包含但不限于未反映在看板上的问题、瓶颈、中断、高优先级需求、长时间无进展的需求。会后，及时处理需要小范围长时间讨论的问题，站会上发现的需要深入讨论的问题。站会结束后需要达成几个目的，看板处于最新的状态，并反映站会讨论的结果；识别阻碍价值交付的问题，并安排其他会议进行解决；每个成员了解项目整体状态，并清除工作的优先级和潜在风险。
在迭代回顾会上需要分析缺陷的引入原因以及防治手段，针对缺陷建立反馈闭环，横轴为缺陷引入阶段，纵轴为缺陷类型。QA更多关注的是披露问题的所在、问题的成因，而提升质量更多还需要依赖研发人员关注架构设计、编码规范等工程实施。精益研发提倡从以项目为粒度控制质量，转变成以需求为粒度控制质量，也就是QA应该以用户故事作为案例集的划分，而不是从项目说明书整体着眼，但这样的设计对用户故事的拆分就有着更高的要求。