![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUZvAjQODcqkSPnbOvMziEfgG_Xi1oHT9JZb7oZ4EY892Ut_ZBw347jVou8H4_3tX0_cYLnzs2ZkBwtneg7chTXVKt78HvADbrbElR9bfI-3lng-nmPcKK0YgbyEEETSWlosi7Bys9VVI/s280/workplace-1245776_1280.jpg)
近年來在符合Agile精神的各種專案方法論中,Scrum應該是最簡單,也是最熱門的。
雖然簡單,但要掌握其精神,必須對抗長久的習慣,而這並不容易。
目前市面上也衍生各式各樣Scrum架構的作法和細節,從一開始的User Story到sprint最後的檢討會議(retrospective)都有琳琅滿目的作法與工具。假如只能選一個最重要的精神,則「實況:瞭解事實」是最最最根本的Scrum精神。(註1)
Scrum架構中,理解事實有很多層面。在此以「角色」「衡量效率」「固定時間」作為範例。
1. 角色
實況(Scrum)只會有三種角色
1. 產品擁有人(Product Owner)
2. 團隊領導 (Scrum Master)
3. 團隊成員 (Scrum Team)
而最根本的Scrum務實精神,在角色所扮演的任務中展露無疑。
也就是:
(A) 只有產品擁有者,才能排定產品功能的開發順序(product backlog)!
(B) 只有團隊成員,才會決定每一段時間,哪些功能會完成!
換言之,什麼事情先做後做,交由最接近市場的人 - 也就是產品擁有人 - 來決定。但是那些事情要花多少時間,是由做事情的人 - 也就是團隊成員 - 來決定!這個作法完全奠基於事實,並且適用於絕大部分的情況。
這和傳統專案有很大的不同。許多專案的時間預估,都不是做這件事情的人來預估。自然就一定不可能預估的準確。
不過,在許多「精采的成功個案」中似乎常常會有一個超強的產品經理,能主導市場,產品進度,甚至使得專案團隊有突破性的創新結果:典型的個案就是第一代iphone直接由賈伯斯(Jobs)作為產品經理帶領開發。似乎就是產品擁有者,主導進度的鐵證?
然而,事實上絕大部分的產品經理都不是賈伯斯。可是,大部分的企業,卻可以雇用到接近賈伯斯擁有的研發團隊品質!!因此,絕大部分的情況下,將產品研發功能相關執行與時間預估,交由團隊成員,才比較可能產出和市場預期的結果。除非該產品經理很確信自己跟賈伯斯差不多,並且也能提出「具體證明」。(就如同大部分的資深程式設計師,都能提出具體的證明 - 程式碼,佐證他的經歷一樣)
2. 以結果來衡量團隊效率
在實況(Scrum)中,一個項目完成的定義就是「完成」。而團隊的速度,取決於每個sprint可以完成多少項目。當然團隊一開始的完成事項的速度,大概很難和自己預估的一樣。
然而,過了兩三個Sprint之後,團隊速度應該已經「固定」,而這個完成工作的速度,就變成「事實」。
要看研發團隊速度在這時候很簡單,打開燃盡圖(burndown chart),算一下每段時間 - 例如每週或月 - 可以完成多少單位,自此之後,要估計時間,只要能有效估計每個功能(user story)規模大概多少單位即可。
這個事實,原則上不會改變。然而,產品擁有者確有權限可以在必要的時候改變事實。他有兩種選擇:(a) 更換產品功能。(b) 改變團隊。
更換產品功能可能是縮小功能規模。例如原本app支援facebook, linkedin, google+的帳號登入,考慮市場都在台灣,因此就先做facebook登入即可。
當然產品擁有者也可以改變團隊,重新組織團隊,更換成員。但一旦改變團隊,就必須重新啟動新的sprint,而也會重新產生新的速度。
3. 以取得事實來固定會議時間
Scrum(實況)的會議,必然鎖定會議「目的」以及「時間」。在事實的基礎下,兩者有很大的關聯。
以每日會議為例-- 不管是不是站著開會,一定是一天工作的開始,最多只花15分鐘。成員輪流以1-2分鐘「說明」三件事:
(a) 從上次開會到現在完成了什麼,沒有完成就說沒有
(b) 今天打算做什麼,而且有什麼會完成
(c) 遇到什麼困難需要ScrumMaster協助。
這三件事情,只是說明,若有問題,也是對說明的問題,絕不應該討論。要討論是開會之後,相關人等,聚集在適當的地方,最好是某個人的電腦前面,開始幫忙解決。
通常最容易花時間就是遇到困難的時候,大家紛紛都想提議見幫忙,但這並不是「這個會議的目的」。每天5-7人聚在一起,是為了將大家對狀況的認知統一,僅此而已。因為一旦開始討論困難,很有可能變成A和B熱烈的討論起來,其他5個人在滑手機發呆。Scrum Master要根據決定好的目的和時間,具體果斷的打斷討論,讓會議前進。
或許有些人會認為,這樣會破壞創造性思考和創意思維。然而,事實上無止盡的會議才是破壞創造性思考和創意的元兇。在每日會議之後,Scrum Master可以根據遇到困難的情況,重新找適當的人,並且到適當的地點 -- 也就是電腦前面,手腦並用的解決問題,而非在會議室空談。
其他在實況(Scrum)框架中的會議,像是Sprint啟動會議,Sprint結束會議,Sprint檢討回顧會議等等也都是一樣。必然是在特定的目的,特定的時間完成。
將能專注控制的事情完成,才能把時間與思維,留給創意。
註1. 因此,敏捷開發中的Scrum方法,中文翻譯應該叫做「實況」,至少也比google翻譯為「爭球」來的好。
註2. Scrum的學習可以參考這裡-> 學習Scrum,或者->Scrum認證
沒有留言:
張貼留言