有放諸四海皆準的開發方法嗎?

本文係投稿於 CNet / ZDNet Taiwan文章初稿,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。

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

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

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

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

專案的特性

相信有些人會覺得很不以為然,軟體專案怎麼可能會沒有放諸四海皆準的開發方法呢,那是因為開發者技術能力不夠純熟吧?其實問題的關鍵並不在於技術上,而是因為專案具有獨特性與臨時性的特性,從專案的獨特性來看,沒有專案是完全一樣的,所以意謂著開發者在上個專案所用的技能及方法不見得可以在下一個專案適用。

當然對大部分的軟體開發專案而言,也沒有專案完全不一樣,但這只是更代表著在每一個專案的規劃過程中,開發方法必須隨著專案問題的不同而有所裁切或調整做法,然後讓專案開發者予以熟練,以確認專案能有效地運用開發方法來使專案能順利進行

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

另一方面,從專案的臨時性來看,專案要解決的問題通常是為了因應環境的變化,為企業創造機會或降低威脅,因此必須考慮時效性的問題。也就是必須在最短的時間內,用最少的成本來滿足專案目標,在這樣的限制條件下,專案常常不能採用最好的解法,卻只能採用最適當的解法。

然而什麼是最適當的解法呢?專案團隊不能只站在工程與技術的觀點來看專案的開發方法,而是要考量專案各種觀點的取捨,專案要成功必須維持這些觀點的平衡,最適當的解法往往是權衡專案之各種不同觀點的取捨之道。

所以相信由以上分析,我們不難瞭解,軟體專案團隊必須因應企業所要解決的問題與客戶要求的不同,調整開發方法並使團隊成員熟練他們所需的技能。不同的專案常會有很大的不同,只靠技術的單一觀點是無法真正的解決問題的。

在大部分的情況下,開發人員必須運用他們的開發技術(development technology)與經驗知識整合客戶的問題領域智能(domain know how)、使用者的現場操作知識,再加上專案團隊的專案管理專業知識與經驗,才能讓專案得以順利進行,以達成專案關係人所預期的目標。

實戰經驗對專案的重要性

因此,用學中做(doing by learning)的方式,只是理論上與想像中的軟體專案開發,與軟體專案開發實務是會有一段差距的,真正的軟體專案開發是無法紙上談兵的,而是要解決真實世界的問題。否則,「實戰經驗」這種概念就不應該會出現,因為如果實戰經驗可以由平常練習所取代,那它就沒有存在的價值了。

實戰經驗之所以可貴,是因為它是解決真實世界問題的實際體驗,而不是依據主觀認定,憑空想像而來的。平常的練習不管是由管理者或練習者來主導,學習目標都會流於主觀,不見得能在真正的專案用得上。然而,以企業營運觀點而言,如果研發部門平日的研究成果不能為公司創造營收或附加價值,將勢必會增加公司的財務風險,這樣當然會讓經營者難以接受這種做法。

誠如筆者在之前文章所提到的那位同學,雖然他是技術背景出身,但身為公司的負責人,營運面的現實考量還是會讓他不希望技術人員去堅持他認為不切實際的設計理念。依筆者的觀察,大部分的管理者都會傾向用 on job training 的方式來訓練團隊成員,讓他們與專案共同成長,而不是讓員工學好了需要的技能才參與專案,如此可見一斑。

面對專案的現實

當然,不可諱言地,on job training 也會由於專案團隊成員的技術不夠純熟,而造成對專案的負面衝擊。但現實世界就是如此,你想要的和你所能獲取到的就是會有一段差距。專案管理者不應把專案的成敗繫於最完美的開發方法、第一流的人才、最先進的設備與工具、最充裕的時間與足夠的預算,因為這樣的想法是不切實際的空想。

真實世界的問題是複雜而充滿變化的,所以沒有最完美的開發方法,我們只能針對於問題的核心,找出可能解決問題的方法,並採用最可行的方法來進行專案。同時,如果專案能取得充沛的資源卻不須考慮時間的急迫性,代表組織相較其它企業而言,具有絕對的競爭優勢,如此專案根本沒有成立的必要。所以,在專案所處環境中,都會存在資源稀少性及有限性的問題。

由此可知,專案往往不可能在最短時間內,找到第一流的人才,獲取最先進的設備與工具、及足夠的預算,因此,任何可行的開發方法,都需要針對專案開發團隊的實際狀況予以適度地裁減與調整,然後必須讓開發人員可以熟練它,以避免人員因為對開發方法的不熟練而產生錯誤。

開發方法的調整

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

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

因此,當我們體認到了開發方法無法放諸四海皆準,我們就必須在專案開發過程中面對現實問題,採用合宜的方法,然後予以調適、熟練,最重要的是我們必須在專案過程中,視開發狀況來調整開發方法,這不是一次性的努力,而是必須反覆不斷地調整的務實態度,團隊應當思考如何讓團隊的紀律 (discipline)與敏捷性(agility)可以達到平衡,紀律可以提昇團隊成員素質,而敏捷性也讓團隊成員可以適應變化,這可不是單純的練兵而已,而是促進團隊的自我組織(self-organization)呀。

Please follow and like us:
分類: CNet/ZDNet, 專案團隊, 專案規劃, 開發流程。這篇內容的永久連結

在〈有放諸四海皆準的開發方法嗎?〉中有 2 則留言

  1. 自動引用通知: 同人的生活派對 » 開發方法的思考陷阱

  2. 自動引用通知: 同人的生活派對 » 新官上任三把火

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *