《軟體開發本質論》讀書筆記

讓我們一起探索如何通過頻繁提供可見價值來使軟體開發變得更簡單。

價值的迴圈

第一章 尋找價值

價值：就是那些我們想要的東西

我們會自下而上從金字塔的底部開始。

指導：通過建立以價值為已任的團隊來實現價值的創造，因此需要確保團隊成員指導客戶需要什麼，以及客戶留給我們的開發時間。我們通過觀察實際構建出產品來對團隊的工作進行指導。

組織：我們圍繞產品的功能特性來進行組織，因為這些功能特性可以使我們更好地計劃，並更快創造出價值。

計劃：根據所需功能特性的前後順序來對其進行選擇，以此來控制專案的進展。這樣就能夠及時創造價值。

構建：通過逐個實現功能特性來構建產品。這樣能夠頻繁地進行價值的交付，同時能夠儘早、經常地看到專案的進展。

劃分：將功能特徵劃分為小塊，使每一塊儘可能小，前提是它們仍然有價值。這樣就能儘早地構建出有用的產品，並在交付日期到來之前對產品進行優化和提升。時刻準備交付產品。

質量：採取必要的措施，以確保生產出來的產品設計優秀、品質精良。（重構和測試是不能忘的）

第二章：價值就是我們想要的東西

只有當軟體釋出時，它的價值才能體現。

根據功能特性劃分價值 假設每個功能特性的高度代表它的價值，寬度代表它的成本。

第三章：根據功能特性可以指導得更好

對於任何一個專案，我們首先知道的第一件事是專案的截止日期。 根據功能特性交付專案更具有可預見性。 上圖中，紅色曲線代表傳統專案一直不停地進行著，但傳達的資訊很少，而且傳到的時間也很晚；直線代表的專案卻能夠頻繁、定期地向我們展示真正有價值的功能特性，我們也能夠看到正在形成的軟體！ 根據功能特性交付專案能夠提供更好的資訊和指導，同時也會產生更好的結果。

第四章：根據功能特性組織團隊

我們想通過功能特性一點一點地獲得價值。當通過價值和功能特性來管理專案時，就能獲得成功。 如果根據技能來組織團隊，每一個專案都需要經過幾個團隊的合作交接才能完成。每一次交接都需要制訂日程表，這樣會造成進度的延遲。而且極有可能每一次交接都會產生相應的問題。

團隊構建功能特性

根據最重要的功能特性優先的原則去組建團隊，團隊正在開發所有待完成功能特性中最重要的那個，那麼很明顯，它值得你去投入餘下的人員中最優秀的人員。 同時為他們創造了一個鍛鍊和學習的機會。

第五章：根據功能特性進行計劃

當我們經常性地釋出軟體版本時，情況會最好：價值會增長得更快、更好；管理層每隔一段時間就能夠看到專案的進展；同時，由於目標小而明確，開發工作也能夠以最好的方式進行。

然而，產品的“願景”總是從偉大的想法開始，雖然朦朧卻很誘人。願景是關於產品的大的思路，而不是小的功能特性。

做計劃是必要的

艾森豪威爾將軍曾說過：“計劃本身是無用的，但做計劃是必要的”。我們的確需要針對產品認真思考，不只是開始，而是一直需要這樣做。

儘早確定哪些核心的功能特性是必須儘快有，哪些功能特性不能沒有，這很重要。我們要確定這兩種功能特性，並將它們記錄下來。

關於有多少軟體專案最終支出遠遠超出預算。

更好的方法如下：一是確定專案的時間期限和開支預算；二是優先開發最優價值的功能特性；三是確保產品能夠隨時釋出，並在時間結束時立即停止。開發工作甚至很有可能會在截止日期之前停止，因為我們已經得到了最重要的功能特性。

第六章：根據功能特性構建產品

根據功能特性來構建產品，能夠使我們交付更多的價值。由於開發團隊能夠演示軟體，因此無論是管理還是做計劃都很容易。

在每一個短週期內，完整地構建一個小的產品

在計劃和管理專案時，我們將其劃分為多個為期一至兩週的短週期。在每個週期內，確定需要完成哪些功能特性，並清除地說明如何測試它們。這樣開發團隊可以根據這些要求構建功能特性，由此我們也可以驗證功能特性是否通過了測試。

細化產品願景

這就意味著業務人員要有能力將大的、模糊的、籠統的需求切分為小的、切實可行的開發步驟。

總是將價值可能最大的任務列為下一個目標

整個團隊一起合作，共同確定有能力完成且價值高、成本低的功能特性。團隊就學會了怎樣在有限的時間和預算內構建最好的產品。 功能特性要麼“已完成”，要麼“未完成”，不存在中間地帶。

確定真實的進展

根據功能特性構建產品這種方法使得每一次迭代都包含完整的開發流程：從需求到設計，然後編碼，最後測試。

淘汰測試再修復式的收尾方式

為了根據功能特性構建產品的方法能夠發揮作用，在為期兩週的迭代結束時，我們開發的軟體必須是幾乎沒有缺陷的。為了確保沒有缺陷，必須隨時對一切進行檢測。

隨著專案的進行，進一步擴充套件和優化設計

通過觀察開發速度的變化，也就是交付功能特性的速度變化，我們就能學到什麼程度的設計恰到好處。設計得太多，進展會緩慢；設計得太少，進展同樣會緩慢。我們的應對法則是：調整，觀察，再調整。

第七章：同時構建功能特性與基礎

有2種方法：一是首先完整構建出專案的基礎結構，缺點是：若優先構建基礎，則在交付日期到來時，可以交付的功能特性太少。它會延緩專案進度的同時減少產品的價值。二是在構建每一個完整的功能特性時也設計它的基礎，缺點是：如果逐一構建完整的功能特性，當交付日期到來時，產品很有可能會缺少關鍵的功能特性。

首先構建簡單而實用的版本

最好的方法是我們以最快的速度構建出最小可行產品。這需要我們判斷使用者需要什麼以及我們還剩下多少時間。在多次迭代中逐漸完善每個功能特性。為在交付日期到來時獲得儘可能好的結果而努力。

第八章：零缺陷與良好的設計

為了確保產品在任何時候都擁有良好的設計而且沒有缺陷，我們需要有良好的技術實踐方法。實時上，因為功能特性是逐漸增加和完善的，同時其設計也是逐漸改進的，所以出現錯誤在所難免。我們需要進行持續的、全面的測試。

我們需要進行2個層面的測試：“業務”測試和“開發人員”測試。

在每一次迭代結束時，都需要進行業務層面的測試來驗證是否得到了想要的軟體。這就是人們常說的“驗收測試驅動開發（ATDD）”。 在已知的最好方法就是先寫測試程式碼，然後再執行這些程式碼。這通常被稱為“測試驅動開發（TDD）”。

重構和測試是我們時刻保持設計良好的2個法則。

第九章：價值的完整迴圈

（1）我們最終想要的是價值，提供價值的則是功能特性。功能特性發布的越早，我們就能越早提供價值。
（2）基於價值的管理比基於時間或工件等不提供價值的事物更勝一籌。
（3）根據功能特性做計劃很簡單，只有在必要時才進行估算。根據以往完成的工作量來安排一下階段的工作，效果會更好。
（4）採用逐漸增加功能特性的增量式開發方法，要去我們每隔幾周就能夠開發出小而完整的產品。
（5）開發工作必須要交付真正可用的功能特性。產品必須經嚴格的測試，業務人員和開發人員都需要參與其中。