将我们的工作方式从瀑布转向敏捷，重点在于展望目标，聚焦成功因素，然后成功转型。这是 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 凭借交付更快、成本更低，赢取了业务侧的信任。
原文链接：