简介:软件研发过程中如何让工作变得更简单高效?事务性工作应该更关注需求还是更关注任务?是持续发布还是批量发布?本文将从七个方面聊一聊软件研发过程中常见的误区及正确姿势,分享研发过程中的那些 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 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

软件研发的这些误区,你中了吗?相关推荐

  1. 语音输入常见六大误区 你中招几条?

    原标题:语音输入常见六大误区 你中招几条? 随着智能手机越来越"聪明",越来越多的新输入方式正在得到长足的发展,而作为最重要的人机交互,"语音"在近几年的发展尤 ...

  2. 关于软件研发生产力的误区与思考

    软件系统的高效开发从来没有像现在这样重要,因为疫情已经迫使全球很多软件工程师在家工作,开发人员和管理者脱离了以往的工作场所和团队.虽然出乎意料,但这个变化构成了一个罕见的"自然实验" ...

  3. 简历投递误区你中招没?

    蓝豹职业辅导:专业简历制作,就业辅导,模拟面试,职业规划专家! 简历投递误区你中招没? 毕业生简历经常出现的问题, 简历投递误区,你不注意投一次浪费一次岗位机会, 话不多说. 看看你的简历投错了没? ...

  4. mme设备内部错误_防爆电气设备安装的三大误区 你中招了没?

    防爆电气设备被广泛安装使用于煤炭.石油.化工.医药.纺织.机械制造等行业中可能出现.聚集爆炸性气体.蒸气.可燃性粉尘或纤维等危险物质的爆炸危险场所.根据调查显示,60%-80%的爆炸和火灾事故是由电气 ...

  5. 滚轮JAVA_java滚轮

    Android滚轮控件,基于ListView实现,可以自定义样式. Android滚轮控件,基于ListView实现,可以自定义样式. 原博文链接:http://www.apkbus.com/blog ...

  6. 青山依旧在,2021这一年

    过了冬至,就开始数九了,『小寒大寒又一年』,2021年就要结束了,平淡也好,无奈也罢,我们只能追随时光的脚步,因为青山依旧在,因为以勤为自在,因为还要坐看云起时. 工作在变,辛勤不变 在加入百度以来, ...

  7. 并发计算中的串行思考

    软件系统性能的提升的重要方法之一是支持并发性编程,尤其是采用多核体系结构的时候.在全局数据库.云计算和区块链应用程序中,并发性对于实现容错和分布式服务也是至关重要的.然而,对并发性的掌握一直是令人畏惧 ...

  8. 架构软件工程的未来(精要版)

    [引言]<架构软件工程的未来>一文共有近5万字,很多朋友反映阅读耗费的时间较多,导致很多人没有耐心读完,特推出4000字精要版. 1. 软件工程作为一种战略优势 我们生活在一个由软件驱动的 ...

  9. 黑苹果 电脑关机是因为发生了问题_【电脑常识】常见的电脑误区,你中了几点?...

    好的电脑使用习惯,可以延长电脑的使用寿命,减少问题的出现.对于很多电脑新手来说,在使用电脑时存在很多操作误区,今天蝈蝈就来给大家一一例举一下,看看你中了几点,希望看完之后,可以改正过来,也希望本文对于 ...

最新文章

  1. R语言使用R基础安装中的glm函数构建乳腺癌二分类预测逻辑回归模型、分类预测器(分类变量)被自动替换为一组虚拟编码变量、summary函数查看检查模型、使用table函数计算混淆矩阵评估分类模型性能
  2. C#可扩展编程之MEF学习笔记(四):见证奇迹的时刻
  3. Linux下使用popen()执行shell命令
  4. Python-OpenCV 处理视频(四): 运动检测
  5. OLEDB不使用SQL语句直接打开数据表
  6. 团队项目(NABC分析)
  7. Win2000自动登陆
  8. ZOJ 1315【Excuses, Excuses!】------2015年2月9日
  9. 《ARM体系结构与编程》中的严重错误
  10. Android APK 修改
  11. 设计求二叉树高度的算法
  12. Laravel Excel导出xls乱码
  13. RK3288 开发板 排插物理引脚对应图以及如何进入android6.0.1内核终端、uboot终端
  14. html点击a标签弹层播放视频,html中点击a标签视频在新页面播放
  15. The file Tomcat.exe was not found... Either the CATALINA_HOME environment variable is not defin
  16. 客户网站中经常用到的英文
  17. oa系统服务器价格,oa软件系统价格
  18. ACM Plan UVa - 168 Theseus and the Minotaur(图的遍历,深度优先)
  19. Fitbit IPO给智能硬件从业者的启示
  20. 43、基于51单片机数码管温控温度控制风扇系统设计

热门文章

  1. 推荐一位资深 Python 大佬
  2. 十分钟用 Python 绘制了近十年编程语言趋势图
  3. git 添加用户名和邮箱_设置 Git 账户及邮箱
  4. aspectj表达式如何书写_化学平衡常数的表达式书写
  5. 使用Microsoft Unity进行日志记录
  6. vueJs开发音乐播放器第二篇(点击歌单跳出详情页)
  7. 防火墙及其功能(转)
  8. filebeat相关registry文件内容解析
  9. iOS quartzCore学习之UIBezierPath 详解
  10. Struts2 入门