阿里、蚂蚁、晟腾、中科加禾精彩分享 AI 基础设施洞见,现购票可享受 9 折优惠 |AICon 了解详情
写点什么

软件研发的这些误区,你中了吗?

  • 2020-07-01
  • 本文字数:3237 字

    阅读完需:约 11 分钟

软件研发的这些误区,你中了吗?

结束了一天的工作,拖着疲惫的身躯,坐在马桶上,回顾一天的工作,发现有那么多的不值得,明显没有价值贡献的任务,却干了一大杯;明明可以好好工作,却硬要表演得很忙似的;明明有机器帮我们干活,却硬着头皮逐字逐句读代码;明明别人家已经持续交付了,而我们依然觉得批量来一把更经济实惠。哥很难,难的不是工作太辛苦,而是明明可以更简单,却硬要搞得很复杂,今天,我们试着扒一扒软件研发过程中的常见误区。

关注需求 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 协作示例:



本文转载自公众号阿里技术(ID:ali_tech)。


原文链接


https://mp.weixin.qq.com/s/ELBpo7kTpp6I87L0CUA2rg


2020-07-01 10:062310

评论

发布
暂无评论
发现更多内容

带着问题读 TiDB 源码:Hive 元数据使用 TiDB 启动报错

TiDB 社区干货传送门

TiDB 整体架构

TiDB 社区干货传送门

【 AskTUG 每周精选】 SOP 系列问题拆解合集

TiDB 社区干货传送门

TiKV 源码略读 - Server Start

TiDB 社区干货传送门

升级5.1.1小问题

TiDB 社区干货传送门

【TUG 话题探讨002】看看 TUG 的技术专家都在用哪些数据库?

TiDB 社区干货传送门

YiDB在翼支付账单业务的应用实践

TiDB 社区干货传送门

【TiDB 社区版主话题探讨】-深入讨论 BR 备份

TiDB 社区干货传送门

TiDB GC 之监控及日志解读

TiDB 社区干货传送门

在Windows下调试TiDB4PG的填坑实记

TiDB 社区干货传送门

如何使用 minio 进行 BR 备份

TiDB 社区干货传送门

使用 TiDB 时的连接池和负载均衡器配置策略

TiDB 社区干货传送门

做出让人爱不释手的基础软件:可观测性和可交互性

TiDB 社区干货传送门

TiCDC使用心得

TiDB 社区干货传送门

【TUG 话题探讨001】TiDB 的应用场景有哪些?看看 TUG 的技术专家怎么说

TiDB 社区干货传送门

TiCDC 实现 TiDB 备份方案

TiDB 社区干货传送门

【TUG 话题探讨004】对 TiDB 的爱恨之情!

TiDB 社区干货传送门

docker方式部署的tidb-v3.0扩容缩容pd节点后需要滚动升级整个集群

TiDB 社区干货传送门

Raft 算法浅析

TiDB 社区干货传送门

使用MySQL Workbench 迁移SQL Server 2012数据库到TiDB 5.0

TiDB 社区干货传送门

TiFlash 5.x 与 4.x 对比测试

TiDB 社区干货传送门

通过label调度副本测试

TiDB 社区干货传送门

TiDB v4.0.12 VS v5.0.0 insert 性能对比

TiDB 社区干货传送门

记一次 Lightning 导入失败导致的 TiDB 集群重启失败事故处理

TiDB 社区干货传送门

How WebAssembly Powers Database: Build a UDF engine with Wasm

TiDB 社区干货传送门

同城双中心自适应同步方案 —— DR Auto-Sync 详解

TiDB 社区干货传送门

【TiDB 社区版主推荐阅读】SQL 窗口函数速查表

TiDB 社区干货传送门

TiDB 5.0 升级性能初体验

TiDB 社区干货传送门

TiDB 常⻅架构应⽤场景

TiDB 社区干货传送门

TiDB GC 之处理案例 & FAQ

TiDB 社区干货传送门

【TUG 话题探讨003】TUG 专家们如何做 TiDB 性能调优

TiDB 社区干货传送门

软件研发的这些误区,你中了吗?_软件工程_张燎原_InfoQ精选文章