在撰寫和編輯 Azure Wiki 上的內容時，圖片是一種非常有用的方式，能可以更好地傳達訊息並增強文章的可讀性。但有時候圖片的大小會導致可讀性下降，這時候就需要調整圖片的大小，以符合頁面的版面設計或減少圖片的檔案大小。 第一種方式可以用 HTML Tag <IMG src="<圖片網址>" alt="圖片描述" style="width: 500px;"/> 但如果你的圖片是複製貼上來的，會存在於 Azure Wiki 這個 Repo，這時可以這樣設定去等比例縮放大小  或明確的給寬跟高 
我會建議在使用 Azure Boards 選定 Scrum/Agile 工作流程後，一定要做“繼承”這件事，如此可以彈性的去設定整個專案的模式 Organzation Setting => Process 好處1: 可自訂欄位 可自己設計 Layout 調整不必要顯示的欄位 並且可以增加欄位，譬如增加 Version 用來指定該單子的版號，增加 Selection 來日常管理時挑選單子的輔助欄位 好處2: 自訂工作流程(State) 如果想要讓狀態更明確，可以自己去擴充或增減，譬如可以考慮多一個 State “Pull Request” 好處3: 隱藏不必要的 Work Items 敏捷最重要的精神就是極簡，但如果造內建定義好的 Work Items，也許會讓管理上更綁手綁腳的，通常我會建議可以有兩種玩法 玩法A: 只用 Product Backlogs 或者是 User Story 任何事情都應該對應到商業價值，要解決的問題也都是對應到“人”，用一種方式，依照 User Story 的撰寫方式把它寫好，會讓事情更單純 玩法B: Product Backlogs + User Story + Bug 將 PBI 定義成從團隊內發起的單子，譬如重構類型，User Story 定義成需求面，Bug 單子內容設計用來專注還原操作步驟 用這種玩法可以進一步撈出每次 Sprint 所著重的比例
有時候需求來源可能來自於一份 Excel，但這樣一個一個建到平台上實在太累了，這篇就來介紹一下如何用 Azure Boards 的 Import 功能將 csv 匯入進平台 要注意匯入功能狀態只能是起始的 state，無法指定該單子為 Doing 的狀態 第一個簡單的匯入 從 Boards => Workitem 進入 我們用 Work Item Type 跟 Title 來做舉例，最後一筆我故意輸入一個錯誤的類型 如果欄位驗證錯誤，也會明確指出哪一筆資料，哪一欄出錯 如果成功匯入，也不會馬上儲存，可以在這介面微調內容 批次修改 如果想要透過 csv 批次修改，首先要先將單子匯出，存在ID欄位，我們可以到 Query，並透過 Column Options 設定所需要的欄位匯入 這時就會看到包含 ID 欄位，我們將 Work Item Type 修改為 Bug 再重新執行一次匯入就能看到全部變 Bug 了 也可以用這種方式來進行不同 Project 之間的單子移動 可以有階層關係嗎? 譬如我們想要將某些單子指向上一層的 Feature 單，ID為 669 只要加一個 Parent 欄位即可 支援匯入的欄位 在官方文件有依據字母排列出所支援的欄位 https://learn.microsoft.com/en-us/azure/devops/boards/work-items/guidance/work-item-field?view=azure-devops
在一條龍的 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, 應具備哪些要素?...