[推薦序] 溫伯格的軟體管理學-擁抱變革(第4卷)

溫伯格的軟體管理學:擁抱變革(第4卷) 溫伯格的軟體管理學:擁抱變革(第4卷)
Quality Software Management, Volume 4:Anticipating Change

-----------------------------------
作者: 傑拉爾德.溫伯格/著
譯者:何霖
出版社:經濟新潮社
出版日期:2012年05月20日
ISBN:9789866031137
語言:繁體中文

這是我在今年五月出版的溫伯格著作-「軟體管理學:擁抱變革(第4卷)」所為其撰寫的推薦序文。從該書的主軸-改變 (Change),作為我這篇推薦序文的核心思想,所以我把序文主題定為-期望改變又不想受傷害的軟工思維

《溫伯格的軟體管理學》這一系列共出版了四集,每一冊看來都很厚,好像閱讀起來也吃力,但其實如果能抓出作者的假設點,就能掌握出閱讀的目標與方向。若是問我這四冊各用一個字詞來表達主題,那就是:整體、觀察、溝通、實踐。這四項因子,也正是軟體專案開發成功與否的主要關鍵。

我們並無法完全移植其它成熟產業 (如建築、硬體製造業)的成功經驗到軟體這個領域來,原因就在於「變動 (Change)」這個最根本的因素。因為變,所以無法事前規劃精密的藍圖再據此施工;也更因為善變,軟體專案無法採用代工業的 IPO (Input-Process-Output)亦即瀑布式 (waterfall)的管理模式。

不是要抑制變動,而是要能順應變化;對軟體專案唯一需要保持的信念,就是要不斷作出改變。

當面對軟體專案多變複雜的特質,第一步就是要能掌握住整體,這也是溫伯格第一冊開宗明義所提及,我們所需要的正是「正確的思考」,也就是系統化的思考,因為唯有如此,我們才能「明白自己在做什麼」。系統化思考就是一種架構觀 (architecture view),而架構並非單指 IT 系統如三層式 (3-tier),我寧願稱呼這為實作面的分層結構框架。

誰需要對軟體專案有全貌認知的系統化思考?個人以為兩種角色是必要的-專案經理 (project manager, PM)與架構師 (architect)。這兩種角色都是在作調和的工作,專案經理調和的是人,架構師調和的是技術。

閱讀全文 »

[軟體開發] Iteration 與 Release 的差異

現代越形複雜資訊系統的開發,尤以要應付快速變動性的議題,幾乎所有的主流開發流程,包括 UP (Unified Process), XP (eXtreme Programming), Agile 等不論重、輕量型的流程方法論,均一致強調反覆 (Iteration)漸增 (Incremental) 開發的必要性。 關於反覆式與傳統瀑布式 (WaterFall) 開發的比較說明,請參考先前我寫過的一篇:「從軟體架構師(Architect)的觀點來看軟體開發流程」。

I&I (Iteration and Incremental) 的開發模式,已逐漸成為軟體開發的最佳實務 (Best Practice)。 但是, I&I 開發模式的實踐與否,只有在軟體開發團隊的內部才知道;對於客戶單位,他們是不知道,也不可能瞭解委外軟體廠商,內部是運用什麼樣的開發模式。

所以,外包的委外軟體開發專案,若是使用 Iteartion 的開發模式,該如何計價收費? 或者,某大型公司的 IT 單位,規範了外包軟體廠商,必然要遵循該公司所制定的開發流程綱要。 這兩個可以說都是相當奇怪、卻也常見的問題與現象。

我先說明第二個那個怪現象‧‧‧

IT 單位規範外包廠商的開發模式,一點意義都沒有。 因為,客戶根本看不到委外廠商內部是如何開發的。 即使你強調希望委外單位能走 I&I 的模式,但是,他要掛羊頭賣狗肉,你也沒轍,因為,從最終產出 (Artifacts)來說,你根本無法知道委外單位是採取何種開發模式來完成的。 客戶單位只能要求說,委外單位要能在毎一個議定的階段時間,要能達成分次交付的產出甚或可以早些釋出 (release)、可以完整被執行的功能案例。

客戶單位所制定每一個該付交產出的階段時間,這個應該是稱之為 "Milestone (里程碑)",完成每一個階段的交付,也可以及早瞭解委外單位的釋出品質,或作為下一次交付的回饋 (Feedback):而若是要求儘早能看到可被執行的部分功能案例(或模組),這稱之為 "及早釋出(Early Release)"。

再回來討論第一個問題,採用 "Iteration" 開發模式該如何計價?

閱讀全文 »

寫好使用案例 (Use Case)有什麼好處?

上個月我在「工研院」授課時,其中一位較為資深的程式開發人員問的問題: 我感覺不到寫好使用案例 (Use Case) 有什麼好處?

別誤會,這位年輕的開發人員並沒有惡意,我也認識他一陣子了。他的確是有感而發,覺得在工作上,從以前透過一般的需求規格書,到現在開發時導入 使用案例 的分析需求技術,但是,他並沒有感受到因為這樣而有加快程式撰寫的速度,反而還覺得縛手綁腳,經常需要受到規範。

這個問題,可比想像得還難以回答。 是為了可以有效保存需求分析的資產? 還是為了系統的彈性 (flexibility)? 前者似乎有道理,但如此對現在正進行的開發專案好像沒有說服力,甚至開發人員還覺得為了要補足這些需求文件,反而拖累了開發的速度;後者的系統彈性問題,我則是很確定與寫得好需求分析文件沒什麼直接的關係,彈性度的考量,與軟體的結構設計 (structure desgin)才是更主要的關鍵。

思考許久,我是以為,寫的好使用案例最直接的關鍵是: 影響到專案開發整個流程的節奏!

以使用案例為導向 (use case driven)的開發模式,我的體會是越來越能感受到那個所謂的 "driven" 這個字眼。 短線專案的特性,幾乎是偏以需求為優先。而使用案例的分析,其本質上仍是屬於功能 (functional)性的分析。只是有別於模組化的功能樹分析模式,後者的功能模組,耦合性 (coupling) 太重,容易牽一髮而動全身,所以在需求分析階段,會耗費許多時間在分析共用模組的考量;而使用案例,是一種目標導向 (goal-oriented)的功能分析方式。 每一個使用案例,都可以看待成是系統在某一段期間 (session),可以滿足使用者使用系統的目的。 所以每一個使用案例,是可以個別被獨立開發,也就是說,UC-A 與 UC-B 甚至可以交付給不同團隊並行開發。而至於兩者若有共用性的議題的考量,則是延宕到結構設計階段再來討論即可。因為在需求分析階段,不用花太多時間在共用議題的考量上,所以可以很快速地實現 (realize)功能需求。

能抓得好與定義得好一個一個的橢圓使用案例,就能以該使用案例為開發單位。 這麼說好了,甚至可以把該使用案例就當成是一個迷你系統,然後來串連出整個開發的程序與產出。 例如,針對一個使用案例,就會設計一個位於中間層 (middleware)的控制型物件 (control object),並從使用案例的敘述 (use case description)中,找出該物件應承擔的行為 (behavior),然後再轉化成更詳細規格、程式語言的方法 (method)。 定義好控制物件與其應有的行為,就可以知道需求分析是容易並可以無縫式地轉移到實做階段,並快速地界定出程式碼的骨架 (sketletion),再來就是補足細節、實做邏輯、連結資料庫或外部系統 等等…。

閱讀全文 »

關於軟體開發「需求獲取」的幾個問題來信回覆

近日有位來自大陸對岸,就讀軟體工程的同學 Email 來信問了我關於需求獲取的問題。 很難得,並不算是問我 How-to 的問題,而我也覺得他問的問題還挺有意思的,所以也把我個人對其的回覆公佈分享出來。

2009/3/24 cnlogn

王克明老師,您好。
  我是一個初學軟件工程的學生,正學到需求獲取。因為仰慕佛教的無遮大會的問答機制,又無意間撞到濛濛的秘密基地,發現了前輩(有緣分),於是冒昧請教。
  我知道需求信息來源,獲取方法/技術。那麼什麼是需求獲取策略?
  我知道需求三個層次分別是業務需求,用戶需求和功能需求(非功能需求)。那麼什麼是客戶需求?什麼是產品需求?
  為什麼把領域分析和業務建模放在需求獲取階段?此致
敬禮

2009-03-24

Cnlogn 同學您好:

  1. 與其說需求獲取的方法/技術 是一種策略(strategy),倒不如說是一種態度。 什麼態度呢? 因為知道不可能一次就能很明確地從使用者端得到正確詳細的需求,所以,需求分析師 (Requirement Analyst, RA)不會也不應該一開始就想要得到所謂正確的需求,而會是以漸增、漸進的方式 (Iteration and Incremental),從一個所謂的功能單位(例如 Use Case),逐步地從目標框架,往精確度要求。 所以這是一種目標導向的作法,先確立目標,再來往細節調整。
  2. 我覺得是不應該去硬背那個什麼三個層次的需求。應該是說,需求會透過多種不同的角度,理解與紀錄各個不同使用者角色的需求。 包括整體性的業務流程面、包括操作員 (Operator)對系統的局部功能要求、包括整體使用者對系統關於穩定、效能、彈性等非功能性的滿意度需求… 等等。 需求的面向 (View)是很多面的,RA 要能擅長透過多種不同的觀點來看待需求面。
  3. 我不會硬性定義所謂的領域分析與業務建模是放在需求獲取階段。 關於分析、設計、乃至實做測試等工作,會是快速跑過一整個循環 (Iteration),再取得回饋 (feedback)來持續修正調整的。 軟體工程把製程 (Process)固定下來的前提是需求穩定不變,問題是,軟體又不同於其它成熟產業領域的關鍵就在於,需求一直持續地變化。

我曾經寫過一篇:「從軟體架構師(Architect)的觀點來看軟體開發流程」,您可參考看看的。

Best Regards.
Kenming.

{iThome 書評—16} 敏捷軟體開發—原則、樣式及實務

副標題:敏捷的開發首重的是人與人的共同合作、自我組織良好的團隊。人不是如同組成系統的元件,可以隨意被抽換的。

敏捷軟體開發:原則、樣式及實務 敏捷軟體開發:原則、樣式及實務
Agile Software Development: Principles, Patterns, and Practices
———————————–
作者/Robert C.Martin /著, 林昆穎、吳京子 /譯
出版社/碁峰
ISBN/986-154-148-9
Amazon 評鑑:五顆星

內容簡介
暢銷書作者及舉世聞名的軟體開發專家Robert C. Martin展示了當今軟體開發者、專案經理與軟體專案領導者如何解決眼前最具挑戰性的難題。這是既全面又實用的敏捷開發與極致編程的教學,由敏捷開發創始人之一所撰寫。教導軟體開發者和專案經理如何使用敏捷開發的威力,讓軟體專案如期完成又能符合預算。

* 使用真實的個案研究來展示如何運用極致編程進行規劃、測試、重整、以及搭檔編程。
* 包括豐富而可復用的C++和JavaTM程式碼。
* 專注於使用統一建模語言(UML)與設計樣式(Design Patterns)來解決以客戶為導向的系統問題。

前言

本書原著在 Amazon 評鑑是極為罕見的五顆星滿分! 書籍也是少見的厚,有近 700 頁之多。 如此深厚的內容,可不像坊間一堆可拿來當枕頭的所謂 OOP 入門書一般,盡是充斥著圖形設定教學與程式碼,沒啥內容。 套一句 John Vissides (Design Patterns 之一作者)在引言上所推薦的:「這也許是第一本將敏捷方法 (agile methods)、樣式 (patterns),以及現代軟體開發方法交織成連貫的整體。當 Bob Martin 開口,你最好洗耳恭聽。」 六年! 是作者在這麼多年來所深刻體會到的軟體設計和開發經驗,而本書也可說是反應了作者自身的學習成果。

本書描述了軟體開發議程的三個主題:設計原則 (principle)、設計樣式(pattern),與開發實務(practice)。當軟體開發人員面對的是需求快速變動時,如何具備迅速的應變能力,而表現在開發的過程中,即為敏捷性的開發;為了達成敏捷性,所以開發團隊要能有某種程度的共識以及具回饋 (feedback)的實務作法;利用專家與前人所提供的設計原則,使得軟體能具有彈性與易於維護;而如何平衡這些設計原則,所以也會瞭解到在特定一再重覆的問題上應用設計樣式。作者就是嘗試著要把這三種觀念成有一個有效的整體。 我覺得書中最大的特色就是,會藉由許多案例研究來說明與示範如何應用上述三種觀念,而且這些案例並非是最終的完成品而已,而是正在進行中的開發,所以讀者也會看到這些設計者所犯下的錯誤,然後他們又如何發現錯誤,進而改正錯誤。

軟體開發的關鍵在於人,而不是製程

本書的目錄綱要編排,正是反映了上述作者想傳達的三種觀念,所以分為六個篇幅,第一、二篇論及的是軟體開發流程的最佳實務與能符合最佳實務的敏捷設計原則;後四篇則是藉三個案例研討 (薪資、氣象臺、教育測驗服務),如何應用設計樣式,來解決一些特定的實務問題。再來就是四個附錄。前兩個附錄算是對於 UML 的語法說明;而附錄C (兩家公司的諷斥),挺特別的寫作方式,每一頁是個別描述兩家公司各自不同的開發方式,一個採需求凍結的瀑布開發、另一個採敏捷的反覆漸增開發。是一篇挺有趣的寓言式寫實故事;附錄D則是摘錄 Jack Reeves 的一篇論文:「原始碼即設計」。我覺得該篇論文真的可以精讀,可以引導與觸發讀者思考,什麼叫做軟體設計。

每一大篇,都可以各自拆開獨立閱讀。軟體開發人員,若想對樣式作個一般性的學習,可以閱讀敏捷的設計原則;而想知道作者是如何應用書中所介紹的設計樣式,則可以參考書內的三個案例研討;而若是專案經理甚或老闆,專心研讀第一篇關於敏捷式的開發流程,絕對會對現實的專案開發與管理的議題上,有很多的體會與啟發。

尤其一開始本書所揭露出來的敏捷軟體開發宣言,我覺得是相當務實地揭露出軟體開發的本質— 流程和技術是影響專案結構的次要原因,人方是關鍵要素。 太多老闆與專案經理們總是常會把他們總是很關心人的永續成長之類的話掛在嘴邊,但是又往往想要創造或導入出一套流程,藉由許多管理工具與各階段的製程產品,用來約束開發人員的活動。而靠一些約束與產出(通常是大量的文件),但錯誤仍持續不斷發生時,管理人員卻又在某些地方設定更多的約束和產出 …,這種造成負回饋的循環,使得軟體人員過度負荷了龐大笨重的流程,而嚴重妨礙了完成工作的能力,並因而喪失了軟體的創意設計能力。

奉勸許多老闆與專案經理們,不能再自欺欺人了,仔細審思敏捷宣言所揭露出來的價值觀吧:
o 個人及互動勝於流程與工具。
o 可用的軟體勝於詳盡的文件。
o 與客戶合作勝於合約談判。
o 回應變更更勝於墨守計畫。

敏捷開發的主張—程式碼即為設計本身?

本書在“敏捷式的設計”一篇中,所引用自附錄D Jack Reeves 所主張的:「真正能符合工程設計標準的唯一軟體文件就是源碼的列表”。本來我還以為敏捷開發的主張是將程式碼當作是設計的一切,這我當然是無法認同,這可是會給一些程式設計人員藉口,只寫程式卻不需要有其它的設計文件。 我是一直覺得,程式碼既是設計(沒錯),但同時也是設計最現實有效的產出 (artifacts)。而程式碼的呈現是綜合了包括多個觀點與層面的設計,諸如需求、結構,甚或架構,而這些是需要透過其它如設計圖,突顯出設計的焦點而隱藏了程式碼不必要的細節。還好,後來我很用力地研讀並思考 Reeves 論文的意涵,他應該指的是,程式碼本身就是一種設計。是的,這一點我是相當認同的,還有就是千萬不要認為 “設計就是一組與程式碼分離開來的 UML 圖示。”這麼說好了,我是一直這麼認為: UML 設計圖與程式碼都是設計,是軟體系統的一體兩面。”所以,個人一直主張,設計圖要作少、作精,不要作不必要的文件,且必然要時刻在開發的過程中保持與程式碼的一致性。

對於開發人員而言,要能看得懂本書所介紹的設計樣式,那就要先瞭解本書所揭露的設計原則,書中介紹了五種設計原則—SRP, OCP, LSP, DIP, ISP 等,全名與細節我就略過不提了。其實這些就是所謂物件導向式軟體設計的基本功與思維,諸如物件的責任分派、封裝的設計、相依性的分析、多型與介面的設計等。還有,讀者要瞭解,這些設計原則不是為了協助你把東西做出來,而是讓你消除程式碼的壞味道,設計壞味是一種症狀,是某種可以被主觀而非客觀量測的東西,會讓系統僵化而難以維護。不過適可而止就好,設計原則並非可以在系統中任意地到處噴灑的香水,過度遵從原則會導致不必要的複雜度的設計壞味。

書本雖然厚,討論的主題涵蓋也廣,但是內容還蠻淺顯易懂的,翻譯的品質也是相當不錯。每一個章節前頭又有很棒很炫的插圖,甚至還有作者引以自豪,是其女兒散佈在各章節裝飾性插圖的可愛作品。還有若是像我不是那麼珍惜書本完整性的話,甚至也可以將各篇分開拆下來,這樣外出攜帶時閱讀就不會那麼厚重。 看到如此言之有物的專業書籍,又不難懂,可以說是生命的喜樂之一。

聊聊 DoDAF/MoDAF 規格與實作議題

上上個星期,應國防某單位要求,希望由我們利用 EA(Enterprise Archiect) UML 工具,藉由一個案例,來展示在順應 DoDAF 規格下,如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖,以及又該如何導出到實作,尤以後者,對他們很困擾,一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具,因為 EA 其中一個 Plugin 產品,稱為 MDG for DoDAF-MODAF,兩者的搭配,應用的是 UML Profile 機制,可以充分完整支援 DoDAF 1.5 的設計規格。 說真的,工具沒啥好介紹的,況且席間諸多長官與教授們問最多的問題就是有沒有 “自動化” 的機制,可以從某一個 View 的設計圖,自動轉化到另外一個 View 的設計圖。這個… 我總覺得他們研究的方向會不會有問題? 我只能反問:1. 如果規則明確,例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話,那麼工具當然可以支援。 (可想而知的答案是,當然沒有那種必然明確的規則) 2.能不能轉到程式碼? 這些我都覺得都不是問題耶,前提是有沒有那種確定的規則? 有趣的是,他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具,也沒有支援他們 “心目中” 的自動化啊。 所以我開玩笑的說,好吧,把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價,用來委託我們開發那個自動化的 Transform 機制,保證可以幫你們生的出來,不過前提是要能給我們明確的轉換規則。 🙂

我可不會想賺工具的錢啦,要能懂得設計符合 DoDAF 架構規格的系統,要具備的是軟體設計基礎功夫的底子;要能有整體性的架構觀,要知道什麼時候該封裝、什麼時候該打開,分析系統的內部;要懂得如何把一個看起來好像很大的系統(關於系統的定義,可不一定指軟體系統,在這種大格局下,包括企業單位,都可能是一個系統),該如何大題小作;又懂得那個時候該具焦在某一個焦點上,然後小題大作。 這一種整體性的設計思維,正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是,我們可以協助國防某單位,如何具備能具有規劃 DoDAF 架構設計的技能(Skill),與相關軟體設計的基礎功夫,以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主,如果可以的話,規劃成一個外包的專案更是好,然後從實作的過程中帶著學習,作中學的效果會更好的。 不過前提是,我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統,一般當然就是出個題目了,這一向是我個人最為意願的了,比較容易在短時間內取得雙方之間彼此的信賴與共識;也比較現實,會就會,不會的話早一點出局,最不囉唆了。 喔,還有,這是繼我十餘年前從志願役中尉預官退伍後,再一次能回到軍中,為國效勞的好機會呢,哈。 😀

由於國防某單位最近忙了些,等了幾星期,還是沒拿出案例讓我們來演練,所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢,這個案例是沒有與軍事任何單位有關連(正因如此,才能拿出來公開分享),完全是充滿想像;也沒有軍事專家的協助,所以需求必然是謬誤百出。不過這也不是什麼困擾,因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助,那麼就很容易可以調整修正,來符合正確的需求了。

整整花了四天的時間,投入了約 2.3 個人力,以一個我們所想像創造出來的案例,也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統,透過偵測與防衛系統,發現到敵人即將進軍來襲時,是如何即時協同陸、海、空三軍暨後勤補給中心,來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔,甚至連那個表達 OV-1 的概念視圖,都還是請美工畫出來的呢,效果十足! 老實說,個人對我們團隊能在如此短的時間內,就能規劃出如此大的架構格局,甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 “潘朵拉密盒”,可說是成就感十足,也算頗引以為傲。

ea_dodaf_demo
圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯! 在座許多高級長官以及教授們在會後的許多問題透過我們的解說,也算能得到合理的解釋。也讓許多中、上尉的資訊官們,見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的),所以到是可以藉由公開發表這一個案例,除了展示是如何實現 DoDAF 規格,並大概解釋一下每一個 View 的 精要(essential)設計意涵為何,同時也算是藉由此,來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal