Ruddy Lee 分享空間

Emergent Design 演化設計

Scrum 如何估算專案開發的時程?

with 3 comments

Scrum 如何估算專案開發的時程?(有學員問了這個好問題, 這通常都是老闆們才會問的問題)

Run scrum時;如果你想了解一下專案大概要花多少時間來開發的話(每個老闆都關心這件事,那就來試試這個吧! 我都是這麼做的)。

書上沒有教如何畫甘特圖以及怎麼做系統Break down,那要如何來估算專案開發的時程?

(一定要再看這篇https://ruddyblog.wordpress.com/2012/07/ )

書上只有說道:先衝刺一次就會知道,如果還不知道,那就再衝刺一次,落實做好Scrum的會議(Sprint計畫會議、每日站立會議、Sprint結束會議還有Sprint檢討會議)及 Sprint 的時間盒管理,結果就會自然浮現(也就是Emergent design囉)。

嘿! 約耳不要再開玩笑了…

(約耳所謂的無痛軟體時程run Scrum的團隊一定要參考一下🙂
參考: http://chinesetrad.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html

這一點,尤其對資訊界的新人而言,如果你不明講,還真是一團迷霧!

(所以我一向都用以下的分析手法教他們一些基礎的劍招 —- 說穿了就是【畫圖】(老實說Run Sprint 時那有時間來畫圖ㄚ!), 這是一些簡單到不能再簡單的分析及時程預估法則,但學會了以後還是得想辦法忘掉才成…)

此時;張三豐的箴言又浮現出來了:『…無招勝有招』,但是話說,你還是必須從基本的招式開始,等到一切招式都記熟了,才有本錢可以忘記那些死記下來的動作,融合成為真正屬於自己的劍術。這段話的意思是,那些基礎的東西,你懂得越多自然是越好的(例如: OOAD是甚麼?),就更能融會貫通在自己的本質學能中,也就能夠自然而然地成為你的內功基礎了。

閒話表過,接著我們來談一些基礎到不能再基礎的劍招:

步驟一、運用HIPO (Hierarchical Input Process Output)的分析技術將抽象的Use Case描述,利用將輸出入明確隔開來的圖示法,從其中分析出流程(Process)及各個大的模組(Module) 區塊。這是起手勢,練的熟練了對專案的了解就越快進入狀況。

步驟二、依據 HIPO 畫出功能圖(Function Diagram),將各個大的區塊再breakdown成更小的區塊,讓它可供較明確的討論使用,或甚至breakdown 到可以開始撰寫程式的模組為止,再來進行工時的估算。此時;專案的概略開發時程就可以浮現出來了(視專案的大小,以每天或每小時為預估的單位)。

步驟三、再依據 Process的部分劃出順序圖Sequence Diagram或流程圖Flow Chart(專案很小時採用順序圖,較大的專案就要靠流程圖了),藉以明確化測試案例(Test case)。這是最有趣的一個步驟了,當你開始寫測試案例時,通常你又會回去改上面的步驟一、二的HIPO圖示及Function diagram了。這是對得、也是好的一部分,就因為這幾個東西的相依性,讓我們足以反覆的思維自己所畫出來的圖示是否合乎邏輯,當然也可以拿來驗證這個 use case 的合理性,這是相當值得的。

至於得到的專案預估時程,則僅供參考了,這是做給雞看的(Scrum的老故事了,老闆是雞,開發人員則是豬: http://zh.wikipedia.org/wiki/Scrum)。

註:
1. HIPO (Hierarchical Input Process Output)
IBM用了幾十年的老東西了,原始文件檔如下:

http://es.wikipedia.org/wiki/Hipo : 這一篇Wiki 的說明網頁談多了些, 但多加的那些東西是為了彌補HIPO的缺陷才衍生出來的。(HIPO的一些缺點,例如: (1)無驗證功能,造成功能的完備性很難被驗證。(2)未能反映系統性能要求。(3)遇到規模大的系統會產出大量的資料,不易維護。)

2. 功能圖Function Diagram
適合專案初期拿來分析會用到那些技術?會產出那些個模組的相當簡單的模組方塊圖。
這是由抽象的討論或模糊印象的輪廓下,轉化成為比較具體、較明確化的第一個步驟。通常這種採用一個一個模組來估算個別工時,再一起加總起來的方式,所得到的估算值都會比最後結果要長一些,這是因為估算的時候依據半天或小時來計算下所產生的誤差。

3. 順序圖Sequence Diagram
順序圖有很多優點,它能夠清楚的描述事件的順序,也顯示了什麼時候物件被建立和銷毀,在操作的容易被了解上表現得很優秀,更重要的是它能夠捕獲事件之間的競爭條件。然而雖然有這麼多優點,但老實說它們也不是完美的工具,因為它太占空間了,只要多幾個狀態,畫出來的結果就會複雜的一踏糊塗,根本沒辦法看,而且也不能很好的表示協作物件之間的相互關係。所以盡管順序圖是強而有力的,但我仍然認為密集而潔簡的流程圖更令人愉快。

4. 流程圖 Flow Chart or Activity Diagram
用來來描述工作流程,業務流程和其他的程序。它夠簡單且易讀易懂,是人們用來相互溝通流程的好圖示。

UML活動圖Activity Diagram: http://www.dotspace.idv.tw/Jyemii/umlcolumn/articles/umlwriting/tipuml05.htm
http://translate.google.com.tw/translate?hl=zh-TW&langpair=en%7Czh-TW&u=http://edutechwiki.unige.ch/en/UML_activity_diagram

Written by ruddyllee

2011 年 05 月 20 日 於 17:02:41

張貼於未分類

Tagged with

3 回應

Subscribe to comments with RSS.

  1. 哈!用功的主管來電:「這樣估算出來的專案時程準確嗎?」
    __
    會準才怪!
    —-
    這樣的估算,對工程師而言,就是一個product backlog的create及breakdown練習罷了,只是讓評估專案工時的技術稍微符合邏輯些而已,當然也有助於專案周遭各項事務的配合作業,讓準備開始實作之前提供我們有機會可以更客觀的來審視整個專案的架構。
    對主管而言,則可以有一個概略的時程觀念,便利進行專案的控管作業。
    __
    其實;在第一個sprint開戰之後,Burndown chart 就會一直跟大家報告進度的。而且;進度會比這樣估算出來的結果,好上很多很多的~
    別忘了! 熱情比加班要有用多了~

    ruddyllee

    2011 年 05 月 21 日 at 10:44:17

    • 當成目標來參考,也是不錯的~總要留點Buffer來做緩衝~

      Edweard

      2011 年 12 月 14 日 at 02:10:32

      • 是啊,參考目標是很重要的開始…

        SCRUM 是相對的,這一點讓我突然想到衝鋒槍掃射及洩光彈的故事。
        衝鋒槍因為瞄不準只能靠掃射來逐漸接近目標;它只適用於白天,而洩光彈則適用在夜晚,他用磷來點燃飛行的路線藉以判斷指向目標的路徑,他們都是能慢慢趨近目標。

        盡快尋求一個參考點是好的開始!

        ruddyllee

        2011 年 12 月 14 日 at 09:50:19


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: