AzureDevOps

這是我在 .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是否拆得不夠細等等 關注 Sprint 健康程度 Azure Boards 提供很多 Chart 檢視 Sprint 的健康成度，在實務上我特別喜歡看以 Task 為基礎的 Burndown Chart，因為 Story 通常都會交付在 Sprint 後判斷，測試完成 state 才會算結束，這會導致 Burndown chart 總在後面才一口氣下降，但如果 Task 是以 1-2 天為大小的話，應該都會發生 Pull Request & Code Review merge的情況，此時 Task 就會變成是 Done，這樣就會穩定的下降...

這是我在 .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 可以怎麼做?...

Scrum 353 Scrum Inc.創辦人 Jeff Sutherland 在他的書《Scrum: The Art of Doing Twice the Work in Half the Time》中提出的概念，它是 Scrum 框架的一種擴展，旨在幫助團隊更好地應對複雜性和不確定性。 裡面提到有個口訣 Scrum 353 的，它的核心概念是 “三個角色、五個事件、三個交付物”，其中： 三個角色：產品負責人、開發團隊、Scrum Master 五個事件：Sprint、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective 三個工件：產品待辦清單、Sprint待辦清單、增量 在跑 Scrum 一直以來我都是用 Azure DevOps 來完成整個流程，但就像 JIRA 一樣，裝了一些外掛後會讓整個運作更順，此篇文章整理我在實務上推薦必裝的外掛 此文章會不定期更新 價值排序 WSJF (Weighted Shortest Job First backlogs開始跟大海一樣，需要的是更多因素的評估，WSJF是一個考量 PMF 及開發成本的評估方式，此外掛可以自動計算出分數 Tags Manager Tag 維護的好，可以用 Query 產生出更多的報表，此外掛可以用來維護已建立的 Tag Multivalue control 如果想區別單子的Compoment，除了 Tag 外，也可以獨立用這種方式進行分類 SpecMap aka User Story Mapping 如果想跟團隊跑 User Story Mapping 腦力激盪跑出產品方向，這就是在 Azure DevOps 實踐的方式...