Fri, 2007-10-19 13:53 — F I N
方法論只教你設計的「方法」、並不會教你設計的「內容」。
偏偏有經驗的設計者、說實在的、並不信賴別人的「方法」、寧願相信自己的「做法」、所以方法論雖說歷史淵遠流長、只是推展成果一向不彰。
方法論要行的通?
首先、「教」「學」雙方先要有「自覺」-「教」的人、先把「理論基礎」搞懂、切莫國外上個課、就去講「概念」(「蓋唸」?)、那不叫「誨」人不倦、而是「毀」人不倦。即使是大師、也要自謙只懂「理論方法」、而非「實務內容」。另一方面、「學」的人、先要調整心態-「摒除成見、虛心接納」。需知「畫貓畫虎難畫骨」、教的人教不好?那是「方法」不對、不代表「方法論」不好。
接著、「方法」要變成「工具」。教「方法論」未必大家聽得懂、但是教「如何使用開發工具」大家一定比較容易學會、而且用工具(Tool)開發、標準化自動會達成、這也是方法論最重要目的之一。所以方法論要普及、開發工具絕對是最有效的手段、只不過目前的開發工具無一有全面涵蓋(從架構到執行)能力、開發過程中部份稍有不足、也讓人無法全面仰賴、這部份就要廠商加把勁了。
Comments
我對"方法論"實在是愛恨交集
拜讀FIN大人的"論方法論"及數篇有關"方法論"、"標準"的回應後心中五味雜陳，小弟也有一些感想與大家分享。
1. 確認"方法論"的定義
深怕一個不小心落入毀人不斷的深淵，我還是上網看看"方法論"(Methodology)的定義。Wikipedia中對Methodology這個名詞有一大串的說明，尤其對它在軟體工程中的定義另闢專頁說明，看完後覺得它的定義與我的印象相距不遠，大意是：
一套完整的條文(a codified set of practices )可以重複運用在軟體開發、產製，它包含訓練教材、教育計畫、工作表及圖形工具；這些嚴謹規範(Disciplines)跨越軟體工程中的各個階段及工作。
這段說明得覺得重點是:完整的規範、重複運用及紀律(可是軟體從業人員是最沒紀律的一群?)。
2. 方法論與實務
小弟在業界打混了幾年，有些感想：基本上"方法論" 是很理論的東西，若要應用到實務面就得看操刀者的功力、當時的環境及配套措施嘍! 若一切如書本的描述，加上天時地利人和，當然得心應手，專案就有可能在時限、預算內完成，可惜的是現實世界中是沒有"王子與公主從此過著幸福過日子"這碼子事；因為內在、外在的變動因素太多了，實在不是完全套用"方法論"可以解決。
小弟比較務實的看法是，專案成功是要靠參與專案人員的基本功、對業務的了解及執行力，有方法論為依據最好，但是方法論不能保證專案的成功與否，更常見的是我們受限於現實環境就採用半套、四分之一套"方法論"來做事(我真的很想知道業界有人一心一德、貫徹始終)。
3. 方法論與專家
常見的是我們受限於現實環境就採用半套、四分之一套"方法論"來做事，加上有一部分的"方法論"專家如FIN大人所述=>只懂「理論方法」、而非「實務內容」，長久下來我對"方法論"一詞實在是愛恨交集，既期待又怕受傷害，深知方法論是軟體工程的基礎，又怕跟一些半吊子的專家一起做專案，不從基本功著手，整天在搞方法論。
小弟多年前在一家國際大公司參與協助一家澳門銀行開發金融系統，公司指派一名資深工程師為專案稽核，這位同仁原是搞系統(System)的資深工程師，從未開發過一個應用系統(Application)，經過惡補了解"方法論"後就上場，飛到澳門開始稽核，我在旁邊看他惡搞，真覺得台灣的軟體界毫無前途可言，這些人真認為方法論可以救國。
4.方法論與工具
小弟一時興起想做一木製書架，上網爬了許多資料、書店買了幾本木工教學的書籍(Methodology)，經過一番研究覺得應該不是難事，到五金店開始購買材料、工具，開始依圖施作，發覺用手拉鋸是鋸不出像樣的木板，深深覺的是工具(Tool)不好，再化大錢買把電鋸、木工工作台，各位看官您覺得從此以後 我就可以隨心所與鋸出又直又圓的木板?
別做夢了! 換了工具只是讓我比較快發現鋸歪了，沒有基本工光靠工具還是徒勞無功。
說了一大串，好像我不支持方法論，大錯特錯，我是絕對支持方法論的，只是回首做了這麼多年軟體，竟然列不出一個專案曾經好好的把某一方法論有始有終的運用在各個階段，不知FIN大大或是其他大哥、大姐們是否有此豐功偉業。
Add new comment