我是王泰瑞

Unit test and singleton from Terry, Chuan Yin Wang

這是今年的Agile Tour Taipei的投影片 我負責的是第一天最後一場的一個小小Session 很高興能認識一大堆志同道合的夥伴 下次有機會再上台～～ 我們是怎麼搞砸scrum的? how did we screw it up? from Terry, Chuan Yin Wang

如何與不同風格的軟體開發團隊合作 from Terry, Chuan Yin Wang

Before projectbegins2 from Terry, Chuan Yin Wang

Before projectbegins from Terry, Chuan Yin Wang

軟體專案如何做估計 from Terry, Chuan Yin Wang

Software101 from Terry, Chuan Yin Wang

1.        用敏捷開發等於加速開發時程嗎 ? 不． agile不能加速開發，但可以早一點看到可以動的prototype． 2.        為什麼要用敏捷開發 ?  別的方法不都好好的用了幾十年了 ?  為什麼要改 ? 因為世界變得太快，軟體需求一定會改，傳統的方法對於處理改變這方面比較弱； 也可以參考 stacey matrix: (from: https://www.capgemini.com/blog/capping-it-off/2011/06/paving-the-path-of-scrum-adoption-2-product-people) 縱軸是requirement的改變程度or 不確定性 橫軸是對開發工具或語言或平台等等的掌握程度 假如是simple，用除法來管理進度，像是鋪路． 假如是complicated，用waterfall來做，還勉強OK． 很遺憾的， 在現在的世界，軟體專案都大概是complex或是Anarchy的等級的 3.        如何做估計 ?  估計不準怎麼辦 ? 看這篇  http://www.slideshare.net/doyouknowsoftware/on-estimate 估計不準是正常的，估計是為了讓我們能根據結果採取對策． 如果有人說，你們這些事情我早就都算好了，之類的，會很糟． 團隊有小孔明的話，那很糟糕；假如團隊老闆是小孔明的話，那就塊陶啊． 4.        何謂 Big Design Up Front?  是好是壞 ? 在前期做了太多的設計與討論，白白浪費珍貴的開發時間，不管是spec, UI, UX等等． 當然是一件不好的事． 5.        在敏捷開發裡面，系統架構怎麼定 ?  由誰訂 ? 由所有人針對這一個sprint要完成的PBI的架構一起訂． 下個sprint要改的話，就改啊，所以design pattern很重要． 6.        與硬體的開發時程如何搭配 ? 在EVT DVT PVT MP各階段，PO要決定軟體要做到哪些東西，也就是把各個需求做priority． 至於是軟體去配合硬體，還是硬體來配合軟體，我覺得要看專案

純屬個人心得與筆記，不一定正確。 只能意會，不能言傳阿。 1. Singleton Pattern 用來做某某某Manager的時候，可以使用。 需注意 Thread-safe 2. Strategy Pattern、Factory Pattern、Abstract Factory Pattern 當switch case很長的時候，可以看情況使用。 3. Observer Pattern 當某一個物件或Thread需叫另外一個物件或Thread做某件事，且必須等待這件事情的結果，可以使用。 4. Command Pattern 當某件物件要另外一個物件去做事的時候，可以使用。 5. Facade Patten 念作"法薩"，當有一個寫得不是很好的物件，而使用他時，大概就是那幾種操作，可以考慮使用。 6. State Pattern 處理State的時候可以用。

這篇又不講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

對於台灣的團隊來說，在導入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 之後，就一直想把一些東西整理整理寫成文章，一方面是複習，另一方面也是跟自己對話。 當然，目前的我還是在公司裡面寫程式，不是專業的顧問，所以，寫的東西，可能層次沒那麼高，但希望會比較貼近實際現在的軟體開發現況。 所以，希望能幫到一點人囉。 加油。