软件研发的这些误区，你中了吗？

简介：软件研发过程中如何让工作变得更简单高效性工作应该更关注需求还是更关注任务续发布还是批量发布将从七个方面聊一聊软件研发过程中常见的误区及正确姿势，分享研发过程中的那些 Dos 和 Dont’s。

所谓，Outcome over output，就是尽可能在最小化 output 的同时，最大化 outcome。output 是任务产出，outcome 是需求结果。站在老板的角度，才不看你完成了几个任务，他关心的是交付了多少特性需求。

【要诀】以需求为单位进行协作，更关注业务价值视角。通过精益交付看板可视化需求交付过程。

流动效率 vs 资源效率

资源效率，指的是那种视人为资源，关注人效，制造局部繁忙。然而局部资源效率的提升，并不能使整体效率提升。这是为什么呢p>

因为，产品交付的整个过程，需要协同所有职能，包括（但不限于）业务、产品、开发、测试和运维。关注资源效率，一是软件的交付取决长短板；二是每个职能进行局部效率优化，容易形成效率竖井，即局部来看，效率很高，产出了很多中间制品，竖井之间的交接形成了批量，整体效能并未得到任何改善。

我们不建议照搬哪个方法论的框架，如站会是要站着开，还是坐着开会议需要分上下午，还是一个下午强调活动的样式，就是形式主义。方法论框架的目的是为了交流理解的需要，而不是生搬硬套，照本宣科。

一切不以解决问题为目的的形式主义都是耍流氓。

【要诀】站会 6+1。

跨职能团队 vs 单一职能团队

以需求价值驱动，流动效率为核心，意味着在协作过程中，必须以业务驱动，拉通从业务、产品，到开发和测试的各个职能，跨职能协同。单一职能的团队，容易形成职能竖井，导致各个职能在局部繁忙，但是整体系统协作效率低下。

我们假设团队内部的沟通效率始终大于跨团队沟通的效率，通过组建跨职能团队，可以有效提升在协作中的等待问题，让整个团队关注在需求的交付上，而不是任务的完成。跨职能团队可以是实体团队，如果没有条件，组建虚拟的跨职能团队也是一个非常不错的尝试。

代码扫描，可以自动化地完成代码质量的检查，借助技术手段，促进代码的高可见性，如代码的重复度、复杂度、扇入扇出依赖度、领域语言识别等等，这远比人工的检查效率高出许多。同时，结合静态代码扫描和规约扫描，把一般性的问题可以快速识别出来，如格式问题、基本的语法错误、潜在的内存问题等等；而对于一些内存问题及性能问题，也可以通过动态检查的手段来检查，如 C/C++中，常用 Valgrind，llvm-clang，efence 等等小工具就可以完成相应的动态检查。

对于 Java 开发者而言，Java 开发手册是一个不错的手段，同时，云效代码管理工具，内置代码安全扫描等功能，可以抓出代码的大部分安全问题。

【要诀】代码评审是开发者能力培养的手段、而非质量守护手段。借助代码规约，通过代码扫描完成代码质量检查。

持续发布 vs 批量发布

持续发布，就是持续地发布，即持续、快速、可靠地发布软件。持续发布，有助于问题的快速发现，同样，持续发布有助于工程效能问题的发现，需要做到持续发布，意味着：

• 需要建立统一规范的发布流程，以工具手段，将流程内建在工具上，防止过多的人工参与引入不必要的问题和安全风险。
• 建立自动、完善的质量守护体系。
• 自动化的部署手段，部署尽量做到无人工介入，如采取 Docker 镜像方式，代码与配置分离，一次构建多次部署。

持续发布意味着持续获得反馈，每天的工作有反馈。更多的反馈和持续改进的机会，有助于质量及工程效率的提升。基于云的一站式代码托管和持续发布系统，可以快速发现，即时反馈。让在线发布协同成为可能。

批量发布意味着大爆炸式集成，问题集中爆发，传统的以瀑布或大迭代方式的开发方式，一般都是批量的发布方式，在当前业务不确定性如此强，变化如此快的大环境下，这种批量的发布越来越不受待见。

原文链接：https://developer.aliyun.com/article/765773p>

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树深入研究容器Collection的功能方法93576 人正在系统学习中