在软件开发过程中，如何让工作变得更轻松、更高效？事务性工作应该更多地关注需求还是任务？是连续发布还是批量发布？本文将从七个方面谈谈软件开发过程中常见的问题误区和正确姿势，分享研发过程中的那些Dos和Don'ts。一天的工作结束后，我拖着疲惫的身子，坐在马桶上，回顾一天的工作，发现有那么多不值得的、明明没有价值贡献的任务，我却干了一大杯；我可以很好地工作，但我们似乎很忙于表演；我们有机器来帮助我们完成工作，但我们是逐字阅读代码；明明其他人还在继续发货，但我们还是觉得分批买更划算。兄弟，难啊。难的不是工作太难，而是本来可以简单点，偏偏硬要搞得很复杂。今天，我们试图找出软件开发过程中的常见误解。关注需求vs.任务办公室里最常见的场景无非是大家并行做很多事情，忙到深夜。“辛苦”的结果是交货时间一再拖延。事务性工作的本质仍然是任务驱动，专注于基础开发任务，因为任务是碎片化的、局部的，缺乏产品需求和目标的完整性。个别而言，虽然完成了很多任务，但由于在产品需求层面缺乏与其他任务的协同，难以保证产品需求交付的按时交付。就像一只忙碌的仓鼠在轮子上奔跑，一刻不停，而是原地不动。软件交付的本质是持续、快速、高质量地交付有效价值。业务或产品需求是有效价值的体现。需求来自用户问题和业务目标。需求可以从业务目标、业务场景、功能需求等几个不同的维度进行分解。分解后的需求仍然保持其完整性、独立性、可度量性和发布性。需求的交付是假设验证的过程，也是创造业务价值的机会。因此，在软件交付协作中，只有通过精益交付看板将需求流可视化，才能实现价值驱动；只有通过需求从整体的角度将“端到端”的价值流可视化，才能实现协作流程中的前后端（Function）拉通。它以用户问题的呈现开始，以用户问题的解决结束。所谓Outcomeoveroutput，就是在尽可能减少输出的同时，最大化结果。output是任务的输出，outcome是需求的结果。在老板看来，你完成了多少任务并不重要，他关心的是交付了多少特性需求。【Tips】以需求为导向进行协作，更加注重商业价值的角度。使用精益交付看板可视化需求交付过程。流量效率vs资源效率资源效率是指把人当成资源，讲究人的效率，让局部忙起来的那种。然而，局部资源效率的提高并不能提高整体效率。为什么是这样？因为，产品交付的全过程需要协调所有职能，包括（但不限于）业务、产品、开发、测试、运维。关注资源效率。首先，软件的交付取决于董事会的优势和劣势。其次，各功能局部效率优化容易形成效率孤岛。也就是从本地来看，效率很高，中间产品很多。然而，整体性能并没有得到任何改善。以流量效率为核心，就是以需求为流量单位，从用户出发，然后快速流向用户，从而加快需求的上市时间。流量效率的快慢直接决定了用户响应和反馈的效率。以流程效率为核心，必须整合交付过程中的所有功能，以打破组织壁垒。同时，关注流程效率可以帮助组织第一时间暴露出协作中的问题，比如阻塞、等待等，这些问题可能是协作的问题，也可能是工程能力的问题。软件开发过程中的主要问题从来不是闲置的资源，而是闲置的需求。打个不恰当的比方，讲究资源效率的老板是按小时付钱的，讲究流量效率的老板是按件付钱的。你的老板属于哪一类？【重点】资源效率关系到个人效率、人力利用率、繁忙的本地资源效率，并不能带来流动效率的整体提升。Focusonissuevsfocusonactivities僵尸站会指的是复制方法论框架、追求形式主义的站会现象。伴随着这种现象，人们常常面临“站立会议应该站着开还是坐着开？策划会应该分上下午开，还是集中在下午开？”这样的问题。过分注重活动形式而忽视问题本身，是本末倒置。方法论框架的目的是传达理解的需要，而不是机械地照搬它并照搬经文。软件项目协作应着重于解决问题、消除障碍以及需求如何从上一个流程快速流向下一个流程。在项目协作中需要注意：哪些是当前阻塞的，哪些是应该交付的，无法交付的需求取决于哪些交付的价值流打断了当前交付流程的瓶颈？是协作中关注问题的指南。我们不建议复制任何方法框架。例如，站会是站着开还是坐着开？计划会议应该分为上午和下午，还是一个下午？过分强调活动的风格就是形式主义。方法论框架的目的是传达理解的需要，而不是机械地照搬它并照搬经文。一切不以解决问题为目的的形式主义都是耍流氓。【Tips】站会6+1。跨职能团队VS单一职能团队，以需求价值和流程效率为核心驱动，意味着在协作过程中，必须以业务驱动拉通从业务、产品到开发、测试的各个职能和跨职能协作。单一职能的团队很容易形成职能孤岛，导致各职能局部繁忙，整体系统协作效率低下。我们假设团队内部沟通的效率总是大于跨团队沟通的效率。通过组建跨职能团队，可以有效改善协作中的等待问题，整个团队可以专注于需求的交付，而不是任务的完成。跨职能团队可以是实体团队。如果没有条件，组建一个虚拟的跨职能团队也是一个很好的尝试。【Tips】虚拟组建跨职能团队，将业务、产品、开发、测试等各个职能部门串联起来，实现跨职能协同。CodeScanningvsCodeReview人们过分强调代码审查（CodeReview）的作用，而忽略了自动化代码扫描的能力。代码审查本身并不能直接提高代码质量。代码审查是社交编程的一种手段。旨在促进代码审查时团队内部的知识共享，提升团队整体水平，确保团队的统一规范。就其本身而言，它是一种培养员工编程技能的方法。图片来自互联网扫码，可自动完成代码质量检测。借助技术手段，可以促进代码的高可见性，例如代码重复、复杂度、扇入扇出依赖、领域语言识别等，效率远高于人工检查。同时结合静态代码扫描和协议扫描，可以快速识别一般性问题，如格式问题、基本语法错误、潜在内存问题等；对于一些内存问题和性能问题，也可以进行动态检查，比如在C/C++中，常用Valgrind、llvm-clang、efence等小工具来完成相应的动态检查。对于Java开发人员来说，Java开发手册是一个很好的工具。同时，云端有效的代码管理工具，内置代码安全扫描等功能，可以捕获代码中的大部分安全问题。[Tips]Codereview是培养开发者能力的一种手段，而不是质量保证的手段。代码质量检查是通过使用代码规范进行代码扫描来完成的。ContinuousReleasevsBatchRelease连续发布就是持续发布，即持续、快速、可靠地发布软件。持续发布有助于快速发现问题。同样，持续发布有助于发现工程效率问题。持续发布的需要意味着：需要建立统一规范的发布流程，通过工具将流程构建成工具，防止过多的人工参与引入不必要的问题和安全风险。建立自动完善的质量保障体系。自动化部署是指，部署尽可能自由，不需要人工干预，比如Docker镜像，代码和配置分离，一次构建多个部署。持续发布意味着持续反馈，每天带着反馈工作。更多的反馈和持续改进的机会将有助于提高质量和工程效率。基于云端的一站式代码托管和持续发布系统，快速发现和即时反馈。使在线出版协作成为可能。批量发布意味着大爆炸式集成和问题的集中爆发。传统的瀑布式或者大迭代的开发方式，一般都是批量发布的方式。在当前业务不确定性如此之强、变化如此之快的环境下，这种批量发布越来越不受欢迎。【Tips】建立统一的发布流程和规范，通过工具或云原生技术实现一次构建多部署。持续发布自动测试VS人工验证的效率很大程度上受限于质量验证的效率，而人工验证的方式完全依赖于人工验证的速度。不符合工程效率的需要。采用自动回归方式，让开发者每次提交都能快速获得反馈，安全、放心、放心。基于RobotFramework、Cucumber等工具的接口自动化测试、服务间调用的契约测试、流量回放等，可以使用常见的自动化测试方法。这样，通过自动回归的方式，开发者提交代码，自动触发持续集成系统的回归验证，可以在第一时间得到反馈。如果有问题，快速定位修改，然后提交，然后返回。【Tips】自动化回归，自动化测试，持续反馈。下图是基于云效果的DevOps协作示例：
