软件研发的这些误区,你中了吗?
简介:软件研发过程中如何让工作变得更简单高效?事务性工作应该更关注需求还是更关注任务?是持续发布还是批量发布?本文将从七个方面聊一聊软件研发过程中常见的误区及正确姿势,分享研发过程中的那些 Dos 和 Dont's。
结束了一天的工作,拖着疲惫的身躯,坐在马桶上,回顾一天的工作,发现有那么多的不值得,明显没有价值贡献的任务,却干了一大杯;明明可以好好工作,却硬要表演得很忙似的;明明有机器帮我们干活,却硬着头皮逐字逐句读代码;明明别人家已经持续交付了,而我们依然觉得批量来一把更经济实惠。哥很难,难的不是工作太辛苦,而是明明可以更简单,却硬要搞得很复杂,今天,我们试着扒一扒软件研发过程中的常见误区。
关注需求 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 协作示例:
原文链接:https://developer.aliyun.com/article/765773?
版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
软件研发的这些误区,你中了吗?相关推荐
- 语音输入常见六大误区 你中招几条?
原标题:语音输入常见六大误区 你中招几条? 随着智能手机越来越"聪明",越来越多的新输入方式正在得到长足的发展,而作为最重要的人机交互,"语音"在近几年的发展尤 ...
- 关于软件研发生产力的误区与思考
软件系统的高效开发从来没有像现在这样重要,因为疫情已经迫使全球很多软件工程师在家工作,开发人员和管理者脱离了以往的工作场所和团队.虽然出乎意料,但这个变化构成了一个罕见的"自然实验" ...
- 简历投递误区你中招没?
蓝豹职业辅导:专业简历制作,就业辅导,模拟面试,职业规划专家! 简历投递误区你中招没? 毕业生简历经常出现的问题, 简历投递误区,你不注意投一次浪费一次岗位机会, 话不多说. 看看你的简历投错了没? ...
- mme设备内部错误_防爆电气设备安装的三大误区 你中招了没?
防爆电气设备被广泛安装使用于煤炭.石油.化工.医药.纺织.机械制造等行业中可能出现.聚集爆炸性气体.蒸气.可燃性粉尘或纤维等危险物质的爆炸危险场所.根据调查显示,60%-80%的爆炸和火灾事故是由电气 ...
- 滚轮JAVA_java滚轮
Android滚轮控件,基于ListView实现,可以自定义样式. Android滚轮控件,基于ListView实现,可以自定义样式. 原博文链接:http://www.apkbus.com/blog ...
- 青山依旧在,2021这一年
过了冬至,就开始数九了,『小寒大寒又一年』,2021年就要结束了,平淡也好,无奈也罢,我们只能追随时光的脚步,因为青山依旧在,因为以勤为自在,因为还要坐看云起时. 工作在变,辛勤不变 在加入百度以来, ...
- 并发计算中的串行思考
软件系统性能的提升的重要方法之一是支持并发性编程,尤其是采用多核体系结构的时候.在全局数据库.云计算和区块链应用程序中,并发性对于实现容错和分布式服务也是至关重要的.然而,对并发性的掌握一直是令人畏惧 ...
- 架构软件工程的未来(精要版)
[引言]<架构软件工程的未来>一文共有近5万字,很多朋友反映阅读耗费的时间较多,导致很多人没有耐心读完,特推出4000字精要版. 1. 软件工程作为一种战略优势 我们生活在一个由软件驱动的 ...
- 黑苹果 电脑关机是因为发生了问题_【电脑常识】常见的电脑误区,你中了几点?...
好的电脑使用习惯,可以延长电脑的使用寿命,减少问题的出现.对于很多电脑新手来说,在使用电脑时存在很多操作误区,今天蝈蝈就来给大家一一例举一下,看看你中了几点,希望看完之后,可以改正过来,也希望本文对于 ...
最新文章
- R语言使用R基础安装中的glm函数构建乳腺癌二分类预测逻辑回归模型、分类预测器(分类变量)被自动替换为一组虚拟编码变量、summary函数查看检查模型、使用table函数计算混淆矩阵评估分类模型性能
- C#可扩展编程之MEF学习笔记(四):见证奇迹的时刻
- Linux下使用popen()执行shell命令
- Python-OpenCV 处理视频(四): 运动检测
- OLEDB不使用SQL语句直接打开数据表
- 团队项目(NABC分析)
- Win2000自动登陆
- ZOJ 1315【Excuses, Excuses!】------2015年2月9日
- 《ARM体系结构与编程》中的严重错误
- Android APK 修改
- 设计求二叉树高度的算法
- Laravel Excel导出xls乱码
- RK3288 开发板 排插物理引脚对应图以及如何进入android6.0.1内核终端、uboot终端
- html点击a标签弹层播放视频,html中点击a标签视频在新页面播放
- The file Tomcat.exe was not found... Either the CATALINA_HOME environment variable is not defin
- 客户网站中经常用到的英文
- oa系统服务器价格,oa软件系统价格
- ACM Plan UVa - 168 Theseus and the Minotaur(图的遍历,深度优先)
- Fitbit IPO给智能硬件从业者的启示
- 43、基于51单片机数码管温控温度控制风扇系统设计