jim yeh on 三月 6th, 2006

軟體專案在時程緊迫的情況下,如果專案範圍、期限與資源不可能更動,常有些人會認為要達成專案目標,應該減少軟體設計的時間,增加程式實作的時間。這些人以為時間緊迫,沒有時間做設計,軟體設計對軟體專案產出的頁獻不是最直接的,還不如把節省設計的時間拿來寫程式。誠如M君在矇矇的秘密基地《軟體的模組化(Modulize)設計應該要徹底實踐!》中提到~

這就是現實的問題,有專案在身上的時候,就很難做到。只有沒有專案的情形下才能真正落實,沒有專案就是要花錢,事實上我們老闆只是把上個專案賺的錢決定不要再接著賺,不是很有錢(我們手上有了三個專案都是10M以上的,全都暫時用政治力量擱置),要落實真的流程,當然目的是想未來能否賺更多錢。

M君的觀點看起來似乎是理所當然,但大多數的專案的經驗及教訓(Lesson Learn)卻告訴我們:「忽略軟體設計的專案難逃專案失敗的命運」。如果我們因應專案時間緊縮而在早期不做設計或整體規劃,到專案後期會因為不做設計所引發的高度風險而以失敗收場。為什麼為這樣呢?因為我們落入了「捨本逐末」的系統陷阱中,見下圖所示:

軟體專案設計系統思考圖

上圖是軟體專案設計的系統思考圖,圖中的紅色迴路便是面對專案開發時間緊縮時,常見的因應之道。省略設計工作得確可以在開發階段的早期減少工作負擔而對專案開發時間縮短的問題有抒緩的效果,但這種解決方法只是治標而不治本,是針對問題症狀的發生的暫時權宜之計;面對問題根本的解決方案應該是如橙色迴路的落實設計理念,加強設計能力進而尋求良好的開發工作績效來解決時間的緊縮。但根本解沒有像症狀解有立杆見影的效果,但一昧地採用症狀解將會出現衍生品質問題的副作用,然後離根本解愈來愈遠,正如粗線迴路一樣產生專案時間緊縮問題反而愈演愈烈,造成一發不可收拾的惡性循環,這樣的事件結構模式就是所謂的系統思考之捨本逐末基模,彼得.聖吉在《第五項修煉》中特別提到:

捨本逐末最嚴重的後果是目標侵蝕,只要目標與現狀有差異,就會產生兩種壓力:改善現狀或降低目標。(略)在人類社會中,原有的目標逐漸被腐蝕的情況常常發生。(略)事實上,因為我們總能找到一些合情合理的藉口,因此極易染上降低目標的「癮」。

其實長期降低目標所造成的後果正如同《易經文言傳》坤卦所言:

積善之家必有餘慶,積不善之家必有餘殃。子弒其父,臣弑其君,非一朝一夕之故,其所由來者漸矣,由辯之不早辯也。

坤道為順應趨勢之道,專案進行中順應趨勢是必須的;而乾道是行事之道,設計工作則是幫我們把工作做得更好,設計必須對實際需要來做因應取捨。所以如果專案面對現實而落實設計(積善之家),即使專案時程緊縮,設計的好處也將在關鍵時刻中展現其效益(必有餘慶);反之,若專案昧於實際需要而一再地縮減設計工作以減少工作負擔(積不善之家),即使專案時程是充裕的,最後也將發生軟體問題叢生而無法善終(必有餘殃)。不知不覺是相當可怕的,發生像「子弒其父,臣弑其君」這樣離譜的事情絕對是長期累積的問題,我們慢慢地失去設計能力,專案便註定了要失敗。設計者要有防微杜漸的能力,所以專案現實不但不會侵蝕我們的能力,而是讓我們能力與時俱進,因為軟體設計是不昧於專案現實的,所以專案前期面對現實的規劃(管理面)與分析設計(技術面)是必須的,即使如M君所言:

我二十多年的寫程式經驗來說,我服膺的是射擊、瞄準、射擊的理論,所以對各種事先的設計嗤之以鼻,不過除非本身的實力夠,而且願意不停的重寫程式,不然很難做到。我之前提到的那個東西,平均每兩年我會全部重寫,不過還是保留向下相容性,畢竟底層是不停的變動的,光是xml parser,在jdk內建的定版前,我們這些先行者就有許多不同的格式,想起以前的xml4j 1.x多好用。也因為最底層修改了,上面也要修改,通常我會重新寫、重新設計一回。射擊、瞄準、射擊是在有的東西上持續改進,別忘了沒有實做的設計有很大的機率會因為底層不支援而不能照想像的來搞,沒有真的去作不會想到jdk有那麼多限制,想起以前C的美好時光,甚麼都能作。

軟體專案的規劃比較適用於反覆與漸近式開發(IID, iterative and incremental development),它強調用適應性計劃(adaptive planning)來取代預測性計劃(predictive planning),把規劃設計與承諾完成的水準與資訊品質等量齊觀,是一種面對現實的規劃。因此M君如上所言,雖然不做事先的設計,但他所做的還是在做設計,一種面對現實的設計。

總之,設計是在專案有限資源的狀況下,找出解決專案問題的最佳方法,其目的是確保專案能夠成功,專案的軟體設計者應當去思考如何面對現實,做符合現狀的設計,所以設計並不昧於專案現實。「沒有時間設計」只會淪為一種抱怨,但抱怨對能力的成長是沒有助益的。而運用設計理念並不需要強大的工具或技術,因為設計思維是來至設計者的創意與智慧,並不在於使用的工具與技術。



     

4 Responses to “軟體設計並不昧於專案現實”

  1. M 說道:

    我是M。
    設計真的要看專案現實,如同我說常說的,只要有幾個高手,通常設計就會不錯,因為高手喜歡重構程式,持續不斷的設計。問題是高手很少,而且設計在腦中,必須由程式才知道設計理念(XP style),所以需要工具,讓所有的人由文件來知道設計流程。
    我們最近也遇到了一些問題,主要是工具(Rose or RSA)對高手太難用,所以幾個高手的設計模式又回到逆向工程的方式,程式出來再回工具,為了產生可以傳承的文件。畢竟,你可以用印地安話(高手的程式語言),不過大家都會說英文(一般人的UML語言),你還是要把設計用英文重說一次。

  2. jim yeh 說道:

    M君您好,

    由程式才知道設計理念並不是唯一的方法,藉由工具來瞭解設計流程也不是軟體設計問題根本解決之道。真正的解決之道是開發者設計能力的提昇,工具與方法只是招式,軟體開發的心法重點在於您面對問題的態度與思考的創見。

    誠如我在由招熟而漸悟懂勁中所提到的:

    如果你對程式沒有深切的體認,很難設計出彈性及功能兼具的系統。所以以個人的心得來說,個別的領域知識、系統流程、演算邏輯及程式語言的技巧是招式的運用,而OOAD的分析設計原則、封裝、抽象化乃至於Pattern的運用則是心法的展現。這兩者互相反覆搭配、增長。

    招式的變化在於個人平常願意動手作及努力練習的心得;心法的流露則是懂得在特定的時機及場合採用適合的招式來因應、兩者相互配合才能開發出良好的軟體系統,(略)心法的加深是需要經驗不斷累積的,每個人會有不同的觀點,所以為避免陷於受限知識框架下,適當的社會化的交流是必要的。「相觀而善謂之摩」,透過相互溝通不同的觀點,以不斷地超越軟體設計開發的招式與心法。

    所以軟體設計的專家除了軟體設計及研發能力外,更重要的是在於他對軟體專業的態度。記得藝術大師朱銘先生曾說過:「我過去的師父教我用刀雕刻,但我的老師楊英風先生卻教我用心雕刻」,所以大師與匠的差別就不言可喻。大師可以創造更多的大師,所憑藉的是他的觀念及精神來影響他人,並不是工具、流程甚至是方法,因為這些東西是死的,而軟體設計理念是必須活用的一門學問。

    個人與互動勝於流程與工具(《敏捷軟體開發宣言》),所以不管有多麼好的流程,多強大的工具能產生出多麼棒的文件,但如果沒有辦法促進團隊成員素質提昇及相互溝通回饋,所得到的結果還是有限的。

    供參考。

  3. [...] 其實這個問題會有兩個答案,我可以說是;也可以說不是。為什麼可以說是也可以說不是呢?說是的原因是那篇文章所繪製的「系統思考圖」和《溫伯格的軟體管理學》中的「效應圖」都可以用來表達動態系統模型,讓我們對事件形成問題的結構然後進展成系統動態模型有更深入的體悟。那為什麼我又說不是呢?因為「系統思考圖」是我慣用的思考工具,在我看過的書當中,《溫伯格的軟體管理學》並不是第一本談論系統思考的書,而且在〈軟體設計並不昧於專案現實〉這篇文章中,我已探討過省略設計活動所造成的捨本逐末的動態系統基模了。專案管理大師詹姆斯.路易斯曾在所著的《專案管理聖經》提過,專案經理必須要有系統思考的能力,傳統的線性思考方式強調絕對事件因果關係在複雜的專案環境常常會不適用,因為在專案管理的過程中,很多事件的發生常是互為因果的,所以我們不可能用簡化的因果模型來管理我們的專案,而是要用動態模型才可能真正看到問題的徵結。否則,我們所採取的任何行動,都會被動態系統的平衡機制所抵削了,專案管理者只有打破模式,才有可能真正地改善專案問題所帶來的困境。 [...]

  4. [...] 其實,design pattern 就是一種軟體設計之延緩設計策略的促成技術(Enabling Technique),但設計者也要小心 design pattern 的誤用所造成過度設計會讓設計變得更複雜,這中間該如何拿捏呢?讓設計儘量簡單吧!Qing 認為:"建立一個具演化能力的設計,讓這個設計能夠隨時依照可見到的迫切需求,在很短的時間內滿足這個迫切的需求,同時繼續為下一次的演化而做準備。就是這樣,每一次的改變,除了滿足目前的需要之外,同時也為下一次的改變而做準備"。喲哪桑也說:"簡單未必容易。為了同時修掉既有的問題、又讓軟體隨著需求而演化,開發者的設計技藝得更純熟,而開發者往往還要更密切地與使用者互動、快速回應、人際溝通要更強。從我經驗來看,這通常是成熟開發者才辦得到。"。我則認為:"軟體專案的規劃比較適用於反覆與漸近式開發(IID, iterative and incremental development),它強調用適應性計劃(adaptive planning)來取代預測性計劃(predictive planning),把規劃設計與承諾完成的水準與資訊品質等量齊觀,是一種面對現實的規劃。雖然不做事先的設計,但開發者所做事就是在做設計,一種面對現實的設計,因此軟體設計並不昧於專案現實。" [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">