Scrum 系列：該不該在 Taskboard 新增 PR Review 欄位呢？
在大多數的情況下，在產品團隊的工作流程中加入程式碼審查（PR Review）的機制，可以提升產品的品質，，並且促進知識的分享與團隊的合作。
前幾天剛好有一位朋友詢問：「你覺得在 Taskboard 上加上 PR Review 這個欄位的想法怎麼樣？」
我回答：「我覺得滿好的，是一個可行的方法，讓團隊的工作流程中內建 PR Review 的文化。」
Taskboard 在預設的設計中，通常有三個基本的欄位，包括 Todo、In Progress、Done。在 Sprint Planning Part 2 時，團隊會將 PBI 拆解成任務並且放在 Todo 欄位中。隨著 Sprint 開始，正在進行的任務會移動到 In Progress 欄位，當任務完成時會移動到 Done 欄位。
如果產品團隊中想要在工作流程中加入 PR Review 的機制，主要有兩種做法：
第一種方法是把 PR Review 當成是一個任務，所以在 PBI 下面新增一個 PR Review 的任務，並且把 Assignee 設定成替整個 PBI 做程式碼審查的團隊成員。例如在上圖中，PBI 是由 Derek 主要實作，紅色方框是 PR Review 任務，由 Meredith 做程式碼審查。
這種方法的優點是在 Sprint Planning 時，預先幫每個 PBI 下面都新增對應的 PR Review 任務，並且事先分配給團隊成員。因此，團隊成員在評估整個 Sprint 的工作量時，也會把程式碼審查工作納入考慮，避免沒有時間幫其他人做程式碼審查。
當然，這種方法也有一些缺點，容易忘記幫每個 PBI 新增對應的 PR Review 任務。另外，每次都要新增相同標題的任務單，重複的動作有些擾人。
第二種方法是在 Taskboard 新增 PR Review 欄位。當任務不需要做程式碼審查時，任務從 In Progress 跳過 PR Review 直接移動到 Done；當任務需要做程式碼審查時，任務從 In Progrss 移動到 PR Review，並且將任務的 Assignee 設定成預計做程式碼審查的成員。
這種方法的優點在不需要事先幫每個 PBI 新增對應的 PR Review 任務。另外，在工作流程中可視化 PR Review 狀態，讓進行中的 PBI 除了 In Progress 狀態之外多了一個更細部的狀態，幫助團隊更能掌握 PBI 的現狀。
總結來說，兩種方法各有優缺點，是否在 Taskboard 新增 PR Review 欄位，應該根據團隊的具體需求和情況進行評估，確保任何更改都能夠有效支持和提高團隊的工作效率。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
