jim yeh on 七月 5th, 2007

一般人以「軟體工程」來說明軟體專案的開發過程,但對於軟體所要解決的問題不複雜、參與開發的團隊規模不大、以及開發時程不長的軟體專案而言,軟體工程卻又太複雜了。於似乎有人認為不應該拿「軟體工程」來比喻軟體專案的開發過程。例如《软件工艺 Software Craftsmanship》這本書,提出了軟體工藝的新隱喻。而我有一位學長喲哪桑也發表了他看此書之後的心得感想

喲哪桑認為「軟體工程」雖然可以幫助我們了解與學習軟體開發,但它卻並不等於軟體開發的本體呀。學長認為「軟體工藝」可成為一個新的隱喻、新的tag,從極致的工藝技術來比擬軟體開發。如此,關鍵將落在於重視軟體開發者的技能、經驗與才華。換句話說,他認為是人的能力左右了軟體的成敗而非工具與技術。

所以,軟體開發是工藝乎?喲哪桑也不敢驟下斷言,但他認為,可以選擇少把 process compliance 掛在嘴邊,而多談 PSPTSP,回歸「以人為本」的軟體開發。而獨孤木看了學長所發表的心得,也提出他對軟體開發的看法,他則認為軟體工程的大部份理論,都是導源於開發軟體時,有很多人需要一起合作,所以需要建立共同的溝通方法與管道,以及一些共用的工作紀律。所有的軟體工程理論,其實都只是在告訴你,在人數眾多時,應該要遵循什麼樣的開發方式,才可以避免或解決他們所面臨的問題。

換言之,軟體工程的目的是提供一種開發方式,讓軟體開發的工作,能做適度的分工,同時也讓開發者之間的溝通,能夠順利進行,以避免或解決在軟體開發過程中,可能會遭遇的問題。然而,站在軟體工藝的角度而言,對於軟體規模不大、參與開發的人數不多、開發工期不長,對於技藝超群的開發者而言,根本就不需要考慮分工及與其它開發者溝通的問題。只要他能夠把客戶想要的軟體做出來,一切問題都會得到解答,是嗎?

有了這樣的推論,我們可以假設軟體開發是工藝,可是,依同人實務上的觀察,問題好像沒有那麼簡單,尤其是要「把客戶想要的軟體做出來」,說起來簡單,做起來卻很困難。雖然減少了開發者之間了的溝通界面,但這樣一來,開發者就必須直接和客戶溝通來導出客戶需求。開發者往往會發現,即使和客戶直接溝通,在導出軟體需求的過程還是會出現需求導出的三大障礙[1],那就是客戶常常不知道他們真正需要的是什麼、永遠會有需求被遺漏、開發者與客戶或使用者之間的不同背景或語言而導致溝通不良。

所以,如果開發者與客戶之間缺乏足夠的溝通,即使開發者擁有精良的工藝技術,但還是無法開發出客戶真正合用的軟體,有時候開發者會不知所託-不知道客戶真正需要的軟體是什麼;有時候開發者會所知非託-習於用技術來主導客戶或使用者的需求,不管是那一種現象,其結論都會一樣-最後必然導致專案失敗。

於是,為要解決導出需求的第一大障礙,開發者通常會應用使用界面雛型、系統展示來與客戶確定需求、用反覆及漸增開發方式來逐步開發並演化系統;要解決導出需求的第二大障礙,則以小心謹慎的方式進行驗證與確認;至於要解決導出需求的第三大障礙,如果開發者及客戶無法以開放的心胸來接納不一樣的觀點的方式,進行良性溝通,就必須在開發者與客戶之間尋求中介角色以增進溝通效率,甚至將開發工作做適度的任務分工。以上做法,都是常見的軟體工程實務,所以,在實務上,軟體開發是工程。而事實上,大部分軟體工程的理論都是源自軟體開發的實務而演變出來的呀[2]

其實,軟體開發其實不同於一般傳統製造業的生產,在軟體產業中,軟體的複製與配置才是真正的製造程序[3],因此軟體開發本質是設計(的服務)而非製造。而從另一方面來看,軟體要解決的問題和傳統製造業也有很大的差異,當我們建造一棟房子、車子或遊艇時,問題對我們而言是很確定且易於掌握的,也不需要結合跨領域的專業。

但軟體卻不一樣,企業資訊系統常常是為了企業因應環境變化,所造成的挑戰與威脅,而設計出來的整合解決方案。所以不同產業的軟體系統,常常會需要該產業與資訊產業的跨領域整合,其問題複雜度及不確定性是高出一般製造業甚多的。關鍵不在於如何生產,而在如何使企業能夠面對複雜的環境變化。所以,同人認為,軟體開發的本體並不在工藝,也不在工程,而是一種問題解決的過程

當我們了解軟體開發其實是一種問題解決的過程後,另一方面,我們的若干經驗也告訴我們,問題變化的本質是複雜的,期待需求不會改變其實是不切實際的,我們應該擁抱改變以適應變化。

同人看過一篇 Peter Ho 在點空間討論區所發表過的一篇文章,正說明了從簡單演進到複雜,其關鍵在於混沌邊緣(the edge of chaos),也就是界於穩定與穩亂之間的過渡地帶,而系統會自我組織並且演化出複雜的行為。此篇文章提出有關學習曲線的不同觀念,那就是我們不應該為有秩序的需求而奮鬥,那是千年以來錯誤的觀念。演進本身不需要小心建構,也不需要工藝,取而代之的是在秩序與混亂之間,彼此互動元素稀疏相連的極致複雜網絡。只有在過渡地帶附近的混沌邊緣,那裡將會發生最複雜的行為:具備足夠的秩序以保持穩定,卻充滿彈性與驚奇,這也就是所謂的複雜性的重要概念。

Brace yourself, here comes a big impact of learning curve:Our intuitions about the requirements for order have, I contend, been wrong for millennia. We do not need careful construction; we do not require crafting. We require only that extremely complex webs of interacting elements are sparsely connected… Just between [order and chaos], just near this phase transition, just at the edge of chaos, the most complex behaviors can occur – orderly enough to ensure stability, yet full of flexibility and surprise. Indeed, this is what we mean by complexity. – Stuart Kauffman, At Home in the Universe, p84 and p87.

複雜性並非靠預測,而是靠演化。或許我們真的弄錯方向了,在軟體開發方面,用軟體工程的小心建構或是軟體工藝的工藝技術都沒辦法讓軟體能夠適應變化解決日益複雜的問題,所以,軟體開發的本體,應該是開發可以隨著環境變化而演進的系統,這也就是,Peter Ho 在點空間的另一篇文章所提到的「複雜適應性系統」(CAS)的觀念:讓系統自己組織起來到混沌邊緣,那兒將會使共同演化發生。但軟體開發要如何讓系統自我組織呢?Peter Ho 認為,未經重構,系統將會沒有空間來容納新功能來適應新的變化驅力;未經測試,開發者不會知道系統邊緣在那裡;未經整合,生命火光將逐漸消散。

Organizes itself to the edge of chaos where co-evolution happens. – Complex Adaptive Systems (CAS)Without refactoring, there is no room for plugging in new functionality to adapt the coming force.

Without testing, we couldn’t know where the edge is.

Without integration, the spark of life will die out.

As quoted by Kauffman, there are three things that allow a system to get to the edge of chaos and stay there:

It has to be confined to a small portion of the vast space of possibilities.

It has to be stable enough that it doesn’t disintegrate into chaos when the slightest change happens.

It has to be balanced between statically dead and the hyperactive “chaotic regime.” [Chaordic]

What we end up with in Kauffman’s world is a set of self-ordered adaptive agents, exploring their way through a vast space of possibilities, with stable flexibility that allows novel “leaps” to new fitness peaks. The specific outcome is unpredictable, and undirected. In Kauffman’s view, Darwin wasn’t wrong, just simplistic and incomplete…Thinking about software development as an effort to grow something, instead of as an effort to manufacture something. – Roy Miller, Managing Software for Growth, Ch6 – Order for Free.

Peter Ho 並引用 Kauffman(著名生物學家兼複雜系統研究者)的觀點指出,有三件事可以讓系統到達混沌邊緣並且停留在那裡,那就是:必須把廣大的可能性限制在一小部分、必須保持足夠的穩定,即使有輕微的改變,系統仍不會崩解成混沌一片、以及必須在靜止不動的死寂與過度活動的「混亂政體」間達到平衡。

最後,Peter Ho 告訴我們,從 Kauffman 的世界觀來看系統,是一套自我維持秩序適應的代理者,從可能性的廣大空間探索他們的途徑,藉由穩定的彈性,允許新穎的「跨躍」,以適應新的高峰。特定的結果是無法預測的,並且是無從指導的。當然,Darwin 並非錯了,只是過分簡化及不完整。而以軟體開發的角度來看,不要把軟體開發思考成為製造一些東西而努力,而是要思考為成長一些東西而努力。

所以,關鍵不在核心,而在邊緣。找到混沌與秩序的交界點,停留在那裡,讓自我組織突現能不斷地發生,自然演化出系統的複雜行為,所以,系統複雜性無法靠預測、指導出來,而是系統自行依據環境變化,自然而然地演化出來的呀。

雖然,複雜理論的觀念或許太新,並不是那麼容易讓人接受。但身為軟體開發者,可不要忘了,軟體開發中,不同知識的整合卻攸關了軟體開發的成功與否。誠如同人在〈你憑藉什麼知識來「做」專案呢?〉中所說的:

稱職的專案經理所憑藉的是運用專案管理的專業知識整合軟體開發經驗知識與使用者現場知識,而專案管理知識最難掌握的是人的問題。

其實每個人都是某項特定知識的載具,若軟體專案的 stakeholders 之間,未能做有效的良性互動,知識就不可能相互激盪而產生火光,調適出適當作法而為專案產生出創意及價值。此時,工藝技術只是工藝技術,工程流程只是工程流程,它們都會跟軟體開發沒有任何關係,變成只是片面的零散知識。所以,不管軟體開發是工藝還是工程,最重要的還是讓不同觀點能夠適當的運用、調整與熟練,這才是優秀的軟體開發者應有的態度呀

Powered by ScribeFire.



附註  
  1. Dean Leffingwell & Don Widrig (2003), Managing Software Requirements: A Use Case Approach, Second Edition, Addison Wesley Professional.[]
  2. 同人曾聽過黃世禎老師主張過這個觀點。[]
  3. 請參考曾昭屏譯(2006),溫伯格的軟體管理學,經濟新潮社,初版。[]
     

7 Responses to “軟體開發是工藝還是工程?”

  1. [...] 軟體開發的知識是築基於實務中的理論,在學校中所能夠學到的,總是比產業的腳步慢上許多。所以有志於程式設計工作的人,從學校畢業以後,他還是必須從實際的軟體開發過程中不斷地磨鍊其編程基礎及技巧。依同人實務所見,程式設計基礎與開發者是否科班出身沒有關係,但卻與開發者對程式設計的興趣及熱忱有關。 [...]

  2. [...] 軟體設計是一種求取均衡的取捨,而取捨的關鍵視軟體欲解決的問題而定。正如同人在《軟體開發是工藝還是工程》中所提到的,軟體開發的本體並不在工藝,也不在工程,而是一種問題解決的過程。依此觀點來開發軟體,我們一開始會用最簡單且直覺的編程方式把軟體的功能做出來,然後再隨著需求的改變,逐步演進程式碼及設計架構。用複雜性及複雜適應性系統的概念,找到混沌邊緣,組織系統讓複雜行為自然發生,如此演化所形成的系統將具備穩定與彈性。 [...]

  3. [...] 軟體是工藝或工程?同人認為都不是,而是問題解決的過程,這也就是我在技術面談的,重點在心態問題。什麼樣的心態?對問題採用合適的技術,並予以”調適”,然後熟練之,第一件事就是分析問題,問對的問題,而非許多技術人員習慣的用技術來主導問題方向,這才是我說的紀律,所我我才會說:”經由穩定及可見的觀察、假設後的求證、尋求問題的對策、最後再採取行動解決的過程,經驗往往是最不可靠的東西之一。態度才是決定技術得以成功的決定因素呀!” [...]

  4. [...] 軟體開發是工藝還是工程? 穩定的程式是偶然? 程式碼的結構、迴圈與處理 Time-Boxing [...]

  5. [...] 紀律,也就是 discipline 這個字。它的意義並不是做我們過去熟悉的事,而是熟悉了解問題是什麼,並加以解決問題的過程。如同我過去的文章所強調的,軟體開發不只是工程,或是工藝,而是解決問題的過程。敏捷開發其實並非依賴制式的軟體開發流程或方法,而是基於重要價值觀與原則發展出來的實務,而最重要的價值觀就是為了思考如何「解決問題」,至於使用流程方法都只是手段而不是目的。 [...]

  6. [...] 這正是同人想突顯和另一篇有關系統開發複雜性的文章〈軟體開發是工藝還是工程〉最大的不同,也算是對我最近兩年在系統開發所行、所思、所得,做一個比較全面的整體論述。系統開發真的需的有效的方法,但沒有任何一套方法可以忽略人的因素而能夠正確無誤地運作。 [...]

  7. [...] 這是因為軟體開發是解決問題的過程,適應性比穩定性或效率更重要。不能適應解決問題所需情境的穩定或效率,只是徒增浪費-亦即不精實、與品質不良-亦即不敏捷,而無法解決問題。故軟體開發團隊應該採用效法雅典娜的精神,致力充實精良的技藝來完成任務,講求整體目標的達成,而非只是盡義務完成個體角色的責任。因為這樣很容易讓人因為不明究理而犯錯,強調阿波羅習慣的做事常規,容易使團隊僵化而形成官僚特性。 [...]

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="">