Don't hire a software developer until you read this book是一本有趣的書，它的副標題是：學習如何管理應用程式的開發流程，確保你的手機程式，網站，網路應用的產品會成功做出來。
這本書和一般的企業巫醫做法略有不同，它只專注在一個單純面向，就是「非軟體人員如何建構軟體開發團隊，並且做出自己要的產品」。實務上，它是一本工具書。裡面的Pro Tips直接而且不廢話的指出應該要的做法。
這本書花了好幾個章節，大致闡述了近年來軟體開發的相關技術與運用，並把重點放在非技術背景的創業者，如何組織建立軟體開發團隊，並且讓團隊往期待的方向前進。
做得到書上的內容的人，大概就是程式設計師心中的好老闆，或者是好ＰＭ。
然而，這本書其實也非常適合給「程式設計師」閱讀
它展示非技術人員領導軟體產品開發「真正關心」的地方：也就是實際產出。至於開發人員使用的程式語言，使用的軟體工具，甚至想要把產品做的完美...這些都是不是考慮的要務。
例如，在書中說明新創產品開發常犯錯誤的幾條
(1) 為求完美把錢燒光了：
MVP需要的是最小規模的產品以及最好的品質。但太追求完美因而增加太多附屬功能，在作者來說是一種無法控制的浪費
(2) 輕忽看似很小的需求規格改變
例如某些開發人員會說「這不會花太長時間，只是把按鈕從這邊移到那邊」。開發人員當然會負責搞定，但是要求預估時間是創業家一定要做的事情
(3) 忽略測試
測試的重要性應該不用多提。然而非技術人員很容易忽略測試的重要。
(4) 即將上線前做需求改變
對作者來說，這等同於自殺任務。其實資深的軟體工程師在內心深處都很清楚這點，但是創業者或PM想要自我毀滅的時候，又有多少人可以阻止？
(5) 開發中後期增加人力以加速開發
在人月神話這本書中有很長的篇幅描述，很多時候增加程式設計師只會讓專案速度更慢。
此外，一般開發人員也可以透過這本書獲得Lean-Startup的精神概念與實務上Agile開發的整合。
舉例來說：它說明了Agile原則，以創業者的角度，來看agile的各種方法論對軟體開發的好處。並且也拿實際工具(Trello)，展示一個創業者實際對開發團隊該做的動作，連同移動Task Card都說明很清楚。MVP，如何做出最小可行規模的產品。從創業者的角度，來看這些工具，其實更可以讓軟體工程師知道專注於最小變動需求的好處。
Scrum是敏捷開發原則下，目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論，並沒有所謂的標準，各個組織的應用方式皆有不同。常見的應用(practice)，例如：spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。
零零總總的practice中，哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神，以下三件事情是「最基本要有的」。也就說，如果這三件事情做不到，那麼其他事情做到也沒有用。
(1) 每個Sprint有交付具體產出
Scrum的Sprint都要有具體「可交付」的產出。sprint的開始，就應該以「結果」為計畫的導向，而此結果必須要是可交付的產出。
有些團隊會以Sprint長度不夠為理由，設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題：(1) sprint結束的檢討，並不基於產出的事實 (2) kick-off下一個sprint的意義不大，因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off，畢竟這個sprint沒有有意義的產出，而如此一來PO就很容易不真正加入團隊。
Sprint不見得要固定長度，請參考這裡。
(2) PO有確實加入Scrum團隊
Scrum團隊成員有三個角色，team member, scrum master, product owner。其中最容易不在的人，就是product owner。許多軟體開發團隊，product owner就是PM。但無論如何，Product owner必須要真實參與團隊。
所謂真實，指的是所有standup應該參加，在團隊運作過程，能夠回答該sprint的需求問題，並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」
更重要的是PO加入團隊之後，DOD(definition of done)的標準才會具有「市場一致性」。舉例來說，不成熟的軟體研發人員常會對事情做完有不同的定義：
「程式寫完只是還沒review，所以還沒merge」
「程式寫完測試也沒問題，只是QA還沒通過」
「功能搞定了，QA也沒問題，只是還沒...」
PO確實加入後，可以讓事情做完的定義，統一在於「可準備交付到市場」。換言之，所有和程式設計相關的工作：測試，相關文件，環境設定，certificate等等都會以「可準備交付到市場」為原則。沒有這個原則，跑Scrum很難達到預計效果，要達到這個原則，最基本的就是PO需要確實投入團隊。
(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)
這世界上沒有完美的團隊，也沒有不用修正的軟體開發方法論。每個sprint的確實檢討，是修正團隊，讓團隊趨於一致的唯一方式，而非強加訴諸任何規矩。請參考這裡
確實的檢討並不容易，要做到兩件事情：
(a) 基於事實檢討
(b) 不檢討不在場的人事物
基於事實的檢討
檢討的內容必須基於事實，不是基於感覺與想像。感覺和想像的情況如下：
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」
事實的情況舉例如下：
「這個sprint我們沒有按照當時說好的DOD的定義，所以有XX與XX項目，本來說完成了，後來隔幾天又說沒完成」
不檢討不在場的人事物
檢討確實是對事不對人，然而，事情都是人做的，不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。
不過，要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確，導致我們要重做某些事情」如果UI/UX是同一個scrum團隊，那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為，Scrum的檢討會議目的是產生「團隊要改善的項目」，而不是去讓非團隊的人改善。
Scrum的學習必然是從實際的經驗獲得，但經驗的獲得又必須從知識學習的取得為基礎，要成為看似不錯的Scrum專家不難，但要實際應用於專案中，並取得可重複成功的結果就不這麼容易了。
