Scrum之父Ken Schwaber:敏捷是一場關於適者生存的進化(圖靈訪談)
Ken Schwaber是敏捷軟體開發運動的領導者之一。他還是一位開發者、產品經理,以及產業諮詢師。Ken和Jeff Sutherland(Scrum波士頓公司CEO)共同建立了最初版本的Scrum開發方法,在OOPSLA'95的年度會議上,他們第一次把Scrum作為正式方法提交出來。Schwaber和Sutherland是敏捷宣言的最初簽署者之一。他們是權威的《Scrum指南》的作者。如今Schwaber掌管著Scrum.org,這個網站提供Scrum資源、培訓、評估,以及向“Scrum Masters”、“Scrum開發者”、“Scrum產品擁有者”,以及使用Scrum的機構發放證書。
圖靈社群:你建立Scrum的最初動機是什麼?
Schwaber: 因為Srum管用。當時我的公司正在忙於交付一個高階產品,這個產品的市場正火,需要有經常性的改動。如果我們採用長開發週期,我的公司就會破產。所以我們設計了Scrum,它讓我們涅槃重生。
圖靈社群:你覺得在中國推廣Scrum有文化障礙嗎?
Schwaber: 不會比其他文化更困難。一種文化是否能接納並利用Scrum的關鍵點在於對可預測性的相信程度。
在文化中更理解和接納可預測性的人會相信他們可以預測未來。他們工作的目的就是通過利用人力和資源讓未來變成真正的現實。
使用Scrum的人們都曾有這樣的看法,像軟體開發這樣充滿複雜性和創造性的工作是毫無預測性可言的。這樣的結果很可怕:糟糕的軟體,趕不上的進度,浪費的金錢,洩氣的工作者。所以他們知道最重要的就是預測什麼才是真正的需求,讓員工們都認識到這點,然後竭盡所能幫助人們實現這個目標。Scrum之道的核心在於“有可為”,利用機會,避開障礙,敏捷起來。
圖靈社群:經常有人會抱怨捨棄瀑布模型的困難重重,你認為有必要把敏捷和瀑布模型結合起來嗎?為什麼?如果可行的話,如何做到?
Schwaber: 這兩個模型分別適合於兩種極端不同的情況。
對於瀑布模型,我們預測我們要建的是什麼,怎麼製作,建立計劃,然後按照進度完成。所有事情的關鍵都在於界定想要什麼的準確性,以及直到產品最終成型前的有效溝通的準確性。如果溝通環節完美無缺,沒有改變的需要,這麼做是可行的。
Scrum的假設是溝通是有缺陷的,而改變才是永遠不變的。在不超過30天的短週期中,人們建立起他們認為最終想要的東西。這在週期的最後會被檢查。根據結果與需求的和諧程度,要做出下一個週期的計劃。這是一個一直在改變的持續反饋環,根據檢查結果和需求變化做出改變。
有人曾嘗試結合兩種方法,結果讓人失望,毫無意義。還不如分開的好。
圖靈社群:一家公司如何知道Scrum是否適合他們的企業以及他們產品?
Schwaber: Scrum幾乎從來不會和某些軟體公司的企業文化契合,這些公司因為不適當的瀑布模型而壓力山大,他們在過去30年中一直都使用毫無新意的技術。
Scrum確實適合某些企業文化,為了年度預測而模仿銷售週期,然後年度預測變成了月度預測,然後檢查結果,並作出合適的變化。
多數公司對給他們開發軟體的部門都不甚滿意,因為浪費、失敗、糟糕的質量屢見不鮮。那些極度絕望或者有真知灼見的人們會努力轉移到Scrum上,這是一種更加適宜的方法,它可以反映出這家公司其餘部門運作的方式。
圖靈社群:在現實開發中,有些公司執著於死板的方法,而不會調整這些方法以適用於他們自身的環境,你對這些公司怎麼看?你對他們有什麼建議嗎?
Schwaber: 軟體發展之迅速,已經成為了公司是否能存活的關鍵,這不僅關乎公司運轉的方式,也關乎已經被嵌入到他們產品中的軟體。那些不進化的企業,不在軟體和產品開發中應用敏捷方法的企業,就無法有效競爭並存活下來。
我的建議就是,敏捷是一場關於適者生存的進化。
圖靈社群: Product owner有很大的責任,有時候,他們會成為整個團隊的瓶頸,如何解決這個問題?
Schwaber: 這個問題確實存在。所以我們要解決它。要解決這個問題有很多方法,包括為團隊增加更多的領域知識。如果團隊沒有領域知識的話,product owner就不存在,那麼我猜測整個開發就會慢下來,直到問題解決。否則就要等釋出糟糕產品,丟人現眼之後再解決了。
圖靈社群:番茄工作法是提高個體效率的方法,可以在Scrum中使用番茄工作法嗎?
Schwaber: 如果你願意的話,Scrum是一種可以內嵌番茄工作法的框架。但是,不加調整地盲目應用任何技術都是有害的。
圖靈社群:如何控制和管理技術負債?
Schwaber: 在你寫每條功能的時候,都要假設你後半輩子要一直維護和提升這個功能。就算你要上手一條爛到骨子裡的老程式的時候,也要這麼做。否則,那部分用來維護和支援老產品的開發預算就會吞噬所有要花在新工作上的費用。
圖靈社群:你認為敏捷方法過分強調了 YAGNI(你不會需要它)嗎?這樣會造成忽視遠期目標嗎?
Schwaber: 敏捷方法並不包含 YAGNI。但是敏捷確實需要清理不需要的東西。比如,為什麼要在有記錄文件的情況下和別人溝通,而不是直接和他們交談?無論如何,維護一個產品所需要的文件應該在每個週期都有發展。做有用且需要的事,剔除所有其他。
圖靈社群:有人認為敏捷方法現在在走下坡路,你認為為什麼會有這樣的聲音?你的看法呢?
Schwaber: 我曾聽見有人問,敏捷是一種潮流嗎?我認為敏捷是一系列的價值觀和原則。而Scrum建立在敏捷之上,Scrum也建立在聚焦,勇氣,開放,承諾,和尊重這些價值觀之上。
價值觀不是潮流。在我的想法中,在這些價值觀和原則下工作的人們會成為潮流,他們的方法遠遠超過其他的方法,或潮流。
圖靈社群:你怎麼看敏捷的派別之爭?你認為他們之間有衝突和矛盾嗎?他們的不同來自哪裡?
Schwaber: 敏捷和Scrum是非常非常簡單的方法。不同和衝突來自想通過製造工具、方法,以及創造基於敏捷理念的新方法而賺錢的機構。一旦金錢進入了等式的一端,衝突就會發生。這些衝突並不是非發生不可的。用你的眼睛選擇對你來說有用的方法。試驗,並持續改進。
更多精彩,加入圖靈訪談微信!
相關文章
- 敏捷史話(三):篤定前行的勇者——Ken Schwaber敏捷
- Scrum是脆弱的,不敏捷的Scrum敏捷
- Unix之父Ken Thompson的BSD密碼終於被破解了密碼
- 敏捷史話(一):用一半的時間做兩倍的事——Scrum之父Jeff Sutherland敏捷Scrum
- 關於Scrum敏捷開發,只看這一篇就夠了!Scrum敏捷
- Scrum轉型(一) 為什麼敏捷和ScrumScrum敏捷
- 基於Jira的Scrum敏捷管理實戰 | IDCFScrum敏捷
- 敏捷和scrum敏捷Scrum
- 圖靈訪談系列之一:陳世欣談產品經理與社群圖靈
- Scrum Master 生存指南ScrumAST
- 計算機之父阿蘭·圖靈傳奇的一生計算機圖靈
- Unix 之父 Ken Thompson 的密碼在 4 天內被破解密碼
- 關於SCRUM的學習心得Scrum
- 緬懷AI之父圖靈,談論人工智慧電話的過去和現在AI圖靈人工智慧
- Scrum並不敏捷! - SimonScrum敏捷
- 自己就是生存專家的“DayZ之父”,又做了一款太空生存遊戲遊戲
- 敏捷和 Scrum 之間的區別敏捷Scrum
- DataGirls社群創始人 Aislinn:做勇敢的少數派(圖靈訪談)AI圖靈
- Peaks:每週至少要進行一次使用者訪談?
- 圖靈訪談系列之九:CNode社群談Node.js技術及生態圖靈Node.js
- 敏捷工具:Scrum板與Kanban如何抉擇?敏捷工具:Scrum板與Kanban如何抉擇?敏捷Scrum
- Scrum敏捷開發學習心得Scrum敏捷
- Scrum敏捷開發方法實踐Scrum敏捷
- 敏捷開發--Scrum開發模型敏捷Scrum模型
- 建一座國際連鎖“商場”:openEuler的雄心與藍圖 | 開源訪談《源創者說》首播
- 敏捷開發:Scrum 中的 Product Backlog 介紹敏捷Scrum
- 敏捷開發大家談(一)敏捷
- scrum|敏捷開發之任務看板Scrum敏捷
- scrum敏捷開發工具leangoo標籤Scrum敏捷Go
- 敏捷大會 II 極致進化-敏捷進化型企業的未來暢想敏捷
- 關於碳中和的一點淺談
- 敏捷規模化框架的思考-再談Spotify敏捷框架
- 最常用的scrum工具、敏捷開發工具、看板工具Scrum敏捷
- 化是漸化,變是頓變:一窺 OpenAI Sora 相關技術的演進OpenAISora
- 說說我們的用的Scrum敏捷開發工具Scrum敏捷
- 敏捷如何應對變化:敏捷團隊檢查和適應敏捷
- C++ 之父:C++ 是一切的無形基礎,透露程式語言生存 40 年祕訣C++
- 關於圖片適配不同尺寸的image View(實戰)View
- 【PM】關於敏捷,瀑布流,文件敏捷