警語：本人沒有合作開發經驗，只有自學、開發一些小專案，因此關於大型專案、合作開發、團隊協作的想法皆從書上以及自己推論而出，必定會有缺漏或理解錯誤的地方，請閱讀時務必小心。
先想怎麼寫這本書的心得：
一開始先用心智圖發想怎麼寫心得
因為作者是以故事的方式編寫某情境遇到的開發問題、思考，其中有內心的OS、最終的決定以及決定背後的想法。
所以決定大致先以 問題－＞行為－＞背後原因 的方式做紀錄，之後統整情境條件對應到把行為抽象後的SOP概念。
Chapter 1 特過雛型構想專案
大方向
情境──客戶想做音樂推薦系統
一、問客戶做音樂推薦系統的原因？
A：有個經營blog裡面有4000部不同屬性的影片，享用推薦系統讓閱聽者更容易探索更多內容。
二、要做獨立碼庫執行，還是整合到系統中？
A：由於現階段不確定想法是否可行，先做探索式編程，確定要執行的產品，再來思考這個問題。
三、影片直接引用自blog的，一來使用者熟悉介面且可以跟blog做連結。
四、有幾百位閱聽眾、blog經營相關者可以作回饋。
第一次迭代，最單純可行版本(註一)
一、根據大方向畫出wireframe
二、突然想到更好但比較複雜的介面？
A：為了效率，把介面最簡單化，減少開發時間，快速做出第一版產品發佈出去，得到回饋。
三、快速架設網頁，產生了奇怪的網址。
A：捨棄美觀和維護性，最快速度「取得客戶設定之目標閱聽眾的有用回饋」
四、外觀？
A：YAGNI，現階段目標是回饋，效率－＞產品－＞回饋。
五、簡單快速排版，套CSS、placeholder、grid layout。
六、在位歌名排序，用了稍長的時間，但那是浪費時間，這個階段是要驗證想法，細節不重要。
七、Code不加修飾的部屬。
A：捨棄維護性，方向還沒確定，之後不一定會用原code。
八、擔心太陽春，客戶能不能理解？
A：效率－＞產品－＞回饋，提醒回饋決定可行性(市場)。
九、Q：客戶回覆手機跑版。
A：先設計手機的wireframe作為回應，如果回饋有反應行動版問題，再優先製作行動版UI。
十、Q：想叫現在處理，之後處理會不會多餘的工作？
A：(自己猜想)介面簡單、功能不多的情況下，行動版元素刪減、更改不多，之後處理差別不大。
十一、 探索階段，要平衡 問題後果 和 處理成本 ，但要讓客戶了解如何處理之後可能遇到的問題，讓客戶安心，可以減少之後很多精力。
註一：「最單純可行版本」專注在快速實現最小產品，先做可行性測試，也可估量之後的開發狀況，之後可以研究看看一詞出處、定義。
推薦機制
在這之前都是為了找專案的切入點，現在要做正事。
一、問客戶推薦的規則。
A：希望不受他們的列表限制，並且能找到性質相同的歌曲。
二、列舉草圖觀察到，實作細節會遇到的問題。
三、先從2個簡單的開始，產生影片內嵌碼(官方支援)、產生縮圖。
四、Q：產生縮圖沒有找到官方的管道，但有找到民間的做法。
A：先用民間做法，同時詢問官方是否允許會有其他合法的管道。
五、Q：討論其他3個問題，影片要有什麼資料、如何儲存這些資料、如何用這些資料產生有用的推薦機制？隨著時間，討論越來越偏離重點。
A：最小可行版本！先從比對演出者入手，根據現在的影片，推薦相同歌手的影片。
僅推薦歌手還不夠，但目前需要的是能在螢幕上攻討論的東西。
六、Q：資料的儲存？
A：先用簡單的陣列寫一些資料集。
七、實作出了基本的 運行骨架(walking skeleton)
八、收到了關於產生縮圖的官方回答──民間做法沒有違法，但沒有支援，所以可能未來會失效，叫好的作法是在官方的開發者社群下註冊，並使用相關的API。
A：決定先暫時用民間做法，但把這個回應記錄下來，讓之後正式產品開發人員知道。
設計容易收集回饋的功能
一、感興趣側欄，一個單欄列表，顯示各個標籤，點選後會提高標籤的推薦度。
二、對於專案何時該快該鬆，何時要扎實的練習，目前交由同事判斷。
辨識碼 |歌手 |歌名 | 標籤 |歌曲年代
三、資料結構
四、推出適用雛形，去獲取回饋。
建議與提醒
一、提出可以揭示專案餐與人員目標的問題。可以驗證假設，也可以更了解相關人員問題的看法。
二、用wireframe溝通，就不會陷入太多風格設計的細節。
三、開始coding要建立所有人都能互動的即時系統，只要能收集到有用的回饋就好。
四、專案初期，專注在風險高或未知的部分，驗證假設。
五、雛型可以用來找到可能的問題，但它不是最終的系統。
抽象SOP
情境：有個模糊的需求、或不確定會不會被市場接受的新功能。
採用探索式編程
先釐清方向(原因)，確定能確定的事，挑出不可取代的核心功能，做為測試目標得到回饋。
製作最單純可行版本
設計－＞產品－＞回饋，一切以最快速的方式進行，並時時提醒自己。
之後最對最單純可行版本最更詳細的探討。