Fin Goulding專訪：在普世管理中注入敏捷

近期在倫敦舉辦的DevOps企業峰會上，Aviva首席國際資訊官Fin Goulding做演講介紹了如何在整個組織中使用Flow原則推進敏捷能力。InfoQ採訪了Goulding，就演講中的一些提法做了深入的探討。

\\

InfoQ： 您在演講中提到“低效的離岸外包”。從您的經驗看，導致離岸外包策略低效的原因何在？資訊長及組織應如何正確處理合作伙伴關係難以按預期運作的問題？

\\

\

Fin Goulding：有太多的企業將其離岸供應商視為一種增加員工的廉價方式。但我認為，該戰略存在缺陷。我曾在布宜諾斯艾利斯的一個離岸部門任職多年。目前為止，最成功的團隊可具有端到端的交付責任，包括產品所有權和生產部署。但這需要信任、可行的最低限度治理和真正的夥伴關係。組織確實需要找到合適的合作伙伴，讓他們有機會證明自己具有端到端的能力，然後再做適當的擴充套件。

\

\\

InfoQ：您並未掩飾自己對Scrum持不喜歡的態度。對於開始採納敏捷方法的組織，要投身該領域的變革中並避開那些您認定是Scrum設下的陷阱，您有哪些建議？

\\

\

Goulding：我並非厭惡Scrum，而只是喜歡抨擊它，因為我認為Scrum需要做重大的改進，並且很可能需要徹底的改頭換面。但我必須坦白，我的妻子就是一位優秀的Scrum Master和敏捷教練，我們之間的確做了很多辯論！對我來說，Scrum（在某種程度上，包括DevOps）的範圍太過狹隘，過度專注於技術。實現Flow原則將靈活性擴充套件到業務團隊和客戶，從而為普世管理注入靈活性。要充分了解Flow原則等最新敏捷技術，需要對Scrum方法具有切身體驗。但我不建議在擴充套件的框架中扮演（sheep-dig）每個角色，或是自上而下地推動敏捷期望。要實現最優工作方式，我們應支援團隊做自管理（self-manage）、協作並改進。在我看來，一位優秀的敏捷教練是物有所值的，但應確保企業僱傭的人具備Scrum、看板、流程和價值管理等廣泛的技能。

\

\\

InfoQ：在DevOps企業峰會上，多位演講者都提出一家組織應成為學習型組織。但在很多組織看來，很難養成將學習嵌入到日常工作中的習慣。您是否可以給出一些建議，以便組織可以根據這些建議改進組織行為，養成學習的心態。

\\

\

Goulding：從你自身做起。如果你的團隊或同事看到你持續學習，通過Meetup、以會議或部落格寫作方式給出各種話題等方法，這將會激勵他們亦步亦趨。必須將團隊或個人面臨的每個問題都視為學習的機會，而不是責備的機會。要做到分享，存在著一些簡單的做法，例如在每週站會（stand-up）上提出本週團隊所學習的內容。還有一種寓教於樂的方式是帆船回顧會議(Sailboat retrospective)。它可以解決最棘手的問題，推動學習的機會。

\

\\

InfoQ：“敏捷已死。敏捷長存” 。讀者應如何看待Ron Jeffries的文章？

\\

\

Goulding：對於Ron、Dave Thomas以及其它幾位敏捷宣言最初發起者撰寫的這篇文章，我的解讀是他們認為人們失去了指引敏捷方向的北極星。人們不再做到敏捷，而是藉助那些缺失持續改進的工具和框架購買敏捷。因此我提到的“敏捷已死”，主要關注的是當前在方法論、職能、工具和領導行為上存在的一些不良方面，並給出使用Flow原則開展文化轉型的優點所在。其中，Flow是實現業務敏捷性的最小框架。事實上我總是講，人們可在Flow中使用任何自己喜歡的工具、方法或技術，只要它們能為組織給出有價值、高質量的產出。在我看來，敏捷將擺脫a當前的侷限後繼續存活下去，此外別無選擇。

\

\\

InfoQ：您提到您管理著一個DevOps團隊。在一些人看來，DevOps團隊是一種反模式，DevOps應是每位員工的工作。您如何看？

\\

\

Goulding：我們具有一些使用DevOps實踐的Flow團隊，我認為這就是事情的發展方向。大家應該看到，DevOps現在已經使用了10年，其最初的目標是解決開發人員和運維人員間的問題。今天，我們看到DevOps擴充套件為更廣泛的業務和技術團隊，這就是為什麼我更喜歡稱之為“Flow團隊”，而不使用DevOps或DevOps 2.0。我完全相信，這樣的整體團隊將成為未來最成功企業的核心。

\

\\

InfoQ：許多組織在獲取正確度量（甚至是任一度量）上步履維艱。您在演講中提到你只關注交付時間（Lead Time）和迴圈時間，該結論是如何得出論的？如何使這些度量可見、可分享並可用？

\\

\

Goulding：有一些度量為我提供了能直接改進之處，但也有一些度量所展示的問題是我無法直接改進的（例如轉換率、NPS或利潤），所以我聚焦於其中一小部分關鍵度量。但在生產力目標的驅使下，一些度量會對團隊造成打擊，甚至更糟的是會影響到每個人。我一直關注的如何是確保工作項或Story具有統一的規模，進而易於確定工作流中存在的問題並加以改進。或許是某位團隊新成員需要得到幫助，或許是某個Sotry過於複雜而需要做簡化。而交付時間和迴圈時間可突出體現這些問題。在本次峰會的演講中，我也著重提及了等待時間。該度量最好地衡量了生產力情況，時常能表明存在著過度的場景切換問題。我認為開發和運維間的等待時間，就是推行DevOps的一個驅動力。

\

\\

InfoQ：如果人們覺得領導者並不瞭解DevOps，並且沒有表現出他們在DevOps領域中的期待行為（例如，剔除礙手礙腳者），那麼人們應該怎麼做？

\\

\

Goulding：要了解高績效組織的做事方式，Puppet Labs釋出的DevOps狀態報告（State of DevOps）是一個非常強大的資訊來源。我建議大家和領導者共同分享所有來自類似組織的報告例項。此外，不能表達任何商業價值的技術術語，的確會阻礙對DevOps的採納。大多數領導者並不願意承認他們在某些事情上缺乏理解。因此要得到領導者的支援，最好是幫助他們去理解這些事情。但是要做好準備，成功實施的全部榮譽都應歸功於領導者！因此在實施DevOps過程中，應邀請領導者參加每週站會（stand-up），並讓他們直接去處理那些礙手礙腳者。

\

\\

InfoQ：您在演講中提及“梳型技能”員工。您認為這類員工是否常見？是否每位員工都能成為“梳形技能”人才？

\\

譯者注：下圖表示了“T型技能”（T-Shaped）、“π型技能”（Pi-Shaped）和“梳型技能”（Comb-Shaped）。 

\\

\

Goulding：多年來，我一直在推動一種我稱之為“HR 2.0”的方式，並與許多HR專業人士探討過“T型技能”、“π型技能”和“梳型技能”。從技術領域看，很多人可以設計、編碼、構建資料庫，並測試和部署應用，所以我很疑惑，為什麼每種技能都會演變為一種單獨的工作職能？在許多企業中，技能已經成為劃分工作職責的一種方式，或許不少企業正試圖擴大這種做法。但我認為，諸如零工經濟（Gig Economy）等新方式的出現，人們將得以擺脫單一技能的束縛，採用多種交易方式生活。要是能與DevOps 2.0或Flow Teams（將DevOps擴充套件到更廣泛的業務和技術團隊中）相結合，那麼人們將可成長為最有價值的人才。設想一下，如果企業家支援員工在傳統的工作職責之外謀求發展，那麼企業自身就可以培養“梳型技能”人才。

\

\\

在任Aviva國際資訊長之餘，Fin Goulding還合著了多本專業書籍，包括《Flow——改革者、獨行俠、創新人士和領導者的手冊》（“Flow - A Handbook for Change Makers, Mavericks, Innovation Activists and Leaders”）、《Flow的12個步驟——業務敏捷的新框架》（“12 Steps to Flow: The New Framework for Business Agility”）和《從DevOps到工作流——建立贏得未來的團隊》（“From DevOps to Flow: Creating Teams That Win the Future”）。

\\

檢視英文原文： Fin Goulding Injects Agility Into the Management of Everything