(圖片版權屬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取消了，這都是軟體開發會遇到的問題。
留言列表
