報恩

September 18 08:58~10:39

▲窗外的浪浪吃飽就睡，何時會上演「貓的報恩」XD

故事一

好幾年前參與第一個Scrum團隊的產品開發，該軟體產品必須支援很多軟體與硬體平台，牽涉到韌體與驅動程式，還要與一些特殊的嵌入式系統溝通。這些軟、硬體平台數量眾多，不但經常改版，並且附贈不少bug。

當時Teddy遇到一個很頭痛的問題：「怎麼設計軟體架構？」因為跑Scrum，不能用傳統瀑布式開發那一套，先花個幾個月收集需求，再花個幾個月設計架構。當時關於在敏捷開發中如何設計軟體架構的資料非常少，能找到的資料也只是提個大方向：「敏捷開發中軟體架構是隨著每個迭代週期長出來的」。

在無計可施之下，Teddy想起念書時在物件導向分析與設計（OOAD）課程學到的RUP（Rational Unified Process；統一軟體開發流程）。RUP的三大支柱：Use Case Driven、Architecture Centric、Iterative and Incremental Development（IID），是不是能在Scrum中使用？

***

敏捷開發方法原本就是迭代與增量，把use case driven換成user story driven，如此一來套用architecture centric的作法似乎也是非常自然的一件事。

RUP把軟體開發分成四個phase：Inception、Elaboration、Construction、Transition。在elaboration結束時大約完成最重要的百分之二十use case，此時軟體架構雛形也大致成形。聽起來很簡單，實際上要在Scrum中套用此原則也不難，唯一需要注意的一點是：「你怎麼知道這最重要的百分之二十use case（user story）是什麼？」。

跑Scrum當然你會有Product Backlog，但這是一個內容隨時間異動的產品功能代辦清單。如果Product Backlog裡面只有接下來1~2個sprint所需要的詳細user story內容，有可能「看得不夠遠」，導致於軟體架構在每個迭代中不斷地（大幅度）修正。所以必須依據專案的特性，包含專案大小、上市時間、複雜度、不確定性等因素，自行判斷需針對這最重要的百分之二十的user story（百分之二十只是一個概念，不一定就是百分之二十，在敏捷開發中這個數字也許越低越好），需要做多少事前設計（up-front design），才能讓團隊的軟體架構成形。

***

故事二

N年前台灣政府砸錢推廣CMMI，當時Teddy還在念書，因故到校外上了介紹CMMI的課程。在學校也修了個人軟體流程（Personal Software Process），體驗了一學期「沒人性」的度量與改善之軟體開發方法XD。

Teddy所認識接觸過CMMI的台灣軟體工程師，幾乎每一個人對它的評價都是「罵聲連連」。CMMI本意良善，可惜在台灣的落實方式變成一種快速拿牌的「文件化流程」。為了長官的績效，為了亮點，原本的精神所剩無幾，徒留形式。

這一陣子Teddy花了一些時間閱讀溫柏格的《溫柏格的軟體管理學》這一套四本「老書」。溫柏格在書中提出「軟體工程文化模式」，包含以下幾個等級：

• 模式0：渾然不知型的文化（Oblivious）
• 模式1：變化無常型的文化（Variable）
• 模式2：照章行事型的文化（Routine）
• 模式3：把穩方向型的文化（Steering）
• 模式4：防範未然型的文化（Anticipating）
• 模式5：全面關照型的文化（Congruent）

模式1~模式5基本上就對應到CMMI Level 1~CMMI Level 5。針對處於不同軟體工程文化模式的公司或團隊，遇到問題時有不同的反應方式。溫柏格這四本書利用幾個簡單的模型（model）來介紹他的軟體管理學，包含：系統性思考、軟體工程文化模式、控制模型、薩提爾的人際溝通模式。

這四本書（中文版）加起來約2200頁，但因為以前 被迫 學過一點CMMI的皮毛，沒想到N年後居然出來報恩，讓Teddy比較讀得懂這一套書。

***

結論

有些人覺得從事軟體開發工作不須要念研究所，大學畢業就很足夠了。因為台灣的研究所教的內容與社會脫節，還不如早早出社會從實戰中學習。也有些人盲目念研究所，只因為鄉民都念了我沒念好像怪怪怪。

不論哪一種情況，大學或研究所教育，雖然求學的當下看起來很多都跟「社會脫節」，但世事難料，就看每個人對於所謂的「社會」的時空定義是什麼。

很多時候，基本功夫做好，才是伴隨自己一生的最佳夥伴。

***

友藏內心獨白：溫故知新。