軟體設計思維應跳脫思考的桎梏

上上星期透過朋友介紹,至某知名教育訓練機構,討論軟體設計課程的合作方案。

在與一位老師閒聊閒聊當中,,談及他正在某資工所上課,他們老師正教授軟體開發製程,介紹到 “XP(Extreme Programming)” 的方法論。

一聽到 “XP”,我馬上精神抖擻起來~ 半年前我把 XP 的譯作約五本全在廁所看完,對於 XP 的哲理及其實務作法,非常地激賞。

哪位老師對 “XP” 的實務作法,一直很懷疑有可能可以在台灣的業界實施嗎?例如,他認為 “pair-programming”、”客戶駐點”,根本是脫離現實的。

聽到這...我的感觸很深,哪位老師直覺是認為 XP 的實務不容易也不一定適用在國內的軟體業界。
但,我認為 Kent Beck(XP 教祖) 的本意不是要你去模仿及學習那 “十二項” 的實務吧?
XP 的 “十二項實務” 只是 “How-to”,”How-to” 會因為現實的環境而修正的。況且,為什麼我們不懂得再找出第 13、14 ...的實務呢?哪應該才是 Kent Beck 的本意吧?

“XP” 是因為 Kent Beck 看到軟體開發流程中,有太多 “昧於現實面” 的現象,尤其是 “人” 的因素往往是影響整個專案成敗的主因。

Kent Beck 從 “本質” 去思考,發現到 “簡單”、”溝通”、”回饋”、”勇氣” 這四項要素是軟體專案開發的核心,從這四項基本元素,才去找出 “十二項實務” 的 “How-To” 來解決現實面專案開發的問題。

我想表示什麼呢?軟體設計人員不能只看到 “XP” 所提供的 “How-To”,就去模仿使用,然後應用在實務不成功時,就怪東怪西的、或心情沮喪、或覺得根本無法與現實結合...

能不能跳脫那所謂的 “十二項實務” 呢?那重不重要?當然重要!
但,更重要的是,是否你能真正用心去思考那四項基本要素呢?

什麼是簡單?為何要簡單?為何簡單是力量? —> 如何達成簡單呢?
為什麼溝通是重要的? —> 如何達成順暢、和諧地溝通?
什麼是回饋?為何回饋可以降低風險? —> 如何達成快速回饋呢?
為什麼要有勇氣? —> 如何提升自我及團隊的自信心呢?

What?-> Why?-> How-to
軟體設計人員可不能再只把焦點擺在 “How-to” 而已,哪未,整個思考就僅會落在 “How-to” 的框架桎梏之內~
跳出 “How-to”,勇於思考本質、勇於創新、勇於找出自己的 “How-to”、勇於嘗試、勇於被批判、勇於修正...

如此,軟體設計者才會有無限地想像與創新,並可以有屬於自己的 “XP” 了!!

解讀『XP軟體製程』的字面意涵

XP 的全名:Extreme Programming。
中譯本其中有三本翻譯為”極致軟體製程”;一本翻譯為”極端軟體製程”。

哪一個比較符合 XP 的原意?
個人到認為,這兩個解釋都很合理!

翻譯為 “極致“,代表如何把軟體製程做到 “最善”;
翻譯為 “極端“,則表示基於現實面的考量,可能會顛覆傳統的軟體製程觀念,如 “Pair Programming”、”客戶駐廠”...等,是一般傳統的軟體開發人員所無法想像的!

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal