如何在 Azure Boards 透過 csv 匯入 Workitems

有時候需求來源可能來自於一份 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

2023-06-23 · 1 min · Kyle

用 Mermaid 在 Azure wiki 繪製圖表 - 圓餅圖

在一條龍的 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

2023-03-27 · 1 min · Kyle

在 Retro Meeting 停下腳步,檢討改善

這是我在 .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, 應具備哪些要素?...

2023-03-17 · 1 min · Kyle

讓 Daily Meeting 不要淪為機械式的報告

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

2023-03-15 · 1 min · Kyle

估複雜度好花時間? 怎麼抓 Sprint 的能量?

這是我在 .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, 但怎麼判斷價值順序?...

2023-03-08 · 1 min · Kyle