鍋碗瓢盆的點滴生活

【同人2007/09/06】 
上次筆者在從高鐵談大型公共建設軟體開發專案的讀者回應中，發現有位讀者 Luke 留下了網誌鏈結，並在他的網誌當中發表了他的看法。他不同意筆者對大型公共建設軟體專案有關解決問題心態的觀點，他指出事實上開發人員並不是在大型專案中試煉自己的技能，不斷的調適、熟練的過程，這些應該是平時應該要做的工作，而不是把作專案或是產品當成是練兵。 

Luke認為開發人員不應藉由大型專案開發過程中試煉自己的技能，而是要在平時就要有足夠的時間讓他們練就好純熟的技能，這樣在專案開發的一開始才能避免不必要的浪費，並且能夠開發出強壯且靈活有深度的架構。 

筆者相信許多軟體開發人員都會贊同Luke的觀點，與其把時間耗費在應付專案永無止境的壓力，還不如在平常多花一點時間研究如何把系統做得更好，以節省專案無謂的浪費。然而，「理想與夢想是美麗的，現實卻是殘酷的」，筆者擔心這種以開發者角度出發的理想在專案開發上卻會是個難以實現的夢想。

 為什麼筆者會這麼認為呢？依照個人多年來參與軟體專案開發的實際經驗顯示，軟體專案沒有放諸四海皆準的開發方法，所以開發人員很難事先預知他接下來應該學什麼，專案也不可能等他們學好需要的技能才開始，所以他們技能的學習與成長往往是在專案的過程中從做中學（learning by doing）累積得來。 

專案的特性 
相信有些人會覺得很不以為然，軟體專案怎麼可能會沒有放諸四海皆準的開發方法呢，那是因為開發者技術能力不夠純熟吧？其實之所以如此，關鍵並不在於技術本身，而是基於專案「獨特性」與「臨時性」兩種特性。 

從專案的獨特性來看，沒有專案是完全一樣的，所以意謂著開發者在上個專案所用的技能及方法不見得可以在下一個專案適用。當然對大部分的軟體開發專案而言，也沒有專案完全不一樣，但開發方法可能無法複製到每個專案過程。 

所謂的專案的臨時性，是指專案要解決的問題通常是為了因應環境的變化，為企業創造機會或降低威脅，因此必須考慮時效性與資源的問題；必須在最短的時間內，用最少的成本來滿足專案目標。 

在種種限制條件下，專案常常不能採用最好，而是最適當的作法。什麼是最適當的作法呢？專案團隊不能只站在工程與技術的觀點來看專案的開發方法，而是要考量各種觀點；最適當的解法往往是專案權衡各種觀點、限制及條件的結果。 

軟體開發與一般的產品製造不同，在專案的管理過程中，必須有效地管理因為不確定性所帶來對專案的負面影響，這不是只為了練兵，而是面對現實的適切做法。 

大部分專案的開發人員必須整合他們的開發技術（development technology）與經驗知識、領域智能（domain know how）、使用者的現場操作知識，再加上專案團隊的專案管理能力，專案才得以順利進行，以達成專案關係人所預期的目標。 

實戰經驗對專案的重要性 
因此，用學中做（doing by learning）的方式，只是理論上、想像中的軟體專案開發，與軟體專案開發實務是會有一段差距的；真正的軟體專案開發要解決真實世界的問題。實戰經驗之所以可貴，是因為它是解決真實世界問題的實際體驗，而不是依據主觀認定，憑空想像而來。平常的練習不管是由管理者或練習者來主導，學習目標都會流於主觀，不見得能用於真正的專案中。 

以公司營運觀點來看，經營者也難以接受不能為公司創造營收或附加價值的研發部門。 

誠如筆者在之前文章所提到的那位同學，雖然他是技術背景出身，但身為公司的負責人，還是會讓他不希望技術人員堅持他認為不切實際的設計理念。依筆者的觀察，大部分的管理者都會傾向用 在職訓練(on job training)訓練團隊成員，讓他們在參與專案過程中成長，而不是學好了必要的技能才參與專案。 

歡迎來到真實世界 
現實世界就是如此，你想要的和你實際獲取到的總是有一段差距。專案經理不應把專案的成敗繫於最完美的開發方法、第一流的人才、最先進的設備與工具、最充裕的時間與足夠的預算，因為這樣的想法本身就是不切實際的空想。 

真實世界裏，幾乎所有專案環境，都會存在資源稀少性及時間限制的問題。因此沒有最完美的開發方法，我們只能針對於問題的核心，找出最適宜的可能解決方法。因此，任何可行的開發方法，都需要針對專案開發團隊的實際狀況予以適度地裁減與調整，然後必須讓開發人員可以熟練，以避免人員因為對開發方法的不熟練而產生錯誤。 

開發方法因時制宜 
所以，筆者認為，如果你所參與的專案問題並不複雜，客戶的要求也不高的話，或許可以發展出大部分專案大致適用的開發方法。例如系統發展生命週期（SDLC，system development life cycle）軟體開發流程（SDP，software developmet process），也就是一般人所謂的瀑布模式（waterfall model），是以線性的觀點來看軟體開發，也是早期大型軟體最常用的開發方式。即使在今天，瀑布模式與它的變型(如V型開發模式)仍是台灣最主流的軟體開發方式。 

然而，它是放諸四海皆準的開發方法嗎？顯然大多數的人不如此認為，因為軟體開發本質不是線性的，尤其是面對軟體需求或技術的變化，瀑布模式很難有適應變化與及早控制風險的能力。而今日因應企業資訊需求的增加，使軟體系統的複雜性增加，軟體使用者的要求也愈來愈多，在這種情況下，我們就更要體認到開發方法無法放諸四海皆準的現實。 

因此，當我們體認到了開發方法無法放諸四海皆準，我們就必須在專案開發過程中面對現實問題，採用合宜的方法，然後予以調適、熟練，最重要的是我們必須在專案過程中，視開發狀況來調整開發方法，這不是一次性的努力，而是必須反覆不斷地調整的務實態度。 

團隊應當思考如何讓團隊的紀律 (discipline)與敏捷性（agility）可以達到平衡，紀律可以提昇團隊成員素質，而敏捷性也讓團隊成員可以適應變化，這可不是單純的練兵而已，而是促進團隊的自我組織（self-organization）。