如何在 Azure Wiki 調整圖片大小
在撰寫和編輯 Azure Wiki 上的內容時,圖片是一種非常有用的方式,能可以更好地傳達訊息並增強文章的可讀性。但有時候圖片的大小會導致可讀性下降,這時候就需要調整圖片的大小,以符合頁面的版面設計或減少圖片的檔案大小。 第一種方式可以用 HTML Tag <IMG src="<圖片網址>" alt="圖片描述" style="width: 500px;"/> 但如果你的圖片是複製貼上來的,會存在於 Azure Wiki 這個 Repo,這時可以這樣設定去等比例縮放大小 ![xxx.jpg](/.attachments/xxx.jpg =500x) 或明確的給寬跟高 ![xxx.jpg](/.attachments/xxx.jpg =500x1000)
Azure Boards 繼承 Process的 3 大好處
我會建議在使用 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 所著重的比例
如何在 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
(啃書) 產品負責人實戰守則:從洞悉顧客需求,到引領敏捷開發
啃書代表是在閱讀時,針對自己有幫助的片段,做反思與紀錄,如想閱讀完整知識建議還是購買完整書籍 :P 產品負責人作為迷你 CEO 的角色定位 產品負責人(Product Owner,PO)在組織中被視為迷你 CEO,但他們的角色與 CEO 又有所不同,畢竟組織上通常不會明確的是一個直屬長官。儘管負有重大責任,但產品負責人更像是一位具有低調姿態、傾聽他人意見並以事實為基礎說服他人的獨行者。他們必須在不確定的情況下具備洞察真相的能力,這意味著他們需要從大量數據中挖掘潛在的問題,並為可能的變化提前做好準備。 做為一個產品負責人,溝通能力與分析能力都相當重要,這些都基於每個領域的知識累積,必須培養全局觀決策的能力 客戶反饋的重要性及其處理方式 客戶是雇用產品而不是購買產品 : 初衷往往是為了解決"某個問題",產品負責人需要密切關注客戶反饋,並對其給予充分重視。一個著名的例子是 “奶昔” 的故事,顧客購買奶昔的目的是為了在通勤途中解決無聊得打發時間的問題,而非單純品嚐口味。通過深入了解顧客需求,產品負責人可以確保產品符合市場需求。了解顧客需求,產品負責人在提案時可採用 Amazon 的六頁式報告,簡潔並完整地描述產品的目的、過去的相關試驗、失敗案例、未來的開發方向,以及用於確認產品成功可能性的數據。 客戶分類: 同樣的產品會擁有各式各樣不同的顧客,要從這些不一樣當中找出相同的意圖,對顧客進行分類,瞭解他們各自雇用這項產品的原因,再根據原因優化產品。PO 如果可以做好顧客分類就等同於成功了一半,因為我們必須瞭解所有的顧客,才可以完整地做好分類。分類完之後就只要專注在如何優化產品就行了。 PO 最容易犯下的錯誤之一,就是以產品製作人的角度看待顧客 數據驅動的決策 「假設」是佐證PO思維必備的工具: 不管怎麼從理論上說服自己,只要無法透過測試與數據證明假說,就不應該著手開發。我們必須要有一個標準來判斷PO的提案是否有誤,決定要不要立刻刪除這項功能,這也是假說與實證測試之所以必要的原因。PO應該相信數據,而不是單憑個人直覺。有時候,一個看似有效的改進實際上可能並未帶來實質性的提升。 假設也會失敗,例如,將選單上的炸雞排序移到最上面可能看似是一個好主意,但實際上可能並未帶來顯著的業績提升。又或者當初 Netflix 導入五星評價機制後發現,儘管評價時間變長,但顧客停留時間並未增加。因此,他們決定改用喜歡/不喜歡的方式,進而推薦給使用者喜歡的影片,從而提高用戶參與度。這些細節影響的小決策變化都會大大影響產品黏濁度因此。 該有自己的數據儀表板 : 產品負責人應該用全局觀去調查問題,並依據數據作出決策。如何做? 建立儀錶板以定期確認產品狀況是很有幫助的,甚至數位儀表板也要當成一個產品。內容可以是產品的用量,以日/週/月,累積數量角度來看,兩週的使用率變化 ,平均產品使用時間/惡意使用、非正常情況等等…另外可以製作WBR(Weekly Business Review),通常WBR可以有以下內容 主旨 (Key Call-Outs): 明確記錄上次WBR會議決策後發生的主要問題 產品目標 (Product Goals): 產品目標(OKR)和主要指標來評估產品的發展狀況 主要指標 (Key Metrics): 以三週左右的數據或近三個月的數據,讓人一目了然哪個部分表現好,哪個部分表現未達預期 身為一個產品負責人,應該要比任何人都還在乎產品發生什麼事,建立定期觀察數據的環境,是一個好產品不可或缺的要素 PO 在團隊的職責劃分 PO的任務並不是直接參與開發,而是要專注在如何讓工程師/設計師/商業分析師了解各自的任務,並明確提出需求與開發方向,如果過多的外務,就會無法扮演好自己的角色,這時擬定 R&R (Role and Responsibility)的劃分,就是一個很有幫助的方式 產品負責人應該努力將組織塑造成一個不斷學習和自我改進的團隊。這意味著他們需要鼓勵團隊成員犯錯並從錯誤中學習,以達到最佳的創新水平。團隊成員應該被鼓勵提出各種想法,即使這些想法可能在實施過程中遇到困難。產品負責人需要在失敗中尋找改進的機會,並將這些改進運用到未來的產品開發中。 也因為有責任又沒管理權力,產品負責人不應該採用獨裁式領導,而是應該用明確的事實和數據說服團隊。此外,在溝通時候盡量以疑問句代替命令,以創建更加民主和包容的工作環境。 在有限的資源裡發揮最大的價值,就是PO的職責所在,如果無法與團隊維持良好的協作關係,開誠步公地討論,都會影響到PO的決策跟產品交付日期 本書以 PO 的視角貫穿整個產品開發流程,除了以實例帶出 PO 在面對老闆/外部與團隊內部的溝通例子外,也將敏捷開發流程過程以PO視角闡述過一遍,並且說明數據決策的一些方式,接受產品的不完美,持續改進的方式,建議擔任過 PO 職務的人再來閱讀會更有感
在 .NET Core 使用 Feature Flag (Feature Toggle)
最近開發流程從 Gitflow 改為 Trunk-Based,讓每個 Feature 能很快速地回到主幹分支,但頻繁交付有時也不會想把新功能推出在使用者面前,所以這時候就能用 Feature Flag 來管理這些還沒有要發佈的功能,本篇文章記錄一下如何在 .NET Core 加入此功能,並講解一下目前實務上常規化的 Flag Nuget 安裝 dotnet add package Microsoft.FeatureManagement.AspNetCore 加入 Feature Toggle public void ConfigureServices(IServiceCollection services) { // feature toggle services.AddFeatureManagement(); services.AddControllers(); services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo {Title = "FeatureFlagPoc.API", Version = "v1"}); }); } 要使用時直接注入 private readonly IFeatureManager _featureManager; public WeatherForecastController(ILogger<WeatherForecastController> logger, IFeatureManager featureManager) { _logger = logger; _featureManager = featureManager; } 基本的 Feature Toggle 使用 var isFeatureAEnabled = await _featureManager....