Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 五月 2011

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 日 at 17:02:41

張貼於未分類

Tagged with

Flipboard: 讓你的網頁變得美美的

leave a comment »

Flipboard: 他能夠讓你經常看到的網頁變得美美的

看過 Flipboard 網站嗎?

2010年1月,Flipboard公司成立。如果你沒看過他的網站, 那你真得還有很大的視覺享受可以體驗了…,創始人是邁克•麥丘Mike McCue,說真的我也是為了他才買iPad2的(因為他目前只能在ipad 上執行)。

Flipboard是一款專為iPad開發的雜誌閱讀應用程式,它利用iPad的觸控式螢幕為使用者介面創造了無與倫比的使用者體驗。

上面這張圖是我每天在看的 facebook,說真的實在不像,太像雜誌了,簡直是美極了(請原諒我拍得不美)。整個UI都被Flipboard 重新編排過了,至於為什麼他要這樣做,下面是他的說詞:

“試想一下,如果網路在颶風中被摧毀了,我們需要從頭開始建立一個新的網路。那麼它應該是什麼樣子?會跟之前的網路有怎樣的不同?使用者介面是怎樣呢?仍然會有流覽器嗎?如果你擁有今天的知識,知道技術發展到了哪裡,也知道它未來的可能方向,那麼當你建立了一個全新的網路時,你會做哪些不一樣的東西呢?”

然後. . .,這就是我們現在看到的了,他讓Facebook 長得不像 Facebook,基本上就是美化了。他的核心理念如下:

“我們確定了幾個核心原則:我們認為,網路的未來絕對是建立在社會化媒體基礎上的,我們還決定創造“美”的東西,堅守不隨時間的變化而變化的平面設計原則。我們希望創造美麗的東西,在視覺上它應該比我們以前見過的網頁更加漂亮。”

可惜的是他以iPad為平臺,因此採用微軟Windows notebook的夥伴是看不到的,所以我才要寫這篇文章,趕快去看吧! 因為他(Flipboard)讓從事設計網站的朋友,看到別人努力來改變我們自己所設計的網頁,讓他變得美美的真實結果。這是經常從事網頁設計的我們應該要檢討的。

說穿了,這是一種極為成功的思想實驗,原由就好像iPhone及 iPad所帶給大家的視覺衝擊一樣,就是簡單又優美。但他也確實地為我們這些從事Windows 作業系統的網站設計人員明確的上了一課,也就是你無需從新設計,你的網頁我也可以幫你變得美美的,至於何時Fipboard要 跨平臺真正運作在 Windows 上呢?! 其實這只是時間早晚的問題,不久的將來那種極簡單的操作模式和優美的外觀都將是任何網站都不可或缺的了。

說真的;我是因為看了這個網頁才急切地在iPad2 還沒在台灣上市之下就決定先買的。而現在;為了從事雲端的工作,我的桌上多了Mac Pro 和可以跑Android 系統的notebook,這種轉變讓我感覺到,人一旦立足點不同了;跟著的視覺也就會打開來了;許多架構及思維也都跟著變了。漸漸的可以稍微的體會到這幾個作業系統之間的差異,真是讓人興奮不已,因此這一陣子都埋首於書房(很少騎車,請車友見諒! 恐怕還要忙好一陣子~)。同時;也希望從事Windows開發的同好,都能打開視窗的界限,迎接雲端的未來。


有興趣的人可以參考
Youtube 上的影片

Written by ruddyllee

2011 年 05 月 01 日 at 22:47:47

張貼於未分類

Tagged with