前言
筆者多年來輔導過諸多不同類型與不同領域的軟體開發專案,本身的職務是擔任軟體架構師(Architect)與顧問輔導。架構師不是只負責技術面的問題,更要兼顧到專案開發的過程中, 」人」 的互動所衍生而來的諸多問題,包括想法的歧異、見解的落差、不同的觀點與角度,甚至情緒問題等等,這些都需要與專案經理協同合作,一同來解決問題。
軟體的開發,最終目標雖然是 「完成高品質」 的軟體系統,但在進行階段過程中,所衍生出的兩大議題—專案管理(Project Management)與開發流程(Development Process),卻是首要需克服的階段目標。而該兩大議題,均是係以 「人」 為核心的考量,專案管理講究的是 「領導統御」、」人和」;開發流程重視的是 「調和 (凝聚團隊成員的觀點、角度,保持產出的一致性)」。專案管理的部分,筆者的角色比較不方便闡述(此一部份由專案管理者來論文比較妥當),倒是相關於開發流程的議題,筆者倒是可以把藉由所觀察到諸多各形的開發型態,以及個人的一些研究、學習、思考與體悟的心得提供給讀者參考之,文中內容會是筆者比較偏以 「主觀意義」 的表達。
變動無常的軟體專案
軟體系統的專案開發,特別的是,需求往往不明確,更何況是經常處於變動中,所以導致專案的範圍與規模無法界定,連帶也引起時程無法估算(人月? 神話吧)。那麼,是不是開發成本的成本也無法預估,而往往也因為成本與時程的低估,更容易導致品質不佳、粗製濫造的軟體系統。
正是由於軟體別於如硬體產業的變動性問題,使得在其它成熟領域的專案管理經驗,並不容易全盤導入至純粹是軟體的系統開發上。若是把軟體開發當成是知識與創新的產業,那麼一成不變且僵化的專案管理方式,並不妥當;除非是將軟體產業當成是軟體工廠,需求固定且明確,工作者(worker) 各司其職,負責實做局部的小功能,再由 「大一點」 的工作者,來組裝成大功能。請記得,這樣的方式,其假設前提是需求不容易變動,工作者也不太需要具備創新獨立思考的能力。
個人是很難相信需求不會變動,同時也認為正是因為軟體的多變性,才造就了更多的好機會,所以軟體的開發,不應該視善變為畏途,反而是把變動看成是理所當然,更是多添了許多的好機會。我們所要作的事情只是,如何將變動抑制或收斂在某一程度可以被控管的範圍內,同時,學會如何在某一問題領域(Problem Domain),重覆性、同質性高的軟體系統,來找出不容易變動的部分,成為系統的框架(framework),或稱之為主結構(Main-Structure)。而容易變動的部分,又是如何從主結構中抽離出來,爾後只花少許的 「工作量(effort)」,就可以輕而易舉的滿足客戶的需求。
很難嗎? 只要有兩個滿足的要素即可:一為開發的資源(包括成本與時程)多一點;另一為團隊對軟體的基礎養成與默契好一點。 但是好像要能滿足這兩點可真是困難,該如何才有可能達成這種 「夢幻」 的要件呢?
這就回到最現實 「人」 的因素了,要能爭取到多一點的開發資源,如果你沒有什麼誘因吸引老闆或業主(兩者可統稱為關係利益人, stakeholder),是不太容易的。專案的領導者總是要有 「實績」 才能讓關係利益人信賴並願意投入資源,而資源越多,當然專案成功的機會就更大。後文會提及,「反覆與漸增(I&I, Iteration and Incremental) 」,會是提升專案開發 「實績」 的好手段。
再探討另外一點,如何才能讓團隊成員對軟體的基礎養成與默契好一點? 默契要好,溝通必然要多,要能溝通多,當然就是要勇於把自己的想法給表達出來,而這些,則是有賴於專案領導者的支援與協調。總之,好的專案領導者是要能懂得 「觀察」 在整個專案開發的過程中,成員之間互動所衍生出的種種問題,然後找出 「解決方案」 來謀和 「人」 的問題;另外回到最根本的是,畢竟這是軟體的開發,軟體的基礎養成功夫不足,當然也不太可能作得好軟體開發,軟體人員持續的學習與成長,更會是軟體產業的命脈。
幾個可能是軟體開發流程的問題點
正是由於 「變動無常」 的軟體開發專案,有些人的想法是想要 「凍結」 住需求,然後依照固定不變的製程,一個階段接續下一個階段以循序式 (Sequential)的開發產出 (artifacts),例如預估一年開發期的專案,三個月的系統分析(SA, System Analysis)、三個月的系統設計(SD, System Design),六個月的實做與測試(Implement and Test),這樣的開發方式稱之為 「瀑布式(Waterfall)」 的開發流程,參考如圖1。 繼續閱讀 »

訂閱 RSS (by FeedBurner)
訂閱 RSS (by Wordpress)![[克莉絲汀] 水晶串珠手機吊飾-天使](/wp-content/medias/ads/opus/DSC02907.jpg)
