《Agile 成功法則｜敏捷實作者的解決方案》心得筆記
寫在前頭
最近對敏捷開發頗感興趣，開始了一個人的偽 SCRUM 生活實驗。這個 Sprint 的目標是讀完《Agile 成功法則｜敏捷實作者的解決方案》，並寫書摘……原本是這樣啦！不過後來決定將文章寫成個人心得或是重點筆記的形式，原因請聽我娓娓道來。
這本書的作者本身是一位經驗豐富的敏捷實作者。他從事敏捷方法的教學，也協助許多組織導入敏捷方法。過程中，蒐集到非常多人們在敏捷路上遇到的問題。因此這本書並不是架構性的介紹某某敏捷方法，而是整理常見的問題，以類似問答的方式，希望可以為讀者解惑。這本書的原文是 Real World Agility，我覺得比較吻合內文。作者再再強調實踐的重要，而不是學了一堆知識，卻無法在真實世界中導入。
作為一個才剛踏上敏捷路的新同學，老實說我對於一些內容可能因為還沒有親身經歷，所以很無感，但也有一些我很喜歡的地方。就好比沒辦法為一本百科全書寫書摘一樣，本文的撰寫方式，是很主觀的將書中我特別感興趣的部分抽出來，消化後重新分門別類一一做介紹。因此它只是部分篇章的節錄，並「不能」代表整本書。
敏捷 vs 瀑布
先說個笑話，某天兩個人在聊天，內容如下：
Ａ：「左手是什麼？」
Ｂ：「不是右手的另一隻手。」
Ａ：「那右手是什麼？」
Ｂ：「不是左手的另一隻手。」
通常，定義一個新東西很難令人理解，所以最好能夠舉一個鮮明的對比作為反例。敏捷式開發最好的反例當然就是瀑布式開發啦！問題來了，什麼是瀑布式開發？是不可逆的程序、還是交付時間很長，還是什麼？迭代的快就是敏捷嗎？還是小瀑布呢？因為自己沒有受過所謂瀑布式開發的訓練，並不真正瞭解瀑布式是什麼。而提倡敏捷開發的書籍或文章，立場肯定是站在敏捷一方，有意無意會認為瀑布式是過時的、有重大缺陷的。所以通常雖然會簡介什麼是瀑布式，但肯定會有所偏頗，不可盡信。
或許，認識敏捷，或說要真的對敏捷有更深切的感受，其中一個好辦法就是認識瀑布式開發。我是說，站在瀑布式的立場認識它。我想，讀 PMP 相關書籍會是一個好的開始。
參考書中章節：
瀑布式與敏捷 P.2
敏捷、精實、六標準差、PMP 與其他方法論的差異 P.12
敏捷的生活應用
我認為敏捷方法，應該可以適用於各種場域。這也是為什麼我會開始一個人的偽 SCRUM 生活實驗（一直自我推銷 XD）。書中第五章，是作者蒐集一些他人在敏捷路上的親身經驗分享。其中最令我印象深刻的，是一位敏捷實作者，他在冰箱上製作 Kanban 看板，在便利貼上寫生活中的代辦事項，然後貼在看板上，提醒自己有哪些事要做、進行中，還是做完了。他也嘗試教一群高中生，透過調整後的 Scrum 方法，完成種植植物的專題！這個經驗分享很激勵人心，這表示敏捷是一種精神，只要把握其精要，即可套用在開發產品以外的諸多情境，且都能獲得好成績！
參考書中章節：
Ebony Nicole Brown 資深企業轉型教練與訓練師 P.182
Scrum 導入
Scrum 是個輕量的敏捷框架，似乎只要符合一些規範，就可以順利在組織中導入……但現實世界不是這樣的。作者在書中提及兩個要點，一是要「訓練領導者」；二是得「小心反抗軍」。
作者認為對於上層，甚至是領導者的敏捷訓練，是相當重要的。唯有領導者理解 Scrum，支持團隊跑 Scrum，願意給新團隊犯錯和學習成長的空間，才有更大的機會獲得成功。
另一個則是，因為 Scrum 要求團隊成員高度自治、自我組織，對產品目標有共識。這跟傳統工程師只要在時間內完成被交付的任務 KPI 就 100 分的習慣是不同的。有些成員並不習慣關心產品好不好、客戶滿不滿意，只想做好自己的事（暫不考慮根本不負責任的員工，這個不論是不是敏捷開發，都會造成問題）。這些人就可能成為導入 Scrum 的反抗軍。我覺得沒有對錯，只是習慣不同而已。這時候，訓練跟溝通就特別重要，此外，我想或許也可以採用類似 OKR（Objectives and Key Results）的指標等方式，讓成員對團隊目標更有感。
最後，許多組織導入 Scrum 時，會過度拘泥於方法論。比如一定要舉行所有規定的會議、要有哪些產出，一定要這樣、一定不能那樣，才是 Scrum。作者認為能立即應用，對組織有幫助最重要。例如，就算無法馬上導入完整的 Scrum，只能採用每天 15 分鐘的站立會議取代本來每週冗長的進度會議，就比原本更敏捷一點。
參考書中章節：
如何讓領導者得到敏捷訓練？ P.66
反抗軍 P.58
參加訓練程式或研討會學到的內容有哪些能夠立即應用？ P.150
Scrum 的角色與互動
Scrum 是由產品負責人（Product Owner）、Scrum大師（Scrum Master） 和團隊成員三個角色組成。通常會強烈建議一個成員不能同時兼任多個角色，原因是如果兩個身份同時有事情要處理，將無法兼顧。可是，這聽起來像是能力或是時間分配的問題？假想有一個資深的專案經理，可以同時掌管多個大案子，且都處理得有條不紊，難道他會沒辦法兼任一個 5 到 9 人的小團隊的兩個角色嗎？作者提出的解釋是，這三個角色彼此有制衡關係，類似於美國法律上三權分立的概念。雖然我還不能完全體會兼任多個角色的衝突點是什麼，但對我而言這是個新的、值得思考的方向。
另外，Scrum 要求團隊成員要具備完成產品增量的所有技能。所以如果產品開發過程中需要 UI / UX 人員、QA 人員，理論上他們就都要被納入團隊中。但實際上，在許多企業裡，只有工程團隊本身在跑 Scrum，Design 和 QA 往往是獨立部門。作者認為，並不一定要完美的達成 Scrum 的所有要求才是 Scrum。比如，就算設計夥伴不在 Scrum 團隊中，如果能固定跟某一群設計夥伴合作，也會比每次都跟不同夥伴合作來得好一些。
最後是「自我組織」。作者認為「信賴」是關鍵。透過團隊成員間互相信賴，以及 Scrum Master 的妥善引導，組織就有足夠的動能創造最大的價值，而且同時成員也會擁有自由、富成就感、快樂！
參考書中章節：
從驅動流程來看，ScrumMaster 跟 PO/PM 的關係為何？ P.126
品保團隊應該屬於內部或外部？ P.134
使用者體驗/使用者介面人員應該擔任 Scrum 團隊的什麼角色？ P.152
有沒有對自我組織的建議？ P.122
Sprint 增量與發布
我很像一直搞錯 Sprint 交付物，也就是增量（increment）的意思。最常見的 Sprint 的長度是兩週，然後 Scrum 規定每個 Sprint 結束時都要交付完整的東西。「怎麼可能？並不是每個需求都可以拆成小小的，分兩週兩週發布上線的吧？」我一直有這個疑問。
作者明確的把「增量」和「發布」這兩件事拆開。交付增量指的是，交付出去的東西，是有價值的，而且以後要發布上線的時候，不用再做調整、修改、測試等等，因為這些都已經被包含在增量中。但這並不代表每一個增量完成時都要馬上發布。所以一個大的功能，確實會在完成多個增量後才一次發布。
另外，作者也很強調完成的定義。完成可能是程式寫完、測試測完、文件寫完、產品負責人驗收完等等。這些都是增量的一部分，只要有一個該完成的東西沒有完成，就可能減損增量價值。所以團隊應該妥善定義每一種完成，且大家都要對其有共識。而每個 Sprint 最後交付的增量，必須是每一種完成都完成，隨時可以被發布的狀態！
作者還提出一個有趣的觀點，是專案通常會在意「範圍」、「時間」和「成本」，並努力在三者之間取得平衡。既然 Sprint 的長度是固定的（時間固定）、Sprint 的成員也是固定的（成本固定），如果固定幾個 Sprint 發布一次，剩下的就只有範圍不固定了。如果某個產品功能需要達到一定的目標才能發布上線，那麼「範圍」就必須固定，但是就不能確定（但可以估算）要幾個 Sprint 才能完成。如此「時間」和「成本」便不固定。若要求三者都固定，就是天方夜譚了。
參考書中章節：
為什麼要求每個增量都必須能夠發布或對終端使用者有價值？ P.80
做完的時候就完成了：使用者故事 P.96
基本條件 P.54
嘿！我可以同時做到固定成本與固定日期！ P.109
認證與課程
或許因為作者本人從事敏捷訓練，所以他對於認證與課程持相當正面的態度。這點我持保留態度，而且在不同國家，狀況可能也會不同。拿到認證本身應是有利無弊，但是這類的認證考試花費不菲。我認為可以多留意求才市場，判斷到底花大錢有沒有那個價值。當然如果可以跟公司爭取到高額甚至全額補助就去考吧！
參考書中章節：
Scrum 認證的市場與就業常態 P.18
延伸閱讀
最後是兩本我之後想要看的書，和想進一步瞭解的方向。
《深入淺出PMP》
這本書應該算知名的 PMP 中文讀物。雖然網路上褒貶不一，也有很多人建議直接讀原文資料較為完整、正確。但作為入門，我想這本書應該還是很具參考價值的。
《SCRUM：用一半的時間做兩倍的事》
這本書是由敏捷之父傑夫．薩瑟蘭（Jeff Sutherland）所著。查了書評，它並不是在談某某敏捷方法該怎麼做，而是在談起源，談「為什麼」這樣做！我認為，唯有瞭解敏捷的本質，才能使用它而不受制於它，不流於徒具敏捷的外表。
另外，我對《Agile 成功法則》一書中提及的許多其他敏捷方法，諸如 Kanban、精實（Lean）、極限編程（XP, eXtreme programming）都頗感興趣，未來有機會要一個一個去研究。
最後，是作者在書中有提及規模（Scaling）的問題。因為 Scrum 建議由 5 到 9 人的團隊組成，但如果要做出一個大東西，這樣的人數肯定是不夠的。如何在大型團隊中導入 Scrum，就成為一個重要的命題，也是我想進一步瞭解的部分。
參考書中章節：
敏捷、精實、六標準差、PMP 與其他方法論的差異 P.12
怎麼讓 Scrum 適用在大型團隊？ P.40
