iThome

在全球化經濟帶來的壓力下,當今企業日益需要將軟體生產能力作為核心競爭優勢。

然而,許多CXO(chief experience officer)都發現他們的軟體開發實踐做法仍然和20世紀80年代沒什麼差異。儘管大量的事實已經證明:預測型的、以計畫為基礎的瀑布式流程經常無法及時交付有實際價值的軟體,還阻礙了公司及時回應客戶日新月異的需求和市場環境,但他們仍然普遍沿用這些流程,而且此種情況一直沒有獲得改善。

為了應付這些挑戰,人們開始廣泛應用較敏捷而且適應性較強的軟體開發技術。透過運用這些技術,組織將能夠加速交付高價值的軟體。Scrum就是其中一個被眾多組織廣泛使用,且已受過驗證的流程。

此為一份關於『如何在企業中實施Scrum』的「攻略」。是一本手冊而非說明書,因為每個組織都是獨特的。在一個組織中實施Scrum的方式必然與另一個組織中的方式不同。由於實施中遇到的阻礙、需要改變的東西、變革的難度,以及實施變革的人員不同,因此相關的時間表、優先順序及工作量也會有所差異。

Scrum與軟體敏捷概論論

表面上看來,Scrum是個非常簡單的流程──只有少量相互影響的實踐和規則,沒有過度死板的規範,易於上手,而且幾乎可以立即提高生產效率的軟體管理方法。

Scrum本質上會專注在如何讓整個組織開發出成功的產品。即使在技術不穩定的情況下,隨著需求、架構和設計的湧現,它也能夠協助組織在固定的時間中交付出有用的特性(feature)。Scrum可以在專案初期引入,也可以在專案中期引入。

Scrum的核心在於它以iterative增量式的流程開發產品或是管理工作。即在每次iteration結束時,開發出潛在可交付的功能集。

Scrum的特徵在於擁有產品待辦清單──該表根據優先順序管理需求(如圖C-1所示)。產品負責人負責檢視對產品待辦清單的變更。經過大概為期30天的iteration才能實現需求,此種iteration就稱為Sprint。Sprint只關注產品待辦清單中優先順序最高的需求。每個Sprint的目標就是完成一個潛在可交付的產品增量。Sprint進行期間,藉由每日的「Scrum」會議來觀察需求的檢查點。會議上人們會討論到團隊目前進度及活動的狀態,還會提出有可能「阻礙」個人或團隊工作的障礙。藉由此會議,Scrum Master就能夠檢視現在距離Sprint所承諾的目標還有多遠,並針對如何確保Sprint能成功完成提出中途修正的建議。圖C-1顯示了Scrum的整體流程。

 

Scrum的原則

當瞭解過Scrum的一些機制後,CXO應該要理解指引Scrum的關鍵原則:

●      堅信經驗型的流程(而非計畫型流程)才是最有效的軟體開發流程。

●      堅信一旦組織的障礙移除了,一個自行組織和自行管理的團隊自然而然能夠交付相較於其它的管理狀態,品質較為良好的軟體。

●      你能夠在規定的時間和預算內交付最有價值的軟體,但是你無法精確預測團隊能夠交付什麼功能。

Scrum宣告只要能夠認清這些關鍵原則,就能夠將組織從眾多妨礙有效軟體開發的束縛中解救出來。然而,CXO還必須意識到,要採用這些關鍵原則同時也預示著對組織潛在的重大變革。由於這些原則組成了Scrum的根基,因此每項原則都值得我們進一步再做探討。

採用經驗型流程還是計畫型流程

Scrum相信大多數今天的系統開發都是根據一個不正確的思想基礎──透過更多與更好的計畫將能夠獲得較為可預測和較高品質的成果。Scrum認識到應用程式開發是個難以預測且異常複雜的(試想一下其中包括了幾十萬行手動編寫的程式碼),其中的價值也只能夠使用經驗來衡量。畢竟你所開發的應用程式可能從來沒有被別的團隊在任何地方開發過,你的團隊開發過相同程式的可能性就更小了。因此,『參考之前的脈絡或按部就班的計畫』這種方法是無法有效解決軟體開發中舊有且難以預測的問題的。

Scrum將系統開發流程定義成一套寬鬆的實踐,其中包含了一些已知且可行的工具和技術,還有一個被授權與客戶或產品負責人密切相關的團隊。由於其中許多實踐做法是寬鬆的,因此需要加以控制(例如,經常性的檢查及檢視)來管理風險,並在每個時間點提供專案狀態的即時經驗證據。

要權衡是否使用Scrum其實非常簡單:

要使用Scrum每天都花一點時間即可知道實際進展如何?

還是

自認為正按照非常完善的計畫按部就班前進,卻在許久之後發現有錯誤?

消除障礙團隊就可以專注工作

在Scrum中團隊是最重要的。因為他們是真正負責設計、開發和交付程式的人。因此,幫助他們消除障礙來提高他們的表現就能提升組織向客戶交付商業價值的表現。管理階層的使命是幫助團隊消除障礙;而團隊的使命就是完成他們所承諾要完成的Sprint待辦清單項目。

換言之,在Scrum中團隊是有責任與義務得交付產品的。團隊必須能夠自行組織,自行管理並自行實現Sprint的目標。對於許多組織而言,如此一來就等於要在組織裡引起天翻地覆的變化。層次型與技術型的管理思想會在本質上被Scrum淘汰。現在,只要產品負責人設定好目標和優先順序,團隊就可以自己找出達成目標的方法,而不再一直需要有人告訴他們該怎麼做。

較少卻優良的預測與錯誤的自信

Scrum源自於一個前提:開發軟體是一項必須在瞬息萬變的技術環境中施展且非常複雜的業務。沒有人能夠可靠的預測出或肯定的計畫出團隊將交付什麼、何時交付及交付的品質和成本如何。Scrum相信團隊可以做出此種程度的預測,並針對這些預測進行交流,還能根據不同的風險藉由討論制定一個短期的計畫,隨著專案的進展還可以根據實際的情況做調整。此處需要達成的共識是:團隊需要在給定的條件下,盡可能交付出最優良的軟體,遵循任何手冊都不會改變「最優良」的定義,只是會去減緩團隊對現實世界的複雜度和不確定性的回應速度。

根據過去的經驗,忽略上述這些原則,將會為組織帶來眾多問題,如:

●      管理階層相信他們可以預測成本、交付時間表,以及可以交付的功能,隨後再根據這些預測來制定計畫。

●      開發人員和專案經理被迫生存在謊言中──他們假裝計畫、預測和交付能夠很可靠。他們以這種方式工作,卻必須假裝正在使用另一種方式。到最後,情況將會變得完全失去控制。

●      系統將要交付的時候,通常會偏離需求,並需要重大的修改。導致此種問題的關鍵就在於過高的iteration成本讓人們直到最後一刻才看清團隊正在開發的東西是否有用。

認清這些事實也是一項挑戰──試想,哪位經理會告訴主管,他不清楚當給定的日期來臨,團隊會交付出什麼東西?然而,此方式的好處是組織能夠真正自由的為終端使用者製造更良好的產品,同時由於能夠加速製造出這些產品,因此毫無疑問的能為業務創造出較多的競爭優勢。

Scrum與軟體敏捷

20世紀90年代中期,Scrum就已經開始被使用了,現在它已經被全球數千個專案所採用。此段期間,除了Scrum以外的一些新式iterative流程也開始抓住人們的視線。正如Scrum一樣,這些流程都融合了新舊思想,但是它們無一例外地強調下列各方面:

●      開發團隊會與業務專家緊密合作

●      面對面的交流方式(會比書面的說明文件更有效率)

●      頻繁交付出新的可部署且具有商業價值的軟體

●      目標、流程和產出物(artifact)都需要具有透明性

●      緊密合作的自行組織團隊

●      建置程式碼的方式及團隊自身能夠持續適應變化的需求

2001年,包括Scrum領袖在內,各個流程的創始人和從業人員會晤並討論這些流程的共通之處。他們使用「敏捷」作為涵蓋性的術語,並制定出《敏捷宣言》,其最重要的部分是下面對共同價值觀的描述。

我們經由親身的體驗和協助他人發現了優質的軟體開發方法。藉此,我們得出了下列價值觀:

●      獨特性和互動優於流程和工具

●      有效的軟體優於面面俱到的說明文件

●      與客戶協作優於合約上的談判

●      回應變化優於遵循計畫

●      也就是說,位於右邊的內容雖然也有價值,但是左邊的內容更為重要。

為Scrum做準備

一旦CXO對Scrum和敏捷能夠帶來商業文化上的好處有所瞭解,通常他們就會採取下一步行動來試看看這類型的開發流程能為組織帶來什麼樣的改進。

Scrum誕生後的15年間,大多數Scrum的實施都是由下而上的。換言之,如果一個專案團隊採用了Scrum並產生了不錯的效果,另一個團隊也會接著嘗試,很快Scrum專案就會遍佈整個組織。但在最近,許多組織希望由上而下、指令式的實施Scrum,試圖提高組織的回應速度和生產效率。

由於Scrum非常依賴授權於團隊和「讓團隊做決定」,因此由上而下的實施需要充分的考慮和準備。

「用Scrum來武裝」軟體開發流程和整個組織

許多組織已經忍受各種效率低落和障礙很多年了,Scrum可以快速找出這些問題並協助他們找到解決的方案。解決這些問題需要費些力氣,但幸運的是,Scrum專案會以生產效率和價值的提升來作為回報。

實施Scrum組織必須先完成2項工作:首先,必須指引開發團隊使用Scrum來開發軟體;其次,為團隊消除『要達到最佳化創新和軟體交付會遭遇到的障礙』。第一項工作將能改善軟體的交付;第二項工作則能消除第一項工作中『要達到提高投資回報率和生產效率』會遭遇到的障礙。

這2項工作都充滿挑戰,且需要艱苦的付出,要完全實施Scrum可能需要長達5年。它們是組織變革的核心,因此無論管理階層的要求有多強烈,也無論他們許下了什麼承諾,這2項工作都不能草草了事。

Scrum中每日與每月的檢視和調整使得所有東西都變得顯而易見,例如:程式碼、流程,以及公司內部的   障礙。使用Scrum的專案能夠定期找出各種需要被記錄、評估、排列優先順序和解決障礙。

實施Scrum的速度直接取決於下列各方面:

●      組織中需要進行變革的程度。

●      改善軟體開發和交付流程在組織內的迫切程度。

●      領導力在組織內的有效性。

CXO身為組織級的Scrum Master在持續變革中所扮演的角色

在Scrum中,Scrum Master的職責就是保證Scrum團隊都依靠著Scrum的價值和實踐生存。Scrum Master能確保團隊不會過度承擔他們在一個Sprint內無法完成的工作量,並以此來保護他們,同時還會不斷消除妨礙團隊達成Sprint目標的障礙。

然而,當團隊遇到組織層次的障礙時,就需要CXO和主管們出馬了。他們需要移除這些有可能會阻礙敏捷開發模型成功的組織障礙。

組織級的Scrum Master的工作就是透過觀察來確認,並為組織內部引起變革與消除各種障礙。也就是說,身為組織級的Scrum Master,CXO主要擔任變革代理人。而障礙的清單就是產品待辦清單。身為Scrum支持者的CXO則扮演這些障礙的「產品負責人」,為這些障礙排列優先順序。組織內以團隊為單位用Scrum流程處理產品待辦清單中的障礙,而交付物就是這些障礙將被移除。組織變革的待辦清單在試行(pilot)專案期間就開始建立,只要在Scrum的檢查和調整期間,還能夠找到需要改變的地方,此清單就會一直存在。

組織級的Scrum Master需要定期與所有Scrum Master、產品負責人和支持者討論並研究出如何進一步挖掘組織級的變革產品待辦清單。在Sprint中將組成負責驅動變革的團隊。在Sprint檢視會議上,人們會一起檢視已經發生的變革和可用於檢測變革進度的指標。CXO將透過此種方式參與到所有組織級的持續變革中,以達到提升軟體開發團隊的生產力和品質等特定的目標。

注意!變革沒那麼容易!

變革是一項困難的工作,同時也沒有捷徑可走。一些正在實施Scrum的組織有時會把實施期間遭遇的困難錯誤的歸結為某個人的錯誤,以為只要沒有這些「錯誤」,他們遇到的問題就會不翼而飛。此種錯誤的責難足以毀掉整個Scrum實施,以及阻礙組織開發優質軟體的能力。當遇到挫折和失敗的時候,必須意識到這只是變革期間不可或缺的一部分,而且還可以藉此機會和人們共同來探討如何一起解決這些問題。

Scrum的實施是沒辦法詳細計畫的,也不可能遵照清單、步驟和表格按部就班的執行。Scrum只是一個能夠在組織內部找出阻礙軟體開發障礙的簡單架構。而管理和消除這些障礙正是實施Scrum的困難所在。而且由於每個組織都是不同的,因此每個組織都會遭遇到不同的問題。

沒有人希望遇到挫折和困難。有些障礙已經在組織的理念和運作方式中根深柢固,變得非常難以消除。就算事先計畫得多好,也沒有辦法可以減少會遭遇到的困難。只會因此提醒了每一個人:要成為世界級的競爭者就必須通過艱苦的奮鬥。Scrum需要高級管理階層將全副身心投入到障礙分析與消除當中,也同時要求那些主張採用Scrum的CXO成為變革的代理人領袖。

CXO會經由此種方式參與到所有組織級的持續變革中,並進一步提升軟體開發團隊的生產力和工作品質。這不是一件容易的事,CXO的領導力在其中會產生非常重要的作用。Ken Schwaber(註:本書作者)在給某CEO的一段話中寫道:

自:Ken Schwaber

給:XX,某某公司的CEO

Scrum一方面提供了非常誘人的可能結果──提升的生產效率、較好的工作環境、增強的競爭力及較高品質的產品。但另一方面,也讓實施難度變得非常大。為了實施Scrum所需要做出的大量改變都是非常困難的。

儘管改變對開發人員及其客戶(產品負責人)是很困難的,但是他們很快會獲得職業滿足感的增加當作即時回報,進而還能幫助他們減緩變革帶來的壓力和焦慮。然而,對於中階管理者而言,情況就不同了,因為他們無法獲得即時的回報。他們被迫將組織中使用的傳統流程轉變成較精實的流程,在此期間,他們無法清晰看到自己的個人目標。他們不禁會想:「我將會做些什麼?我要怎麼樣才能在轉型後重新融入到組織中呢?」此種問題將特別難以解決。但由於中階管理者是組織轉型後的中堅力量,這些問題不解決,未來將會變成非常危險的問題。可想而知,由此可能引發非常可怕的衝突和辦公室政治。

根據過去我由上而下實施企業Scrum的經驗,我相信實施成敗的關鍵就在於您。您是否能夠展望未來並且將願景傳達給管理階層,能否有足夠的耐心帶領他們完成變革,能否讓中階管理者們認識到自己的價值,並且讓他們組成團隊?這些都將影響到您能否成功變革並實現價值。

(摘錄整理自附錄C)

 

Scrum需要高級管理階層將全副身心投入到障礙分析與消除當中,也同時要求那些主張採用Scrum的CXO成為變革的代理人領袖。

 

告別瀑布,擁抱Scrum

Ken Schwaber, Jeff Sutherland/著

王軍、李麟德/譯

博碩文化出版

售價:320元

 

作者簡介

Ken Schwaber

Scrum軟體開發流程的創造者。早期的職業生涯中,Ken使用了瀑布式流程開發軟體卻無法讓專案成功;於是,他創造了新的流程來代替瀑布式流程。Ken花了將近20年在發展Scrum,與世界各地的組織合作並協助他們使用Scrum。

 

Jeff Sutherland

Scrum軟體開發流程的創造者,Jeff是位於劍橋Massachusetts的Scrum企業的CEO。他同時也是OpenView Venture Partners的高級顧問,幫助他們在其所有的投資公司中實施Scrum和敏捷實踐。

熱門新聞

Advertisement