我是王泰瑞

這篇又不講scrum了，結果說好要寫scrum的，關於scrum的文章卻沒幾篇... 在Clean Coder這本書裡面，聊到了估計，寫得超好的，用這篇文章把它簡單介紹一下。  要講數學囉~~~~ Blogger打數學符號不好打，大家加減看。 PERT法 ( Program Evaluation and Review Technique ): 簡單的說，就是對一件事情或是一個任務作估計的時候要給三組數字： 極樂觀的估計 -- O 一般的估計 -- N 極悲觀的估計 -- P 在樂觀與悲觀的估計，都是假設發生機率在1%之下的情況。 得到這三個值(O，N，P)以後，我們就可以來估計了。 期望完成時間 E = (O+4N+P) / 6 標準差  stdev = (P - O) / 6 得到這兩個值以後，套用統計的理論，在正負一個標準差之內的機率是68%，在正負兩個標準差之內是95%，以Clean Coder書上的例子，E是4.2天，stdev是1.8天，所以很有可能可以在兩個標準差之內，也就是4.2 + 1.8*2 = 7.8，約八天內做完。 假如有很多事情的話，就把這些東西加起來算一算。 總期望完成時間 E_total = E1 + E2 + ... +En 就是把每一項的E值加起來的意思。 而總標準差 stdev_total = sqrt( stdev1^2 + stdev2^2  + stdev3^2 + ... + stdevn^2 ) 就是把每一項的stdev的值，平方，加起來以後開根號。 然後，就可以拿著這些數字(E_total, stdev_total)去得到兩倍標準差內的值是A天，而一倍標準差之內是B天，就大概可以跟老闆說，我們估計在這些東西，95%的機率下，可以在A天內完成，而65%的機率下，可以在B天內完成，簡單清晰明瞭易懂，我相信老闆會對這個員工大大的加分。 這太帥了，不是嗎？ 估計是準確的嗎? 不是。 所以估計不準的話，真的是正常的。 但不要忘記，估計是為了讓我們能採取相對應的行動。 結論 我有兩位前同事，一位是PM一位是業務，兩方似乎為了估計而鬧得非常不愉快，可是兩位都是我的好朋友，真的很可惜...

這篇文章先不講scrum了，先講一下我自己看軟體開發的一些經驗，而這些經驗應該是可以增加軟體專案在時間內deliever的機會。 1. 越早開始越好 專案一開始還在cook的時候，就可以先做一點事情了，就可以先做一點prototype了，千千萬萬不要等到spec出來了，才開始施工。要用盡全力避免 BDUF (Big Design Up Front)。 除非你的專案是很大超級大無敵大的那種，比如說太空梭專案、高鐵專案或是核能電廠的專案，一開始沒想好就可能會死人的那種。我是說真的，人會過世或是造成整個國家社會動盪不安的軟體專案那種。你手上的網站、 App、遊戲或是device的軟韌體的Spec更改了，是會死人的嗎？ 還有... 到底是誰說有了spec才可以開始動工的？ 2. 寫越少的code越好 恩，不解釋，這好像是廢話。 3. 做越多的測試越好 恩，不解釋，這好像是廢話。 但是第二點跟第三點好像是衝突的喔？測試越多品質越好，但也會找到很多bug，要修這些bug，就必須要在原本的code上面加上一點code，那就跟第二點衝突了。所以這是很有深度的。 解決方法是使用TDD。但TDD真的不容易啊。  4.把權力下放給團隊 工期給它們估計，進度給他們自己掌握。你需要一個自動自發的團隊來做這件事，如果沒有的話，一個有經驗的scrum master或是，至少，有經驗有熱血的資深工程師都可以幫助塑造這種自我管理的氣氛。 不要再找PM來管理團隊了，團隊真的可以自己管理自己。 5. 擁抱改變 所有團隊成員都要知道，這樣做軟體的話，會有很多白工，也很多re-work。某一天，大家會士氣低落，因為覺得：e04，又要改了。 這是正常的，目標是持續的做出老闆或是客戶不要的東西，才能知道甚麼是老闆跟客戶要的東西；而以這些不要的東西作為基礎，打造出正確的東西會更快更舒服。 所以要 擁抱改變 阿！  以上，一點小小個人意見。

在 擁抱改變 這篇文章中，我稍微聊到了傳統專案做法中，抓時程的方法。 我打算用這篇文章來稍微聊一下在scrum中，對"估計"這件事情的看法。  先來玩個小遊戲好了。請大家看下面這張圖：  (圖片出處：http://hdw.eweb4.com/out/440195.html) 好了嗎？開始囉~  -------------------------------------------------------------------------------------- 第一題  請估計紅色圈圈的大樓跟綠色圈圈的大樓的高度，單位請用公分，沒錯，是cm。 第二題  請估計紅色圈圈的大樓跟綠色圈圈的大樓的高度，這次請把地下停車場的深度一起估進去。 單位一樣是公分。 第三題  請問，畫紅色圈圈的大樓是綠色圈圈的大樓的 幾倍 高？  包含地下停車場呢？紅色框框的大樓是綠色框框的大樓的 幾倍 高？  好的，玩完了。  -------------------------------------------------------------------------------------- 哪一種估計比較難？假如你找十個人玩這個遊戲，哪一題的答案會比較一致？ 這個遊戲我第一次玩的時候，也很驚訝，希望在電腦前的你也有同樣的震撼。 我自己的感覺是： 1. 用無意義的單位來估計，是無意義的。 用公分來估計大樓的高度，就好比用(人-天)來估計軟體feature或bug的loading一樣。 假設，一個bug估計需要10人-天，我找5個人來，assign這群人這個bug，兩天以後，這個bug就解掉了嗎？那如果我找100個人來呢？ 2. 絕對 vs 相對 在傳統的做法裡面，總會有一個人跳出來說： 以我過去的經驗跟目前專案成員的能力，我估計這個專案至少需要四個月的時間。 說這個話的人可能是PM，可能是資深的工程師、架構師之類的，糟糕一點的話，可能會是業務，總之是個說話有份量的人。於是，他說了，老闆就聽了，團隊也聽了。然後大家再抓一下debug的時間，再抓一下buffer ，於是經過一番討價還價...

確定大方向，修改小目標 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...