談談"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. 政府訂定一個流程要比訓練一批可用的人(夠敏捷的人)容易的多。所以每天關起門來拼命的定流程,如果也有檢驗政府流程的檢驗方法,也許我們的政府已經是 CMMI Level 5。

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

    回覆刪除
  2. 有一句片語說"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. Can't agree more. 我想補充的是,依據軟體開發團隊特性將流程客戶化的作法,亦為當今主流生命週期管理(SLM)平台如Microsoft VSTS、IBM Jazz等採納的作法。只要依格式事先定義團隊的流程後,就可以使這類平台符合團隊的流程需求,團隊可以避免因採用新平台而被迫放棄原先的作法。

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

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

    回覆刪除
  6. 簡短的意見引發有趣的討論。首先,我先聲明對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. 作者已經移除這則留言。

    回覆刪除
  8. 感謝鄭教授的解釋。有機會會嘗試用jazz或VTTS試試看。不過應該一條蠻辛苦的過程吧!

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

TCSE 2017

加油站與小鎮