咱們在閱讀了書上的內容的時候,大概瞭解了MSF是一套大型系統開發指南,它描述瞭如何用組隊模型、過程模型和應用模型來開發Client/Server結構的應用程序,是在微軟的工具和技術的基礎上創建並開發分佈式企業系統應用的參考。它的最大特性是商業化,並一直體如今項目的實施過程當中。所謂商業化意味着客戶的商業利益。客戶投入多少,獲得多少回報,客戶要用到哪些最新的技術,最後如何把項目計劃(Project)變成產品(Product)直至產生效益,等等,這些都是MSF要考慮的問題。
MSF有8個基本原則,基於這些原則咱們又進一步加入了本身的理解
(1)推進信息共享與溝通(Foster open communications):第一個原則,用大白話來講,就是全部信息都保留,並公開,討論要包括全部涉及的角色,決定要公開,並告知全部人。固然,對牽涉到技術機密、安全性等信息要採起必要的保護措施。
(2)爲共同的遠景而工做(Work toward a shared vision):「共同的遠景」是指產品的遠景。咱們作一個產品,不論是應用軟件、行業軟件,仍是通用軟件,要明確項目的目標是什麼。這個目標必須是明確的,沒有二義性,並且這個目標不是當前就能達到,必須是經過努力才能達到的。這個目標不是空泛的,它應該對項目成員天天的工做都有指導做用。天天你來上班,若是發現你作的事情對項目的遠景沒有幫助,你應該跟老闆提出來。
(3)充分受權和信任(Empower team members):在一個高效的團隊中,全部的成員都應該能獲得充分的受權,他們有權力在本身的職權範圍內按照他們本身的承諾完成任務,同時,他們也充分信任其餘同事也能實現各自的承諾。相似地,團隊的顧客(包括內部和外部的顧客)也認爲團隊能兌現承諾,並進行相應的規劃。
充分受權的管理方式是MSF的核心觀念之一。
(4)各司其職,對項目共同負責(Establish clear accountability and shared responsibility):團隊中的每一個角色都有本身的職責,若是出了問題,這個角色就要負責任。與此同時,團隊的各個角色合起來,對整個項目最終的成功負責,爲何?由於每一個角色在其職責範圍內的失敗都會致使整個項目的失敗。並且各個角色的工做都是互相滲透、互相依賴的。這種互相依賴的方式也鼓勵團隊成員在本身本職以外爲其餘領域作貢獻。例如,測試人員能夠幫助「用戶體驗」角色更好地設計用戶界面,由於若是用戶界面不好,再好的功能也不能發揮應有的做用。
(5)重視商業價值(Focus on delivering business value):咱們在開發預估項目的時候要明白咱們也是一個商業實體,咱們的項目都應該是出於商業目的,若是沒有商業的需求,再酷的技術也沒有用,商業項目須要重視市場和用戶,技術是處於第三位的。簡單的說咱們開發的項目要可以讓咱們最大程度的獲利。
(6)保持敏捷,預期變化(Stay agile, expect change):軟件工程,惟一不變的是變化。因此乾脆別幻想客戶的需求會在第一時刻很明確,而後保持不會變。要注意,咱們是預期變化,不是指望變化。
除開外部緣由,團隊內部也在變化,咱們對技術的掌握天天都在提升,原來認爲不可能的事可能變得容易。咱們對客觀世界和軟件系統的瞭解天天都在深化,原來以爲沒問題的小細節突然成了大問題。甚至原來一塊兒打拼的同事突然要離開……這些都要求咱們團隊保持敏捷的身段。
(7)投資質量(Invest in quality):對質量的重視,引發對質量的投資,引發對人、過程和工具的投資。在作項目的時候不能一味的寫代碼,咱們更應該考慮對質量的投資,要作到高效投資、正確投資和長期投資。
(8)學習全部的經驗(Learn from all experiences):MSF在每個里程碑結束時都要作一個「里程碑回顧」,這個回顧沒必要等到整個項目結束才作。這樣作的好處是,你們對最近的成敗都記憶猶新,能提供比較準確和全面的反饋;若是發現了錯誤,能夠立刻研究解決辦法,在下一個里程碑中經過實踐來驗證。另外,一些好的作法能夠及時獲得總結和推廣。
在項目結束時,MSF推薦請團隊之外的專家來主持召開「過後諸葛亮」會,這樣的專家會比較系統地總結團隊的成功經驗和失敗教訓,同時也客觀評價團隊的一些特性和團隊的開發過程管理,這樣能促使團隊成員以客觀、向前看、解決問題的心態來參加「過後諸葛亮」會,避免主觀臆斷或相互指責。html