我是王泰瑞

確定大方向，修改小目標 scrum 是以經驗法則(Empirical)為主的開發方法，在開發過程中，每個sprint做出來的potentially shippable有可能很棒棒，也有可能評價不高。所以跟打橄欖球一樣，每一次進攻、推進的路線、節奏跟戰術必須要一直修正，最後，才能達陣得分。 雁子南飛 在certified scrum master的課程上，老師(至少我那位老師)用的例子是雁子往南遷徙過冬，那些鳥其實只是要找到符合三個條件的地方： 夠溫暖 夠安全 食物夠多 於是，它們每天早上起飛，黃昏降落。每天它們都在觀察(Inspect)四周環境，是不是夠溫暖、夠安全跟有沒有足夠的食物，然後它們做出決定(adapt)，看是要繼續往南飛，還是就在當地過冬。 假如不透明，這些雁子就不知道他們飛到哪裡了，是不是夠溫暖、夠安全跟有沒有足夠的食物。 很有道理吧，不透明怎麼知道飛到哪裡了？怎麼知道自己是不是飛到北京，明天就變成北京烤鴨了？ ...好啦，我知道雁不是鴨，但大家懂我的意思吧。   In scrum framework... 在 上一篇文章中 ，聊到了三個方向的透明度： 主管對下屬 下屬對主管 同事之間 有了這三個方向的透明，基本上團隊會在對的方向跟士氣上做事，然後，這一篇再繼續講一下透明的重要，尤其是在scrum框架下。 scrum框架規定了很多個會議，要這些會議發揮到最大的功效大家就要做到三個方向的透明。還記得sprint planning meeting嗎？假如團隊不敢跟PO說，我覺得妳這些東西我們一個sprint做不完，那最後一定是喇掉。還記得daily stand up meeting嗎？假如不好好sync，別人的東西可能會跟你的打架，又要浪費時間去修。還記得sprint review meeting嗎？假如PO或是其他stakeholder不好意思把覺得怪怪的地方說出來，那最後成品也是喇掉。還記得retrospective嗎？假如大家不敢指出彼此做得不好的地方，最後團隊也是在互相忍耐而不會進步。  有話就要大聲說阿。 scrum框架的每一個會議都是在蒐集feedback，讓整個團隊能inspect，因為大家都不是笨蛋，不是白痴，大家會想出一些方法(adapt)慢慢地去改正做得不好的

不透明，毋寧死。 在軟體開發團隊裡面，不管是不是scrum團隊，透明度都是很重要的。在台灣，很多主管或是同事們為了保住自己的位置或是地位，會努力的不透明，於是有人想知道些甚麼 東西 ，就必須去拜託這些少數的知道的人，這些 東西 包括，對方的程式的運作方法與邏輯，團隊的目標，或是接下來的部門的road map，甚至聽過連deadline都是假的或是不公開的。於是團隊營造出一個又一個的 information gap，知道的人就好棒好厲害，不知道的人就必須要低聲下氣的去問，才能做事。 這是很不健康的文化。 Impact of being opaque? 我想用很短的篇幅跟負面列舉的方式，來講不透明的影響。 主管對下屬不透明 所以很多事情只有主管知道，要知道就必須去問他或是去拜託他講。"朕不給的，你不能要"、"一個口令一個動作"。在這樣的長官下面的人做事會很痛苦，除非是智力很低，或是當兵的情況就沒問題。 這是一種統治術，但是是很糟糕的那種。 做軟體不是當兵、也不會找一堆智力很低的人來做，用這招來管理團隊...也不是不行啦... 下屬對主管的不透明 這也常常見到，尤其是老闆是不懂技術的團隊尤其是這樣。 比如說：一個bug可能只需要4小時，可是如果老闆不懂，就可以跟他說：喔，幹，這bug很難耶，可能要一個禮拜，但我知道schedule很緊，我盡量三天把它修好。於是老闆對這傢伙大加分，這傢伙得到了兩天多的時間打混摸魚。 這對專案好嗎? 平行同事間的不透明 阿，辦公室文化。 在同事之間的不透明，情況輕的，大家會做到同樣的重複的事情。比如說，取得local IP address，因為相對的簡單、又常常用到，就有可能由不同人寫了好幾份，分散在各處。這是一種浪費。 情況嚴重的，會一山不容二虎。也就是一個團隊裡面會只有一個大當家、山大王，任何會威脅到他的地位的人，都會被弄、被排擠，所以一個團隊裡面只有一個強者，就算HR或是主管找來了多強的幫手，經過一陣腥風血雨後，總會默默的認輸或離職，公司永遠留不住新來的強者，這個專案跟部門永遠是XX幫的地盤。在這裡，二當家是頂不上來的，因為大當家會壓住他不讓他出頭，直到某天，大當家離職了，專案跟公司也受到很大的傷害與損失。 Con

<這篇是個人心得> 我認為一個好的programmer應該具備某一些特質，假如有這些特質的人浸淫在agile的環境中，又會給他另外一些特質，就變成了一個好的agile programmer．

其實這應該是第一篇才是 XDD scrum是英式橄欖球的術語，我也不知道為什麼大師們要用這個詞來稱呼他，反正打橄欖球麻，就是要贏球麻，要贏就是要得分麻，要得分就是要達陣麻，要達陣就是要一步步的一尺一寸的努力的往前推進，整個隊伍撞啊擠啊的，整身是血是汗的，然後達陣得分． 在這樣的情況下，團隊裡面是有凝聚力的，是努力往前進的． 開發軟體也是一樣，團隊裡面 不應該 有人只會打嘴砲， 不應該 有人閃事情， 不應該 有人不負責任的指責對方， 不應該 有人在團隊裡面搞政治權謀．因為大家的目標是一致的，來打球就是要贏球，來開發軟體就是要把軟體寫出來上線． 如果你發現你現在的開發團隊有以上講到的" 不應該 "，請你要非常非常非常小心． 好吧，我承認，其實，開發軟體跟橄欖球並不能完全類比，大家不要誤會了，所以到底什麼是scrum咧？ scrum is a development framework. 換成中文就是，scrum是一套開發框架．他不是流程，也不是一套系統，目前大家可以先把它想成是一套開發流程吧，但他不是流程喔喔喔喔，我們最後再慢慢解釋吧． sprint的概念 scrum把開發的時程切成一個一個單位，通常以1到4星期為單位，這樣的一個單位叫做是"sprint"．就好比是橄欖球裡面的每次每次往前推進，軟體也是要每次每次的往前衝刺． 至於為什麼需要sprint，為什麼是1到4個禮拜，sprint的長度要怎麼選擇？ 先這樣，不要寫太多，不然這篇文章會不小心變一本書． Iterative and incremental 有了sprint以後，團隊在每個sprint要重複的(iterative)開發軟體，每次開發完產出的軟體都要是完全測試過的，假如今天老闆說”好！出貨吧！“那應該隨時都有ready的東西出貨，這個ready的東西簡稱是potentially shippable，全名是Potentially shippable product increment． 看到increment這個字了齁，所以，這個sprint結束後的產出物是應該奠基於上一個sprint的產出物，但是再加了一點點功能或是修好的bug，每次每次加上去(increment)，直到某一天這個potent

對於台灣的團隊來說，在導入agile, scrum的過程，會遇到以下幾個問題，先大略寫一下，以後有空再詳述。 1. 公司內的政治問題 比如說，有設計部門，有App team，有framework team，有BSP team，有QA team，要跟這些部門的老闆以及他們的老闆說："我們來玩scrum吧，從你的部門拉兩個人給我"，那是多難的一件事。 2. Waterfall的遺毒 其實去上CSM的課程就有講到， Tyranny of Waterfall，大家都在Waterfall模式下作太久了，根本轉不過來。 3. 每個人都在尋找標準答案 在台灣，從小的教育就是教我們找出標準答案，但出了社會上了班，根本都沒有標準答案了，只有好與更好，覺得做事方法、流程等等不對勁了，自己要想辦法反映、解決或改變，要自己去做而不是老闆交代了才做，但很多軟體從業人員自己都沒有這種認知。 4. Rock Star 心態 台灣人大概是工作狂吧，大家都覺得把部門的工作攬在自己一個人身上，是很強的，很受尊敬的，但真的不是的！各位，你們需要的是一個團隊，是一群在錄音室裡面默默的、不求出名的、願意努力的反覆的把音樂做得很好的一群樂手。 5. PM是偉大的存在 事實上在 scrum框架 裡面，PM們，你們根本沒有工作，你們要扛起更大的責任同時下放更多的決策給你的團隊，這樣的角色叫做Product Owner (PO)。 曾經有人跟我說，PO跟PM只是名稱不一樣，只是玩文字遊戲而已，但其實不是的，PO領導著團隊，也被團隊領導．而不是："我是PO，所以你要聽我的"。 很多台灣公司，在裁員的時候，都先砍QA、然後RD、然後HR，PM是很少被砍的，但其實在做軟體的時候，PM的工作是最容易被取代的，假如PM一直以為自己高高在上，沒有辦法把自己的心態降下來，為團隊服務的話，那這樣的PM，說真的，應該優先被砍。 Conclusion 導入agile或是scrum的時候，心態的改變是很重要的，在好的scrum team裡面，大家會很快樂、很有士氣，每個人都可以專注在自己的事情上，那是多棒的境界！但是心態改不過來的話，自然會報著否定的態度來看這一切事情， 指著別人說，你那個scrum方法根本亂七八糟，怎麼可能work，最後還是回到老

真害羞，動不動就擁抱。 但是在做軟體的時候，很難不改變的。先來說說傳統瀑布式開發的做法。  Waterfall 在傳統的瀑布式開發法，一個專案會被切成需求分析、設計、開發、測試，有時候 前面還會加個cooking，後面測試又還有phase 1、phase 2等等，假設一開始，kickoff的時候，專案被估計是一年，可是最後總是會、常常會發現專案delay了，為什麼？大家指來指去，都怪他他他，所以delay了。 面對delay這件事，PMP會教："抓buffer"，於是一個stage就抓一個buffer，怎麼抓？怎麼決定buffer要抓多久？                        "猜" 多感傷阿，一群受了這麼多教育的人，面對問題還是在猜。 Root cause 抓Buffer是一個消極的解法，真的的解法是找出問題，去解決、或至少面對真正的root cause。而真正的root cause是：需求改變了。 承認吧！在開發時程中，需求總是會改變，不知道為什麼，反正他就是會變，假如有公司有軟體專案開始到結案，需求都沒有改，那這間公司已經倒了。 Deal with it !!! 面對需求的改變，通常有兩種做法： 1. 用合約、spec來不讓改變發生 需求改變的時候，會發生三種現象： 業務端會去跟客戶吵，"大家把合約攤開來看阿" QA/RD/designer/architecturer也會去吵，"大家把spec拿出來看阿" PM會被狗幹 整個團隊陷入一種不和諧的狀態，與客戶的關係也不會太好，在這樣的情況下，基本上，所有人都是抗拒的、不愉快的，要在這樣的情況下做出好的軟體無異是緣木求魚。 於 是，有人會說，一開始就要想得好一點、想得透徹一點，一切都想好，把所有變數都考慮進去，就妥當了。但這不是火鳳燎原，這種八奇是不存在的，就算有，他也 在google、facebook等等大公司上班了，不會龜在你的公司。相信我，假如在軟體專案裡面有人說，所有的事情我之前都想到了， 我都準備好了，那只是聽起來很安心，跟這樣的團隊成員合作，你104可以先開了。 2. 直球對決 既然會下雨，那你就帶雨傘阿。既然會改變，那就

其實拿到certificated scrum master 之後，就一直想把一些東西整理整理寫成文章，一方面是複習，另一方面也是跟自己對話。 當然，目前的我還是在公司裡面寫程式，不是專業的顧問，所以，寫的東西，可能層次沒那麼高，但希望會比較貼近實際現在的軟體開發現況。 所以，希望能幫到一點人囉。 加油。