顯示具有 實況 標籤的文章。 顯示所有文章
顯示具有 實況 標籤的文章。 顯示所有文章

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) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等






1/11/2017

企業巫醫 - 統計與謠言



In god we trust all others bring data 

  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低,同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會,例如:十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪,例如:誠品可怕迷魂盜泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇,例如:裝翅膀飛起來

最糟糕的類型,莫過於以「統計數字」造出看似符合邏輯的謠言。並且,從這樣的謠言中獲得利益。


許多時候,數據本身難以查詢正確性。而且由數字導引出的邏輯,更容易因人而異,因地制宜。從數字所引導的偏誤,有時候甚至比單純的謠言還可怕,因為它可能會在網路上留存多年,難以辯證。如果只是單純搞笑也就罷了,如果個人或者組織,以這類型的資料來作為決策的判斷依據,那下場可能非常慘。錯誤的資料,比沒有資料更糟。


不過,只要稍微留意,加上合理的好奇心,統計謠言是有機會判斷其可能性:


(1) 不解釋的數字


在各類文章或研究報告中,為求精簡,只會根據重要數字做衍生推論。然而,數字背後通常還有「未解釋」的數字,而這個數字可能更為重要。

企業僅21%的需要大學以上學歷為例。這篇文章,簡單說明勞動部的調查,僅有21%的企業需要大學以上的學歷。然而,這個數字有很大的問題。

也許,該調查隨機抽了100個企業主,其中只有21個企業主宣稱需要大學以上學歷的員工。

也許,該調查抽樣了企業主的「100個正在招募工作職缺總數」,這100個職缺中,只有21個是需要大學學歷。

這兩者有極大的差距。前者,可能這21個企業主,所需要員工數量高達2萬人,而另外79個企業主,所需員工只要79個人也說不定。而後者,正在招募的職缺,和「已經在職」的學歷也並未顯示。而單就此推論,僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化,而沒有附上數據的真實來源的推測,其解釋很容易被扭曲。然而,被扭曲的解釋,當然比較有戲劇性,比較容易被注意。

勞動部網站根本也找不到這份調查。

此外,很多政治性民調也是屬於此類,涵蓋許多不解釋的數字。



(2) 接近完美的不可能


網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示,越早退休壽命越長。(參考這裡這裡這裡)  

這份數據流傳非常之廣,被引用次數非常多,每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字,是退休年齡跟「壽命」的對照表如下。


retirelife
49.986
51.285.3
52.584.6
53.883.9
55.183.2
56.482.5
57.281.4
58.380
59.278.5
60.176.8
6174.5
62.171.8
63.169.3
64.167.9
65.266.8

不會統計的人也可以看出,在這個表中,越早退休,壽命越長。如果49.9歲就退休,那麼可以活到86歲。65.2歲才退休,就只能活到66.8歲。

以相關係數簡單計算,他的相關程度高達-0.96,換言之,這是一份極為完美的負相關數字。

這種過度完美個數字,應該要看研究論文的細節加以瞭解。例如他的樣本有多大?是什麼時候做的研究。就可取得的事實來看,他的樣本很小,並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲,所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是,這些數字並非真實研究論文,卻在很多人的轉貼中,莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因,是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷,財務規劃,人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外,別無他因。雖然已經有些人發現不對勁,例如這裡。但是許多第一次看到此研究的人,仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究:請參考這篇研究。該篇的結論就交由各位判斷,但至少它的研究方式,數字細節,都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng,懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者?)。至今2017/Jan/11尚未收到回覆。


(3) 邏輯上的不可能


邏輯上不可能,或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來,竟然遠超過全國GDP,而且高過很多。這在邏輯上是不可能的事情,因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查,而且其實也不打算認真做統計的相關文章上,例如這裡。因為在許多時候,謠言只是想要造成吸引人的目的,其真實性不重要,當然就也不特別檢查數據。所以自己造成自己數據兜不攏,邏輯上不可能的情況並不少見。

這和前兩者不同,邏輯上的不可能,可以單就資訊本身的內容加以探索,或者是再加上一些事實根據來檢視。因此,比較容易看出謠言的真實性。




最後,稍微提醒一下:廣告的統計宣稱,其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證,一般市井小民根本無法查證屬實與否。





12/22/2016

企業巫醫 - 年底才績效評估或考慮轉職?已經太遲。



年末,巫醫們會試圖對迷惘的人們,提供某些指引。

因此,在各部落,社群網站總是有各式的「轉職衡量」,「績效評估」,「個人職涯規劃」,「獵人頭的建議」...等等相關文章。(註1) 

不過,就實際情況來說,假如你到「年末」才考慮這些重要事情,那麼已然太遲。


為什麼?


績效評估要及時


大部分的企業在年尾都有績效評估。但以個人職涯而言,這些事情,應該是每隔一小段時間 (例如一個月) 就應該自我有所評估,並調整未來的做法。

就好像今年初打算減肥20公斤,並降低體脂肪到20%以下,而直到年底才量體重體脂肪,基本上已經太晚。即便最後仍然達到目的,也可能只是運氣好。

無論層級高低,無關老闆是誰,無論組織狀態,每隔一段時間,個人應該就事實以及個人產出部分自我評估一下績效。更重要的是,了解別人(特別是主管)對自己的「真正評估」。

自我評估,必須要根據「事實」,與其他人的「衡量」。不應該根據自己的想像,以及感受。

舉例來說,如果你是個軟體程式設計師,每個月你都如期產出符合品質的程式碼,並且bug數量也很少,那麼確實是個好工程師。

反之,如果相較於其他軟體程式設計師,你的程式碼產出低於其他人,bug數量也多,即便你有參加福委會,搞了很好的尾牙活動,你的績效評估恐怕依然很糟。

但由於,許多績效評估是根據「相對績效」來判定。而由於人類有天生的偏誤,自我評估一定會趨向「好的結果」。

因此每一小段時間,你一定要試圖取得主管或其他相關人的「真正看法」。越嚴格的越好。如果在2016年2月,你知道主管對你的績效是不滿意的,那麼你還有很長的時間可以改變(註2)。但如果你是在2016年底年終考核,才赫然發現主管與你對績效的「看法」不同!那幾乎沒有翻盤的可能。

另一個重點在於:績效評估是為了自己的職業生涯,不是為了組織,也不是為了讓主管決定薪資。

如果你覺得,如果要做每月的績效評估,公司/主管應該要主動進行才對?那表示你根本不是個能獨力處理事情的人,同時也表示你的主動性太差,也很難自己成長。



轉職衡量要完整


年底並不一定是換工作的最好時機。只因許多人因為領到年終,所以剛好離開「忍受很久」的工作,所以一時間就似乎有很多職缺出現。然而,某個人忍很久的工作,通常表示下一個人也不一定好受。

換工作的考慮有很多,無論哪一種考慮,都需要基於事實(請參考這裡)。簡單的說,在這份工作遇到的困難沒有解決,下一份工作一樣會遇到。

完整的換工作衡量需要對自己在「事實」上的長期認知。包括過去一段時間有去哪些地方面試?並且被錄取?自己倘若離開這個組織,對組織有沒有影響?自己如果沒收入,可以支撐幾個月?

更重要的考慮是:自己真的想要的是什麼。



那麼,年末可以做什麼?


當然還是得進行轉職衡量,績效評估,個人職涯規劃,參考獵人頭的建議...等等。可是更應該進行的是「檢討自己」與「改變自己的實際做法」。



1. 不設定一年為單位


以個人生涯規劃而言。應該將「一年的結尾」。從新定義為「一個月」或者「一季」的結尾。

並自現在開始,設定自我評估的時間單位,例如一個月。

每個月直接詢問主管或者工作上最相關的人:「有哪些地方需要改進」「哪裡做的事情有問題」「這個月哪邊沒有超乎期待的表現」...。

對於調整職業生涯也是以比較小的單位取得回饋。

當然,這並不代表不能有年度目標,或者五年以上的願景。只是,檢視願景和目標的單位必須要有及時回饋的可能(註3)。而單指個人而言,每個人的記憶有限,根本不可能有效回顧12個月前發生的事情。因此採用Scrum的精神,以大約一個月為單位應該是最適合。



2. 不重複過去無效的做法


恆毅力是一本在誠品門口有超過5公尺橫幅廣告的書。作者以她數年的研究顯示恆毅力是成功的重要因素。

毅力耐心確實是朝著目標前進時不可或缺。不過,實際作法的調整也很重要。以創業為例,pivot幾乎是必要。

每過一段時間,應該就事實來檢討,目前做法是否達到效果。如果沒有,就應該衡量原因,考慮改變執行的方式。不見得一定要改變,但一定需要檢討。

改變當然有可能帶來風險,甚至會比沒改變的時候更糟糕。然而,不改變就沒有前進的可能!



3. 不等候重要的事情


誠如第一段所述,年末考核等到年末就太遲。其他和職涯有關重要事情也是,不應該年末才進行。

因此,今年年末可以設定未來「重要的事情」頂多等到下個檢討點 - 例如一個月後。

每個人所意識到的重要事情都不同,有很多時候心裡覺得一件事情重要,和實際上真的很重要是截然不同的事情。一個人的真正行為,才是斷定他認定重要不重要的指標。





參考:

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間?

職業生涯的突破

成長的最好方式:檢討


註1: ....對... 這篇也不例外

註2: 所謂調整,一樣要考慮手邊有的選項:可以針對不好的地方改善,也可以試圖換個工作項目。甚且也可以換工作。

註3: 有些人可能會用「爬樓梯可以一步一步,但是要跳過鴻溝不能分步驟吧?」來辯解過短的時間區間會有其他問題。不過,這真的是問題嗎?跳過鴻溝的確是一次跳過,但起碼助跑的時間和助跑距離的測量,也是必要的前一步啊!



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的精神中,團隊的溝通跟改善,遠比「規定」來的重要。由於軟體專案太常出現這類問題,所以後續文章也會有針對這種問題的建議解決方式。




8/14/2016

Scrum (實況) - 瞭解事實才能領導專案






近年來在符合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認證