將我們的工作方式從瀑布轉向敏捷，重點在於展望目標，聚焦成功因素，然後成功轉型。這是 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 憑藉交付更快、成本更低，贏取了業務側的信任。
原文鏈接：