scrum.jpg
(圖片版權屬Prentice Hall所有)

  終於將這本Agile Software Development with Scrum給看完了,雖然它只有薄薄的154頁,但看的過程中卻有很多值得思考的東西,所以看的速度快不起來,不想在圖書館借來的書上面用紅畫畫線,所以在上面貼了很多3M的小標籤貼紙,方便讓我回去找有疑問的地方。

  對我來說,Scrum是一種專案管理方法,而不是一個軟體開發流程,適合用在creative、uncertain、unpredictable及complicated的產品開發專案管理,不限定是軟體開發,軟體開發恰巧都有上述四個特性,而且軟體多了幾個特性,讓Scrum跑起來更有意義,例如working product,在第一個sprint,即便沒有一個好的軟體架構(我沒說一定是這樣),還是可以用現有的需求快速建立一個可以執行的軟體,反正之後可以用refactoring的方式改善軟體架構,但很多其他的領域就沒法這樣了,像是建築,不可能根據購買者不明確的需求就去蓋個屋子,如果不滿意再打掉或是敲敲打打的方式改進,而且一旦牽扯到梁柱,這種會引響房子會不會倒的問題時,更不可能隨隨便便就加蓋或拆掉,但軟體就沒這問題(ㄟ...不見得,以目前ezCMS的現況,就算現在要拆要打都不知道怎麼做...)

  Scrum有幾個我認為不錯的優點,書中列了很多,但我並沒有全然接受,主要是因為書中的例子中,team member都是programmer,但我很難想像一個team中全是programmer會長什麼樣子,或是寫出來的軟體UI會長什麼樣子,有些practice對於非programmer根本窒礙難行,這之後有空再討論,先寫優點:

  1. Protected scrum team:在一個sprint執行的期間內,sprint backlog (需求)是無法更動的,也無法要求team member做一些與sprint backlog上沒有的事情,除非story提早消耗完或是無法如期完成,才會更動sprint backlog,這可以避免多頭火車(單一指揮),team member不會無端被打擾,也不會有沒有經過思考的需求一直搗亂真正該做的需求。
  2. Daily impediment removal:Daily scrum除了可以每日監控進度外,還可以快速地發現問題,並提供尋找解決方案的管道,well,有些企業組織上的問題,除非上層非常support,否則即使列為問題恐怕也是無解XD
  3. Incremental output:咳,我用的是incremental output,不是incremental working product,書上很多例子是web應用,我並不是說web應用很簡單開發,而是要有一個能看到能操作的working product比較快速,以我過去四年的業餘專案經驗(WiMAX & DVB-H),WiMAX的通訊層有2大層,細分後分成7個子計畫(外加空氣傳輸的破壞模擬XD),要寫出個能夠彼此獨立(不跨越通訊協定層)的story都相當不容易,加上專案的人力和實際可工作時數少,要在一個30天的sprint中完成一個working product有點難,能有working components就已經相當了不起了。但即便如此,每個sprint都要有產出,不一定是可操作的working product,但要能達成當初目標鎖定下的規範(也就是definition of done),週期性少量的產出一定比沒產出要好,事實上如果幾個sprint都有產出後,後面的幾個sprint就非常有機會能有incremental working product了。
  4. Empirical estimation:這是典型的將(工程師)在外不受君(PM)命,以台灣的現況來說,很多PM根本沒有工程師的經驗(我沒說全部),一行程式也不會寫(如果在硬體廠,PM可能連電阻色碼都不會看),PM根本不知道問題的複雜度,只要是客戶說的什麼都對,為什麼要聽從這種人規劃的時程?那肯定是行不通的時程!所以工程師加班是必然的。Sprint planning提供一個機會,讓真正開發軟體的人參與時程的評估,不但是務實而且是週期性的修正(再評估)。
  5. Decision authority:跟上述的優點一樣,面臨軟體開發上的問題,我相信沒有工程底子的PM是無法做出任何技術性的決定,只有真正在開發的團隊有辦法做決定,不過,巧妙的是product owner可以在sprint review時否決已經做出來的東西喔!但與其懸而不決,讓專案停滯不前,直接讓團隊快速做出決定反而比較好。
  6. 取得Balance:軟體專案有很多面向,例如書中一再提到的functionality、cost、quality和date,一個軟體要加入多少功能,客戶願意花多少錢買這個軟體,這個軟體的品質要多高(例如穩定性、效能等),和專案的時程,這些都會互相拉扯,上述的empirical estimation和decision authority都是透過sprint planning和sprint demo (review)取得scrum team和product owner之間對各種不同面向的平衡點。

  Scrum這麼好,那應該大家都來使用,不過Scrum要跑的順,有幾個條件:首先,管理高層要支持,不然什麼都不會發生,而且考績還可能被打很差,連年終獎金都沒了;再者,團隊不宜太大,作者建議7加減2,如果是很大的專案,平行運作的scrum團隊會比較適合(Scrum of scrums);第三,scrum team必須是cross functional team,意思是團隊裡的成員成員可以扮演多個角色,但必須涵蓋到所有專案需要的角色,例如:DBA、SA等等;最後,團隊成員至少要有50%是experts (domain or programming experts),我覺得這很重要,不然experts光是被novices煩都煩死了,哪有工作進度,而且有足夠的expert,才能在沒有專職software architect的情況下,設計出不算太離譜的軟體。

  對scrum有興趣的可以找這本書來看看,裡面還有提到不少優點我沒列出來,改天再花個篇幅用幾個可能極端一點的例子來看一些問題。 

  後記:今天買中職冠軍賽的門票,因為系統負載量不夠(FamiPort根本連不上去,連要結帳都連不上去),加上流程設計的問題(10分鐘內結帳,不然取消訂位),讓可憐只能訂到外野座的我,只能看著店員一直刷條碼卻無法結帳,座位被硬生生time out取消了,這都是軟體開發會遇到的問題。

dbi1463 發表在 痞客邦 PIXNET 留言(0) 人氣()