将我们的工作方式从瀑布转向敏捷,重点在于展望目标,聚焦成功因素,然后成功转型。这是 Torstein Skarra 在 TestCon Europe 2019 大会上的话。 挪威劳工福利管理局(简称 NAV)过去采取基于项目的瀑布式方法,每年发布六次,现在已经转变为敏捷的跨职能自治团队,每个团队每天都会完成多次发布。Skarra 管理 NAV 的卓越测试中心(Test Centre of Excellence),后者支持本次敏捷转型。
Skarra 指出“项目会摧毁敏捷”。它们天生不会存活太久,重点放在具体工作上,目标常常是按预算准时完成,而不是为了给用户或者客户提供价值尽可能付出努力。项目会有自己的生命,它们开始有自我意识,因此丧失交付的每一行代码都应该达成的最高优先级:为用户或客户带来价值。
NAV 从开发项目拿来购买的代码后,他们主要做验证测试,这就将测试变成“验证合同”的过程。Skarra 提到,项目测试更关注度量进度和工作,有时候会无视真正的质量问题,比如“我们是在构建正确的东西吗?”
NAV 取消了固定价格合同,以及承包人为错误负责的条款,然后将所有合同变为“时间和材料”。承包人成为团队的一份子,大家的目标都放在产品上,一起持续改进产品。团队的构成不同,不过主要包括产品负责人、设计师、程序员、团队主管,有时候还有技术测试人员或者功能测试人员。Skarra 提到:这样一来,在业务人员和程序员之间就没有交接的过程,程序员和运维人员之间也不存在交接。团队处理一切事务,剩下最多的交接,都是在团队之内发生的迷你交接。
Skarra 提到:为了跟系统用户建立联系,团队成员需要做各种工作,比如拜访实际用户以及和他们一起工作。他们在应用中安装了直接反馈按钮。大家还建立了间接联系,方法是监控必要的功能,比如必须手工处理的交易数量。“最重要的效果是回到本源:我们是为了用户来到这里的,我们的目标是为用户和业务创造价值”,Skarra 这么说。
你所做的任何事情,如果不能直接为用户或者你的客户增加价值,也许就是应该停止做的事情;Skarra 指出。据此来看,当我们让我们的日常生活更复杂的时候,生活也就变得越来越困难了。诸如项目、水平组织、合同、系统架构(常常遵循康威法则)都让事情变得越来越杂乱无章,却披着有益的构想的外衣,其出发点都是一片好心。
Torstein Skarra 在 TestCon Europe 2019 的演讲结束后,InfoQ 采访了他。
InfoQ:在你决定采纳敏捷之前,NAV 是什么状况?
Torstein Skarra:我们当时相信项目对于软件开发有益,传统的规模经济效应适用于软件开发项目。我们当时也相信自己可以规划、设计复杂的东西,还能不出现浪费数百万资金构建错误成果的风险,然后把东西开发出来。当时我们的想法是,软件像是引擎,一次安装,永远运行。我们当时的部门是按照“规划-开发-运行”划分的,因此就产生了庞大而浪费的交接物,它们浮于表面,而且浪费大量时间。所有这些让我们需要大量协调、控制和管理,这些工作无益于最终客户。
InfoQ:你说过“NAV 不是 IT 公司”是错误的理念。能详细说明吗?
Skarra:我们的大部分服务和产品是很专业化的,而且对于我们的组织使命有重要的战略意义,所以它们必须要用定制化的软件。市面上也没有符合挪威法律的“退休金系统提供商”。因此,我们购买软件项目,雇佣大批优秀程序员,还会购买定制的软件,但我们没有能力和资源来改变或者修复这些软件。基本上,我们没有认识到:掌控处理自有 IT 资产的技能和知识,是可以带来好处的。其讽刺意味在于,我们的大部分系统是很独特的,对于我们的运营至关重要,但我们干坐在那里,认为让别人拥有那些知识是最好的做法!
InfoQ:是什么让你决定减少测试环境的数量,这么做效果如何?
Skarra:维护这些环境很花钱,这是原因之一。同时,让每个团队都有自己独享的环境,隔绝于其他正在开发的软件,即便看上去这样做有必要,但其最佳效果不过是隐藏杂乱的开发工作。现实世界中,没有多少共享环境,要想避免被投诉淹没,避免必须为临近的团队修复 bug,因为你把他们的工作搞砸了,你最好提供稳定的高质量代码。我们在实践中看到,很多团队就是这样做的,同时我们也看到很多创新想法,它们的效果和发生的地方。总而言之,这是正确的做法,我们对此毋庸置疑。
InfoQ:你是如何增加信任的?
Skarra:为了增加雇员和承包人之间的信任,我们去掉了所有的固定价格因素,同时宣布:从现在开始,我们都是地位等同的团队成员。业务侧和 IT 侧的信任,在人的层面不是严重问题。在部门之间,预算讨论、项目筹资和跨部门活动更透明了。IT 凭借交付更快、成本更低,赢取了业务侧的信任。
原文链接:
From Waterfall to Agile at NAV Test Centre of Excellence
评论