# Yves 敏捷專書 - 鈦坦的敏捷開發實踐分享 ## 前情 對了 我想要把這本書收錄敏捷夥伴們的實踐經驗，所以也許可以往嘗試過的敏捷方法和心得這方面寫嗎？這好像比單純推薦文更寶貴，當作一個共創的紀念。 - 推動 pair 的經驗 - 如何幫助團隊燃燒熱情，用技術 ## 引言 從 2017 年中開始輔導鈦坦的產品開發團隊，至今也三年半的時間了，我們一同改善了不少過去產品的痛點，一起建立了團隊的紀律，齊心讓所有團隊成員的技術水平拉到更高的檔次。很榮幸獲得 Yves 的邀請，將過去在鈦坦這些年一些值得紀錄的歷程與目標分享給各位讀者參考。 ## 如何激發團隊相互學習與知識共享 - 行酒令 ## 素材 - [團隊共同分享知識-熱鍵大賽](https://www.facebook.com/91agile/posts/1706001582907786) - [技術債清理策略](https://www.facebook.com/hatelove/posts/10222445664944966) - 重構與重寫 - 兩者的差異，為何重寫一般不可行 - 重構之前要有測試保護 - 測試 ROI 與切入點 - [菜鳥養成策略-pair programming](https://tdd.best/blog/rookie-strategy-pair-programming/) - 菜鳥 as 書僮 - [code review to pair programming](https://tdd.best/blog/code-review-vs-pair-programming/) - pair programming 補充 今天又碰到客戶端的工程師在問 pair programming 實務上真的可行嗎？會有老闆接受嗎？ 如果大家都認同，在軟體產品上錯誤越晚發現，修復成本越高。程式寫好之後要再修，成本就會比寫的當下修掉還高。 如果大家認同飛機上都要有機師與副機師，才能足夠安全。實際上會發生問題就是一連串的巧合跟原因，導致錯誤發生。 加上你原本程式碼就應該要有兩個人以上看過、看懂且認同（一般是 code review)。還別說同樣的需求不同的 developer 會有不同的思維，你有機會在一開始就挑到比較好的方案，所帶來的好處。 除非你們的東西都很簡單、重複性且趨近於無腦的作業（但每個人都覺得自己接到的需求超難超複雜的），否則 pair 能帶來的好處很多。（有些團隊根本沒 code review, 或是假的 code review, 自然也覺得 pair 沒帶來多少好處。） 總之，看你的角度是啥，你只想看產出，不想看品質跟價值，或是只要結案就好，只要數量就好，那真的用不著 pair。 - CI 紀律與測試穩定性 - 團隊紀律 - 產品基準 - 健康分析，避免破窗 - 一鍵部署 - 修復 bug 的時間縮短 - 團隊內部渲染力 - 新進成員受既有團隊成員影響而學習 - coaching 方式、事後渲染 1. 以產品痛點、重要流程為主軸 2. 各 team 派種子跨 team coaching 3.