Kenming’s 鮮思維

上上個星期，應國防某單位要求，希望由我們利用 EA(Enterprise Archiect) UML 工具，藉由一個案例，來展示在順應 DoDAF 規格下，如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖，以及又該如何導出到實作，尤以後者，對他們很困擾，一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具，因為 EA 其中一個 Plugin 產品，稱為 MDG for DoDAF-MODAF，兩者的搭配，應用的是 UML Profile 機制，可以充分完整支援 DoDAF 1.5 的設計規格。 說真的，工具沒啥好介紹的，況且席間諸多長官與教授們問最多的問題就是有沒有 『自動化』 的機制，可以從某一個 View 的設計圖，自動轉化到另外一個 View 的設計圖。這個… 我總覺得他們研究的方向會不會有問題？ 我只能反問：1. 如果規則明確，例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話，那麼工具當然可以支援。 (可想而知的答案是，當然沒有那種必然明確的規則) 2.能不能轉到程式碼？ 這些我都覺得都不是問題耶，前提是有沒有那種確定的規則？ 有趣的是，他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具，也沒有支援他們 『心目中』 的自動化啊。 所以我開玩笑的說，好吧，把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價，用來委託我們開發那個自動化的 Transform 機制，保證可以幫你們生的出來，不過前提是要能給我們明確的轉換規則。

我可不會想賺工具的錢啦，要能懂得設計符合 DoDAF 架構規格的系統，要具備的是軟體設計基礎功夫的底子；要能有整體性的架構觀，要知道什麼時候該封裝、什麼時候該打開，分析系統的內部；要懂得如何把一個看起來好像很大的系統(關於系統的定義，可不一定指軟體系統，在這種大格局下，包括企業單位，都可能是一個系統)，該如何大題小作；又懂得那個時候該具焦在某一個焦點上，然後小題大作。 這一種整體性的設計思維，正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是，我們可以協助國防某單位，如何具備能具有規劃 DoDAF 架構設計的技能(Skill)，與相關軟體設計的基礎功夫，以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主，如果可以的話，規劃成一個外包的專案更是好，然後從實作的過程中帶著學習，作中學的效果會更好的。 不過前提是，我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統，一般當然就是出個題目了，這一向是我個人最為意願的了，比較容易在短時間內取得雙方之間彼此的信賴與共識；也比較現實，會就會，不會的話早一點出局，最不囉唆了。 喔，還有，這是繼我十餘年前從志願役中尉預官退伍後，再一次能回到軍中，為國效勞的好機會呢，哈。

由於國防某單位最近忙了些，等了幾星期，還是沒拿出案例讓我們來演練，所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢，這個案例是沒有與軍事任何單位有關連(正因如此，才能拿出來公開分享)，完全是充滿想像；也沒有軍事專家的協助，所以需求必然是謬誤百出。不過這也不是什麼困擾，因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助，那麼就很容易可以調整修正，來符合正確的需求了。

整整花了四天的時間，投入了約 2.3 個人力，以一個我們所想像創造出來的案例，也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統，透過偵測與防衛系統，發現到敵人即將進軍來襲時，是如何即時協同陸、海、空三軍暨後勤補給中心，來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔，甚至連那個表達 OV-1 的概念視圖，都還是請美工畫出來的呢，效果十足！ 老實說，個人對我們團隊能在如此短的時間內，就能規劃出如此大的架構格局，甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 『潘朵拉密盒』，可說是成就感十足，也算頗引以為傲。

圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯！ 在座許多高級長官以及教授們在會後的許多問題透過我們的解說，也算能得到合理的解釋。也讓許多中、上尉的資訊官們，見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的)，所以到是可以藉由公開發表這一個案例，除了展示是如何實現 DoDAF 規格，並大概解釋一下每一個 View 的 精要(essential)設計意涵為何，同時也算是藉由此，來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

繼續閱讀 »

前天星期六 (6/14)我們家蓁妮從「育才國小」畢業了！！

是該高興呢？ 還是該感傷啊？
高興的是，蓁妮長大了，也要邁入青澀少女的人生階段；感傷的是，我心目中那個調皮的小妮子，已經不再是個小孩子了，不容易再跟她一同玩小孩子們的遊戲了 (例如騎小馬、公主抱抱、躲貓貓 …)，說到這，我越來越感傷了。 :.

星期六一大早，我們全家，還有蓁妮的奶奶 (專程從台中趕來)，我開著車先到「育才國小」的校區內 (今天的特別日子可以停車)，在校園內休息一下後，就走到離學校不遠的永和市公所，也是「育才國小」97年度畢業典禮的場地。 「育才國小」人數並不多，今年的畢業班共六班，大約也才百餘人，所以市公所的場地是足以容納同學與家長們。 喔，實在是太早了，雖然八點半就開始，但看來還在入場中，我又不喜歡一開始聽校長啊什麼的講一大串，蓁妮的媽媽她們先過去場地，而我就在隔壁的「丹庭咖啡」點個美式套餐，吃完後還在沙發椅上打個盹，九點多才進場。

典禮開始後，包括校長、董事長的演講 (這是必然會有的，也是我跑去咖啡廳的原因)，還有四、五年級的學弟妹們給予畢業學長/姐們的祝福等。另外我覺得不錯的是，校長是親自頒發給每一位畢業的同學，人人都有一個獎項，這個就不錯。

繼續閱讀 »

常逛 Mobile01 網站，好處是可以知道各種數位產品新知，同時也能看到許多各行各業的能人高手所發表的心得文章。 (缺點當然就是，沒有相當的自制力，你會很想敗家 :no: )

是這樣的，前陣子買了張電視卡安裝放在我臥房裡的電腦，但是在房間內的收訊品質並不佳。先前曾購買了「大通」的強波器，但是效果還是不好，而我買的電視卡應該算是硬壓等級中相當不錯的— 麗臺(Winfast) PVR3000 Delux 電視卡(PCI、硬壓、類比、3D Y/C+去雜訊)，畫面真的慘不忍睹。

後來也就是在 Mobile01 敗家網站看到了這篇：「分享有線電視接頭標準作法圖解」。在佩服作者的技術之餘，也輾轉連到他個人的部落格，才知道作者本人有兼差協助網友檢修有線電視線路。 昨天我馬上就留言，而昨晚本人就打電話給我，約了今天下午到我家來協助檢修設定。

在其部落格是號稱為 『坤仔』 先生，姓陳，人蠻客氣的，我請教他許多問題，都會不厭其煩的說明給你聽，與他相談可說是甚歡。看了我家的佈置，大概就知道我們家是拉大樓的共用線路，然後再從客廳分接到房間的，所以線材是沒有辦法抽換的。不過坤仔先生說最重要的反而不在線材，而是在分配器上，一般預設安裝的分配器都比較簡易，自然接多了訊號也就會衰減了。 結果要找客廳的分配器源頭時，哇，線路竟然是在原來我們買新房子時請裝潢師傅裝的客廳電視櫃內，想說這樣就沒辦法設定了。 還好的是，坤仔先生判斷是在底層收納櫃後隔版那邊，如果拆掉那個薄的後隔版應該可以安裝設定。嗯，還是拆吧，結果還真的線路就位於那邊，設定上就沒問題囉。

坤仔先生三兩下就做好天線接頭，鍍金的，線芯是很堅實的，不像我們在普通電子材料行買的哪種容易凹折的芯，然後再換裝了價值一個要價 NT$500 的分配器 (原先我先在電話上所決定的款式)。哇哇！ 電視打開後，畫質真的清晰銳利很多了，本來有幾台不清楚的頻道現在也都變得很清楚了。 再來就是到我房間，再裝一個同型的一分二分配器，因為從我的房間還有再分接到我家的頂樓去。 啟動那個 WinFast PVR2 的電視播放軟體，當然，在我的 22″ LCD 液晶螢幕上不可能如電視畫質如此佳，但是，比沒有換之前畫面好上太多太多了，有圖為證：

繼續閱讀 »

＊＊＊ 這一次的系統分析課程，是特別經過 HSDc 團隊精心特別設計的，其目的旨於不要讓所謂的系統的需求分析，以及結構設計，與實做的程式碼脫勾。分析與設計絕對是務實的，是要能平衡現實的一面(快速實做出來)，與往理想的另一面(持續讓結構演化重整，捉出最穩定的元素)。

『系統分析設計與實作—活用 UML 塑模 與 Java (５４ Hrs)』 已確定於本星期六(06/14)在「開羅會議中心」開課。目前尚有名額，歡迎有志於學習完整系統分析與實做的學員們踴躍報名。

本課程的編排是有別於傳統一般系統分析(Top-Down 瀑布式作法，無法有效結合實做)，採兩階段的漸增與循環(Iteration)的階段目標開發方式，先求有— 做好需求分析、快速實做、產出程式碼、符合實體三層(3-tier)架構、瞭解系統面的必備技術； 再求好— 軟體結構面的分析設計重整，與程式碼的重構(Refactoring)、確實捕捉領域的概念，成為軟體的主結構企業元件。

報名資訊請參考請至：
http://www.hsdc.com.tw/course_signup/20080614_sa_sd_to_implement_by_java

o 由於本站線上報名系統尚未測試啟用，煩請報名學員填寫下列資料報名 (下列欄位前為 * 者請務必填寫)，並以 Email 寄至： service.hsdc@gmail.com
　　————————————————————————————-
　　* 姓名：
　　* 電子郵件：
　　* 聯絡電話：
　　任職公司與職位：
　　備註(請填上如 ATM 轉帳帳號(後五碼即可)與新生或舊生等資訊)：
　　————————————————————————————-
　o 報名經確認後，本站即會寄送確認通知信給報名學員。
　o 為確認上課人數，以便教材印製，煩請先以 ATM 轉帳預約費用($1000)，並請於報名表備註欄位內，註明您的轉帳帳號末 5 碼與轉帳金額。 ATM 帳號： 新光銀行 (103)　帳號： 0772-50-100979-9

課程介紹
http://www.hsdc.com.tw/course_introduce_sa_sd_to_implement_by_java

※ 課程大綱參考

——————————————————————————————————————–
§ Iteration #1 (36 hrs)
o 課程階段目標： 捕捉系統功能需求，快速設計，立即產出程式碼

一、軟體開發方法論—開發流程與塑模 (6 hrs)
　o 開發模式的介紹
　　o 瀑布、循序的典型開發模式
　　o 漸增(Iteration)與漸進(Incremental)的主流開發模式
　　o 主流開發流程的簡介 — RUP/XP/AGILE
　o 簡介專案開發的工作流程
　　o 專案中各個角色人員的工作執掌
　　o 專案中各個階段的產出(artifacts)介紹
　o 軟體開發的最佳實務
　　o 以架構為中心(architecture centric)的開發
　　o I&I(Iteration and Incremental) 漸增與漸進
　　o 視覺化的方式設計軟體模型 (Visually Model Software)
　　o 需求的變動管理與持續驗證軟體的品質
　　o 侷限與收斂軟體的變動性
　o 軟體塑模— 統一塑模語言(UML, Unified Modeling Language)的綜觀介紹
　　o 利用完整案例導引來介紹 UML 的十三種圖形

二、物件導向觀念養成與應用 (6 hrs)—觀念、模型與程式碼的三面表達
　o 介紹「概念(concept)」與「抽象(abstraction)」的觀念
　o 確實瞭解「類別(class)」與「物件(object)」的區別與關係
　　o 結合(association)、組合(aggregiation)與
　　　一般-特殊化(generalize-specialize)關係的說明
　o 封裝(encapsulation)與多型(polymorphism)的設計觀與應用
　o 瞭解繼承(Inheritence)與介面(Interface)」的設計原理
　o 程式碼範例—
　　o 利用 Java 程式碼表達類別的結構關係(結合,組合,一般-特殊化)
　　o 利用 Java 程式碼呈現介面與多型的設計實作

三、需求面的功能分析設計—Modeling by UML 三劍客 (15 hrs)
　o 建構使用案例模型，實現企業流程的需求
　　o 利用使用案例圖表達系統的功能需求
　　　o 如何界定系統範圍(System Boundary)
　　　o 如何找出使用案例與參與者(Actor)
　　　o 使用案例之間的關係— include and extend
　　　o 利用使用案例圖表達架構觀點
　　o 從表達企業流程(Business Process)的活動圖導出到使用案例圖
　　o 使用案例敘述(Description)的寫作實務
　　　o 如何寫出高品質的使用案例敘述
　　　o 如何依據使用案例範本完成使用案例敘述的撰寫
　　　o 如何表達正常、替代、擴充與例外事件流程的敘述
　　　o 寫好每一條動作步驟陳述的要領
　　o 針對每一個使用案例，撰寫測試案例 (Test Case)
　　o 利用 EA 『Document Generation』 機制產出美輪美奐的需求報表文件
　o 使用案例的實現(Realization)與實作(從使用案例到循序圖到產出程式碼)
　　o 利用類別圖設計與創建 Use Case 控制物件，以實現使用案例的功能需求
　　o 利用循序圖表達程式碼物件的互動設計
　o 利用 EA 『Code-generation』 功能產出控制物件的程式碼框架
　o 測試先行—在 IDE 工具內撰寫該控制物件的測試程式碼
　　o 利用虛擬碼(Pseudo Code)撰寫程式碼內部的細節
　o 實際執行應用程式碼的部署與執行功能測試
　o 利用 EA 反向工程功能，在 IDE 環境內修改程式碼，並反轉(Reverse)回 UML Model。

四、實做面 by Spring Framework (9 hrs)
　o Spring Framework 綜觀介紹
　　o 輕量級(light-weigh)的應用系統容器架構介紹
　　o Spring 在實體 3-tier 的角色定位與架構設計
　　o Spring 重要特性介紹，包括 IOC與相依性關係、Domain-driven 的設計設計觀
　o 利用 JSF(Java Server Faces) 實做 Web Form
　　o 將 UI 與企業邏輯確實分離的基礎設計觀
　　o Web 表單連結至中間層控制物件，實現 MVC 設計樣式
　o 利用 Hibernate 實現永續性機制
　　o Hibernate 設定與實作
　　o HQL 語法與 O-R Mapping 原則
　o 從中間層控制物件連結資料庫
　　o 利用 EA 快速建構資料庫表格
　　o 利用 Java 撰寫程式碼 (從控制物件透過 Hibernate 連結 DB)

五、案例分析與實作 – Iteration #1 (實做部分涵蓋於上述課程內)
　o 利用 EA UML 工具
　　o 實做使用案例模型(Use Case Model)、類別圖與E-R圖、循序圖
　　o 利用 Code-Generator 機制，產出程式碼框架
　o 利用 Java Eclipse IDE 撰寫
　　o JSF Web 表單
　　o Java 控制(Control) 物件 by Spring
　　o Java 資料存取物件(DAO) by Hibernate
　o 利用 JUnit 撰寫功能與單元測試程式碼
　o 應用程式的部署(Deploy) – JBoss Application Server

§ Iteration #2 (18 hrs)
o 課程階段目標： 重構程式碼與類別結構，讓系統更有彈性。

一、軟體結構面的分析與設計 (12 hrs)
　o 運用交易樣式(Transaction Patterns)找出核心交易物件
　　o 從使用案例的敘述中找出潛在的概念物件。
　　o 利用 Peter Coad 的交易樣式(transaction pattern)
　　o 利用 UML類別圖 建構領域的物件模型
　　o 從類別圖產出資料庫表格，並利用 EA 部署至資料庫
　o 物件的責任分派(responsibility assign) — 屬性與行為的分析
　o 活用設計樣式(design pattern)
　　o 合成(composite)樣式的設計 — BOM 表的最佳呈現
　　o Facade and Adapter 樣式，表達在 Control and Boundary 物件的設計原則
　o 進行分析類別(Analysis Class)的設計
　　o Control 物件
　　o Entity (Business)物件
　　o Boundary 物件

二、程式碼的重構 (6 hrs)
　o Java Spring 的進階設計觀
　　o IOC 與 相依性的分析。
　　o Domain-driven 的設計原則。
　　o AOP 對非功能性需求的 crosscut(橫切) 與 Concern(考量)的設計觀念。
　o 分析類別在 Middleware 的實現
　　o 實現 Controller by Java Spring
　　o 實現 O-R Mapping by Hibernate
　　o 實現 企業物件 by POJOs(Plain-old Java Objects)
　o 利用委託(delegate)的設計原則，從控制類別分派責任給企業物件

三、案例分析與實作 – Iteration #2 (實做部分涵蓋於上述課程內)
　o 利用 Eclipse 重構程式碼結構
　o 利用 EA 更新類別與E-R圖，並重新部署 DDL DB Schema 至 MySQL DB 內
　o 利用 EA 實現正反向工程，達成程式碼與 Model 的同步
　o 利用 Iteration #1 所撰寫的測試碼驗證與修正被重構的程式碼

§ 整體開發流程總複習
　o 檢視兩個循環(Iteration)開發所各自產出的設計圖與程式碼
　o 回顧每一個流程開發階段的產出與所運用的設計、技術與技能
　o 學員課程中的問題提問與回答總整理

昨天晚上八、九點左右，我在客廳與我們家小女兒采潔一起瀏覽兒童版的世界地圖集 (共有上下冊)。我們家采潔現在就讀小四，但是完全沒有地理知識，她的同學問她，非洲大不大？ 她還說很小呢。 還有看了「麻辣鮮師」電視劇，采潔還問我說，那個劇中的偷渡客是從那個國家來的？ 我說大陸啊，她還問會不會有其他國家呢？ 嗯 :crazy: ，若是只用口說解釋或文字敘述，小朋友心中肯定是沒啥底。一般說來，地理這個咚咚，就是要有視覺化，然後烙印在腦海中，才會有那個感覺。 這真的需要感謝我國中時代，有個很溫柔可人的地理女老師，她總是鼓勵我們拿張中國大陸的全開地圖，然後上課到某一章節講述該地區的地理、人文時，比對地圖，你就會很清楚該地區的相對位置，而且習慣後，就很容易轉化為視覺化的記憶了。

嗯，「寓教於樂」往往是教導小朋友的好方法。 昨晚我就決定，今天 (6/4)要去買顆地球儀給我們家采潔，讓她以後三不五時，可以看看地球儀，然後觀察看看那個國家是在那個位置上。 爬了 Y拍，決定向這位店家：『 地球儀百貨 』globes 購買。從他們商店網頁的介紹，看得出他們是很專業的批發賣家，價錢想當然爾比在書店看到的要便宜上一截。另外一個原因是，只有他們家唯一有這一款 【最新款兒童圖示版】10吋無夜光型地球儀-中英對照。 摘錄他們 DM 所述：

「特色是有每個地方的代表圖示。陸上動物、海上動物、各國景點、交通工具、水果與植物， 利用圖示、色彩鮮艷增添小朋友對地理的興趣 ；繁體中文與英文對照」

好耶！！ 看來活潑豐富，應該是比較能吸引小朋友的興趣。 今天早上接近中午時就打電話訂購，下午就約在台北我在輔導單位附近取貨，他們家老闆是親自騎著摩托車送貨，相當辛苦。 價錢 (含送貨價)是 NT$1170，是還可以啦，比較過很多家，價錢是不會差到那裡去的。

真的很可愛，質感也算不錯。 字體很清晰，不過字真的很小，我是打算要去買支大的放大鏡，如此就可以很清楚的放大想要過的國家。 這個地球儀最大的特色真的就是那個逗趣的各類的卡通圖示，雖然不多，但也盡量有去凸顯了各個國家的特色，給小朋友當作初學地理的玩具，不錯了啦。 不過，我更看中意另外一個他們最夯的暢銷商品，是 12″ 觸控式點燈，根據美國NASA衛星照地球真實地形數據相關資料，利用明暗的著色方法、數位高科技影像加上立體浮雕獨門成型技術製造立體感，質感看來奇佳的地球儀。可惜要價 三千多大元，實在買不下手。 糟糕，我敗家的潛伏慾望因子又要跑出來了。 不聽，不聞，不看， 趕緊扼至住敗家的慾望吧。 :lalala:

老實說，在我試用過眾多時間管理的工具中，無論是 GTD-based or not，Desktop or Web-based。我還是覺得，FranklinCovey 的 PlanPlus 是目前個人心目中的首選工具。 那為何我不使用它？ 一來我覺得該產品有些小貴，從早期只是紙本的萬用手冊開始，就比一般的萬用手冊貴上數倍許多，這讓我挺反感的，貴上一些代表著創意智慧財產的象徵不為過，但若是貴上數倍，那是暴利，說難聽點是在坑錢，而不是旨在推廣理念了； 再來我已不使用 Outlook 了，況且它與 Outlook 的整合仍有些 Bug 存在，而該公司的軟體開發技術能力看來不佳，推出 Patch 或新版本等，總是慢吞吞的。雖然它有另外一套 Standalone 版本，但同時也是一套完整的 PIM (Personal Information Management) 軟體，這我不要，我只需要時間管理所需要的機制即可，因為 PIM 中關於聯絡人資訊、行事曆與電子郵件等，我已轉為使用 Google Gmail 的工作環境了，簡單方便、可攜性佳，也不需要作備份等管理工作，好處多多。自然，我也就希望 時間管理工具 的選用是以 Web-based 的形式呈現的。

我會以為，時間管理只有兩個最基本的元素： 行事曆 (Calendar)與工作 (Task)。 再怎麼功能強、複雜的時間管理工具，都不會脫離出這兩個最基本的元素。 行事曆讓你可以看到與規劃何時有 Meeting，以及要做的事情；而工作項目 (Task Item)則是讓你寫下要做的事情，何時要完成，以及優先順序等。 一般而言，執行力強的人，總是能把所寫下工作項目整理成的清單 (List)一一的給完成。 喔，這突然讓我想到，我所看過執行能力最強的是誰呢？ 『海綿寶寶』，沒錯，就是他！ 我在卡通上起碼看過三集以上，海綿寶寶把要做的工作，從上到下寫在一張好長好長的清單。例如，他要辦 『狂歡派對』，就把派對前需要準備的項目、要邀請的人、哪些人什麼時候要講什麼話，甚至哪個時間要安排讀報紙的冷笑話等．．．，他就是一絲不苟地一一地去完成清單上的項目工作，行動力與精力之充沛，可真的是驚人呢。

畢竟那是卡通，一般人總是沒有那麼好的精力，從上到下、Top-Down 的方式，去完成好長一串清單上的工作，所以我們會希望能以 『有效率』 的方式來處理工作。 那個 『有效率』，我曾說過，不只是懂得做事的技巧外，還要能分辦出，什麼是 『有價值』 的事情。我是覺得， 優先處理 『有價值』 的工作，比懂得 『有效率』 地運用技巧來處理工作還要來得重要。 而什麼是 『有價值』 的工作，這就與每一個人所認知的價值觀，以及對目標的規劃設定等有其關連。 所以價值觀、目標，中、短期的專案 (Project)等，是可以引導所要做的事情的方向上。自然你就會瞭解什麼樣性質的工作，會是在你心目中佔有優先權比重較高，需要優先處理的。

所以，工作事項會被組織，會分類，可以排定優先權順序與預計完成的期限等。 再則，諸多工作事項可能會有關連的，例如專案，它可能會區分為多個工作項目，而每一個工作項目也可能是專案，包含更細部性的工作項目．．．，如此的延伸與關連，而形成一種樹狀的結構。 我在當初評估時間管理工具時，正是因為考量到此，所以花了很多時間尋找能適切處理好樹狀結構的工具軟體。 正因如此， 『Remember the Milk』 一開始雖然是我最優先評估的工具，但因為沒有樹狀結構，所以棄而不用； GTD Life 介紹的一篇： 推薦四個在線任務管理網站。 其中如 TODOIST, iPrioritize 是有支援樹狀結構的工作項目，但總覺得繁瑣了些，介面操作就是有那種不是味道的感覺。 說到味道，又讓我回想起那個牛奶，竟然在國外網站諸多網友的評鑑中， 『Remember the Milk』，是 on-line 最佳的 GTD 工具網站。 我挺驚訝的，感覺功能如此的陽春，怎麼評價如此高？ 再深入去研究使用，以及著實看了很多國外網友們的使用心得分享 (參考此篇：Get Organized with Remember the Milk)，才發現到真的簡單就是美！ 下面我就來分享一下，我是如何利用 『Google Calendar』 與 『Remember the Milk』 ，來達成個人在時間管理的規劃與執行。

繼續閱讀 »