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