MSF九大原則：

1. 推動信息共享與溝通:“諧”，Alert

2. 為共同的遠景而工作:目標明確—用戶/老板

3. 充分授權和信任:

4. 各司其職，對項目共同負責:

5. 交付增量的價值:

6. 保持敏捷，預期和適應變化:

7. 投資質量:

8. 學習所有的經驗:

9. 與顧客合作:

MSF團隊模型定義了小組同級成員的角色和職責：用戶體驗、產品管理、項目管理、開發、發布管理、測試。我驚訝地發現，在分配職責時“用戶體驗”顯然不是一項團隊的開發活動，MSF使用了“結果”（Outcome）來進行定義，而不是Action.

而過程模型——螺旋模型，除了幹活之外，十分註重規劃優勢、交流與增量式開發，這與之前提到的敏捷原理不謀而合。

軟件需求方面，體察用戶需求上，調研“可用性”成為一個非常容易忽略的因素，為了避免“用戶在各種菜單中幽幽暗暗反反復復地尋找某個功能，我們在單向玻璃後面替他著急……我們的界面裏’平平淡淡從從容容才是真‘差太遠了”，我認為：開發人員應該成為用戶的一部分。正如我們的項目源於自己的需求而非純功利性的獲益，本身就身為用戶的我們就能更好的體察到用戶的感受。

而另一個讓人深思的問題則是人類學調查，面對著海量用戶，或許我們真的不需要非常geeky的手段與狂拽酷炫的界面，簡單實用才能適用於大多數的人，太高端的功能反而得不到普通人的青睞。

Estimate估計是指計劃時間、以當前了解的情況和掌握的資源，要花費多少人力物力時間才能實現某事。有了對開發時間的估計，我們才能明確目標和並且及時在岔路口覺醒。書中舉了許多例子中國陸地邊界長度、非洲人口密度、長江年流量、2013年亞洲貨幣流通總量、一生說過多少句話等等，這些數據很難一眼就估計出數量級，並且大多數時候人們總是有一種對自己有利的傾向。

在估計之後，我們還要找到估計後面基於的假設，推動數值收斂，使上下界不斷接近。通常的公式是：實際時間花費Y=X+-X/N，X為估計時間，N為類似開發工作的次數

最後書中介紹了WPS分割樹，要點從結果出發構建而不是從團隊的活動出發，葉子節點足夠小，子節點不相互覆蓋，所有子節點覆蓋全部父節點內容。從結果出發構建正好與之前MSF團隊模型不謀而合。

【讀書筆記】構建之法（CH7~CH8）