如果要針對某用戶或群組來開啟特定功能，在 .NET Feature Management 中可以用 TargetFilter 來指定 appsettings.json (指定當前使用者的Guid或群組) RolloutPercentage 為選擇性參數，可以指定多少百分比的使用者會導向該功能 "FeatureManagement": { "FeatureA": { "EnabledFor": [ { "Name": "Microsoft.Targeting", "Parameters": { "Audience": { "Users": [ "1948fcc1-dc03-44a6-824f-fb48166ffa9d" ], "Group": [ { "Name": "Group1", "RolloutPercentage": 80 }, { "Name": "Group2" } ] } } } ] } } 實作 ITargetingContextAccessor public class TestTargetingContextAccessor : ITargetingContextAccessor { private const string TargetingContextLookup = "TestTargetingContextAccessor.TargetingContext"; private readonly IHttpContextAccessor _httpContextAccessor; public TestTargetingContextAccessor(IHttpContextAccessor httpContextAccessor) { _httpContextAccessor = httpContextAccessor ?...

承接上一篇，如果有一些情境是限時開放的功能，時間過了以後就要關閉，那就可以用到 TimeWindow appsettings.json "FeatureManagement": { "FeatureB": { "EnabledFor": [ { "Name": "Microsoft.TimeWindow", "Parameters": { "Start": "2020-11-09 04:58:00Z", "End": "2099-11-09 05:00:00Z" } } ] } } 基本的 Feature Toggle 使用 var isFeatureAEnabled = await _featureManager.IsEnabledAsync("FeatureA"); if(isFeatureAEnabled) { // 有打開，走新邏輯 } else { // 未打開，走舊邏輯 } API Route 多個使用方式，驗證不過會回傳404 [FeatureGate("FeatureA")] public async Task<ActionResult> Foo() { return Ok(result); } 也可指定任一或多個 Feature 是否有打開 [FeatureGate(requirementType: RequirementType.Any, "FeatureA", "FeatureB")] public async Task<ActionResult> Foo() { return Ok(result); } 也可以用 Enum 避免弱型別的typo [FeatureGate(MyFeatureFlags....

在一條龍的 Azure DevOps 平台，當然也存在 KM 功能， 透過 Azure Wiki 與 Workitem 結合，撰寫全貌的文件，能協助團隊更有效地進行開發與協作，其中Wiki 支援 Mermaid 語法來繪製圖表，本篇以圓餅圖作為示範 透過 ::: mermaid 與 ::: 裡面放置 mermaid 語法，即可呈現圖表 ::: mermaid pie title 年度銷售量 "Q1" : 2000 "Q2" : 1500 "Q3" : 3500 "Q4" : 4000 ::: 會產生以下結果 也可以加入 pie showData 讓 Label 呈現數值 也支援小數點數值 只可惜目前在 Azure wiki 無法針對樣式去做設定，但會跟著使用者的 theme 進行適當的配色 Reference https://learn.microsoft.com/zh-tw/azure/devops/project/wiki/wiki-markdown-guidance?view=azure-devops https://mermaid.js.org/syntax/pie.html

這是我在 .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, 但怎麼判斷價值順序? 一個好的 User Story, 應具備哪些要素?...

這是我在 .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，這樣就會穩定的下降...