“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

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

  • 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:062302

评论

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

mac电脑高效解压缩工具:keka激活中文版

mac大玩家j

Mac软件 解压软件 解压缩工具

ATE测试工程师是做什么的?

IC男奋斗史

芯片 半导体

秒合约交易所系统开发技术搭建[多语言双端源码版本]

V\TG【ch3nguang】

代码标准之信达雅

agnostic

代码质量

Koordinator 协同 containerd NRI 增强容器 QoS,提升应用性能

阿里巴巴云原生

阿里云 云原生 Koordinator

寻找AI时代的关键拼图,从美国橡树岭国家实验室读懂AI存力信标

脑极体

存储

打造成功的SRE团队

俞凡

DevOps 最佳实践 研发效能 SRE

电商爬虫API快速入门指南

Noah

白嫖azure,随时随地ChatGPT

MorningTZH

azure 白嫖 容器应用 弹性伸缩 ChatGPT

比特币合约系统开发,永续合约交易所搭建

V\TG【ch3nguang】

比特币交易所开发链上合约dapp技术方案搭建

V\TG【ch3nguang】

币圈数字货币现货/合约秒合约交易所/系统开发

V\TG【ch3nguang】

合约跟单系统开发

V\TG【ch3nguang】

【有奖体验】轻点鼠标,让古籍数字化“重生”

阿里巴巴云原生

阿里云 云原生 函数计算

也许是时候停止编写详细的操作手册了

俞凡

最佳实践

免费 AI 编程助手 Amazon CodeWhisperer 体验

亚马逊云科技 (Amazon Web Services)

JavaScript Python 3.12 #人工智能

合约币交易所系统数字货币开发解决方案

V\TG【ch3nguang】

芯片检测哪家强?

IC男奋斗史

芯片 半导体

Python - 字典1

小万哥

Python 程序员 软件 后端 开发

Linux该如何学习,给你支招

攻城狮Wayne

职场迷茫?行动才是唯一出路!

老张

职场成长 职场发展

FBX转换GLB格式

3D建模设计

模型格式转换 FBX转GLB

目前最流行的DeFi流动性挖矿系统开发技术说明

V\TG【ch3nguang】

ATE测试工程师的职业展望

IC男奋斗史

职业规划 芯片 半导体行业

dapp丨defi丨nft丨lp单双币流动性挖矿系统开发

V\TG【ch3nguang】

从VSCode迁移到Neovim的体验

SkyFire

vim vscode neovim

阿里云在云原生领域喜获多项 OSCAR 开源尖峰案例奖

阿里巴巴云原生

阿里云 开源 云原生

1分钟搞懂什么是XY问题

俞凡

认知

为NeoAI增加千帆大模型支持

SkyFire

neovim 千帆大模型平台

2023-10-14:用go语言,给定 pushed 和 popped 两个序列,每个序列中的 值都不重复, 只有当它们可能是在最初空栈上进行的推入 push 和弹出 pop 操作序列的结果时, 返回

福大大架构师每日一题

福大大架构师每日一题

基于 Kubernetes 的 Serverless PaaS 稳定性建设万字总结

阿里巴巴云原生

阿里云 Kubernetes 云原生

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