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

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

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

关注需求 vs 关注任务

在办公室里看得最多的场景,无非是每一个人都并行工作在很多事务上,忙至深夜。而“努力”的结果还是交付时间一而再、再而三地延期。事务性工作的本质还是任务驱动,关注在基本的开发任务,因为任务是片段的、部分的,缺乏产品需求及目标的整体性。个体上,虽然任务完成很多,但因为缺少与其他任务在产品需求层面的拉通,也难以保证产品需求交付的按期交付。这就像忙碌的仓鼠,虽然不停歇地在滚轮上奔跑,但依然在原地。

而软件交付的本质,是持续、快速、高质量地交付有效价值。业务或产品需求才是有效价值的体现。需求来源于用户问题和业务目标,可以从业务目标、业务场景、功能需求等几个不同的维度分解需求,分解完后的需求,依然保持续其完整性、独立性,可测可发布,每一个需求的交付,都是一次假设验证的过程,是业务价值创造的机会。

所以,在软件交付协作中,通过精益交付看板可视化需求流动,才能做到价值驱动;只有通过需求,以一个整体视角,可视化“端到端”的价值流,才能做到在协作过程中的前后(职能)拉通。始于用户问题的提出,终于用户问题的解决。

image.png

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

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

流动效率 vs 资源效率

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

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

image.png

以流动效率为核心,就是要以需求为流动单元,从用户来,然后快速流向用户,加速需求的 Time to market。流动效率的快慢直接决定了用户响应、获取反馈的效率。以流动效率为核心,必须拉通交付流程中的所有职能,打破组织壁垒。同时,聚焦流动效率,可以帮助组织即时暴露协作中的问题,如阻塞、等待等,这些问题可能是协作问题,也有可能是工程能力问题。

软件研发过程中的主要问题,永远都不是闲着的资源,而是闲着的需求。

做个不太恰当的比喻,关注资源效率的老板是计时发薪,关注流动效率的老板是计件发薪。你们老板属于哪一类呢?

【要诀】资源效率,是关注个人人效,关注人力的利用率,繁忙的局部资源效率,并不能在整体上带来流动效率的提升。

关注问题 vs 关注活动

僵尸式站会,指的是那种照搬方法论框架,追求形式主义的站会现象。这一现象,人们往往会面临“站会是要站着开,还是坐着开?计划会议需要分上下午两场,还是集中在下午?”这样的问题。过分关注活动的形式,而忽略了问题本身就是本末倒置。

方法论框架的目的是为了交流理解的需要,而不是生搬硬套,照本宣科。软件项目协作,应该关注问题的解决,阻塞的移除,关注需求如何快速从前一道工序流动到下一道工序。项目协作中,应该关注:

  • 当前有哪些阻塞
  • 哪些到期应该交付,而不能交付的需求
  • 依赖有哪些
  • 交付的价值流中是否有中断
  • 当前交付过程中的瓶颈有哪些

我们建议的站会 6+1,是对协作中关注问题的一个指南。

image.png

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

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

【要诀】站会 6+1。

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

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

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

image.png

【要诀】可以虚拟组建跨职能团队,拉通从业务、产品,到开发和测试的各个职能,跨职能协同。

代码扫描 vs 代码评审

人们过分强调代码评审(Code Review)的作用,而忽视了自动化代码扫描的能力。代码评审本身并不能直接提升代码质量,代码评审是社交化编程的一种手段,旨在代码评审中,形成促进团队内部知识共享,提高团队整体水平,确保团队统一规范。其本身是员工编程技能培养的一种手段。
image.png

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

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

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

持续发布 vs 批量发布

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

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

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

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

image.png

【要诀】建立统一发布流程和规范,通过工具或云原生技术实现一次构建多次部署。

自动测试 vs 人工验证

持续发布的效率,在很大程度上受制于质量验证的效率,人工验证的方式,完全依赖于人工验证的速度,对于互联网多端多环境的开发方式,人工验证的手段完全跟不上工程效率的需要。采用自动化的回归的方式,让开发者每次提交都能快速获得反馈,安全放心,有信心。

常见的自动化测试手段可以用于基于 Robot Framework, Cucumber 等工具进行接口的自动化测试,服务间调用的契约测试,流量回放等等。

这样,有了自动化的回归手段,开发者提交代码,自动触发持续集成系统的回归验证,在第一时间就能获得反馈,有问题快速进行定位修改,再提交,再回归。

【要诀】自动化回归,自动化测试,持续反馈。

下图为基于云效构建的 DevOps 协作示例:

image.png

原文链接:https://developer.aliyun.com/article/765773?

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
展开阅读全文
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值