事實上，當你了解理論是如何形成的，或許你對理論跟實務的關係，會更加的清楚。

Wikipedia對於＂理論＂（Theory）的解釋如下：

理論，又稱學說或學說理論，指人類對自然、社會現象，按照已有的實證知識、經驗、事實、法則、認知以及經過驗證的假說，經由一般化與演繹推理等等的方法，進行合乎邏輯的推論性總結。

接近真理的學說是科學的，反之則是違背科學的或者說偽科學；任何自然科學的產生，源自對自然現象觀察。 人類藉由觀察實際存在的現象或邏輯推論，而得到某種學說。任何學說在未經社會實踐或科學試驗證明以前，只能屬於假說。如果假說能藉由大量可重現的觀察與實驗而驗證，並為眾多科學家認定，這項假說就可被稱為理論。

理論並不是無中生有，像孫悟空一樣從石頭蹦出來的，而是累積人類過去的經驗法則與觀察，並藉由種種的辯論驗證的程序而產生。這代表著當你在學習某種理論的同時，也是在吸取前人的經驗跟智慧，避免因為走不一樣的路而造成的風險。

事實上，＂理論＂也是一種經驗法則，只是比較嚴謹，需要經過多次的試驗跟辯證，以確認其正確性。相對於＂實務＂來說，理論已經有過去許多人的經驗支持，但不代表一定會相同的發生在每個人身上，也有可能因為已被、或未被發現的假設前置條件，造成不同的結果。

以PMP來說，如果只是拿來當作工作求職升官的一紙證明，其實並不難（答對60%就過關了），但拿到這一紙證明就想管理好專案，事實上還有一大段差距。很多人沒念過PMP，可是自有一套專案管理的方式與做法，一樣會評估風險、一樣會控制時程；沒有學過激勵理論，但會主動幫專案成員謀福利；不知道什麼是Dephi Technique，卻善於跟客戶打交道，取得需求的共識。很多時候你不得不佩服這種＂Street Smart＂的人，或許他們不會念書考試，但他們不怕失敗，知道怎麼抓住重點與成功的機會，但他們所使用的工作方式與技巧，其實有都有其理論基礎，只是Street Smart自己本身並不知道。

PMP證照當然不代表專案管理的能力，拿到了證照，下一步應該就要開始思考如何活用，如何在自身的專案工作中使用這些工具與技術。沒有念過PMBOK Guide，即使你現在可以管好專案，最好還是去了解一下什麼是PMBOK，你會得到更多可以用在管理專案上面的知識技巧。更重要的是，要知道這些理論的假設條件與限制，並思考現實狀況的適用程度。現實跟理論一定會有差距，School Smart跟Street Smart沒有孰優孰劣，惟有設法結合理論跟實務，並不斷的思考，找出屬於專案的最佳實踐（Best Practice），才會是完整的專案管理能力。

幾年前，台灣曾經播過一部美國電視素人選秀節目＂誰是接班人＂（The Apprentice）。有別於一般素人選秀節目，可能是用歌唱或是其他才藝（廚藝、舞藝、模特兒），它所不太一樣的地方，是以＂專案管理＂能力與實際作為，做為競賽勝敗的依據，並且把專案管理的歷程赤裸裸的呈現的電視機螢光幕前。這個節目的另外一個賣點，則是一樣具有話題爭議性的節目主持人，同時也是美國知名房地產商的唐納川普（Donald Trump）。藉由他的參與，製造了節目中許多的高潮與爆點。例如在節目中幾個他的口頭禪：最有名而且每集都會出現的＂You are fired!＂、還有＂Are you tough enough? Are you strong enough?＂、＂Winners take all＂等等，都是在節目中膾炙人口的名句。

雖然＂誰是接班人＂的競賽內容，多半對IT專案或是軟體開發專案無關，但專案管理的精神、內涵、實務做法其實都是大同小異：一樣面對時程的壓力、預算跟範圍的限制，一樣有一堆要管理的專案關係人，一樣要控制好品質，最後專案的產出要符合評審的期望，否則就有人要走路（Fired）。相對的來說，雖然電視節目（TV Show）還是要迎合觀眾的胃口，要找俊男美女以及醜八怪，要製造話題與順便幫川普自己的企業打廣告（而且還蠻明顯的），但在節目中仍有不少值得探討學習的企業管理（MBA）以及專案管理（Project Management）的內容。

就拿第三季的主題＂Book Smart vs. Street Smart＂，就是一個值得深入討論的話題。到底是書念得多，表現會比較好？還是商場職場上的經驗跟直覺的正確，來得比較重要？於是在這一季的影集中，製作單位找了兩批不一樣背景的參賽人員：大學畢業但沒有太多的工作經驗，以及高中畢業卻已經在商場上小有成就的人來比賽，看看到底是＂Book比較Smart，還是Street比較Smart？！＂（大誤）

書不會聰明，街也不會聰明，比較好的中文翻譯，是比較＂理論＂（Book Smart）跟＂實務＂（Street Smart）何種比較重要。這在台灣也是許多人討論的話題，尤其是現在碩士滿街跑的時代，許多主管常常對學歷高的員工嗤之以鼻，認為學歷不等於能力，卻又用另外的方式設下了求職的門檻，仍然要求學歷、看證照，透過筆試測驗來評估等等。因為實務能力本來就是很難量化的，工作年資、經歷的職位跟工作內容都只能參考，書念得好、證照拿得多，卻是的比較好評估的門檻，過了這個門檻的人，似乎就應該不會差到哪裡去？這是很有趣的現象。

回到專案管理的主題上，到底是書念得多比較好，還是實務經驗比較重要？我們拿PMP做例子，把這個大問題細分成一些狀況題，看看能否產生一些火花：

1.PMP（專案管理專業認證）是否代表PM（專案經理）的能力？

2.不懂PMBOK Guide（專案管理知識體系）是否可以管理好專案？

3.理論都有其假設及限制，是否代表理論常常不適用於實際工作？

（下回待續）

上一篇文章po出來之後，前輩Cash大馬上就FB給我，叫我去看一下X-Model。後來一問才知道，Cash大認為類似TDD的模式比較接近X-Model，多用在探索性開發(沒有特定需求或擷取需求之處)的模式裡，與一般可以固定訪談and/or擷取需求的模式是不同的。

會討論到有沒有明確的需求，或是需求是否可以先被確認，主要的問題都是在想＂如何節省軟體開發的成本＂上面，不然不會一直有新的方法論出現，當然這在每個軟體開發的任務上都不盡相同，有些用瀑布式開發就好，有些需要因應不明確的需求不斷的做調整。事實上有人就認為TDD就是希望藉由測試來確定規格（Specification by Example），才會有在測試案例寫好前，不進行開發的定律。若是要因應需求的變更，雖然不需要調整到程式碼，但是仍需要修改測試案例，一樣有成本的問題，這跟做需求文件是一樣的道理。不過另一方面，我自認還沒有跳脫傳統軟體開發瀑布式模式的觀念，以及大家對＂明確＂的需求，定義上不盡相同，有此討論，其實不失是一個繼續努力學習的機會。

針對以上，剛好我找到一些對岸及台灣同胞針對TDD的一些觀點討論，還蠻有趣的，順帶整理跟大家分享：

那些炒作過度的技術和概念
TDD並不是看上去的那麼美
TDD到底美不美？
Bob大叔和Jim Coplien對TDD的論戰
Test-Driven Development？別逗了
不要把 TDD 和做測試混為一談
測試驅動開發的精神
讀書摘要：敏捷測試的思考(1)

我不是討厭或喜歡TDD，而是在研究討論一個方法論之前，能多聽一些不同角度的討論，都是有幫助的。至少不要是在缺乏資訊下就推動，這也是我想寫第一篇TDD文章的原始用意。雖然上面連結引用的有些是同一個blog的文章，但對於TDD的優點與缺點，以及國外大師針對TDD的一些討論，都蠻精彩的，值得推薦給大家看。

原先我對TDD並沒有太多的了解。原因之一，這是Aglie（敏捷開發）方法論的一環，而目前我所經歷的專案與團隊並沒有使用敏捷開發；之二，對於TDD，我一直以為就等於是Unit Testing，只是把寫Unit Testing Code的時間從寫程式本文後提前至寫程式本文前，就這麼簡單。事實上不然，TDD不單單指的是Unit Testing，事實上也可以用來進行後端的模組測試、整合測試等等。但TDD強調的不是＂測試＂這件事情，而是＂開發＂這件事情。為了要做好開發，所以先寫好測試程式，這對於某些想改變軟體品質的主管或是專案經理來說，看起來好像是個不小的誘惑，但真的做起來，這那麼簡單嗎？

最近幾天看了一些講TDD觀念與執行心得的文章，歸納了幾個想法，順便整理一下跟大家分享：

一、要導入TDD，軟體的需求必須明確，才有辦法讓測試程式碼開發先行，事實上Agile開發方法論強調的是應變需求的速度加快，但無法應付變化頻率太高或是變化幅度太大的軟體需求（以Scrum來說，一個衝刺周期建議是一個月，當然還是要看個別專案而定，但原則上不會偏離太大）。測試就是在測程式的＂功能＂，這可能小到是一支程式裡面的其中一個Function，抑或是大到系統中使用者會使用到的所有功能，若是軟體需求一直變更，變更幅度又非常大，連開發原來功能都來不及了，怎麼還會有時間來修改測試程式碼呢？

二、網路上看到有人說使用TDD，軟體開發的時間被拉長為原來的1.5~1.8倍，聽起來主管及PM的心臟要夠強，尤其在初期導入TDD的時候，往往會因為專案時程的壓力，把TDD三定律先拋在腦後，那TDD的導入註定要失敗。

（TDD三定律：(1)沒有測試之前不要寫任何功能代碼；(2)只編寫恰好能夠體現一個失敗情況的測試代碼；(3)只編寫恰好能通過測試的功能代碼）

三、在軟體開發工作中，我們常常會碰到，卻很少在文章討論中提到的，是所謂＂工作交接＂的問題。開發人員來來去去，人員異動，調動專案配合人員，常常在發生，一個交接不好，往往就變成了＂歷史的懸案＂，功能原來是好的，某天突然不能用，維護的工程師搞不清楚動了哪裡變成這樣。如果TDD有落實，可以避免類似的情形發生。當然，前提是要有落實。

四、TDD代表的另一層含義，叫做＂自動化測試＂。這又是一塊誘人的大餅，的確可以軟體開發在測試的成本上面大大地降低。不過，TDD本質上是屬於白箱測試，一般站在軟體品保的立場，還是會建議進行黑箱測試來找出原本未預期的問題。尤其當需要進行使用者介面的測試，如GUI，Web-Based操作等等系統測試，就不合適以TDD的方式來進行。就如同我前面所說的，TDD主要目的是協助開發，而非協助測試。

五、有人說施行了TDD，測試人員就不需要了，我倒不這麼認為，理由有下列三點：
1.測試人員在專案組織中多半也負責了軟體品保的其他工作，追蹤Defect/Issue處理進度，收集、協調、討論溝通問題，同時扮演第三方的角色來客觀監督審查專案的品質，甚至還可以幫忙PM檢查開發人員是否有落實TDD三定律，這部分是開發人員無法取代的。

2.對於測試的設計（Test Design），如Test Cases情境的撰寫，測試環境的準備與使用，測試人員還是比開發人員會多一些經驗與關注。簡單講一點，像＂等價分割法＂對於Test Cases的設計有效度是有幫助的，但這是測試方法論，不是開發方法論。太過於要求開發人員執行TDD的時候要懂得Test Cases Design，反而會分散了開發人員的專注力。

        3.TDD是功能測試，非功能測試的部分（如安全性測試、效能測試等等）是TDD無法取代的，還是要有人進行這些測試。

看完TDD的一些討論，我越來越覺得，當整體組織的觀念尚未到位的時候，要推動一些新的軟體開發或是品保的方法論，是非常痛苦，而且是不容易成功的事情。即使觀念到位了，同時還要其他的條件配合（例如客戶，專案時程等）。有人說可以不要全面推動敏捷開發，只推TDD，我則認為這樣失敗的機率很高。

一、 永遠要留意開發時程的延遲，沒有延遲的消息不代表真的沒有延遲，很可能是你不知道實際的進度。

二、 開發時程的延遲不僅僅代表你的測試時程被壓迫，需要加班測試，同時也代表你需要更留意軟體的品質。因為開發時程有問題，軟體的品質多半有更嚴重的問題。

三、 跟開發人員站在同一陣線上，而不是對抗他們，因為你會發現你需要他們更多的協助，他們同樣也需要你。

四、 有測試工具很好，但不代表從此你的人生從黑白變成彩色，工具只是讓你更有效率的執行測試的工作，但你也需要投入更多的時間熟悉跟練習使用工具。

五、 有文件很好，沒有文件不代表不用測試，很可能是要你在沒文件的狀況下測試。

六、 有文件很好，但是不要高興得太早，等你看完文件就知道為什麼了（要你幫忙補文件）。

七、 留意你在缺陷追蹤工具上面的缺陷描述，很多開發人員對缺陷的說明非常敏感，要小心確認他們對於缺陷描述的理解與看法。

八、 特別留意重複發生的缺陷，試圖找出根本的原因，並適當的反應。相同的缺陷一再發生代表資源的浪費，而且包括開發的資源與測試的資源。

九、 解決所有測出的缺陷不代表軟體就沒有缺陷了，上線後才是真正的考驗，試圖先讓你的主管跟你的客戶知道這件事情。並從上線後的發生的問題，改善你的測試計畫與測試案例。

十、 Eat your own dog food。並設法變成是軟體的知識庫，這對你的測試工作會有很大的幫助。