文章
讀書報告：《The Art of Agile Development》說的主要是 extreme programming (XP)，介紹裏面各個實踐和其價值，應用配合。我自己看 Agile 看得雜東雜西的，這書就看得比較全面了，你會大概了解由專案開始到交付其間會有的各種活動如何互相配合，而 XP 是如何將其追求的價值推致極致。書中介紹了 37 個實踐，你會發覺他們之間有很強的相依性。所以作者說，初學者應該全部都先試行，在稍有經驗後才修改需要。
比如說，軟件估算永遠都是難做得準的，不只是開發者經驗不夠，還有開發時遇到意外情況，碰上技術問題，突然開會等等，都會使估算偏差，這些偏差是軟件開發活動必然會有的，那如何準確估算？這裏將用戶需求寫成一個 stories，其 story point，也就是實作要花的時間，靠稍有經駛的 developer 用直覺估算。在每次 iteration 排好 stories 順序，再按團隊的速度派 stories。速度來自 iterations 之間的 story points 完成數值，所以 iterations 夠短就能充實反映團隊速度。因為以速度為參考，所以中間團隊被打擾、開會等等都會被考慮在內。另外，story point 亦不能塞得過密，中間要有 iteration slack，讓團隊做 code cleaning、training 或處理例外情況。這裏有個假設，就是外部打擾是一個常數，不會大起大跌 (波幅大的話暗示另有問題)，可以被速度數值吸納。在這裏，幾個實踐如 Slack、User Stories、Estimating (velocity)、Planning Game、Iteration Planning 等等便互為合作。
又例如，在有關開發技巧的實踐裏，TDD 帶來的 Tests 固然是 Simple Design 的基石，但 TDD 需要紀律，用 Pairing 就可以補足，也需要用 iteration slack 去清理 technical debt。至於要支持 Pairing 和 slack 就得在上述計劃實踐互相配合。
另外有些實踐則令 Agile 成為能自我完善的過程，通過 Retrospective 定期檢視工作流程不順之處，用 root-cause 分析 (問5個why) 去尋找問題根源。一旦有自省機制，整個流程就能自我進化，更貼合需要。
這一籃子的 Agile 實踐，彼此相依，這就是為何作者會建議你先執行所有的實踐，因為部份執行未必見效的，但這相對來說也帶來實行上的阻力。人們近年愛說 Agile 文化不在於實踐教條，而在於核心價值，這當然是永恒真理。不過 Uncle Bob 就提出現實很多問題是實踐不足，而Agile文化其實顯於實踐。
延伸閱讀:
* The Art of Agile Development 七成書內容
* The True Corruption of Agile
* Trying to change company culture is a fool’s errand