顯示具有 Certified Scrum Master 標籤的文章。 顯示所有文章
顯示具有 Certified Scrum Master 標籤的文章。 顯示所有文章

8/19/2017

如何成為Scrum專家 - 極簡計畫書



Scrum是推進團隊進度,合作專案的敏捷方法論之一。在過去幾年來從資訊產業,金融業,甚至學校教育,都有不少人在倡導這個簡單而且踏實的方式。因為Scrum有很多優勢,例如減低壓力,具有務實的彈性,容易評估現況,易於控制品質。這些優勢,可以用在大部分的企業環境中。因此,成為Scrum專家對職業生涯很有幫助。

學習Scrum並不困難,在各企業巫醫的網路資料中,早就擁有看不完的資料。請參考這篇

對職業生涯有幫助的不僅是「學會什麼是Scrum」,更重要是成為Scrum專家。或者,至少成為在他人眼中的Scrum專家。專家的定義,請參考註1。

或許你在職場有2-4年的工作經驗,作為一個團隊成員,在專案領導人的帶領下,參與以Scrum為基礎的專案。然而,這不會讓你變成Scrum的專家,因為你只是「照著做」而已。

在此提供一個極簡計畫,可以在很短的時間內讓自己變成Scrum專家。

如果懶得看說明的長篇大論,可直接到這個網頁下載計畫書


開始之前的條件


這份一頁極簡計畫書有使用上的條件:

(a) 必須要有還不錯的英文閱讀能力,TOEIC750以上。如果你的英文能力自認不夠,請參考這裡

(b) 必須要有2-3年以上的實務工作經驗。而且在工作環境中,至少聽過Agile/Scrum。

(c) 必須打從心裡認為有效使用Scrum是有好處的。換言之,不能是因為「有人叫我要學Scrum」而學Scrum。因為,此極簡計畫書本身執行的方式也是Scrum!


如何成為Scrum專家極簡計畫書的使用步驟如下:

(1) 確認目標的實質意義


此極簡計畫是要在2個月內,讓執行計畫的你變成「Scrum專家」。而何謂Scrum專家的實質意義就是在此極簡計畫中三個sprint的「實質產出」。

Sprint-1 知識:讀完2本Scrum書籍,以及2份網路資料

Sprint-2 證照:取得Scrum證照

Sprint-3 研討會:舉辦公司組織內Scrum研討會或分享會

這三個實質產出的組合意義,目的就會讓你成為Scrum專家。即便不是Scrum大師,至少也是被大部分人承認的專業人士。

這三個Sprint各有已經設定好的任務(Task),所有任務完成後,就表示該Sprint完成了。而每個任務本身的描述都是有簡單清晰的「完成條件」definition of done。



(2) 分配每個Sprint的時間


計畫書中,每個Sprint各有數個任務,每個任務都有估計的時間。時間是以小時為單位。加總起來,會有要完成Sprint所需要的總時數。

一般軟體專案Scrum估計都可能會有錯,在Sprint過程中,要能實際反映團隊實際的「速率」,因此前1-3個Sprint的燃盡圖很重要,可以讓團隊知道實際的效率。所以每個Sprint都是固定時間,大約4-6週,sprint時間到就結束了,只會看做完哪些Story,在下一個Sprint才調整要完成的story數量。

然而,個人Scrum做法會略有不同。整體概念仍然一樣,但因為Product Owner也是「你自己」,因此Sprint時間可以變動。換言之,可能第一個Sprint是4週,第二個Sprint是5週。

請在極簡計畫書中,每個Sprint任務表格上方,填寫預計的Sprint開始的日期,和結束的日期。Scrum是要反應實際狀況,因此,也許整個sprint需要5小時,但因為你有本來的工作要做,因此可能要花2個月才能有5小時的空閒。

(3) 每日工作


當有超過30分鐘空閒的時候,就可以把那張極簡計畫書拿出來,在這個Sprint選一個任務(Task)開始「執行」,或者,繼續上次未完成的任務。這些Task都是大約設計成30-40分鐘完成,但是根據Scrum的精神,每個人的績效不同,因此也有可能會花的時間多或者少,但無論如何,在還沒完成已經做一半的任務之前,不要換任務!

當然,如果該日沒空,自然就不需要拿出極簡計劃書來執行。

每個任務,都有完成條件,確定滿足完成條件後就可以塗黑空格,並且在右邊簡單的紀錄所花費時間,和大約日期。時間不用太精確,以半小時為單位即可。有些任務很簡單短暫,也許10分鐘就完成,但也以半小時紀錄就好。

如果沒辦法在0.5小時內完成一個任務,那要請自己休息一下,再決定要繼續完成該任務,也可以決定今天就先到此為止。

不能有某任務做到一半,就「先拿了」下一個任務,也不能有這個Sprint還沒完成,就先開始做下個Sprint的某個任務。當然Sprint中的任務,有些是沒有前後關聯,因此Sprint中的任務不需要按順序。只是,一旦開始做,就一定要做完為止。

某些任務需要下載檔案,請參考註2的各個下載網址,可以一次下載完成。

在計畫書中的任務描述都很簡單清楚,但如果真有問題,也歡迎來信詢問




(3) Sprint 結束自我檢討和下個Sprint的開始


完成Sprint中所有任務之後,表示這個Sprint完成。要花15分鐘時間,先自我檢討一下Sprint過程中有哪些阻礙,而自己應該怎麼改善阻礙。

接下來就要開始下一個Sprint。實際上,本來Sprint的開始是需要先討論Story和Task的選擇。然而,極簡計畫書希望你不要花時間在研究這些Task重不重要,而是先努力的花時間搞定它。畢竟這些任務所需要的時間都不多,實務上也對你有莫大的幫助。

不過,或許有些任務你早就已經完成,那就可以看一下完成的條件(DoD),已經達到就可以自動塗黑。


(4) 計畫書完成?專案結束了嗎?


三個Sprint完成之後,這個極簡計畫書就達到它的功能。但就個人專案的角度來說,專案不見得要結束。只是這時候你已經有足夠的能力和經驗,可以決定要不要繼續以Scrum的方式來學習Scrum。

(5) 3個Sprint結束後的彩蛋!


很簡單,當你完成這個極簡計畫書,實質上你自己完成了一個Personal Scrum。

彩蛋要靠自己完成。請在計畫書背面以三個Sprint的各任務所花的時間,「手工」繪製燃盡圖。

這件事的意義在於,你有確切證據證明你能有效運用Scrum在非工作事項上。也證明你有自我學習的能力。它可以用在未來履歷表,面試,或者說服同事Scrum不如想像中困難,只需要一點點毅力去執行。


在此下載計畫書



常見問題:


Q1:這個極簡計畫書,很多地方跟我在工作上用的Scrum都不一樣啊?

Ans:當然不一樣,因為他屬於Personal Scrum。但是它的最基本精神是一樣的。請參考這裡,了解Scrum哪些最基本精神比較重要。

Q2:我不就是自己的Product Owner?為什麼我一定要用這三個產出來達到「變成Scrum專家」。

Ans:你當然可以自我決定產出和任務,也有機會變成Scrum專家。極簡計畫書,是在如果你還沒有好的定義時,可以透過過去人的經驗,減少時間浪費,讓你專注在精進自己。

Q3:為什麼要取得Scrum認證,這樣就會變成專家嗎?

Ans:有些人可能會以「取得相關證照」,作為專家的標準。這的確是個參考標準,但也只是參考而已,因為Scrum並沒有所謂官方證照,所以市面上各種證照到底哪一個比較適合?請參考這篇「Scrum認證!不要再浪費錢了」。在此採用的是Scrum-Institute的低成本證照




註1:即職場上的專門行業,指具備專業化知識技能職業人士。通常,專業技能須符合科學原理,經過長時間的學習訓練,並有經專業認證的考試獲得的合格證書執照,擁有自我約束行為的職業操守(或道德)及可量化的專業標準等。...定義細節請參考這裡


註2:各種需要下載的資料

(a) 任務 1.4 的2個pdf教材
https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

(b) 任務1.7的wiki頁
* https://zh.wikipedia.org/wiki/Scrum

(c) 任務2.1的pdf
* http://www.scrum-institute.org/Scrum_Books_International_Scrum_Institute.php

(d) 任務3.1與任務3.3的材料


* http://www.eduscrum.com/


https://www.crisp.se/gratis-material-och-guider/scrum-checklist


2/16/2017

建立軟體開發團隊 (1) 計畫 組成




... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作,不可能有完美的狀況。但是,妥善的計劃,能大幅降低軟體團隊的運作風險,並且讓團隊成員專注於發揮專長和創意,減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面,例如:

(1) 目標極端困難。例如:要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如:團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成,目標也還沒確認,就已經有時間壓力。例如:一個2-3個人合作的新創公司,剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如:在大企業中,因為高層要求,一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員,在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標,併購等等),讓某個團隊大幅流失人才,而需要重整補齊人力。

(7) 因為文化與跨國合作困難,導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人,最最基本的認知就是:

軟體團隊組成這件事情:本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊,其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考:

(1) 了解探索事實,盡可能將事實攤在陽光下


許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」,或者「假設在3個月後可以找到2個優秀的iOS開發人員」,或者「假設大部分的使用者都有fb的帳號」,或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下,很多事情的確有假設,才能進行下去。

但是,在建立團隊的時候,除了瞭解背景假設之外,先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景:

可參考下節「確切定義短期中期目標」。如果是非營利組織,團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業,營利組織,除了獲利之外,也可能會伴隨其他更遠大的目的。例如:「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體,也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的,如果只是單單純純想賺大錢的公司,例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的,就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知,才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊,自然不會將社會責任活動當作是團隊成員想要做的事(例如:到沙灘撿垃圾,協助獨居老人),當然「培育企業人才」也不太需要,甚至Scrum裡面的「自己選取task來做」也根本不用,採用由上而下的軍隊式管理,讓工作以最有效率的方式完成,才是這種團隊的最好方式。


(b) 資源現況:

目前的現況是不可否認的事實,但許多人一開始的時候,會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人。...這就是資源現況。

但也有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣,其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人,年預算只剩下600萬台幣,所以可以找10個人,但是平均年薪只能為60萬,或者找6個人,平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人,資源現況的瞭解和掌握,必須要越清楚越細節越好。實際上,絕大部分的情況下,只要稍微多花個幾個小時,就可以掌握到很多現況細節。


(c) 組成專長:

即使已經是軟體開發的專家,這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定,組合的專長可能大致確認。然而,某些專長不見得是「團隊成員需要有的」,這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段,需要清晰可見的專長分佈圖。

以上圖為例:簡單地列出做一個購物網站可能需要的專長,並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是,這樣的圖並不是要完全技術上正確,而是要做為未來計畫的參考。因此有可能一再修改,也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素:

哪件事情做好了,會讓這個團隊成功。成功關鍵因素應該只有1-3個,不應該太多。 這個關鍵成功因素必須要很「實際」,能夠被「衡量」,當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例,他的關鍵成功因素不只是火箭能發射,還要能「掉回地球後,能自己站立,以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而,建立組成的本身也有關鍵成功因素。例如,在2個月內吸引3個具有5年工作經驗,並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然,不可能花幾百天的時間,只是為了收集事實,只要在合理的時間內,盡量收集了解重要的事實。


(2) 確切定義短期中期目標



前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言,八九個短期目標完成後,差不多就等於一個中期目標完成。

任何軟體開發計畫,必定會有目標,而讓團隊朝向「同一個方向」前進。所謂團隊,當然是一群人往同一個方向前進,才能叫做團隊。一群在同一個組織架構的人,或者在同一個老闆底下工作的人,不見得是一個團隊,很有可能每個人在軟體開發



(3) 根據目標擬定計劃和備用計畫- Plan B



兵法有云「夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!吾以此觀之,勝負見矣。」

計劃本身並不重要,但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情!

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容:

(a) 團隊目的,短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是,哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示,根據分佈圖,來劃分團隊組成。

切勿用想像的方式。




以上圖為例:這是一個打算建立電商網站的技術分布圖,和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示,團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節,而且也把技術不相干的東西納入(例如裡面有個API doc,其實是還沒有去做的事情)。但整件事情的精神在於「視覺化」。透過視覺化,對團隊的變化才有整體性的考量和規劃,而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡


(d) 初始化工作項目

當團隊的成員是逐漸到職,最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節,但是是隱含的關鍵成功因素。

初始化工作項目,在新成員到職的前幾天,最好是鉅細彌遺。規劃了新成員第一天到第五天,「每天」要做的事情和達成的結果。並規劃前4週,要達到的大項目,以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短,對團隊的組成越有利。

規劃前五天的細目,絕對不會讓這個新成員變得沒有創意,也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內,先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項,如果在前一段時間沒有擺脫,之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目,同時也是檢閱清單:

Day-1  
    - Mentor介紹工作環境,取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限,確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件,Mentor協助了解文件內容
    - 參加Scrum會議,理解Scrum雞與豬的原則 
    - 在Mentor協助下,建立自己開發環境

Day-3
    - 在Mentor的協助下,在自己的開發環境確定能修改程式/簽入(commit)/建立branch,最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例,這些看似細節,但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡這裡

簡而言之,建立團隊的過程也需要被檢討。

例如:

新加入的成員,在當初面試的時候所呈現的能力,和實際上工作的產出,是否吻合。

新的成員對於非技術類型的雜事,是不是很快能找到資訊。例如git的位置,目前各個branch的狀況,自動化建構的方式,建立開發環境的方式等等。




註1:如果這個挑戰對負責組織團隊的人來說太過困難,最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天,或者品質降低一些;但是一個失職的領導者,會讓整件專案崩壞。


註2:例如xspace

註3:建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術,需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等






2/06/2017

Scrum - 團隊中永遠的反對黨



最近被問到的幾個問題:

   - 怎麼聚焦討論,譬如說有人很愛插話,或者有人很愛在會議室角落另開討論群,或者有人非常堅持己見,很愛先否決對方 ...

   - 有遇過非常固執的人,總是以否定句開頭去否定對方嗎 ?


   - 有人固執的反對什麼事情都反對


....


以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力,並且也假設,團隊成員對於「溝通」都有某種程度的共識和經驗。

然而,實際情況通常不太美好。

** 技術人員常常會因為麻煩,而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心,很多人在開會時候搞不清楚情況
** 某些人常常提很多意見,而且實在太多意見!

任何由人組成的團隊,多少都有溝通問題。如果你是團隊領導者,或者Scrum Master,溝通問題一定是你必須要負責的問題!

Scrum溝通問題,就像處理bug一樣,最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。

建立這三個基本共識,可以讓未來的溝通變得簡單清晰,減少不必要的誤會。

(1) 建立雞與豬的基本共識


專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。

** 負責人(R = Responsible),負責執行 
** 誰批准(A = Accountable),對任務負全責的角色,通常是負責人的老闆 
** 顧問(C = Consulted),提供意見或建議的人 
** 通知誰(I = Informed),被通知結果的人,例如其他部門的相關人等 

在Scrum專案中,可以被簡化成兩種人:雞和豬。(雞與豬的故事可以在網路上找到很多版本,例如這裡)


豬:負責做的人也是負全責的人

雞:所有其他人(當然必須是和這個專案有關的人)

在溝通時,所有雞都可以出意見,但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿,雞只要下蛋而已。

就平等的軟體開發Scrum而言,任務是有自己選取。但是就實務上,專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候,等於是分配「誰是豬」!

任何會議上,對「豬」的正面或負面意見都可以討論,但是最終決定必須要是「豬」。

例如,PM決定哪個功能要先做,而工程師都反對,原因是嫌未來會有其他麻煩的事情產生。然而,就決定功能的先後次序來說,「PM就是那隻豬」而其他所有人「都是雞」。

團隊必須要有清楚的認知,才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知,是團隊領導者的任務。


 (2) 建立事實優先的基本共識


Scrum溝通,必須,而且只能,建立在事實上。

這也是為什麼每日例行會議只說明三件事情:哪些工作完成,接下來做哪些,遇到什麼問題。

假設有人在某討論會議中說「現在UI速度很慢,登入要等很久」。某種程度來說,可能是事實。但是,「慢」以及「等很久」,都只是形容詞,必須要請他提出何謂慢,什麼叫做等很久才能繼續有意義的討論。

或者,有人提出「如果先做A會讓之後變得很麻煩,應該要先做B」。這其實也是模糊的說法,A和B這兩個功能,如果先做A是會讓以後時程延後8小時?還是8天?還是8個月?這才是根據事實的討論。

然而,這種建立於事實的共識,Scrum Master必須要不厭其煩的提醒和導正,才能建立這種共識。



(3) 建立產出優先的基本共識


大部分的專案,都是需要產出某些東西。無論這個東西是軟體,或者硬體,或者某些解決方案。

在團隊討論中,要讓「為反對而反對」的人閉嘴的最佳方式,就是以「產出優先」而不是以「嘴巴講」優先。

例如,某工程師強烈反對A做法,希望改用B做法。最好的方式就是請這個工程師,作出他自己希望的A做法,用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」,那表示他的強烈反對,也不是那麼強烈。

至於對於「只反對而不提出取代方案」的人,其意見大概也只是僅供參考。如果經過負責的豬判斷,其意見很好,當然可以欣然接受,加以改進(例如在code review的時候)。





如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。

不過,越早了解,並試圖解決溝通問題,通常成本越低。

那麼可能的解決方法有:


(1) 自己的問題?


如果你是一個領導5人以上的團隊領袖,無論你的名稱是Scrum Master還是專案經理,如果你認為團隊裡「大部分的人」都有溝通上的問題。

那麼真正有問題的人是你!!

但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為,讓團隊容易產生溝通問題。

問題的產生點可能是:

(a) 試圖面面俱到,顧及每個人的感受,而非先考慮事實。每個人都喜歡受人愛戴,但是在軟體開發團隊中,鄉愿和受人愛戴只有一線之隔。唯有根據事實,腳踏實地領導事情的進展,才是長久之道。為了顧全少數人的面子,或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情,對團隊從來都不會有好處,反而只會讓多數沉默工作者更難獲得信任


(b) 未掌握Scrum精神,只是掌握Scrum的作法。請參考這裡

(c) 其他,請參考:作為技術領導者的方式



(2) 解決老鼠屎


如果團隊之中,溝通問題老是產生於某個人。

除非此人是像高斯,愛因斯坦之類的天才中的天才,否則不應該容許有嚴重溝通問題的人存在於團隊。

這類型人有幾種表徵:

(a) 無論什麼事情都悲觀 
(b) 事情不分大小時常抱怨 
(c) 問題都是別人的錯  
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物

其實,每個人或多或少都會抱怨,也會有悲觀的時候。此乃人之常情。但是如果非常嚴重,那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎,即使被稀釋了幾萬倍,也不會有人想吃那鍋飯。團隊也是如此,一個負面老鼠屎,其影響範圍遠超過5個好隊友。

老鼠屎不見得就是錯的,他或許自己創業會變成一個好創業家。因此,及早讓不適合目前至個團隊生活的人離開對大家都有好處。

(3) 縮小範圍


當溝通問題發生,可以將重要的溝通,盡可能縮小範圍,讓溝通清楚簡單。

這聽起來是淺白無聊。但是,實際上在團隊之中,太多無聊的溝通錯誤發生,以致於這麼簡單的事情,仍然值得注意。

以Scrum而言:「DOD」什麼是完成,乃是基本的問題。即便團隊已經彼此合作過一段時間,仍然三不五時要確定一下什麼叫完成。

以溝通進度而言,必然將最近在做的事情,縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說,軟體開發中,如果有一個人的某A任務,需要20個工作天,那麼在3天的進度報告,絕對不能聽到「還有17天就完成」,而是要縮小範圍到:「下一個milestone會是明天,而預期也會如期完成」。因為,最近的一個檢查點(milestone) 如果不能如期完成,就代表未來的17天,很有可能也不會如期完成。反過來說,最近的一個milestone會完成,那麼未來就比較有可能如期完成。

縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。

有個真實的案例:有個團隊舉辦慶功宴,由甲和乙兩位負責。甲很熱心的定好了餐廳,並且就「自認為剩下的事情乙會處理」,然而乙心理認為,既然甲定了餐廳,表示後續的小事情甲也會處理,畢竟許多事情和餐廳有關係。那麼到了慶功宴當天,當然除了餐廳定好之外,其他的雜物(例如當天如何報帳之類)一件都沒完成。

另一個真實的案例:有個軟體開發專案,大家都認為某甲的程式需要重構(refactorying)。但是,某甲認為他需要4周才能完成,因此遲遲不肯進行,大家也難以和某甲溝通。專案經理於是縮小範圍,先找某甲也認為很小規模的一個功能-原本預計一天-加以重構,透過pair-programming,確定某甲專注於這個任務上,最後只花了1小時。因為有這樣的證明,專案經理於是要求某甲先完成全部程式碼翻修,最後整體只花了2天就完成,雖然仍是麻煩事,但遠比某甲估計的4周來的快太多。其原因也很簡單,重構是繁瑣麻煩的事情,當然會被估計成很長的時間。





12/05/2016

Scrum - 檢討完了...然後呢?




定時檢視目前的進度與問題,是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後,舉行檢討會議(驗屍會議),找到在過去一段時間最需要改善的事項。


假設團隊依照正確的Scrum的事實認定原則,踏實的列出問題。接下來就應該「解決」它。誠如前篇,所有的問題必須要有歸屬「某人」。某些事情是「很多人」或者「不知道什麼人」,這種情況的歸屬就屬於Scrum Master。

稍微強調一下,只要Scrum Master稍微不注意,就會讓歸屬人這件事情變成互相指責,試圖鞭屍,對人不對事的謾罵。但是,如果不試圖歸屬某人,就常會讓問題懸空,無法真正解決。

只要確切的定義真正的問題,就等於是產生了一半的解決方法。

不過有些常見老問題,還是值得探索一下。

例如:

(1) PM/PO 常常在Sprint中間要求修改規格,甚至新增額外的項目...

(2) 某個人的產出和績效,明顯的比其他人差很多...

(3) 某個功能的實際時程遠超過預估,以至於某些團隊成員需要很大幅度的加班...



而常見問題都有其共通性,常見的試圖解決方法也有共通性。然而,以Scrum而言,Scrum Master在此扮演非常重要的角色,因為所有的問題,其有效解決方式,應該都和Scrum Master本身有關。


Scrum Master必須要掌握以下原則:

原則一:試圖做到完美是不可能


    完美的team不可能存在,每次sprint應該試圖解決最重要的幾個問題就好。

原則二:持續做同樣的事情,不可能產生一樣的結果


    參考愛因斯坦的名言:Insanity: doing the same thing over and over again and expecting different results.

原則三:任何創意方式都應該嘗試:包括「無作為」

    
    當定義好問題之後,下一個sprint應該要試圖改善問題。但是,改善問題的本身有時候需要「時間」,而由於Scrum每個sprint都只有4週,Scrum Master應該要將「無作為」當作某些問題的處理選項。畢竟,有時候過度反應某個未來可能不存在的問題,也沒太大意義。

但是也請謹慎區分「無作為」和「逃避」,這兩者只有一線之隔(註1)。
    



針對身為Scrum Master的人,在此提供一些解決問題的範例:

(1) 時間相關的問題


由於時間是軟體專案衡量進度的唯一單位。時間是最初,也是最後要考慮的事情。因此許多檢討事項都和「時間」有莫大關係。



--- 在Sprint中某些時間估計錯誤,導致加班 ---


這在專案前幾的sprint特別常發生。建議解決方式有:

(a) 探詢真正的需求點和重要的事情,移除根本不重要的工作事項

(b) 減低時間浪費,特別是大型專案中開會的時間

(c) 無作為:因為團隊已經了解問題,而且下個sprint估算也應該會比較正確,加班問題很可能自然消失。

(d) 厲行「最大時間」單位,假設是1天。換言之,工作項目超過1天,就需要分拆成不同的項目,或者不同的完成階段。這樣可以在比較短的時間內,很快發覺時間錯估的規模。


絕對不建議解決的方式是:讓某些人繼續加班;犧牲品質;謊報進度...



--- 某個人的事情老是做不完 ---


這個也很常發生。如果是該員能力無法趕上團隊。似乎是個很大的問題。然而,絕大部分的團隊都應該利用分工導致的比較利益法則(參考這篇),根據相對優勢來分工。

細節請參見下一節:(2)人才和人力的問題


建議解決方式有:

(a) 先確定他不是不想做。假設有個不想在這個團隊努力的人,無論再怎麼調整,也都沒有意義。應該用最快的方式讓他好好離開。

(b) 讓他做可以用時間苦勞換取績效的工作,而非需要能力才拿達成的工作 ,例如將其人力保留用於意外任務或者PM臨時修改需求 

(c) 找到他的相對優勢,換言之,Scrum Master要略為調整scrum的精神,改以指派的方式指定工作。但這點需要觀察並且徹底了解他的優勢才有辦法執行。


--- 團隊有意外任務 ---

這個問題也很常見,可能的解決方式有

(a) 無作為:經過一番思考,發現這只是意外,下個sprint應該不會發生

(b) 根據前sprint所耗在意外任務的時間,重新估計下個Sprint意外任務要花的時間

(c)  設定意外任務防火牆:可以找一個專門的人,處理所有意外任務。不得已的時候也可以找工讀生,委外人員等等。



(2) 人才與人力的問題


許多軟體開發的相關研究,都一再顯示,一個好的設計師和普通的程式設計師的績效相差很大。某些1980-1990之間的研究認為可能差距10倍,當然這個10倍厲害的程式設計師的爭論很多(註2)。但就一般的情況來說,超過5個人的團隊,就自然而言有人能力以及產出比較好,而有可能有某人能力和產出都比較差。

一個團隊裡,人力和人才必須要平衡,並且由Scrum Master在前幾個sprint的結果瞭解哪些是人力,哪些是人才。人力和人才的衡量標準在於「產出」而不在於「個人能力」。換言之,即便大家都認為他能力很好,但是某些原因,他的產出只有一般般,那麼他就不是人才,而是人力。

但是,無論是人才還是人力,團隊的組合的先決條件就是1+1>2,團隊合作可以讓整個團隊獲利。Scrum Master在發現團隊有某些人的績效和產出問題時,應該優先考慮分配工作上的比較利益法則。(台灣經濟學的入門書通常會用蓋木屋與磚屋的例子:參見這裡

要注意的是,過於追求表面上的公平,但是反而會團隊績效的降低。公平雖然重要,但是團隊合作產生的獲利更為重要。Scrum Master要能讓團隊追求團隊目標,而非追求個人公平。其方法有:

(a) 讓團隊成員看這篇文章

(b) 不要設定表面的績效衡量標準(例如:bug數量) 而是設定每個人不同的標準

(c) 所有不同的標準,朝向同一個目標。例如,在籃球比賽中,得分籃板助攻失誤阻攻...等等都是指標,而所有指標必須都要朝向球隊勝利才有意義。而不應該對每個球員設定同樣的目標。





(3) 目標的問題


目標指的是現在要做什麼,現在什麼事最重要,要達到什麼效果...簡單的說,每個專案都有其最終目標,但是在專案開發過程中,都有中間目標,PM/PO理論上應該會透過各類型中間的目標,達到(也有可能會修正)最後的目標。

然而,Scrum為了讓開發人員專注於工作,在一段短時間的Sprint是不允許修改目標。因此,如果遇到PM中間亂入,常常會造成團隊困擾。

但其實更為重要的是,如果團隊方向具有很大的不確定性,Scrum Master應該視其為「機會」,而非「威脅」。因為Scrum的天生優勢就是在於處理不確定性。


--- PM客戶或其他長官常常突然要求修改做的一半的規格---

(a) 無作為:因為這可能是專案開始的意外插曲,Scrum Master很確定下個sprint不會發生

(b) Scrum Master作為擋箭牌。在Sprint中間過程,用盡一切手腕,擋住所有需求修改,直到sprint結束為止。但是,允許PM重新開始一個sprint。

(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌,將擋下需求,或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼,放在另一個branch(分支中),每個sprint結束之後,才檢討他的branch是否要合併。這個做法的依據在於,通常會修改的規格,都會被一改再改,與其影響團隊作業,不如將影響範圍降到最低。


--- Sprint產出PM不喜歡或不要了 那我們不是白做 ---


這樣的抱怨也很常見,它不是問題,而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可:

(a) 我們頂多白做4個禮拜,如果是project結束才發現這件事情?那浪費的成本是高得嚇人。

(b) 如果是PM不喜歡,那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤,在檢討會議應該要求PM改善此項目。



如果有其他常見問題在這裡沒有獲得解答?也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。





註1:許多事情好與壞都只有一抹微妙的界線。除了「無作為」和「逃避」之外,還有「足夠自信」vs 「自我感覺良好」;「自卑」vs「謙虛」...

註2:請參見這裡

註3:如果有其他常見問題在這裡沒有獲得解答?也請用email與我們聯繫 support@talent-service.com

12/02/2016

Scrum - 回顧。檢討?驗屍!



在Scrum方法中,每個Sprint結束要做事情是(1)實際交付產出 (2) 回顧檢討這個Sprint (3) 決定下個Sprint的開始。

其中,回顧檢討這個Sprint的做法,通常是一個2-4小時的Retrospective Meeting(回顧會議),再加上改善動作。


實務上,回顧檢討是sprint最難做得好的項目。


困難因素在於,人類有天生的認知謬誤。回顧檢討會議既然是人來召開,人來組成,當然很難確切找到此Sprint的需要改善的問題,並對症下藥。偏偏,絕大多數專案Sprint問題和人有關。

說得更直白的:

    - 所有專案團隊的主要關鍵問題,都跟人有絕對的關係。每個sprint檢討會議不去檢討「人」,就等於是兇殺案發生而不去驗屍一樣。

    - 所有未來改善項目,其改善效果和速度,也都和人有絕對關係。


Scrum基本作法


在大部分的Scrum教學材料中(註1),都很輕而易舉地說,團隊要在回顧檢討會議說,瞭解並討論三個項目:

(a) 這個sprint哪些地方團隊做得很好

(b) 這個sprint哪些地方團隊做得不好

(c) 下個sprint 團隊要做哪些事情使其變得更好



許多Scrum教學中,回顧會議都用一些簡單的方式:例如每個人提出3個意見,然後由Scrum Master逐一唸出,並且分類意見,接下來針對分過類型的意見投票,投完票之後再指定人選負責在下一個Sprint中改善。這個方式當然可以消除不少偏見和謬誤,但是容易忽略了「改善是需要針對人的行為而非針對事情」。


舉個某回顧會議中,團隊認為最需要改善的問題:

* 需求在sprint開始時還沒確定

這是個極為常見的sprint回顧問題,也通常是軟體團隊的困難。Scrum方法雖然試圖避免這個困難,但是還是非常容易在回顧會議中被提出來。筆者常看到會議記錄中,天真且單純的紀錄這一條問題....然後?也只是記錄而已。


這個紀錄有什麼問題?  ....有很大的問題!


大部分團隊,剛組成的時候,其Sprint檢討會議中,會不自由主的「避免」提出直接針對「某些人」的能力,做法,產出的問題。團隊會因為想要「努力團結」而避免針對人的討論。然而,除了超短期專案外,所有軟體專案,幾乎不可能「沒有人的問題」。反過來說,解決重要的人的問題,專案就會執行得更好。

回顧檢討要注重「人的問題」,並非單指某個人的能力不夠,也非某些人難以溝通。而是要透過實際的事物,探究人的行為造成的問題,而非問題的本身。「需求在sprint開始時還沒確定」是個血淋淋的事實。

但是,回顧檢討的重點在於,過去4周內,到底團隊成員知道是「誰做了什麼,或者沒做了什麼造成這個事實」,這才是重點。

正確的回顧檢討事實,可以是:


* 需求在sprint開始時還沒確定,因為Scrum Master沒有邀請Product Owner參加kick-off會議。

也可以是:

*  需求在sprint開始時還沒確定,因為Product Owner在kick-off會議沒講清楚,而團隊當時卻認為自己清楚需求,直到開始做了才發現不清楚,偏偏Product Owner之後就不參加每日例行會議。

也可以是:

*  需求在sprint開始時還沒確定,因為Product Owner在專案中間需求有改變,但是Scrum Master並未注意到大幅變更。


無論哪種回顧,都需要有「人」,「當時做的事情或這沒做的事情」,「產生的結果或沒產生的結果」。這樣的回顧檢討才會有意義。


但是,Scrum的方法論,看起來都是對事不對人。要如何在不交互指責的憤怒會議中,做到針對人的檢討,並能在下個Sprint還能持續團結合作?

如果你是專案經理或者Scrum Master,有三個基本的關鍵作法可供參考。(1) 先個人,再團隊。只內部,無外部。(2)  沒有問題,是最可怕的問題 。(3)實際事實,實際行為優先。



(1) 先個人,再團隊。只內部,無外部。


在會議開始之前幾天,先通知大家,回顧檢討會議的重點:先檢討自己,再檢討團隊,只檢討團隊內,不檢討團隊外。


(a) 先檢討自己的「行為」,再檢討團隊的「行為」。


並非要檢討個人的價值觀。例如,是不是很認真,很願意和其他人溝通...等等。而是自己先看自己過去做的「行為事實」,有什麼可以改善的地方。

例如:完成某功能程式碼之後,沒有先執行整合測試,就在某天每日會議報告已經完成,隔天發現,該功能有很多問題,還得修正進度,並且讓測試人員額外進行rollback。

另一個例子:這次sprint開始的時候,Scrum Master沒有堅持要Product Owner確定所有要完成的項目的需求,就讓Sprint展開。使得Sprint需要額外需求確認時間。

檢討團隊的行為,也和個人一樣。稍微不一樣的是,團隊行為通常是「個人行為」的組合。換言之,以「沒有人」為開頭的陳述就是團隊行為。Scrum Master或者專案經理,或者實際決定事情的主管,要特別注意,絕大部分的「沒有人」開頭的陳述,就要當作「自己」!

例如:沒有人發現在第二週自動測試的伺服器當機,連續好幾天的測試報告都沒有自動email出來,以至於團隊錯失及早修復bug的時間。

另一個例:沒有人提醒Product Owner開會的時間。



(b) 只檢討團隊內,不檢討團隊外


Scrum對於團隊有很嚴格的定義:做事情的人+Scrum Master = 團隊成員。

回顧檢討會議,必須要檢討內部,而不是檢討外部。許多檢討會議看似檢討內部,但其實是在檢討外部。

例如:加強和UX/UI部門溝通

這通常隱含對方不好溝通,我們只好努力跟他溝通。

又例如:公司有臨時交辦事項,團隊得分心處理

這隱含是更高階主管來的非專案任務,需要打斷專案時間。

這兩個例子並非不要改善。而是檢討回顧方式,會大幅「限制」或影響改善方式。與其他部門溝通問題,應該是具體列出過去4週,那些確切事情「被誤解」或者「理解錯誤」。根據實際的錯誤,來改變團隊對應的方法。

以UX/UI而言,釐清理解錯誤,可以用「雙方討論事情的時候,一定要至少要有mock-up」。

而以公司有臨時交辦事項為例。應該是「每個sprint預設的工作時間原本是160小時,下個sprint改為145小時,因為上個sprint臨時交辦非專案任務大約15小時」。這樣是以具體的事實,解決公司有臨時交辦事情的問題。

重點是:解決問題必須在「團隊內部能做的行為」,而非「希望團隊外去做的事情」。

會不會有回顧檢討的問題是「團隊內部解決不了」的事情?的確有可能,但是機率很低。團隊解決不了的事情,早就在sprint kick-off (開始會議)被隱含排除,所有團隊「認知到」的專案問題,幾乎都是團隊內部有方式解決或減少影響的。




(2) 沒有問題,是最可怕的問題。


有為數不少的專案團隊,在回顧檢討會議時,因為很多因素,無話可說。只好拿一些雞毛蒜皮的小事,或者看似重要但是不太重要的事情敷衍一下。

例如:

* 每週固定的下午茶太不健康,看能不能換健康一點的。
* 我們的螢幕太小,寫code很不方便。
* 每天站著會議好累,可不可以坐著
* 能不能有免費可樂
* 昨天code view有說code style要統一但是還沒有
* 我們可以固定一段時間來分享一下大家coding的心得

如果檢討會議的重要事項,全都是這類型的,那有三種可能(註3):

(A) 團隊有如NBA夢幻一隊素質極高,工作合作超級愉快,成果驚人。

(B) 團隊失去對專案的信心和動力,或根本不相信Scrum Master。

(C) 團隊絕大部分的成員經歷太淺,不知如何開始檢討。



--- (A) ---

如果你認為你現在的團隊是A,大概有49.99%的機會你是在欺騙別人。另外有49.99%的機會是你自己騙自己,或被別人騙。


--- (B) ---

如果你認為你所處的團隊是B,而你恰好是Scrum Master,或者是專案經理,或者任何領導階層。那你最最需要做的事情是「檢討改善自己」,而非「檢討改善別人」。一個團隊,大部分的人不願意說真話,最有可能有問題的一定是管理階層。

如果你認為你所處的團隊是B,而你非管理階層,也非Scrum Master。你可以先審視自己專案對社會的重要性。如果你是在核電廠,或者急診室,那你應該盡自己一切的可能,不計代價,不眠不休地改善現況。

然而,如果只是一般的軟體專案,建議你先就自己可以改善的地方檢討自己。確定當你看到不正確的事情時,會先審視自己的能力與做法。但也不需要強出頭,把自己當作革命烈士。畢竟,大部分的軟體專案並不是那麼重要。


--- (C) ---

這種情況似乎也常發生,但是解決方法很簡單。

首先Scrum Master應該在第一時間對於「雞毛蒜皮小事」,做立刻回應。對於每個小事的回應都是:下次不用等到sprint結束,中間任何時候都可以馬上找我講。這樣才會讓團隊成員養成自動自發,並容易判斷哪些事情很不重要。

如:

* 每週固定的下午茶太不健康,看能不能換健康一點的

...可以,馬上就換。以後一遇到這種問題,不用等到sprint結束,任何時候馬上跟我說或者寫信給我。

* 每天站著會議好累,可不可以坐著

...不行,因為站立會議的目的就是要讓你累。以後想到這類型問題,不用等到sprint結束,任何時候馬上跟我反應。

* 能不能有免費可樂

...可以,你馬上去買,發票給我。以後一遇到這種問題,不用等到sprint結束,任何時候馬上跟我說或者寫信給我。


* 我們可以固定一段時間來分享一下大家coding的心得

...可以,你馬上去發固定會議通知時間。以後一遇到技術分享的事情,只要不影響sprint時間,任何時候就直接去做,不用等到sprint結束。



(3) 實際事實,實際行為優先



Scrum的精神在實況與事實,而檢討的實況和事實在於「行為」而不在於「想法」或者「內心深處的感覺」或者「價值觀」。

這個概念非常重要。缺乏了這個概念,就容易讓檢討回顧會議,變成「互相責怪」會議。

然而,執行也很重要,執行不當,也會讓回顧檢討會議變成「互相責怪」會議。

首先會議一開始Scrum Master一定要強調,接下來的會議以事實優先,而事實當然是根據某人做的事情。在團隊成員互相不熟悉的情況下,要「反覆」的重述事實優先。並且在討論時,嚴守只看事實的承諾。

會議的形式此時就不太重要,不過:點名發表意見是個簡單的好方法。當然Scrum Master應該要自我拋磚引玉一下。

以下舉幾個常見例子:

成員J說:PM常常來叫我們改東改西,為什麼之前不確定好需求

這時候Scrum Master應該列出這個sprint完成的task。追尋到底哪些task的需求被改變,大約影響了多少工作小時。
當然成員可能會說他不記得,就請他大致猜測一下。然後再跟sprint的時間做比對。如果改動所花時間很少,那其實不是問題。如果改動時間比率很高,才是值得關注的問題。值不值得處理,要看比率原則。-- (註4)


成員A說:我覺得我的task太多,都做不完。


這時候Scrum Master應該立刻請成員A把過去一個sprint做完的Task列出,看看是不是有做完,並且完成這些task是否有加班,或者,其實他的task是由別人完成,但是每日站立會議中並沒有說明?總之,現場應該了解事實,而事實也一定能被了解,不能等到「之後」。因為每個Sprint只檢討這個sprint,也就是過去4周左右,不可能需要很長的時間了解事實,也不可能有「我現在忘了要回去找一下」



成員K說:負責前端的人的bug太多,有時候負責後端的人都得幫忙修復bug。


這時候,Scrum Master應該立即根據bug清單,看看前端的bug數量,和負責解決bug的人。假設前端bug數量在過去sprint中有100個,而99個bug是由前端的人解決,有1個是後端的人幫忙解決,而且也只花了1小時。那麼這個問題根本不成立。只是因為後端開發伺服器的人,會特別記得「例外事件」就會有別人bug多太多害我多花時間的印象。這事情比例上多寡,是不是值得處理就要看「實際情況」列出判斷。一旦列出來給團隊成員看,就很容易大家一起判斷。


成員F:我coding速度是沒很快,但是有些速度更慢的人,就完成比較少的task,好像不太公平。


這時候Scrum Master應該根據git或其他版本控制系統,列出團隊成員程式碼數量。配合完成的task數量,bug產生數量(表示code品質不好) 以及bug解決數量(表示解決的問題)大約比對一下,看看團隊的產出是否「差不多」。當然,不同的作業系統,不同的平台,不同的程式語言是不能這樣比較。

不過大部分的情況下,這個問題並不會被提出來。但是,這個問題會存在在壓力比較大的團隊成員中,並且有礙於團隊成長。因此,Scrum Master自己必須要有客觀的衡量產出的方式!即便沒有人提出這個問題。


成員L:我們對所使用的open source工具不太了解,導致於需要學習的時間。

由於這個問題很具體,Scrum Master只需要確定這件事情是否還存在。下個sprint還會不會有不熟悉的工具需要使用。



後續?

 Retrospective檢討回顧會議中,如果找到重要的事項應該要改善。當然就是Scrum Master或者管理階層需要去「執行改善」的時候。前述內容都只有「找到問題」而關於如何有創意的解決問題,還請參閱後續文章。






註1:網路上參考資料非常多,例如:這裡這裡 或者 這裡

註2:專案驗屍(postmortem)在許多人心中另有其定義,可以參考這裡,或這裡

註3:就只有這三種而已啊?確實有可能有別種,但是不太需要討論。例如:在某些軟體專案團隊的前幾個sprint,因為「蜜月期效應」的確真沒有大問題。也有很多軟體專案,本身的目標比較特殊:例如學校的畢業專案,或者政府國科會案,雖然要交付結果,但結果的本身根本不重要,當然也不有大問題。也有某些專案,並不適合採用單純的Scrum,所以無法使用檢討會議針對人進行檢討。

註4:Sprint的中途按照Scrum的精神本來就不能由PM/Owner隨意修改需求規格。但是,在這裡是Sprint的結束。如果Sprint中途真的發生臨時修改的事情,Sprint的結束當然要作為「事實」加以檢討。要注意的是,目的是檢討事實,而不是簡簡單單的說PM/Owner沒遵守「Scrum的規定」。Agile的精神中,團隊的溝通跟改善,遠比「規定」來的重要。由於軟體專案太常出現這類問題,所以後續文章也會有針對這種問題的建議解決方式。




11/12/2016

Scrum - 專案壓力來自於無法掌握的命運



一個壓力實驗:

有兩個籠子(A,B),都連結同一個電極器,各有一隻老鼠。A籠子中,有一個燈號和按鈕,當燈號亮起時,如果在數秒內,A老鼠沒有按下按鈕,則就會產生高壓電極,讓A,B兩籠的老鼠都被電的很不舒服。不過,如果燈光亮了,在時間內A老鼠按下按鈕,則A,B兩籠就都沒事。B籠的老鼠則是全然被動的,只要A老鼠能做好他的工作,B老鼠就沒事。當然,經過幾次電極之後,A老鼠很快就學會了一旦看到燈亮,就應該儘速去按按鈕。

過一段時間之後,哪一隻老鼠的壓力大?

經過健康檢查,A老鼠幾乎看不到壓力大的特徵。而B老鼠,則出現各種癥狀:高血壓,胃潰瘍,成長障礙等等不一而足。

(以上內容取自:數位痴呆症:作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難,而是在於自己「全然」隨著命運擺佈,無法控制。以A老鼠的情況來說,他仍然是被關著,而還得三不五時瞄一下燈是不是有亮,一旦亮了就得趕快反應。

然而,「至少有一件事情」A老鼠可以控制:他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實,固定的時間,以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內,每一個角色都有「至少可以全然控制」的事情,不但可以正確減低無法掌握命運的壓力,更能組合出正確的團隊合作方式。


Product Owner(產品擁有者或產品經理)


在傳統的「瀑布開發模式」,或者,系統整合商SI的「隨意無止盡需求模式」中,產品經理會就所有應該要做的事情列一個驚人的功能清單,交由專案經理負責領導開發。接下來的18個月,產品經理就在B老鼠的壓力下度過,即便有檢查,也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理,更有可能在每一段時間,修改需求,讓開發團隊變成B老鼠,不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任,這個責任用非常簡單而清晰的方式減低他的壓力:「撰寫並排序需要完成的使用者情境」。

專案開始時,產品經理會撰寫數個使用者情境(user story)並且排定優先順序,而每個sprint開始時,團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後,檢查這些當初答應的story是否有如預期完成,並且在下個sprint開始時,或確定,或重新排列,或增加,或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成,並且確定每sprint開頭都能選他最想要的事情先做完。因此,產品經理確實能掌握這個產品每一段時間的「樣貌」,而不是在最後關頭才求神拜佛,或者要求加班。甚至,在sprint的中間階段,若有必要,產品經理可以要求sprint停止,重新開始新sprint,用來調整後來才發現不正確的優先順序(priority)


Scrum Master (開發領導者)


過去一個團隊的技術領導者,帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理(或客戶)以及開發成員中的角色。

在傳統模式下,他若非變成一個技術獨裁者,用以壓迫成員前進並反抗大幅需求改變,就是變成試圖面面俱到的好好先生,用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description),但事實上,困難的專案,不會因為一個很能講話的專案經理,就變得簡單。最後最常出現的結果是:專案經理總是能有效呈現「自己的貢獻和功能」,但無法反應在專案成功。換言之,常常看到自己從來不失敗的專案經理,曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理,其責任和角色也有很大的不同。而他能有效掌握的事情,也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」:完成了哪些事情,接下來要做什麼,有遇到什麼困難。確保每個sprint開始的會議,領導團隊能完成哪些使用者情境(user story),並且確定這幾個要完成的事情,產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情,但是透過掌握每一個sprint,腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖,Scrum Master掌握過去真實進度。因而可以有效推測未來進度,並有足夠的證據顯示給產品擁有者。因此,才能有足夠的「動作權力」成為A老鼠:仍然在籠中,但掌握部分真實權力,以減少壓力。


Member (團隊成員)


傳統模式下,團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是:「某功能我們在要X月X日之前出來!」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是,在Scrum中團隊成員,決定使用者情境:「真正完成的所需要的時間」。而這個權力,僅代表一個事實:由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做,只要決定現在在做的事情,什麼時候可以完成,以及「真的去做他」。換言之,Scrum團隊真正的A老鼠,其實只有團隊成員,只有他才會真正的按下按鈕。然而,如果Scrum團隊不能掌握分工負責的精神,團隊成員很快就變成B老鼠:不是被無謂的壓力掌握自己的命運,就是試圖跳脫牢籠。






8/06/2016

Scrum 認證!? 不要再浪費你的錢了!


管理類型的證照無用論,早在軟體工程界提倡Agile Movement的時候就逐漸存在。

以目前看起來取得成本最高的PMP在資訊科技的評價為例:比較客氣的說法像是這篇:雇用有PMP的專案經理需要更進一步了解其能力。而比較不客氣的說法會像是幾篇:PMP毀了專案管理,或者PMP證照無用。(註1)

而這幾年Scrum的方法論,因確切執行之後確實對軟體產品開發有顯著效益。隨之就有各類型推廣,教育,甚至認證產生。

然而,花大錢考Scrum真的有意義嗎?


(1) 認證市場


技術專業認證,絕對有其必要性,例如:醫生執照,律師執照,CCNA,SCJP,TOEIC,甚至,職業大貨車駕照,乙級中廚檢定...等等。擁有此技術執照,表示你至少「會」做某些事。

然而,非技術執照,只證實「考過」某些考試,一旦考試內容和實際會到的問題有差距,該執照就沒有太大意義。只能代表你對某些考試的努力成果。專案管理,企業經營方面的執照就屬於這類。這類型執照如果成本不是太高,倒也無妨。高收費的認證?等於是浪費錢。

一旦有高收費的認證,自然就會有認證教育訓練市場。教育訓練本身是好事情,可以讓人學習成長,但是,教育訓練本身如果是應付考試,意義就降的很低。


(2) Scrum高收費認證為何沒用?


迄今,Scrum認證有很多種類,單就Scrum Master而言,網路上隨便找,都可以找到以下七種,請參見下表。


證照名稱考取成本 (以台幣計算)組織
Certified Scrum Master$30,000 (含16小時訓練課程)Scrum Alliance 
 Professional Scrum Master I 
 Professional Scrum Master II
$4,500

$7,500 
Scrum.Org
Expert Scrum Master$3,000EuropeanScrum
Certified Scrum Master$3,800 (不含訓練課程)
$4,500 (含8小時訓練課程)
GAQM
Scrum Master Certification$13,500ScrumStudy
Agile Scrum Master$5,880EXIN
Scrum Master Accredited Certification$900Scrum-Institute


筆者考過並取得最貴的認證以及最便宜的認證。其價格差距很大(三萬台幣 vs 九百台幣)。單就「考試內容」而言,最便宜的考試內容甚至還稍微難一點點。而最貴的CSM (ScrumAlliance)其實也就是台灣各教育機構最努力推廣的認證。

就考取認證作為職場價值這點來說:

1. 如果是沒有任何軟體專案經驗者,透過高收費教育訓練考取最貴的收費認證,基本上,和只自學而通過最便宜的認證,在Scrum基礎知識上根本沒差別。而在Scrum實務運作上,也沒差別:都屬於完全沒經驗。


2. 如果是有數年軟體專案經驗者,「有無證照」對於專案管理來說,只是履歷表上的一撇,一旦遇到真正的艱難問題:在Scrum上採取正確作法的經驗和收獲,遠比考證照的收穫大得多。因此,昂貴證照和便宜證照也無任何差異。

3. 沒有駕照,就不能合法開車。但沒有Scrum證照,在務實的企業中,只要你有足夠實務經驗,足夠證明支持你的能力,根本沒有問題。反之,如果有Scrum證照,但無法足以匹配的經驗,能力,而再加上創意不足,那麼甚至是有害無用。



(3) 建議作法


如果有想考Scrum相關證照,有三個強烈的建議:1.「自我學習Scrum」2.「確切運用Scrum」3.「考最便宜的」

1. 自我學習Scrum:

學無止盡,無論是Scrum還是其他未來可以出現的方法論,都值得一學。但更重要的是,如何自己學習。任何教育訓練都很有用,但也不可能完全取代自我學習。

自我學習的方式可參考這裡:如何學習Scrum 。以及這裡:如何成為Scrum專家,或者:scrum的缺點,或者 :Scrum三件必要的事

2. 確切運用Scrum觀念與作法在軟體專案中:

任何專案管理上的知識技能,如果不能有效運用在專案管理上,當然就沒有意義。以Scrum的每日會議(無論是不是站著開會)來說,其基本觀念在於:

「限時」 - 15分鐘
「事實」 - 只描述做完的項目,和下次打算做完的項目。(註2)
「困難」 - 只說明困難,不是要在每日會議上解決困難。

也許現實會讓Scrum Master或專案經理有所調整,但如果調整的方式不能切中Scrum觀念,則取得昂貴Scrum證照也沒有任何意義。(例如每日會議花超過40分鐘,肯定不符合任何一種Agile專案方式)

3. 以實力考最便宜的證照:

不可否認,還是有不少人認為一旦履歷表上有幾個証照,似乎會多一點點面試機會。另外,也有些有專案管理經驗者,自我學習Scrum想要有個目標來證實自己。

以這樣的立場,其實考取最便宜的證照即可。而最好是在沒有任何準備的情況下,抱著隨便考的心態。如果這樣考過了,表示Scrum的基本知識已經深入腦海中,考不過其投入成本也不高。

剛出社會的新鮮人,如果覺得萬一在面試時,有人對便宜的證照有疑慮?你可以客氣的敦請他去考考看,了解一下其考試的品質。





註1: 我們不是反對PMP。事實上,在其他工程領域PMP有其必要性。例如:cern的LHC是一個橫跨數十個國家,涵蓋土木,電機,資訊的龐大工程,PMP條列的九大項目,五十多種可能的文件在此就有點必要性。本文反對的是,以PMP(或其他管理證照)來判斷一個專案經理有沒有能力執行資訊軟體相關專案

註2: 何謂做完?(definition of done)也是Scrum team需要在專案開始前定義好的。

註3: coursera.org 提供各種課程修業完成認證,目前沒有ScrumMaster,但是有類似Agile Management的課程,上課是免費,不過,取得認證約為3000~5000台幣之間。

7/02/2016

如何學習Scrum


如何學習Scrum?

端看學習Scrum的真正目的,有三種方式可供參考:(1) 網路資源 (2) 收費課程 (3) 實際經驗


(1) 網路資源


很簡單,費用幾乎為零。

下載這兩個pdf,接下來,先不要上網查專有名詞,也暫先不要查字典,好好的先花時間看完。

* Scrum-institute 的 training pdf
* m-plaza 的 Scrum Guide pdf

然後,隨意上網找一些相關資料閱讀佐證即可。也可以自己做個類似這樣的簡單學習計畫

不確定自己有沒有學會?可以考慮花29美金考一下證照看看,請參考Scrum證照這篇

假如是剛畢業的大學碩士學生,英文閱讀沒有太大障礙的話,大概8-16小時應該可以完成。


(2) 收費課程 <- 不推薦


也很簡單,但是要花錢,大概7,000~20,000不等。


在google搜尋[scrum 認證課程],出現起碼5個不同的教育機構,其價格從7,000到20,000台幣不等,時間通常大約是2整天左右。衡量自己的時間和財務狀況,挑選離家近的參加即可。

這類型的收費課程通常會協助考取證照。在此並不推薦這個方式考取非技術專業之證照。

(3) 實際經驗


非常難!要花的成本看起來很高,不過他通常伴隨工作經驗的成長。

(a)基本作法:


首先必須要先參與開發團隊一陣子,在此期間必須要先用方法(1) 網路資源。用以了解Scrum的基本精神。

然後,只要運氣不要太差,加上自己的努力,有朝一日會變成專案經理,或者是團隊領導者的角色。接下來,由於自己已經擔任領導者角色,就在自己領導的團隊中,以務實的方式執行Scrum。其中一定會遇到阻礙,每當你碾平一個障礙,就更多一層對務實的認識。

基本作法其實也是最佳作法,如果是一個已經有足夠技術背景的人,而有意識的朝這個方向前進,在台灣大概3-5年就可以有很好的成果。


(b) 突破性作法:

和所有專案管理技能一樣,當不能付諸現實的時候,技能的本身就沒有意義。就像籃球教練沒有籃球隊可以教,沒有籃球比賽可以參與的時候,籃球教練等於沒有付諸實踐的意義。

要有突破性作法的原因在於:

* 企業組織長久以來沒有真正agile的精神
* 在創新小公司任職,架構混亂,以完成事情為優先
* 自己並不是團隊領導,但希望能改變團隊
* 剛畢業,沒有領導管理經驗
* ...


然而,在這些外在因素不利的情況下,如何有Scrum實際經驗?(突破性方式的概念可參考這篇。)

簡要的說,自己起頭一個專案,無論是跨界虛擬專案,還是開源(open source)專案,還是到便宜的外包市場找南亞工程師加入的專案。當自己開啟專案時,自然就可以確定,如果要採行Scrum,不可能會有其他外界因素,所有成功與否的因素都在於自己。當然也是靠自己來碾平困難。

一旦個人的能力提昇,自然就越能貢獻現在的團隊,現在的組織,更容易體會團隊合作的可貴。