The Nature of Software Development
薄薄一本、每頁短短的還有可愛插圖(?)，觀念不難但做到很難。
軟體開發環繞著「value」，翻成中文我想是「價值」。
value is “what you want”.
重要概念：
- 決定 value 是什麼或者說要什麼，feature 會為軟體帶來 value
- 以重要性決定做 feature 的順序
- 以 feature 組織 team
- feature by feature 開發，以 feature 了解目前進度
- 頻繁 deliver 得到回饋以知道是否需要調整 feature、方向甚至可以結束開發
每個概念都有更細的觀念跟具體作法，不過本書不太提具體作法。
Agile
整本書概念算是環繞著 Agile 的精神吧，看完最大感想：
Agile is simple, but not easy.
Agile 應該不只是開發人員的事，也包含業務甚至客人，而光開發要能做到就已經很困難了。
我沒有長時間跑 Agile style 開發的經驗，不知道長時間運作的結果，也不知道跑起來順的 Agile 是什麼樣子。只有拿相關東西做些實驗，例如 unit test 跟自動化測試，但連 CI 都還稱不上。
對開發而言光是「隨時保持軟體可正常運作、可以 deploy」，也就是完整 CI/CD 就已經很不容易了。
Feature by Feature
feature by feature 開發也是我覺得很困難的地方。我對 feature 的定義是軟體功能，但書裡不是這樣定義 feature，那什麼東西可以是 feature？
本書觀點：Features add value to software and value is what you want.
然後你就覺得有講跟沒講一樣……
好吧，假設我們知道要什麼了（喂），接下來如何估 feature size？如果 feature 太大要怎麼切？分工又要怎麼分？
目前遇到做不到 feature by feature 開發（這邊說的 feature 還是偏向「軟體功能」）的最大困難在「不知道怎麼將一個大功能切成多個部份去分工」。有時候大功能可以切分成比較不互相干擾的小功能，這種情況還可以分工，但很多時候怕修改的 code 互相衝突所以不敢再切再分。
不是做所有東西都需要多人分工，畢竟多人就有溝通成本。東西大到某個程度後分工會比較快，可是大到多大該分？而「害怕修改互相衝突所以不分」又真的無法解決嗎？
Design and Clean Code
本書主張快速並且持續的 deploy 小 feature 來進行開發，能這麼做的基礎來自 clean code、自動化測試、不斷 refine 的 design 等等。
程式整體架構跟結構是會逐漸變動的，並不是一開始定好長怎樣，往後就不再變動。
我現在傾向做「比剛好符合需求多一點擴充性的 design」，完全不考慮擴充性會讓之後有些東西動不了，例如 DB，現在還不知道到底要怎麼在中後期改善 DB 結構。也儘量避免做擴充性超強或者非常 general 的設計，一是擴充性超強不見得用得到，二是一開始做的 general 常常是自以為的 general，有第二組類似東西要加的時候很容易根本不合。
Planning with “stretch goals” is destructive (p.39)
不要試圖在一段時間內增加要做的 feature。
這會導致 team 為了「多加一個 feature」變得匆忙、開始「趕」，然後開始這裡少一個 test、那裡髒一點，結果是增加出 bug 的機率，之後得花其他時間修，或者後續開發因為 code 太髒而變慢。
蠻同意這一點的。我在匆忙下會開始掉東西，也會試圖減一些不太該減的東西，還有加 feature 看到別人趕出來的亂 code 真的會覺得「為什麼當初不好好寫，現在還不是要先 refactor……」
「匆忙趕工」只會更慢。
心有戚戚焉也能理解，但還是有點違反直覺。就是來不及或者多塞東西了才想要用趕的，反射性認為用趕的就能追上或比較快，但……事後要嘛有 bug 不嘛掉東西再不然下次加新功能難改到想罵人。因為違反直覺，所以現在遇到還是得克制一下衝動(?)。
About member
請容我說一句，我認為開發 team 裡每個人能力都要在一個水準之上並且擁有「想不斷改進」的 mindset，才能做到還算順暢的 Agile style 開發。
同時，發現 team member 欠缺某些能力時，是要去提升的。
Conclusion
本書最後結論寫得蠻有意境的。
Agile style 開發是很多人面對軟體開發的種種問題，經過實際使用然後認為有效的方式。
對於習慣，呃，土砲硬幹開發法？（不要亂取名字）的人來說，Agile 可能蠻容易違反直覺的？或者，違反「一直以來都這麼做」。
只是，那些直覺跟那些「一直以來都這麼做」的方式，真的有經過試驗確認有效？又真的試過 Agile 方法確認無效？
有用同樣標準看待各種方法嗎？
還是說，之所以堅持那些直覺跟「一直以來都這麼做」，是因為試驗跟換方法很麻煩？
每種方法有適用的問題跟情境以及使用後的效果，武器庫有愈多武器，面對各種狀況就有愈多選擇、愈能針對情境選擇最適用的。