关注需求 vs 关注任务
事务性工作的本质还是任务驱动，关注在基本的开发任务，因为任务是片段的、部分的，缺乏产品需求及目标的整体性。个体上，虽然任务完成很多，但因为缺少与其他任务在产品需求层面的拉通，也难以保证产品需求交付的按期交付。这就像忙碌的仓鼠，虽然不停歇地在滚轮上奔跑，但依然在原地。
而软件交付的本质，是持续、快速、高质量地交付有效价值。业务或产品需求才是有效价值的体现。需求来源于用户问题和业务目标，可以从业务目标、业务场景、功能需求等几个不同的维度分解需求，分解完后的需求，依然保持续其完整性、独立性，可测可发布，每一个需求的交付，都是一次假设验证的过程，是业务价值创造的机会。
所以，在软件交付协作中，通过精益交付看板可视化需求流动，才能做到价值驱动；只有通过需求，以一个整体视角，可视化“端到端”的价值流，才能做到在协作过程中的前后（职能）拉通。始于用户问题的提出，终于用户问题的解决。
所谓，Outcome over output，就是尽可能在*小化 output 的同时，*大化 outcome。output 是任务产出，outcome 是需求结果。站在老板的角度，才不看你完成了几个任务，他关心的是交付了多少特性需求。
资源效率，指的是那种视人为资源，关注人效，制造局部繁忙。然而局部资源效率的提升，并不能使整体效率提升。这是为什么呢？因为，产品交付的整个过程，需要协同所有职能，包括（但不限于）业务、产品、开发、测试和运维。关注资源效率，一是软件的交付取决长短板；二是每个职能进行局部效率优化，容易形成效率竖井，即局部来看，效率很高，产出了很多中间制品，竖井之间的交接形成了批量，整体效能并未得到任何改善。
以流动效率为核心，就是要以需求为流动单元，从用户来，然后快速流向用户，加速需求的 Time to market。流动效率的快慢直接决定了用户响应、获取反馈的效率。以流动效率为核心，必须拉通交付流程中的所有职能，打破组织壁垒。同时，聚焦流动效率，可以帮助组织即时暴露协作中的问题，如阻塞、等待等，这些问题可能是协作问题，也有可能是工程能力问题。
软件研发过程中的主要问题，永远都不是闲着的资源，而是闲着的需求。
关注问题 vs 关注活动
僵尸式站会，指的是那种照搬方法论框架，追求形式主义的站会现象。这一现象，人们往往会面临“站会是要站着开，还是坐着开？计划会议需要分上下午两场，还是集中在下午？”这样的问题。过分关注活动的形式，而忽略了问题本身就是本末倒置。
方法论框架的目的是为了交流理解的需要，而不是生搬硬套，照本宣科。软件项目协作，应该关注问题的解决，阻塞的移除，关注需求如何快速从前一道工序流动到下一道工序
跨职能团队 vs 单一职能团队
以需求价值驱动，流动效率为核心，意味着在协作过程中，必须以业务驱动，拉通从业务、产品，到开发和测试的各个职能，跨职能协同。单一职能的团队，容易形成职能竖井，导致各个职能在局部繁忙，但是整体系统协作效率低下。
我们假设团队内部的沟通效率始终大于跨团队沟通的效率，通过组建跨职能团队，可以有效提升在协作中的等待问题，让整个团队关注在需求的交付上，而不是任务的完成。跨职能团队可以是实体团队，如果没有条件，组建虚拟的跨职能团队也是一个非常不错的尝试。
人们过分强调代码评审（Code Review）的作用，而忽视了自动化代码扫描的能力。代码评审本身并不能直接提升代码质量，代码评审是社交化编程的一种手段，旨在代码评审中，形成促进团队内部知识共享，提高团队整体水平，确保团队统一规范。其本身是员工编程技能培养的一种手段。
代码扫描，可以自动化地完成代码质量的检查，借助技术手段，促进代码的高可见性，如代码的重复度、复杂度、扇入扇出依赖度、领域语言识别等等，这远比人工的检查效率高出许多。同时，结合静态代码扫描和规约扫描，把一般性的问题可以快速识别出来，如格式问题、基本的语法错误、潜在的内存问题等等；而对于一些内存问题及性能问题，也可以通过动态检查的手段来检查，如 C/C++中，常用 Valgrind，llvm-clang，efence 等等小工具就可以完成相应的动态检查。
持续发布 vs 批量发布
持续发布，就是持续地发布，即持续、快速、可靠地发布软件。持续发布，有助于问题的快速发现，同样，持续发布有助于工程效能问题的发现，需要做到持续发布，意味着：
1、需要建立统一规范的发布流程，以工具手段，将流程内建在工具上，防止过多的人工参与引入不必要的问题和安全风险。
2、建立自动、完善的质量守护体系。
3、自动化的部署手段，部署尽量做到无人工介入，如采取 Docker 镜像方式，代码与配置分离，一次构建多次部署。
持续发布意味着持续获得反馈，每天的工作有反馈。更多的反馈和持续改进的机会，有助于质量及工程效率的提升。基于云的一站式代码托管和持续发布系统，可以快速发现，即时反馈。让在线发布协同成为可能。批量发布意味着大爆炸式集成，问题集中爆发，传统的以瀑布或大迭代方式的开发方式，一般都是批量的发布方式，在当前业务不确定性如此强，变化如此快的大环境下，这种批量的发布越来越不受待见。
持续发布的效率，在很大程度上受制于质量验证的效率，人工验证的方式，完全依赖于人工验证的速度，对于互联网多端多环境的开发方式，人工验证的手段完全跟不上工程效率的需要。采用自动化的回归的方式，让开发者每次提交都能快速获得反馈，安全放心，有信心。常见的自动化测试手段可以用于基于 Robot Framework, Cucumber 等工具进行接口的自动化测试，服务间调用的契约测试，流量回放等等。这样，有了自动化的回归手段，开发者提交代码，自动触发持续集成系统的回归验证，在**时间就能获得反馈，有问题快速进行定位修改，再提交，再回归。
