jim yeh on 七月 21st, 2009

本文於 2009/07/22 經 ZDNet Taiwan 部落格文章專區轉載

facebook 看到舜平學長提到「求快求彈性忽略系統文件的後果,找了兩個小時的BUG」讓同人想寫一篇文章來談談系統開發的彈性。

舜平學長說求快求彈性,忽略系統文件重要性的後果就是使用者說沒空寫文件,如果這時我們也沒有將系統重要資訊記錄下來,那麼就算是自己也會因為時間一久而逐漸淡忘這些資訊,結果使得系統的維護變得更加困難。

雖然以上的現象在台灣是開發者經常碰到的問題,但那是否代表系統開發追求速度與彈性,就必然犧牲文件與流程呢?同人認為這樣看就太過簡化了,系統開發的彈性並不是忽略系統文件與流程,而是只重視有實質效益的一切事物,當然包括文件與流程。

「彈性-快,是之前老闆說的。常常就是邊想邊做,搞死 IT 人員」舜平學長提到他對彈性的認知。但這種對彈性的定義有沒有問題?我們追本溯源,從教育部國語辭典可以查到「彈性」這個字詞有兩個解釋:

物體受外力作用,會改變其形體,而當外力除去後,即恢復其原狀,此種性質,稱為「彈性」。

比喻事情無固定標準,而可隨機調整。

從這裡可以看到舜平學長提到彈性的定義,是採用彈性的第二個解釋。指系統開發這件事沒有固定標準,必須隨著需求改變而機動調整,以達到讓系統快速適應變化的目標。但事實上正如學長說的,搞死 IT 人員,而系統也不斷發現問題叢生的問題,這樣其實並沒有達到彈性可隨機調整的標準。

開發系統臨機應變,不去根據未來可能的改變而計劃,而是面對當前需求的改變而修正系統,可以讓開發者不把時間浪費在無謂的預測上,迅速地開發出使用者真正需要的系統。但實際上為什麼卻並不是那麼一回事呢?我們可以從與系統開發相關的事、物、人來了解,彈性固然是沒有固定標準,但所謂的擁抱改變卻並不代表任由毫無限制的改變發生,那樣只會造成極度的混亂而使系統崩壞。

從事的角度來看,任何使用者需求都需要時間,而時間是取決於功能的複雜度。對於使用者而言,他們認為他們需要的功能都很簡單。但當許多簡單的功能集合在一起,其相互關聯的交互作用所產生的複雜度與錯誤,可能就會讓開發者很難應付。因此,開發流程的彈性,是用來決定該在什麼時候修改或增加什麼功能,以降低複雜度與錯誤的機會。

從物的角度來看,良好的系統架構有助於快速因應需求的變化。架構良好的系統具有強固性,不會因為系統運作環境的不同而產生功能失常。同時也具備擴充性與延展性,可以隨時依據使用者的需求變化而調整系統的功能。然而,通常在專案時間及成本的壓力之下,很難有時間能夠設計出最佳的系統架構來適應所有的情況,只能因應最主要的問題來設計適當的架構,並在必要的時候可以逐步演進系統功能,這便是系統架構的彈性。

從人的角度來看,專案具備來自不同利害關係人的各種面向。例如使用者通常在意的是他們作業的問題,系統能不能幫他們解決,開發者則在乎使用者提出來的需求是否精確,用來發展出良好的架構以增進開發的效率。這些不同的觀點常因為不同的需要、價值觀、專業、以及所用的語言不同而產生相當的落差。因此,溝通的彈性是在於是否能允許各種正反意見充分表達,進行對話與良性的互動,以建立資訊暢通的溝通管道。

因此,從系統開發相關的事、物、人來看,我們知道彈性的意義是追求快而不亂。這意謂著接受一定範圍的改變,而非任由混亂無秩序,那是一片混沌而非美其名追求彈性。彈性其實也需要計劃與紀律,只是和典型的開發方法有所不同。

如果開發者最早開發出來的系統,是可運作與架構簡明不容易出錯的系統,那麼隨著使用者需求的增加,為什麼會愈變愈複雜呢?這當然是因為時間緊迫與系統沒有足夠的空間可以容納新功能。

時間緊迫意謂開發者沒有時間增添或修改系統功能,原因通常是會干擾他正在進行的開發,而增加開發的複雜度與出錯機率。所以開發者應該延緩會影響現有功能的使用者需求,這才是追求彈性的做法,這樣就不可能邊做邊改;因為戴上修正功能的帽子時,是不應該去增加功能的。

那麼如果沒有足夠的空間呢?這時開發者應該著手改善系統架構而非疊床架屋勉強加入新功能。由於開發者以前可能對需求了解程度有限,所以很難開發出比較具有彈性的架構。等到對問題的了解愈來愈清楚,慢慢看清楚問題的脈絡與解決問題的模式時,這時正是改良設計的最佳時機。就是因為架構的改良,無所不包文件與繁複的流程自然不太需要,而是需要在開發過程有助溝通的基本文件與流程。

然而,開發者為什麼不修正架構以容納新功能呢?或許有些開發者以為架構不改變還是可以容納新功能,所以可以允許複雜度多加了一點。但等到下次,他還是會有同樣的想法,直到這樣的行為結構造成系統問題叢生的弊病才會發現事態嚴重。寫到這裡,讓同人想到《易經坤卦文言》所說的:

積善之家,必有餘慶。積不善之家,必有餘殃。

臣弒其君,子弒其父,非一朝一夕之故,其所由來者漸矣。由辨之不早辨也?

不去順應變化之道,讓系統不斷更新[1],這樣並非追求彈性的系統開發。充其量,只能算是擠壓開發者的彈性,這是彈性的另一種解釋;承受壓力後回復原狀的性質,但結果通常是讓開發者彈性疲乏。或許這就是舜平學長說的無言吧。

延伸閱讀:(其它與系統開發彈性相關的文章)
軟體開發是工藝還是工程?
穩定的程式是偶然?
程式碼的結構、迴圈與處理
Time-Boxing 於軟體反覆演進的必要性
資訊服務的適應性觀點
評論「專案假設」的相關討論
軟體開發能力的自我組織



附註  
  1. 坤卦順承變化趨勢,否則陰疑於陽必戰的結果是坤上六爻變的「龍戰于野,其血玄黃」而產生劇烈變化,最後還是會重新走向乾卦的自強不息。[]
     

2 Responses to “系統開發的彈性”

  1. [...] 或許有人會認為詳盡的文件可以增進溝通,但實際上它的成效不高而且常常要人們花費很多的心力,除非你發現它真的有幫助,否則你應該只需要寫必要的文件。雖然工具或方法論可以增進開發的效率,但它們也會讓工作變得艱難。因為無法被替除的工作,它們是更具備知識密集的特性,需要更有才幹的人來完成任務(DeMarco & Lister,2007)。所以在導入任何工具或方法論之前,你應該提醒自己,敏捷開發是以人為基礎,面對的是現實而非理想。 [...]

  2. [...] 同人這樣說不是代表技術才是解決問題的關鍵,而是解決問題需要因地制宜。我們每次碰到需要解決的狀況都不盡相同,因此都會需要各種觀點的參與,讓彼此產生互動,進行對話而共享意義。所謂的抽象化思維就是從不同觀點的互動中,經由演化而創造出全新的不同觀點;它既不是業務觀點也不是技術觀點,而是彼此交織之後產生有用的解決問題觀點。其實把抽象化當技術的繆誤,不單單只出現執著於業務觀點的情形,執著於技術觀點也會犯了相同的錯誤;以為堅守特定觀點就可以解決問題,然而這樣的繆誤讓我們缺乏解決問題所需要的彈性呀。       Posted by jim yeh 分析設計建模, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 衝突 Subscribe to RSS feed [...]

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