在這個關於軟體工程的專欄裡，作者將應用敏捷方法學對軟體開發過程中架構設計進行研究。
方**對軟體開發而言意味著什麼？我們如何看待軟體開發中的方**？方**能夠成為軟體開發的救命稻草嗎？在讀過此文後，這些疑惑就會得到解答。
在第一篇文章中，我們來了解標題中的一些詞的含義。
● 方法學是什麼？
● 敏捷是什麼？
● 為什麼討論架構？
方**的英文為methodology，詞典中的解釋為"a series of related methods or techniques"我們可以把它定義為軟體開發（針對軟體開發）的一整套方法、過程、規則、實踐、技術。關於方**的出現的問題，我很贊同alistair cockburn的一句話，"方**源於恐懼。"出於對專案的超期、成本失控等等因素的恐懼，專案經理們從以前的經驗出發，制定出了一些控制、監測專案的方法、技巧。
這就是方**產生的原因。
在agile software development一書中，作者提到了方**的十三個要素，基本能夠涵蓋方**的各個方面：
● 角色（roles）
● 個性（personality）
● 技能（skills）
● 團隊（teams）
● 技術（techniques）
● 活動（activities）
● 過程（process）
● 工件（work products）
● 里程碑（milestones）
● 標準（standards）
● 質量（quality）
● 工具（tools）
● 團隊價值（team values）
它們之間的關係可以用一幅圖來表示：
圖 1. 方**的十三個要素
很多的方**，都涉及了上面列舉的十三要素中的部分要素，因此，我們可以把方**看作是乙個抽象的、無窮的超集，而現實中的方**都是指超集的乙個有限的子集而已。它們之間的關係就好像有理數和1到100之間的整數的關係一樣。不論是xp，還是ui設計經驗之類，都屬於方**的乙個子集，只是這兩個子集之間有大小的差別而已。
我們還應該看到，討論乙個完備的方**是沒有意義的，因此這種方**鐵定不存在，就好像你檢視窮舉出所有的有理數一樣荒唐。因此，我們關於乙個通用的方**的說法也是無意義的。好的方**，比如說xp、水晶系列，它們都有乙個適合的範圍，因為它們了解一點，自己並不是乙個無所不能的方**。
在現實中，我們其實不斷的在接觸方**。比如說，為了控制專案的進度，專案經理要求所有的開發人員每週遞交乙份詳細的進度報告，這就是一種方法、一種技巧。如果把開發過程中的這些技巧系統的組織起來，就能夠成為一種方**。
你可能會說，那一種方**的產生也太容易了吧。不，這樣產生的方**並沒有太大的實用價值，沒有實用價值的方**根本就沒有存在的必要。因此，乙個成功的方**是要能夠為多個的專案所接受，並且能夠成功實現軟體的交付的方**。
我和我的同事在實踐中做了一些試驗，希望能夠把一些好的方**應用於開發團隊。試驗的結果很無奈，方**實施的效果並不理想，一開始我們認為是方法本身的原因，到後來，我們發現事情並不是這麼簡單。在試驗的過程中，開發人員一致認同方**的優勢所在，但是在實施過程中，鮮有堅持的下來的。
在agile software development中，我發現作者遇到了和我們一樣的問題。
alistair cockburn在和大量的專案團隊的訪談之後，寫成了agile software development一書。在訪談之前，他篤定自己將會發現高度精確的過程控制是成功的關鍵所在，結果他發現事實並非如此，他把他的發現歸結為7條定律。而我在實際中的發現也包含在這七條定律中，總結起來就只有兩點：
溝通和反饋。
只要能夠保證良好的溝通和即時的反饋，那麼開發團隊即使並沒有採用先進的方**，一樣可以成功。相反，那些"高質量"的團隊卻往往由於缺乏這兩個因素而導致失敗（我們這裡指的失敗是使用者拒絕使用最終的軟體）。最有效，而成本也最低的溝通方法就是面對面（face to face）的溝通，而隨著專案團隊的變大，或是另外一些影響因素的加入（比如地理位置的隔絕），面對面的溝通越來越難實現，這導致溝通的成本逐漸加大，質量也慢慢下降。
但這並不是說非面對面的溝通不可，重要的是我們需要知道不同的溝通方式的成本和質量並不相同。xp方法尤為強調面對面的溝通，通過現場客戶、站立會議、結對程式設計等方式來保證溝通的有效。在我的經驗中，乙個開發團隊其實是需要多種溝通方式的結合的。
完全的面對面的溝通對某些團隊來說是很難實現的，那麼問題的關鍵就在於你如何應用溝通的方式來達到你希望的效果。在前不久結束的歐萊雅創業計畫大賽上，有一支團隊特別引人注目，他們彼此間素未謀面，僅僅憑藉internet和**完成了高效的合作。他們雖然沒有使用面對面的溝通方式，但是仍然達成了既定的目標。
軟體開發也是一樣的，面對面的溝通是非常有必要的，但其它的溝通方式也是需要的。
再看反饋，不論是控制進度，還是保證客戶的滿意度，這些活動都需要管理成本。軟體開發中的管理成本的乙個通性就是伴隨有中間產出物（intermediate delivery）。比如說我們的需求規約、分析文件、設計文件、測試計畫，這些都屬於中間產出物。
中間產出物的增加將會帶來效率下降的問題，因為開發人員的時間都花在了完成中間產出物的工作上，花在給軟體新功能上的時間就減少了。而中間產出物的主要目的是兩個，乙個是為了保證軟體如客戶所願，例如需求規約；另乙個是為了作為團隊中的其他成員工作的輸入，例如開發計畫、測試計畫等。因此，我們也可以針對這兩點來商討對策，一種是採用迭代的思想，提高軟體發布的頻率，以保證客戶的需求被確實的滿足，另一種就是縮小團隊的溝通範圍，保證成員能夠從其他人那裡得到新的思路，而不是撰寫規範的內部文件（內部文件指那些僅為內部開發人員之間的溝通所需要的文件）。
因此，乙個軟體專案的成功和你採用的開發方**並沒有直接的關係。
我們根據把擁有大量artifact（rup官方翻譯為工件，意思是軟體開發過程中的中間產物，如需求規約、設計模型等）和複雜控制的軟體開發方法稱為重型（he**y weight）方法，相對的，我們稱artifact較少的方法為輕型（light weight）方法。在傳統的觀念中，我們認為重型方法要比輕型安全許多。因為我們之所以想出重型方法，就是由於在中大型的專案中，專案經理往往遠離**，他無法有效的了解目前的工程的進度、質量、成本等因素。
為了克服未知的恐懼感，專案經理制定了大量的中間管理方法，希望能夠控制整個專案，最典型的莫過於要求開發人員頻繁的遞交各種表示專案目前狀態的報告。
在planning xp一書中有一段討論輕重型方**的精闢論述，它把重型方**歸結為一種防禦性的姿態（defensive posture），而把輕型方**歸結為一種渴望成功（plan to win）的心態。如果你是採用了防禦性姿態，那麼你的工作就集中在防止和跟蹤錯誤上，大量的工作流程的制定，是為了保證專案不犯錯誤，而不是專案成功。而這種方法也不可謂不好，但前提是如果整個團隊能夠滿足前面所提到的兩個條件的話，專案也肯定會成功，但是重型方**的乙個弊端就在於，大家都在防止錯誤，都在懼怕錯誤，因此人和人之間的關係是很微妙的，要達到充分的溝通也是很難的。
最終，連對人的評價也變成是以避免錯誤的多寡作為考評的依據，而不是成就。我們在做試驗的時候，一位專案經理開玩笑說，"方**源自專案經理的恐懼，這沒錯。但最糟糕的是整個團隊只有專案經理乙個人恐懼，如果能夠做到人人的恐懼，那大家也就沒有什麼好恐懼的了。
"這句話提醒了我們，如果乙個團隊的精神就是力求成功，那麼這支團隊的心態就和其它的團隊不同了，尤其是對待錯誤的心態上。根本就沒有必要花費大量的精力來預防錯誤，錯誤犯了就犯了，即時改正就可以了。這其實就是渴望成功的心態。
軟體架構設計的思想與模式
事實上架構設計是不可能獨立存在的，架構設計提供的是使用者需求的解決方案，所以一 個架構師對需求分析的要點和關注點需要有深刻的理解，否則是不可能有好的架構設計的。什麼是需求呢？產品為使用者在特定的背景中所必須滿足的約束就是產品的需求，需求的表達 一般是抽象的而且與技術無關的，這樣主要是避免對技術方案產...
結構設計札記 PMCAD中懸挑板的設計方法
16pmcad中懸挑板的設計方法 2010.12.15 16.1pmcad在模型錄入時，對懸挑板在 樓板生成 選單提供了 布懸挑板 功能，具體布置方法詳見 pmcad使用者手冊及技術條件 模型中布置的懸挑板可以在生成結構平面圖時形成板布置，板上布置的樓面附加荷載 板自重軟體在導荷時也會按均布荷載傳至...
論環境小品的設計思維方法
摘要 近年來，隨著城市建設的不斷發展，環境建設水平的不斷提高，城市廣場環境小品已經成為表達城市文化內涵的主要表現形式之一，在文化溝通 市民娛樂 優化城市空間等方面起著十分重要的作用。關鍵詞 環境小品 設計 空間 一環境小品概述 1 我國環境小品發展概況 由於世界各國文化不同，城市環境小品的表現形式也...