發表文章

目前顯示的是 3月, 2015的文章

Clean Coder的估計

這篇又不講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 ,於是經過一番討價還價以後,專案的時程可能就訂在六個月了。 很熟悉對吧。但是,為什