结束了一天的工做，拖着疲惫的身躯，坐在马桶上，回顾一天的工做，发现有那么多的不值得，明显没有价值贡献的任务，却干了一大杯；明明能够好好工做，却硬要表演得很忙似的；明明有机器帮咱们干活，却硬着头皮逐字逐句读代码；明明别人家已经持续交付了，而咱们依然以为批量来一把更经济实惠。哥很难，难的不是工做太辛苦，而是明明能够更简单，却硬要搞得很复杂，今天，咱们试着扒一扒软件研发过程当中的常见误区。编程
关注需求 vs 关注任务
在办公室里看得最多的场景，无非是每个人都并行工做在不少事务上，忙至深夜。而“努力”的结果仍是交付时间一而再、再而三地延期。事务性工做的本质仍是任务驱动，关注在基本的开发任务，由于任务是片断的、部分的，缺少产品需求及目标的总体性。个体上，虽然任务完成不少，但由于缺乏与其余任务在产品需求层面的拉通，也难以保证产品需求交付的定期交付。这就像忙碌的仓鼠，虽然不停歇地在滚轮上奔跑，但依然在原地。安全
而软件交付的本质，是持续、快速、高质量地交付有效价值。业务或产品需求才是有效价值的体现。需求来源于用户问题和业务目标，能够从业务目标、业务场景、功能需求等几个不一样的维度分解需求，分解完后的需求，依然保持续其完整性、独立性，可测可发布，每个需求的交付，都是一次假设验证的过程，是业务价值创造的机会。框架
因此，在软件交付协做中，经过精益交付看板可视化需求流动，才能作到价值驱动；只有经过需求，以一个总体视角，可视化“端到端”的价值流，才能作到在协做过程当中的先后（职能）拉通。始于用户问题的提出，终于用户问题的解决。运维
所谓，Outcome over output，就是尽量在最小化 output 的同时，最大化 outcome。output 是任务产出，outcome 是需求结果。站在老板的角度，才不看你完成了几个任务，他关心的是交付了多少特性需求。工具
【要诀】以需求为单位进行协做，更关注业务价值视角。经过精益交付看板可视化需求交付过程。性能
流动效率 vs 资源效率
资源效率，指的是那种视人为资源，关注人效，制造局部繁忙。然而局部资源效率的提高，并不能使总体效率提高。这是为何呢？测试
由于，产品交付的整个过程，须要协同全部职能，包括（但不限于）业务、产品、开发、测试和运维。关注资源效率，一是软件的交付取决长短板；二是每一个职能进行局部效率优化，容易造成效率竖井，即局部来看，效率很高，产出了不少中间制品，竖井之间的交接造成了批量，总体效能并未获得任何改善。优化
image.pngblog
以流动效率为核心，就是要以需求为流动单元，从用户来，而后快速流向用户，加速需求的 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 协做示例：