敏捷與 Scrum 軟體開發速成

第 2 章加入敏捷實踐者行列¶

不管你是要採用 scrum、精實(LEAN)、極限程式設計，還是要融合多種敏捷方法論，來建立你自己的混合方法，你都要：

邊做邊測試，現在就修復 bug，否則過了好幾個月之後，你早忘了那個 bug 是什麼造成的，要改哪幾行程式碼。一出現就修 bug，你立刻就知道是剛剛改的那個檔案的那幾行的問題
及早且頻繁的交付產品，只有透過展示可用軟體的方式，你才能發現客戶真正想要的是什麼。沒錯！客戶會看著電腦螢幕說「這不是我想要的樣子」或是「你可以改成那樣嗎？」，客戶看到軟體運作的樣子，會開始想像「如果改成那樣呢？還是這樣呢？」事實上我自己也是會這樣，所以程式會改來改去也是很正常的。
文件邊做編寫，只寫必須的文件。將文件作業融入流程，只寫有關的、有效用的文件。所以先寫使用者手冊/技術文件，再寫測試，最後才是實作程式？只寫這兩天時做的功能需要的文件？
打破隔離筒倉(silo)建置跨職能團隊，不要讓任何個人或部門成為流程、資訊的瓶頸。把資訊全部放在 issue、wiki 或網路上，不要問人。萬一他正忙著趕進度呢？萬一他請假/出差/上廁所呢？一旦要問人才知道，就只能一直等，於是他就變成流程與資訊的瓶頸

敏捷軟體開發宣言。請注意，它是說某一個因素「重於」另一個，而非「取代」另一個。因為敏捷的哲學不是「必須」、「應該」、絕對或權衡。

你籌組了一個新團隊，要求他們一定只能使用規劃撲克(Planning Poker)的方式作估算嗎？NO！你問是否可以建議新團隊嘗試規劃撲克，就試試一兩個 sprint 如何？YES！

文件只要有用即可，不要在乎是否美觀(12pt 標楷體)，更別把文件寫成上千頁的文學鉅作。

P. 40 重新裝潢廚房，別用「你已經簽約了」來威脅人家，屋主和承包商合作才有最好品質。儘早且頻繁的交付軟體，讓客戶早早看到東西，會更有信心持續合作，這時簽約才有意義

軟體開發是充滿未知數的流程，是一場發現之旅（進入偉大的航道上冒險？）。經常檢驗和調整才是真理。