這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 Scrum 團隊可以在 Retro 會議中有效地檢視自己的工作狀況，找出需要改進的地方，並制定具體的行動計劃。這有助於團隊持續改善工作流程，提高工作效率，並確保專案能夠成功地達成預定的目標。這可以說是 Scurm 當中最重要的 Events，必須要有個共識，每次 Sprint 都會越來越好 實體可以用便利貼，面對面溝通，但如果是遠距團隊，在 Azure Boards 上可以安裝Retrospectives 這個套件，透過這引導可以線上開一個即時的回顧會議，它會分以下五個步驟: Collect (收集) Scrum 團隊在 Retro 會議中的第一個步驟是收集。在此階段，團隊成員共同分享在過去的一個迭代或是開發週期中所遇到的問題、挑戰、成功經驗和改進點。收集階段的目的是讓團隊有個機會回顧自己在專案中的表現，並確保大家都有足夠的機會表達他們的想法。在這個過程中，團隊成員可以自行建單，將他們的想法和建議記錄下來。這有助於確保每個人的想法都能夠被考慮到，並創造出一個共同的基礎以進行後續討論。 Group (分組) 在分組階段，除了理解大家回饋的項目外，也一起將相似或相關的議題整合在一起。這有助於團隊更有效地針對特定議題進行討論，並確保在限定的時間內充分探討各個問題。分組階段的目的是讓團隊有機會深入了解各個議題，並確保討論的範疇不會過於繁雜。 Vote (投票) 團隊成員將對在隊分組過後的議題進行投票，以確定哪些議題是最為重要且需要優先處理的。一般而言，每個人都會有限定的投票次數，以避免單一意見主導討論。投票階段的目的是讓團隊達成共識，確定哪些改進項目最為關鍵，以便在後續的步驟中針對這些議題進行更深入的討論。 Action (行動) 行動階段是團隊討論如何解決所確定的問題，並制定具體的行動計劃。在這個過程中，團隊成員將提出解決方案、改進方法，並討論如何實施這些措施。最終，團隊將就每個行動項目達成共識，建立 Workitem，分配負責人和設定期限。行動階段的目的是確保團隊在會議結束後能夠將所討論的改進點付諸實踐，並持續改進團隊的工作流程和效率。在這個階段，團隊成員需要承擔責任，並對所提出的解決方案保持承諾，以確保改進措施能夠成功地實施。 History (紀錄) 歷史階段是 Scrum 團隊在 Retro 會議中回顧以往改進經驗的時間。在這個階段，團隊將檢視先前的 Retro 會議紀錄，評估之前提出的行動項目是否已經完成，以及這些行動項目對團隊的影響。歷史階段的目的是讓團隊在不斷進步的過程中保持學習和成長，並確保之前的改進努力沒有白費。 如果你想要看完整的演講影片，現在也已經傳到 Youtube 影片: https://www.youtube.com/watch?v=G0ggjY5kzF8 簡報: https://speakerdeck.com/kyleshen/dot-net-conf-taiwan-na-xie-nian-yong-azure-boards-jiao-fu-guo-de-chan-pin 5篇 Scurm 痛點文章 Product Owner 需維護好 Backlogs, 但怎麼判斷價值順序?...

這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 Daily Meeting 講什麼? 我昨天做了什麼 我今天打算做什麼 任何阻礙您完成工作的障礙 在透明度看板下，我覺得第三點特別重要，目的在於: 重新確定優先順序並分配重新計劃的工作 這篇文章寫給 Scurm Master，除了聽取報告外，在 Azure Boards 我們能在 Daily 看哪些事 Work Detail 在前一篇文章我們設完 Capacity 後，在 Azure Boards 的 Work Detail 就能針對團隊每天的消耗量去看進度是否有異常，如果消耗不如預期，甚至有 Daily風險，會呈現紅色，這時 Scurm Master 就能關心該名成員，是不是有需要協助的地方，並與團隊討論重新調配 Task Board 在看板模式，我們可以看出成員是否有多工的情況，理論上 In Progress 每個人都只需要專注一件事就好，因為分工是隨著每天的狀態去調整的，最重要的事團隊一起努力達到 Sprint 的目標 以週的檢視角度 在實務上我更喜歡以週為單位，讓團隊預先安排 Task 發生的先後順序，有計畫地展開一週工作，會讓整個節奏更穩定，在 Azure Boards 可以透過 Drop Plan 這個套件去在 Daily 時檢視，也可以看出實做的先後順序是否有相依性，Task是否拆得不夠細等等...

這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 複雜度評估的兩個方式 在 Azure Boards 裡面可以安裝 Estimate 這個套件，在 Planning Meeting 的時候可以針對 User Story 進行估點計算，且這是一個線上即時的功能，即使遠端協作的團隊也可以達到很好的估點流程 這工具在出點的時候可以一起呈現，如果彼此點數落差大，可以進行多輪的討論，我們通常會用相對點數來讓團隊取得共識，此套件也能選擇很多範本 但如果你今天是有海量的需求，不想花太多時間一張一張評估，也許可以用 Affinity Estimation 這種方式，他的執行步驟是由PO解釋完單子後，將所有單子都建在看板上，透過團隊共同拖拉的方式，越左邊代表複雜度越小，越右邊越複雜，之後取中間當個分隔線，在給予不同大小的渠道。 最後一個步驟是針對鄰近的單子去比對，兩個大小是否是差不多大小，如果落差過大再微調 延伸閱讀: https://www.techagilist.com/agile/scrum/affinity-estimation-agile-estimation-method/ 如何知道團隊成員工作量? Planning 另外一個重點就是在 User Story 底下去拆技術細節去分工(Task)，雖然估時估不準，但我會建議還是能在 Original Estimate 這個欄位讓工程師評估一下這個單子預計要花的時間，通常一天我們會以 6hr 為單位，如果 Task 評估大於 12hr，代表顆粒度太大，需要再細拆，為什麼要這樣做呢? 因為搭配 Capacity 針對每個工程師每日可貢獻的時數，可以讓我們知道每個工程師拿的量會不會過多或過少 但記得一點，不要用這個來挑戰工程師產值，敏捷強調自我管理，信任制，為了共用目標努力，太在乎每日產出只會造成工程師給錯誤的資訊 在 Planning 檢視每個人的工作量是否平均 如果你想要看完整的演講影片，現在也已經傳到 Youtube 影片: https://www.youtube.com/watch?v=G0ggjY5kzF8 簡報: https://speakerdeck.com/kyleshen/dot-net-conf-taiwan-na-xie-nian-yong-azure-boards-jiao-fu-guo-de-chan-pin 5篇 Scurm 痛點文章 Product Owner 需維護好 Backlogs, 但怎麼判斷價值順序?...

這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 在 Mike Cohn 的 使用者故事一書中，有提到一個好的 User Story 應具備以下內容 獨立的 (Independent) 為了提高產品開發效率，User Story 必須盡可能獨立，與其他單子的依賴性越低越好。這樣可以讓團隊更好地分配工作，並使開發流程更加靈活和高效。當 User Story 之間有很強的相互依賴性時，只要一 Delay 可能就會影響其他單子的進度，進而影響整個產品的交付。因此，將 User Story 設計為盡可能獨立的單元，可以降低風險，減少延遲和錯誤，同時提高產品的可靠性和可維護性。 可協調的 (Negotiable) 為了達到產品開發的效率和靈活性，User Story 必須是可協調的，即可以保留一些開放式描述，讓團隊進行討論和協調。User Story 的開放式描述可以激發團隊成員的討論，進而確定 User Story 的實際需求和功能。同時，開放式描述也可以在開發過程中進行調整和修改，以適應產品開發的實際情況。在 User Story 中保留開放式描述可以幫助團隊在開發期間進行更好的協調和溝通，並確保產品能夠滿足用戶需求。最終，這樣的協調和討論可以幫助團隊建立更強的團隊合作精神，以達成產品開發的最終目標。 有價值的 (Valuable) User Story 對於使用者來說非常重要，因為它們確定了產品的功能和特性，並且能夠滿足用戶的需求。如果 User Story 無法滿足用戶需求，那麼產品將無法被成功接受。為了確保 User Story 的價值，開發團隊必須理解並關注用戶需求，將其轉化為可實現的 User Story。只有這樣，才能創造出一個有價值的產品，並滿足用戶需求。 可預估的 (Estimable) 必須能夠對它們的大小、難易度和所需時間進行預估。這樣可以幫助開發團隊更好地分配工作，同時確保產品交付的準時性和品質。通過對 User Story 進行預估，開發團隊可以更好地掌握開發進度和進度風險，並提前進行調整。但需要注意的是，User Story 的預估並不是一個精確的科學，因為它們可能受到多種因素的影響。因此，開發團隊需要持續進行評估和調整，以確保 User Story 的準確性和可行性，並最終創造出高質量的產品。...

這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 Scrum Guide 說 Product Owner 需要依照價值排好 Backlogs，讓整個團隊可有穩定的節奏開發產品，但怎麼排序往往是個難題，有沒有一個框架可以參考? https://uxdesign.cc/how-to-choose-your-product-prioritization-framework-ff0320d63ebf 的作者製作了一個框架提供參考 可以用兩個面向各字給 1-5 分來決定用哪種價值排序方式 需給客戶驗證的程度: 需要在End User的參與下進行一定程度的數據收集或假設驗證練習來驗證程度，越密切分數越高 定性定量的程度: 需要更多的數據驗證，因素越多分數越高 透過這樣的兩個面向，可以初步選擇所使用的框架，本文以最 MoSCoW 及 WSJF 做舉例 MoSCoW MoSCoW是一種常用的優先順序法，用於將需求和功能分為四個類別： “M” 代表必需品（Must Have），這些功能或需求是關鍵的，必須在產品中實現，否則產品無法正常工作或無法交付。這些功能或需求通常是必要的核心功能或重要的業務需求。以我自己定義通常為 “沒有交付就不能達成商業目標” 的項目 “S” 代表應該品（Should Have），這些功能或需求是非常重要的，但不是必須的。如果有足夠的時間和資源，這些功能或需求應該被優先實現。 “C” 代表願望品（Could Have），這些功能或需求是可選的，通常是增強產品體驗或功能的選項。如果時間和資源允許，可以考慮實現這些功能或需求。 “W” 代表不需要品（Won’t Have），這些功能或需求是不必要的，不需要在產品中實現。這些功能或需求可能已被視為過時或不再需要。 當然，以上可以自己定義，目的為直覺得加速判斷，以我自己定義可以用以下方式來做收斂: Must Have: 沒有交付就不能達成商業目標 Should Have: 重要但短期有替代方案 Could Have: 不做沒關係，但做了能為產品帶來加分效果 Won’t Have: 就算做了有無助於提升產品價值 而 Azure Boards 可以怎麼做?...