l

2012年10月18日 星期四

導入Scrum真的可以提升一倍的生產力嗎?

Oct. 17 16:31~18:04

image

 

昨天Teddy在《導入Scrum很貴嗎?Teddy算給你看》提到成功導入Scrum「預期整體生產力至少提升50%-100%。」有鄉民問Teddy有沒有什麼具體的例子可以佐證?例子不少,今天提一個導入Scrum兩年左右的鄉民甲告訴Teddy的實際案例。鄉民甲在軟體公司開發某軟體產品,團隊成員有7人。N年前在導入Scrum之前,鄉民甲的團隊已經花了兩年的時間在開發該產品,但是最後做出來的東西卻被公司高層「打槍」惱怒,認為這樣的產品賣不出去。後來,老闆下定決心將這個產品「打掉重練」,這時候剛好公司在因緣際會之下,開始著手導入Scrum,也找到很好的ScrumMaster來協助團隊進行Scrum的導入工作。

新的專案基本上要做的功能和原本已經花費兩年所完成的產品是類似的,但是公司希望新的產品能夠具備輕巧(不要佔用太多記憶體)、可擴充性(要能夠快速地在產品上面增加新的功能)、可組裝性(依據客戶不同,可以用設定的方式啟用或禁用某些功能)、易用性。原本專案所開發的程式碼幾乎無法重用(只有小於5%的程式碼可以重複使用),之前所採用的技術大多也派不上用場,所以基本上可以當作是開始一個新的案子。

導入Scrum的過程細節就不多談,直接講結論。後來鄉民甲的團隊只花了一年的時間,就把這個產品做完,而且這次做出來的產品真的有客戶使用,客戶對產品的反應也很正面。這個案例很特別,因為同一個團隊,前後用兩種不同的方式,開發「功能」(functional requirement)基本相同的一個產品。原本的方式用了兩年,但是做出來的東西不被接受。後來的產品只花了一年,而且已經有大客戶實際在使用。姑且不去算前後這兩個產品的「程式行數」差異多少,光從開發時間來算,導入Scrum之後開發相同功能的產品,時間縮短了一半。所以生產力至少提升一倍以上。

***

看到這邊鄉民們可能會認為這樣比較不公平,因為同一個團隊作相同功能的產品做了兩次,就算是原本第一次的程式碼只有很少部分被重複使用,但是第二次的開發畢竟整個團隊變得比較有經驗,怎麼可以確定是因為導入Scrum所造成的生產力提升呢?

Teddy也有同樣的疑問,所以問了鄉民甲同樣的問題。

鄉民甲:我認為生產力的確有大幅的提升,主要因素有以下幾點。

  • 導入Scrum之後,因為每兩週都要產出可以demo的功能,所以會強迫Product Owner(PO)去思考需求的重要性,選擇對使用者最有價值的需求開始優先開發。而開發團隊也「被迫」要更專注於交付「可以執行的程式」。在導入Scrum之前,整個團隊曾經因為準備採用某種新的技術,而花了將近整整半年的時間都在「研究」這個技術,而沒有任何實際的軟體產出。這是傳統軟體開發作法很容易犯的一個錯誤:「想要採用的技術還沒研究好,就無法開工實作功能,所以要花時間去研究技術」。這段花在研究新技術的時間,其實大家也不知道這些新技術最後可以用來幹嘛,變成為研究而研究。現在回顧當時的作法,其實那段研究新技術的時間因為沒有訂定清楚的產出目標,應該算是一種資源的浪費。
  • 導入Scrum的初期,發現產品的品質不佳,bug很多,因此每個sprint都投注時間在撰寫單元測試、持續整合、撰寫驗收測試、測試自動化等工作上面。雖然剛開始PO會覺得「為什麼要花時間去做這些所謂的technical story,而不是全部的精力都花在開發功能上面?」但是隨著時間過去,PO發現專案的品質變好,bug變少,PO對產品越來越有信心(因為以前隨便操作一下系統就會出現一些很詭異或是很不應該出現的bug,讓PO每次測試完產品之後都很沮喪),因此PO對於這些敏捷實務做法也越來越支持。
  • 團隊開始真正學習如何合作。在導入Scrum之前,雖然我們號稱是一個7個人的團隊,但實際上每個人只負責產品的某一塊(某些模組),彼此之間基本上是 老死不相往來 不知道其他人在做些什麼。當別人遇到問題的時候,很少也很難幫上忙。很多時候是開發人員卡在某個工作很久,如果有人可以幫忙一下,整個開發時程就可以加速。

***

再回到昨天Teddy提到的《導入Scrum很貴嗎?Teddy算給你看》,以鄉民甲的這個例子,僅僅算一下節省一整年開發時間的人事成本(假設每人每月的人事成本為10萬元):

7人 * 12 個月 * 10萬 = 840萬

這省下來的840萬,就算是全部都拿來聘請Scrum導入顧問,都相當划算。為什麼?因為產品提早一年上市、品質變好。更重要的是,產品真的有客戶願意使用。

***

友藏內心獨白:以上故事由真人真事改編而成 熱戀

沒有留言:

張貼留言