談談"Change over Plan"與"People over Process"

作者：
這次辛樂克怪颱侵台，重創台灣，其中后豐大橋斷橋，造成1死5失蹤的大不幸事件，照理颱風來前就必須封閉該危橋，但事後我們的官員說依照「程序」處理，這種說法讓我想起陳振炎教授文章所談的敏捷方法，我曾在其「意見」箱內談到，使用任何敏捷方法時不要忘記敏捷宣言的精神，我認為宣言的精神不但使用敏捷方法時必須時時在意，處理日常事務亦須念茲在茲，宣言第四項"Responding to change over following a plan"，"plan"可解釋為一種「程序」，程序故然重要，但反應變動應高於程序(不含法律)，這位官員在這個時候的這種說法有待商榷，也許他的字典裡沒有「敏捷」這種東西吧!

敏捷(agility)最重要的定義是：快速與彈性反應改變(rapid and flexible response to change)，或說"embrace change"，change就是一種變動，能快速並彈性處理各種變動(如封橋)才符合敏捷精神，因此如能活用敏捷之義，其功能大矣! 總之，如果不懂embrace change，可能會誤用各種發展「流程」的真義，我們可以看看CMMI ML5：具調整與修正流程的能力‧‧‧，(本部落格中鄭有進教授文章：CMMI是什麼？)，將發展流程客戶化就是調整與修正流程，可想見使發展流程適合自己專案之需的重要性，但這要靠人，所以說"People over Process"。
屬人生「古來稀」族群，現在頭銜：國立中央大學資訊工程系(所)榮譽教授。謹希望借重「輕鬆談軟工」部落格讓學界、工商界以及具有決策權的官員注意軟體工程對各行各業的影響，進而重視台灣軟體工業的發展。

留言

  1. 匿名2008年11月2日 上午8:45

    政府訂定一個流程要比訓練一批可用的人（夠敏捷的人）容易的多。所以每天關起門來拼命的定流程，如果也有檢驗政府流程的檢驗方法，也許我們的政府已經是 CMMI Level 5。

    有沒有檢驗『敏捷度』的方法呢？

    回覆刪除
  2. 黃為德2008年11月2日 上午11:03

    有一句片語說"one size fit all"，在軟體發展上這個說法是行不通的，例如Unified Process(UP)雖然並非那一國政府所擬定的軟體發展流程，但已成為de-facto標準，當初提供這個發展的三位專家Ivar Jacobson，Grady Booch，以及James Rumbaugh也不主張使用者嚴格遵循UP的規定，可依軟體發展專案的需要，將UP「客戶化」(customize)，因UP是一種流程骨架(process framework)之故。同樣道理，由政府訂定一個流程讓全體軟體發展者遵循，是危險而且不可取的（許多官員很喜歡這麼做以顯其權威性），因為這種流程不能"fit all"，當然行政流程必須由政府擬定標準，否則會各取所須，天下大亂，但軟體發展流程不同，我不反對各單位有自己的標準流程，即使如此，這種標準流程並不能fit all projects，須視project的特性有所修改，否則無法應付需求的不段變動，這就是本文"Change over plan"的用意，（全句應為"Responding to change over following a plan"，我不擬此時對這句「敏捷宣言」多做解釋，將來有機會再為文討論）。至於『敏捷度』不知所指何意，我想大慨是指軟體發展管理的一環，不過我要強調的是，使用敏捷方法並非沒有管理、預測與度量(metrics)，也非閣下所言「訓練一批可用的(夠敏捷的人）」就可成事，這一點須長篇論述，無法在「意見欄」說清楚。總之，「敏捷方法」的座右銘就是"embrace change"，並非沒有作業規矩而讓「夠敏捷的人」隨意做做，如果這樣只勉強屬CMMI Level 1而已。

    回覆刪除
  3. Y C Cheng2008年11月2日 下午2:10

    Can't agree more. 我想補充的是，依據軟體開發團隊特性將流程客戶化的作法，亦為當今主流生命週期管理(SLM)平台如Microsoft VSTS、IBM Jazz等採納的作法。只要依格式事先定義團隊的流程後，就可以使這類平台符合團隊的流程需求，團隊可以避免因採用新平台而被迫放棄原先的作法。

    回覆刪除
  4. 黃為德2008年11月2日 下午4:48

    我寫了「長篇大論」是回應暱名人士的意見，不料引起鄭教授提供重要的說詞：避免採用新平台而被迫放棄原先的作法，這就是發展軟體的一項原則，即所謂：Open-Closed Principle(OCP)，這個設計原則是1988年由Bertrand Meyer所提出，其可以定義為："Modules should be open for extension , but closed for modification"，就是將variations保護起來，也是符合encapsulation的OO原則，使用敏捷方法的人也要遵守這項原則，否則軟體系統如經不斷保養，可能越來越複雜而失去控制。此外，我要請教鄭教授的是，如果使用MDA技術會如何？雖然MDA技術尚未100%成熟。

    回覆刪除
  5. 匿名2008年11月2日 晚上10:10

    想請教鄭教授，VSTS與IBM的Jazz可否視為一種流程引擎？目前國內外用的情形多嗎？我個人感覺軟體開發的流程摻雜太多人的因素，要變成一個電腦流程來跑有點困難。還是我們公司的流程水平還不夠？

    回覆刪除
  6. Y C Cheng2008年11月4日 凌晨12:11

    簡短的意見引發有趣的討論。首先，我先聲明對MDA了解相當有限，這兩天趕緊惡補了一下，發現黃教授在本部落格中的四篇關於MDA與Agile MDA的文章(http://sea-taiwan.blogspot.com/search/label/MDA)，以及在JSES的文章(http://jses.seat.org.tw/index.php/jses/articale/view/34/22)，清晰的剖析了MDA的原理、作法、與優點；讀者如對MDA有興趣，建議以這幾篇作為探索的起點。

    言歸正傳。第一，從軟體開發的角度，MDA最大的優點當在“Model is the executable”，可有效縮短傳統的實作活動。這意味著軟體流程可相對的化簡。如此一來，Agile方法就顯得更為恰當；經過PIM-PSM-Code自動轉換，使用者可極短的時間內看到軟體運作的實況，並據以驗證與修改。第二，個人相信軟體工程與生命週期管理的相關議題在MDA開發模式下仍然成立，例如需求管理、建構管理、變更管理、建置管理等。這意味著VSTS或Jazz這類SLM平台也適用於MDA的開發模式(雖然我沒有實際以MDA方法開發軟體的經驗)。當然，前端開發工具將有所不同。總之，我們可以推論團隊的傳統開發流程將因使用MDA而簡化，而簡化後的流程亦可在SLM平台上實行。

    剩下的問題，就是MDA的成熟度了。衷心期待黃教授可以在MDA系列中再寫一篇加以探討，相信一定非常精采。

    接下來是關於讀者杜的觀點與提問。VSTS或Jazz這類SLM平台的確實可以被看成流程引擎。例如，在VSTS中，將瑕疵處理定義為基於「提出-審查-交付-解決-驗證-關閉」等狀態的流程，的確可以做到每一個狀態轉換，都由流程定義中指定的專責人員加以簽核後完成。在實質面，將SLM平台設定成嚴謹的流程引擎，將對團隊運作造成一定程度的限制。除了讀者杜所提的人的因素之外，由於軟體開發牽涉產品、技術、方法、工具等議題，這些議題的處置通常需要流程具有相當的彈性，如在流程引擎上依據嚴格的定義執行，反而容易「卡住」。

    所以，團隊需在流程嚴謹度與彈性度間取得平衡，而衡量的參考之一為「紀律」：紀律情況不明、互動較少的團隊(例如初次合作的外包廠商)需要較嚴謹的流程定義，而紀律較佳、互動良好的團隊(例如堅守Agile Manifesto四大宣言的團隊；見黃為德教授的文章http://sea-taiwan.blogspot.com/2008/07/blog-post_25.html)則可以多給一些彈性。在此基礎上，SLM平台仍須提供足夠的報表，如burn-down chart、bug rates, rework rates等，以供團隊檢視流程執行的情形與軟體的品質。

    關於您提到的公司水平問題，個人認為並不至於構成使用VSTS或Jazz這類平台的障礙。只要團隊的流程是經實證可行的(如開發上一個產品所使用的流程)，加以整理並忠實植入(這部份需要團隊中有人能描述流程，了解SLM平台特性及如何設定；當然也可找顧問協助)，團隊即可在VSTS或Jazz這類平台，依自己熟悉的流程開發軟體，並為未來的流程改善工作預做準備。

    回覆刪除
  7. 黃為德2008年11月4日 下午5:37

    作者已經移除這則留言。

    回覆刪除
  8. 匿名2008年11月4日 晚上10:38

    感謝鄭教授的解釋。有機會會嘗試用jazz或VTTS試試看。不過應該一條蠻辛苦的過程吧！

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容