我是王泰瑞

這篇又不講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 ，於是經過一番討價還價...