第七章 MSF

What is MSF?——Microsoft Solution Framework（微軟解決方案框架）即一個方法論，也就是微軟推薦的軟件開發方法。

MSF基本原則：

MSF沒有像敏捷那樣搞一個宣言，但是它也有一套思想框架—9條基本原則

1. 推動信息共享與溝通（Foster open communications）

• 第一個原則，就是所有信息都保留並公開，討論要包括所有涉及的角色，決定要公開並告知所有人。當然，對牽涉到技術機密、安全性等信息要采取必要的保護措施
• 看不到所有的信息，那麽項目進度以及項目中存在的各種問題就不能及時讓所有人知道，這樣MSF中其他的原則也就不能實行了。沒有開放的信息，也就談不上“授權”，或者“建立清晰的責任和共同的職責”，以及“保持敏捷，預測並適應變化”。這也是為什麽“推動信息共享與溝通”是第一個基本原則。MSF團隊模型和MSF過程模型也是建立在“信息共享與溝通”原則上的

2. 為共同的遠景而工作（Work toward a shared vision）

“共同的遠景”是指產品的遠景。我們做一個產品，不管是應用軟件、行業軟件，還是通用軟件，要明確項目的目標是什麽。

• 這個目標必須是明確的，沒有二義性；
• 這個目標不是當前就能達到，必須是通過努力才能達到的；
• 這個目標不是空泛的，它應該對項目成員每天的工作都有指導作用。每天你來上班，如果發現你做的事情對項目的遠景沒有幫助，你應該跟老板提出來

遠景一般是由“有遠見的人”提出，然後公開討論，在討論的過程中，可以消除誤解，凝聚共識。這是一個項目的關鍵，是項目第一階段要達到的主要目標

3.

這一點的關鍵是“授權”這個詞，授權（Empower）有兩個意思：

• 給某人權力和權威
• 給予某人更多自信和自尊

在一個高效的團隊中，所有的成員都應該能得到充分的授權，他們有權在職權範圍內按照自己的承諾完成任務，同時，他們也充分信任其他同事能實現各自的承諾。類似地，團隊的顧客（包括內部和外部的顧客）也認為團隊能兌現承諾，並進行相應的規劃

充分授權的管理方式是MSF的核心觀念之一。MSF團隊模型就是建立在以下兩個原則上的：

• 平等協作—成員之間、團隊之間是平等協作的關系
• 充分授權給團隊和成員

這就是為什麽MSF團隊模型是網狀，而不是層次結構。這樣做有什麽好處？好處

• 被授權的人會承擔起自己對項目的責任，同時也期望同事們也同樣對項目負責
• MSF提倡自下而上的計劃，每個人有充分的權力估計並決定自己的任務需要多長時間，而不是上級交給的時間，這意味著讓真正做這件事的人按照自己的估計去完成任務。這樣做的結果是啥？是人人都會支持項目的計劃和時間表，因為這個時間表是每個人自下而上訂出來的

組員充分授權，到頭來發現事情都沒做完，咋辦?

• 這要靠工具的支持，在VSTS系統中，由於所有工作的進展都記錄在案，任何延遲都會被及時發現
• 這樣組長（或其他層次的領導）就不用把力花在“詢問”，而花在“幫助解決”上，在最關鍵的時候提供指導和幫助
• 領導在項目中的角色是“支持成員完成任務”，而不是“控制成員，迫使他們完成任務”
• 充分授權在MSF團隊模型的另一個含義是：信任，鼓勵團隊成員成長，每人都可以在某一時段、某一領域當領導

4. 各司其職，對項目共同負責（Establish clear accountability and shared responsibility）

在項目進展的過程中，對於每一項任務，每個人都要明確以下幾點。

• Who：誰負責
• What：做什麽，具體的執行方案，什麽叫做“做好了”
• When：什麽時候開始，什麽時候結束
• Why：為什麽是這樣安排（和項目的遠景是否吻合），在什麽情況下可以變更？

與“信息共享與溝通”原則相呼應，這樣的安排能讓所有人都明確自己的職責，同時有“大局觀”—知道別人在做什麽，為什麽，以及整個項目的目標

5. 交付增量的價值（Deliver incremental value）
現在的軟件產業，特別是和互聯網相關的產業，變化非常快，用戶希望產品團隊經常提供更新，以適應新的需求。我們要保證在兩個方面保證客戶的利益：

• 我們提供的新版本對用戶真的有價值
• 和客戶商討一個最優的新版本的發布頻率
  最優的頻率會因為產品的特點（企業產品，消費者產品）和發布平臺（辦公電腦、家用電腦、互聯網、智能手機及平板電腦）的不同而大不相同

在MSF團隊模型中，“用戶體驗”這個角色代表了用戶的利益，保證產品能真正易於使用；“產品管理”這個角色代表了客戶的利益，保證了我們的產品能為顧客提供商業價值。搞技術的，要尊重這兩個角色，因為他們代表的是我們的衣食父母

6. 保持敏捷，預期和適應變化（Stay agile, expect and adapt change）
軟件工程，唯一不變的是變化。所以幹脆別幻想客戶的需求會在第一時刻很明確，然後保持不會變。要註意，我們是預期變化，不是期望變化

除開外部原因，團隊內部也在變化，我們對技術的掌握每天都在提高，原來認為不可能的事可能變得容易。我們對客觀世界和軟件系統的了解每天都在深化，原來覺得沒問題的小細節忽然成了大問題。甚至原來一起打拼的同事忽然要離開……這些都要求我們團隊保持敏捷的身段

7. 投資質量（Invest in quality）

對質量的重視，引起對質量的投資，引起對人、過程和工具的投資。

• 投資要講效率
  軟件開發過程大部分時間花在了解/設計/變更/再了解/再設計的過程中。我們要重視質量，但並不是要不惜一切代價達到最高的質量標準（有人倒吸了一口涼氣），因為提高人/過程/工具的質量是要花成本的！我們不是為提高質量而提高質量。我們要講投資的效率。比如，在做快速原型的過程中，有些部分可以做得粗糙一點
• 投資要講時機
  比如說對於某項技術的培訓，最好的做法是在即將需要的時候進行培訓。太超前或滯後都不靈
• 投資是長期的
  和投資股票/不動產一樣，真正的投資者看重的是長線的收益；人的成長、團隊的成熟都需要時間，不可能短期內立竿見影。那些“短平快”的東西，叫投機，不叫投資

8. 學習所有的經驗（Learn from all experiences）
在學習過去的經驗的同時，也要避免讓過去的經驗妨礙解決現在的問題
這一原則有兩個含義——

• 把經驗總結出來
• 分享經驗

為什麽要堅持總結和分享？是為了——

• 讓團隊成員從別人的成果和失敗的例子中學到東西
• 幫助新項目重復以往成功的做法
• 培育團隊總結的習慣和“批評與自我批評”的文化

MSF在每一個裏程碑結束時都要做一個“裏程碑回顧”，這個回顧不必等到整個項目結束才做。這樣做的好處是，大家對最近的成敗都記憶猶新，能提供比較準確和全面的反饋；如果發現了錯誤，可以馬上研究解決辦法，在下一個裏程碑中通過實踐來驗證。另外，一些好的做法可以及時得到總結和推廣

在項目結束時，MSF推薦請團隊以外的專家來主持召開“事後諸葛亮”會，這樣的專家會比較系統地總結團隊的成功經驗和失敗教訓，同時也客觀評價團隊的一些特性和團隊的開發過程管理，這樣能促使團隊成員以客觀、向前看、解決問題的心態來參加“事後諸葛亮”會，避免主觀臆斷或相互指責

9. 與顧客合作（Partner with internal and external customers）

MSF團隊模型

MSF團隊模型定義了小組同級成員的一些角色和職責

在MSF團隊模型中，任何技術項目都必須達到特定的關鍵質量目標，才能夠被認為是成功的項目。任何一個角色無法實現其目標，都將危及整個項目。因此，每個角色都被認為是同等重要的，重要的決定都要共同作出。相關的目標和角色如上圖所示。

MSF過程模型

每個項目都要經過一個生命周期

MSF過程模型是從傳統的軟件開發瀑布模型和螺旋模型發展而來的，它把瀑布模型中基於裏程碑的規劃優勢與螺旋模型中增量叠代的長處結合了起來

MSF過程模型的基本元素是階段和裏程碑。所謂“階段”，就是在這一段時間裏團隊集中精力做某一類事情，每個階段的結束都代表了項目的進展和團隊工作重心的變化。比如在“開發階段”結束後，團隊就不再允許設計/實現新的功能，除非有理由充分的“變更請求”

在Visual Studio TFS中，MSF演化為以下兩個分支：

• MSF敏捷開發模式
• MSF CMMI開發模式

MSF敏捷開發模式吸收了近幾年來在軟件業界流行的各種“敏捷”開發模式的優點，認識到目前大部分軟件是以網絡應用相聯系的，強調和用戶更緊密地交流，快速叠代，避免不必要的過程。

更強調與用戶的交流

項目的商業價值要由用戶說了算，那些“我覺得用戶會喜歡”的東西要及早和用戶交流。因為“我覺得”和“用戶覺得”是兩碼事

質量—防患於未然

防止缺陷的發生成為團隊質量控制的首要任務，在防止缺陷的發生和確保缺陷被修復上，所有的角色都要負責

有一些團隊把開發和測試有意無意地對立起來，好像二者是矛盾的。一個典型的例子是，有時開發人員不想給測試人員足夠的信息，好像不想“幫”測試人員找到缺陷；與此同時，測試人員一旦找到缺陷，會有些得意，“看，你寫的代碼那麽臭，我又發現了N個Bug”。這種對立情緒，也許在短期內能刺激成員的工作熱情，而從長遠來看是有害的。很少有人會希望在這種充滿對立情緒的環境中工作

微軟公司內部做過統計，在一個中大規模的團隊中，一個“缺陷”從發生到被改正，中間經過了近20道工序，平均總的時間開銷是12小時。優秀的團隊能做到這一點：可能的缺陷在設計階段之前就討論過，並且在代碼中已經避免了，因此在“缺陷跟蹤系統”中，並沒有出現很多缺陷記錄在案，但是軟件的質量仍然很高

重視在實戰條件下的質量

這一點要求我們保持隨時可以發布的高質量。如果用戶說：時間到了，網站要上馬。我們應該很快地交給用戶一個可用的版本，也許功能不多，但是現有的功能都可用。這就要求我們必須保證項目的質量是“隨時可用”。為了達到這一點，我們要重視產品的安裝和發布—產品要盡早能夠達到隨時安裝、發布的標準。在一些項目中，安裝和發布都是最後階段才做，這就導致幾個問題：

• 開發過程中，測試團隊很難安裝產品，阻礙了測試團隊的進展。很多情況下，測試人員不得不從多個源頭拷貝不同的文件到測試環境中，才能開始測試，浪費了大量時間
• 關於安裝的缺陷得不到重視—用戶拿到一個Beta版，意見最大的就是安裝不上！或者好不容易裝好了，卻卸載不了，不得不重新安裝系統。

精簡過程，直奔主題

我們一幫人吭哧吭哧幹活是為了什麽？主題是什麽？是為了解決用戶的問題。用戶給項目投資了成千上萬，不是為了看到一堆過時的文檔。同樣，在團隊成員之間的交流要簡明，不必為了交接而搞出許多文檔。另外一個重要的因素是，如果團隊在整個軟件生命周期都使用團隊協作服務器（TFS），那麽很多活動、決定、文檔都自然地記錄在TFS上，不必額外去為了文檔而再寫一些東西。

MSF CMMI開發模式

• MSF也支持CMMI 的開發模式
• CMMI是英文Capacity Maturity Model Inte-grated（能力成熟度模型集成）的縮寫

CMMI是CMM模型的最新版本，資料顯示，如果一個項目的管理達到了CMMI較高的等級，那麽項目的質量與按期完成率都會有較大的提高。

CMMI雖然源於美國，但在世界各地得到了廣泛的推廣與接受，特別是和外包服務相關的軟件企業（例如印度）。

但是要註意的是，眾多新興的小企業，特別是互聯網企業，並沒有多少采用CMMI來指導軟件開發。

在MSF中，CMMI 在所有的流程上都加了一個“提議”（Proposed）階段，通過“審核”或者決定“開始調查”，處於“提議”階段的工作項可以變為“激活”狀態。如果調查的結果不是要開始著手工作，那麽工作項可以退回到“提議”狀態。以缺陷類型

構建之法——讀書筆記（5）