【腦殘遊記之我也懂Scrum】sprint final

故事講完了，這篇是後記。

sprint之所以會叫sprint，是從橄欖球這運動來的。橄欖球能帶著球往前跑，但傳球只能往後傳，用此意喻專案的進度其實會有進有退，也有可能停滯。一時的後退可能會帶來長足的進步，當然，是指合理的後退，在開發的過程中發現必要的修改，像是前期規劃有所錯誤或不盡理想之處等，短週期的檢視，讓這調整的風險降至最低，這也是為什麼scrum會用為迭代式開發(iterative development)的方法的原因。

但iterative並不是反覆修改，否決過去所累積的東西，朋友的專案浪費了太多時間在翻掉舊有的東西，甚至是翻掉又再翻回來，反反覆覆，毫無建樹，糟踏了迭代式開發的美意。

這篇講到橄欖球，其實主題是要講運動的。正如村上春樹寫了一篇關於慢跑的文章，寫了運動的文青就更文青了。

在活到這歲數，才覺得運動的重要，讀書時期，管這叫「體育」。體育被評分的標準就是跑步跑多快、籃球投進幾個、鉛球能丟多遠，但那並不是體育。

運動是讓人身體健康，體育則是讓人能有跟其他人合作、競爭的學習，這也是為什麼歐美國家很重視體育，可惜台灣的教育也不重視這塊，學校的老師都不會教這方面的事情。

合作的觀念應該不用多做說明，競爭也是學習的項目，中國文化以和為貴，「君子無所爭，必也射乎！揖讓而升，下而飲，其爭也君子。」所以很排斥競爭，但從競爭的表象來看，可以學到企圖心，為了成就某件事努力不懈的拼勁。從內裡來看，能學到面對失敗的容挫力，不屈不撓、愈挫愈勇的精神，這兩點是念書學不來的。

君不見所有熱血的漫畫都會有這兩個要素，海賊王的魯夫，為了成為海賊王而前往新世界，打敗不少敵人，在頂點戰爭中失去了哥哥，意志消沈的他透過冥王雷利的提點，才想到他還有夥伴而振作再出發。

更別提經典運動漫畫灌籃高手，這是我看過唯一一部主角沒有拿到全國冠軍就結局的運動漫畫！真是太挫折的主角群了。湘北籃球隊從磨合、成長、挑戰、失敗、成熟，很經典熱血的過程。

只會讀書的人，很怕承受失敗，不敢失敗，失敗一次就好像就世界末日了。人生不像遊戲，失敗可以重來，但人生也不像遊戲，失敗一次就全盤皆墨；也不像灌籃高手，打輸山王就結局了。

這就是我對體育的看法，希望能透過這篇讓各位家長能瞭解孩子的教育不是只有讀書而已。

而scrum會引用橄欖球也是這個想法，要能接受sprint中產生的失敗，及造成的進度延遲，就像運動漫畫常會講的台詞「這局輸4分，下一局贏回來就好了！」「OH~~~(打氣聲)」，當然，前提是sprint，而不是沒有休息時間、不間斷的walk。

胖子有沒有這體認，我猜沒有。因為他喜歡的運動是游泳跟騎腳踏車，追求的是never stop。

THE END.

【腦殘遊記之我也懂Scrum】sprint 5

Daily Meeting在sprint 1有先提過，所以重覆的就不多提了。

Daily Meeting會在每天早上固定時間召開，小組成員要自主參加，先在各個task上填寫昨天對該task的工作時數，完成的項目則推進到待驗證的欄位中，各人報告昨天做了什麼，今天要做什麼，遭遇到的阻礙或問題，而SM則在一旁瞭解整體狀況，結束後由SM統計燃盡表(Burndown chart)。

Task board可以顯示每個Story的完成進度，Burndown chart則可以顯示小組工作的效率是否如預期。若有時數一直跟不上預期的，就表示有問題，SM需要瞭解狀況並予以排除。

我朋友遇到的狀況是，小組成員並不想瞭解彼此的工作內容，這與Daily Meeting的初衷就相違背了。更別提胖子希望大家瞭解專案狀況，而要求SM要記錄小組成員的工作事項並寄信給整個專案成員，又，希望大家開會能看著實體的板子，比較能…我也不知道能比較怎樣，胖子的心思很難理解的。因此，每個人僵化的對SM報告，SM需要記錄下來，然後再輸入電腦寄出，我的天啊，到底是什麼愚蠢的念頭，能這般折磨人的時間。

SM應該是花時間在排解問題上，如今卻浪費在記錄上，捨本逐末。

另外，大部份台灣的公司只在乎「個人」的作為，擔心有人白領薪水不做事，所以前述以Story為主的task board及以小組為主的Burndown chart，全都無法提供胖子跟白頭翁評估一個人是不是有認真工作，所以在前面提的會議都消失後，沒有User Story的task board便要求以人為單位記錄每日工作時數，WHAT THE FUCK！扭曲這task board的用意就算了，還這麼扭曲的要求每個人照著做。

這個毒就這麼長在他們專案，消不掉了。這就是我所看到關於scrum的故事，scrum真的是解救專案拖延的萬靈丹嗎？看人吧。

【課後複習】Daily Meeting的另一個目的在於發現問題並加以排除，但Daily Meeting並不是討論問題的會議。小組內能解決的問題互相幫忙，無法解決的由SM負責排解。如此，小組才能專心無罣礙的處理工作。

【腦殘遊記之我也懂Scrum】sprint 4

今天要邁入非常複雜的一個步驟，就是工作規劃會議。

產品負責人(Product Owner, PO)會列出他的需求，簡單的描述一個需求需要達到的目標，稱為一個User Story，並評估每個User Story的重要性，在工作規劃會議之初，提出這個sprint希望做到的User Story。

而小組則根據Story的困難度及重要性來挑選這次sprint要做的項目，這個過程會由PO跟團隊進行溝通協調，如果評估時程無法做完某一項長時間但PO又覺得很重要的項目時，可以降低該項目的需求以減少開發時間，或是再將該項目細分小項，先做其中優先、重要的項目。

選完之後，小組成員則會對各個Story給予故事點數，這個點數除了說明這項目的困難度以外，也能用來做為下次評估能做的Story的依據。若這次能做完20個點數的Story，下次做35點做不完，那久了就能拿捏每個sprint的負荷量。

另外，評分是有固定分數小卡的，若分數差距太大，顯見Story大到無法精確評估，或是組員的工作量差異太大，都需要再重新定義拆解User Story的。

評分完，成員各自將Story拆解成實際的工作項目(task)並填上預估完成時數，這些task就會進到之後的Daily Meeting。

內容過程十分繁複。我朋友一開始也玩得很開心，但誇張的來了，朋友的小組接了Avatar系統，可是組內的美術是2D美術，並不擅長做模型，鑑於「小組對於一項User Story進行討論研究並實作出來，小組成員能提出自己的想法有參與感，是一件非常有成就感的事情」這個原則下，2D美術學著拉模型，這是什麼情形？

幾次下來發現不對勁，改了，「這個Story我們接，你們組的誰誰誰來配合幫忙」，小組仍舊是小組，有著互動良好的參與感，只是有時會「配合」別組，配合而已，不礙事的。最好是！Daily Meeting的時候，SM無法掌握自己小組成員的工作進度。造成跨組合作的情形，不是分組錯誤，就是Story有問題。

User Story原本只需簡單描述，由小組成員完成內容實作，可是往往胖子跟白頭翁無法接受成品，因此User Story越寫越詳細，差點沒直接把工作項開出來，最終還是喪失了前面提的原則，控制欲強，就不要用這麼依賴團隊創造的方法啊，莫名奇妙。

到最後，這個會議也消失了，直接用指派的了。至此，所有的會議算是消滅了，只剩一個Daily Meeting還存在，但荒謬的就在這裡，看似回到了原點，主管指派工作，不需討論、不需參與感、不需瞭解各組狀況及專案進度、不需檢討，但實際上並不是。

小組以奇怪的模式生存著，各專業別的組長分派工作，SM召開Daily Meeting，小組成員間既沒合作關係，卻要花時間聽彼此的工作進度，每天。就只為了胖子要掌握各人工作狀況，有這麼難掌握、變化多端，要天天檢視嗎？荒謬、扭曲。也有可能為了胖子不為人知的神聖理由，沒人知道。

下一次，最後一堂，來聊聊頑強的Daily Meeting。

【課後複習】工作規劃會議中，小組根據PO提出的User Story，評估其實作的可能性做為這個sprint的工作內容，與PO的溝通能研保彼此對品質的認知。評分的步驟不僅檢視Story，也能成為未來小組工作量的評量。

【腦殘遊記之我也懂Scrum】sprint 3

好久不見了，如果忘了之前的內容，請自行去找"scrum"標籤複習一下。今天要講的是回顧會議。

在評審會議之後，會由SM舉行回顧會議，討論的內容是這次sprint中好的項目是什麼，待改進的項目又是什麼，透過組員自身思考檢視，找出影響待改進項目的障礙是什麼，藉此反覆週期，排除障礙，增進工作效率。

我朋友他們的回顧會議是這樣開的，組員們列出這次sprint做的好的跟做不好的項目是什麼，並畫出每人的心情曲線圖（這個sprint中每天的情緒是在高點/正面或是低點沮喪），然後說出這個sprint要感謝的人是誰。

第一個看似正確，但聊了才知道，事情只做到列出來而已，列出來幹嘛？不知道，就是一個形式，最關鍵的事情反而沒做，組員沒有思考問題癥結在哪，SM也沒能去解決問題。至於後面兩項，我也不太知道重點在哪，我就想不起來上一週的心情到底是怎樣，難不成要寫日記記錄嗎？

幾次下來，所有人都覺得這個會議不知所謂，就被省略了，然後問題就這麼擱在那了，組員們盲目地處理工作，SM有名無實，毫無作為，淪為記錄Daily Meeting的工具。

不知所謂的，不是這個會議本身，而是沒有人瞭解這個會議的用意是什麼。要導入新的制度，因為不習慣，就人性上本就容易排斥，在胖子一知半解的導入，底下的人不願意花時間去瞭解，回顧會議這麼被當成雞肋放棄了。

sprint的中文叫做衝刺，scrum不用walk(走路)、jog(慢跑)、run(跑)，而叫sprint，是有他的涵義的，衝刺是盡全力的跑，但人不可能一直在衝刺，在衝刺結束後，需要有休息時間，才有力氣做下一次的衝刺。

回顧會議若能輕鬆的舉行，不僅能得到更有效用的回饋，還能放鬆這個sprint在工作上的壓力。可是台灣企業會認為「恁爸花錢請你來工作，不是來休息的」，一個sprint最後的這些會議既無生產力，也沒實際效益，在他們眼中是非常刺眼的存在，恨不得除之而後快。

這樣的做法，在一開始可以叫sprint，但在漫長開發期情況下，又沒有喘氣的時間，衝刺早就變老牛拖犁，疲乏的士氣，不過是拖著一口氣在撐著而已，scrum該有的功能全都省略，唯一留下的是繁雜的文件，可悲。

【課後複習】回顧會議的作用在於透過組員自身思考檢視，找出影響待改進項目的障礙是什麼，由SM負責排解，藉此反覆週期，逐一排除障礙，增進工作效率。

更甚者，還能給組員有一個休息放鬆的時間，以迎接下次的衝刺。

【腦殘遊記之我也懂Scrum】sprint 2

上一回說到了導入期，這次就正式來了。

正式的會議很多，到了sprint結束時，會需要先開評審會議及回顧會議，這通常一個早上就用完了，而下午還有工作會議。所以理論上兩週為一週期的sprint，工作天數會挪用一天進行這些會議而只剩9個工作天。這跟以往的工作模式有很大的不同，要接受這樣的「消耗」需要很大的勇氣。

像我朋友的公司，在一窩蜂瘋scrum的時候，連不是開發的團隊也有樣學樣，明明就是開發流程用的方法，也能套得很開心，導致會議室都不夠用。而時間一久流於形式，也可能覺得沒有必要，評審會議跟回顧會議就消失了。

今天的主題就來講這最容易被犧牲的這兩個會議。

評審會議會在全部小組面前報告各組該sprint的工作成果，名義上，透過這樣的展示，對於認真完成任務的小組，能給予其成就感，同時也能達到督促各小組完成任務的果效。但為什麼我會說是名義上呢？我也不太清楚，聽朋友轉述，每組大多能完成任務，即使票選出最佳的小組也沒有多大的成就感，哦，對，PO(Product Owner)，也就是胖子跟客戶（這裡是胖子的Boss，後稱白頭翁），會選出本期MVP，得到就是一個掌聲，離成就感有段距離，你不如發笑臉貼紙算了。

至於沒完成的小組似乎也沒什麼感覺，畢竟台灣是個以和為貴的環境，peeeeeeace〜。不過台灣的工作文化也不容許你有半點拖延，做不完就加班做，老子給你錢，你就要叩頭謝恩了，還敢有延遲，完全違背scrum的精神。這個之後會再講，回來講評審會議。評審會議另一個功能是瞭解所有小組的工作，除了讓PO跟客戶掌握目前進度，及是否有偏離自己預期走向，因為客戶開的是需求，也就是User Story，並不包含實作的細節，因此在這會議後能進行調整，這也是它屬於迭代式開發的原因。

同時，小組之間也能瞭解整體進展，這個部份也很重要，因為他們到後期時常發生矛盾或認知不同的狀況，這也等後續再說，因為這是很多因素造成的，不能歸咎於單一原因。

而白頭翁的個性使然，也能說該公司的文化使然，上層總是很想掌握細節，尤其遊戲這種創意性十分岐異的東西，跟一般軟體開發又不同。一般User Story可以說，我要一個訂單查詢功能，我怎樣怎樣，就能那樣那樣。遊戲開發，我說玩家被攻擊要能看到損血狀況，最後的結果變成畫面上同時有三個血條存在，這是怎麼演變的，我也不清楚，畢竟我只是聽來的。

就這樣，種種原因讓這會議流於形式，久了就覺得不必要而消失了。天才的胖子以為改善成更適合的形式，殊不知不完整的scrum，就不是scrum。刪掉了部份，遺留下來的也只是消磨人力的表格及表格。

沒想到評審會議就講了這麼多，看來回顧會議就待下回分曉了。

【課後複習】評審會議在展示本期成果，用以激勵、督促小組成員，同時能使客戶、PO、小組成員瞭解專案進度。

【腦殘遊記之我也懂Scrum】sprint 1

上一回說到了Scrum大致的內容，不記得的話，請回去複習一下。

在一開始的時候，我朋友的主管(後稱胖子)因為某些考量，可能是擔心這種方式不適合，等等的，我也不太清楚，總之，決定先導入Scrum的一些內容，就是小組的概念跟Daily Meeting。

所以，那陣子是針對胖子所關注的項目召集相關處理的人員開Daily Meeting，但是有可能一個人會處理兩個項目以上，也有可能有人做的項目不是胖子所關注的，造成有人每個會議都要參加，有人一個會議都不用參加，像個外人似的。

原本Daily Meeting是各小組各自召開的，但那時候是導入期，還請了別部門有Scrum經驗的人來指導，又是胖子很關注的項目，而且還有人會疊到，所以Daily Meeting是一個一個開的。一。個。接。一。個。

但是開會又沒有Daily Meeting的精髓，只有站著這件表面的事有做到，一個會議還兼著討論工作內容，都說要迅速了，還在「討論」工作內容，真是見到鬼了。Daily Meeting主要是報告工作項目，讓所有小組成員知道彼此的工作進度，因為是做相同的User Story，所以都是互相有相關的，知道狀況，配合進度才不會有空窗，這個會議的目的在這，而不是討論這件事要怎麼處理。

這是其中一個目的，之後有別的狀況再提別的，怕一次提太多，大家會吸收不了，我這系列也是有教育意義的。說回來，一個會議花了半個小時，倒楣的人全都要參加，一個早上就沒了，就花在這會議上，重點是，他是"DAILY"，就是你有可能每天都要耗在這FUCKING DAILY MEETING上，世上沒有比這種鬼打牆還令人沮喪的了。

一個追求敏捷開發的模式，卻被人亂用成這副德性，情何以堪。這還是導入期，到了完全期……我真不敢想像，還好我們跑的Scrum很成功，吁～

【課後複習】Daily Meeting的目的之一在於讓所有小組成員知道彼此的工作進度，知道彼此狀況，配合進度才不會有空窗

【腦殘遊記之我也懂Scrum】sprint 0

在網路上看到了別人寫了scrum多好多好的文章，心中不免也想做平衡報導，這世界要是只有說Scrum好的文章，就太不對勁了。

當然不是說Scrum不好，而是要知道，制度是死的，人是活的。活著的人會把死的東西搞成怎樣，你永遠無法想像，透過分享的例子，來瞭解Scrum是如何被扭曲成莫名其妙的怪物折磨人，以此為鑑，讓想跑Scrum的人能避免重蹈覆轍，我真是佛心來著。

要先說一下，這是朋友的例子，絕對不是我的例子，我們跑的Scrum可成功了，還被拿來當案例分享，所以如果有似曾相識的感覺，那一定是巧合。

今天只是前言，先來說明一下什麼是Scrum。

這就是Scrum。真偷懶。Scrum是軟體開發的一種方法，透過短期的開發週期（2到4週）檢視開發有沒有延誤或偏差，這樣一個週期，叫做sprint(衝刺)。就像玩橄欖球一樣，經過一次次的衝刺將球帶近對方球門(目標)，直到達陣。

首先，由客戶跟產品負責人列出他們的需求，稱為User Story，而小組則評估選擇適合的來做。客戶不見得是真的客戶，是泛指有需求的人。

接著，就是將客戶提的User Story拆解成實際的工作項目(task)，評估出時數後，由小組組長(稱為Scrum Master)判斷是否合宜(有無高估或低估)，就進入上述的sprint。

sprint中，每天會有Daily Meeting，填寫昨天對task的工作時數，檢視小組成員的工作進度，如有問題也在這個會議中提出，問題由Scrum Master來排解。這個會議講求快速，要求站著開會，將該講的事講完就結束，不拖泥帶水。

每個sprint結束，會有評審會議及回顧會議，評審會議是讓各小組向其他人(小組、產品負責人、甚至客戶)展示自己的成品並評分。回顧會議則是每個小組的檢討。

之後，又回到選擇下個sprint的小組工作，就是一開始提的User Story。

透過短期的工作週期，以及固定的評審及回顧會議，來檢視專案進程是否延誤，也可以為上個sprint做不足或客戶不滿意的地方及早改善。

是不是很完美呢？讓我們繼續看下去。