這一季常用的專案管理、技術工具

Ann

Published in

Product Code: Ann

8 min readSep 19, 2023

第三季的季末放自己 2 天特休，回顧最近生活與工作上的配速，順便做個紀錄。

專案管理方面

Sprint Planning & Retro

這一季終於摸索出更有效率的 sprint 會議。

我處在老闆作為 product owner，並由 server engineer 組成的技術團隊，會議中一直以來仰賴他們導入、討論後端及資安的議題。也因此，我在會議中明明應是 scrum master，卻往往望著熱烈討論的他們發愣，雖然擔心會議拖得太長，但實際上介入了，也只是擔任司儀宣讀下一個議程。

記得一次又開了場嚴重超時的會議，懊悔之餘跟公司中資深的 PM 討教，才沿用她的經驗談，慢慢掌握出 sprint 每場會議的定位：

1. Sprint Standup

頻率最高的會議，我們 team 是排在每週一三五，每次大約 15 min 不到，用於核對進度及排除障礙。我會請成員分享進度讓眾人知道，隨後提醒未來兩天新進、或即將到期的 ticket；若成員工作上遇到困難，就排在會後、趁大家還在同個空間時討論完畢。

2. Sprint Weekly

每隔週召開，每次大約 1hr，用於確保開發進度是否跟上該 sprint 目標。在進度之外，我會事前向 product owner、engineer 蒐集的議題，寫好 agenda 供大家閱覽準備。

此外，公司常態地使用 GitHub Discussion 供大家自由投稿沒有明確 action item 的議題，在 PM 同事建議下，如果近期開發已經沒有障礙可討論（聽起來很棒），我就從 Discussion 裡面抓主題來提出，確保我們能兼顧短長期議題。

3. Sprint Retro & Planning

跟 Sprint Weekly 交錯，每兩週 sprint 期末同時召開這期 retro 及次期 planning，總長約 1.5hr，除了檢討進度是否跟上該 sprint 目標，也用於調整團隊開發節奏及訂定下期主要目標，放在同一個會議單純是為了減少會議次數（但有中場休息）。

Sprint Retro 前還是要核對進度，我事前會追蹤完該 sprint 的所有 delayed tickets，標註它們未完成的原因，先判斷是否延期到下個 sprint 或丟回 backlog，讓 product owner 現場附議或給予其他意見。

Sprint Retro 中會請大家回饋工作流、開發效率上的 what we’ve done well、what we could do better，這方面慶幸是團隊成員都敢於發言，但主持人還是事前準備 1–2 個點子先拋磚引玉會更順利。

Sprint Planning 用於規劃次期 sprint 要拉進 to-do 的 ticket，我會事前先跟 product owner 取得想法，標記符合主要目標的 tickets，避免成員在 sprint 中偏離 roadmap，反而先去完成相對不重要的 tickets。
此外，事前也要先確認 backlogs 中的 ticket 規格是否足夠明確（我的體感是要能在會議中講出完整的背景故事及預期產出），把有時效性的 ticket 先拉近下一期 sprint，並用 bug/ enhancement/ improvement 的性質分類過一遍給成員聽。

藉由提高已知的資訊量，我能更大程度地掌握會議時間，並把待討論的議題（如這個 ticket 要不要延後）定義成封閉式的問句，減少與會人的決策負擔。

GitHub Tips

在公司捨棄掉 Asana、Notion 並全面採用 GitHub 作為專案管理工具後，雖然非 dev 職能的成員花了點時間習慣版面及 markdown，但以推行數個月來說，接近 codebase 的效益仍是顯而易見。

我在工作中除了跟進每個 contributor 的進度，有時也會負責一些簡單的前端調整（有點像用現成的 UI kit 在 Figma 上延展頁面，只是換成臨摹 devs 寫的扣，依樣畫葫蘆）。長期摸索下來的結果，就是滿擅長在 GitHub 上追蹤 ticket，挖掘某個功能的扣寫在哪裡。

印象中是以 commit 次數計數，一直 git reset HEAD^ 重新 commit 的我不就虧大

Tracking Tickets

Project
GitHub 的 Project 專案管理工具偏陽春，比如無法像 Asana 設定該 ticket 的 start date & end date，很難在 roadmap 上一目瞭然；但基本上堪用，開 ticket 後自動匯入 project、PR merged 就 close ticket 的功能除了 GitHub 原生以外，多半是像 Jira 這些昂貴工具才能支援。
而隨著組織、功能擴張，開發時 issues 可能散落在不同 Repositories，值得慶幸的是，當各個 Repositories 都設有字串完全相同的 Milestones 時，在 Project 中能夠用 Group by: Milestone 來把不同 Repositories 的 issues 分組在一起（但我一直覺得 Milestone 應該跟 Project 一樣，提高到 Organization 的層級）
在 Sprint Planning 時，我就會用這個方式幫助成員了解各個 milestone 的 ticket 內容。
Notifications
因為 discussion、ticket 實在散落各處，我為了避免漏掉任一個討論，會 watch 參與程度高的 repo，當有更新時就送 email；此外，你曾經留過言（participated）、被提及（mentioned）的 discussion 或 issue 也可以在 Notification 中統一查看。

Search & Contribute

每個人在 local 寫好 code → 開 branch 發 PR 到 develop → PR approved & merge → merge develop 到 main → deploy to server/ platforms

自從理解到多人的軟體開發流程後，對我產生最深遠的影響就如航海王一樣——「工程師把邏輯都上傳到 GitHub 上了，大家去找吧！」

每當要做一些簡單的工程修改（如修錯字、翻譯、調整轉址）時，我會去回顧其他人相似議題的 commit 紀錄，抓到調整的規律後就開 branch 來寫。又比如遇到 client 上有沒看過的 error message，基於 error message 要嘛是 browser 定義好的、要嘛就是我們自己的，我會直接把那段訊息丟進 GitHub 查，一定能查到當時工程師寫好的 source code。

除了 codebase 方面，我也常常要把規格不夠明確的需求寫成 Discussion，供 Sprint Weekly 上討論。BTW，GitHub 上傳圖片方面都會預設 full width，要搭配 <img src="https://your-image-url.type" width="your-image-width"> 來自訂寬度。

Technical Tips

Visual Studio Code

我覺得最實用的兩大 shortcut keys

Add Selection To Next Find Match: Cmd + D

先在其他地方（如表格）複製 N 列，到 IDE 複製特定字串後按 Cmd + D 選取到 N 項後，再按貼上，就可以批次貼上 N 列的資料

Toggle the Terminal Panel: Ctrl+`

有時打開 VSCode，Terminal 會被預設關掉，就要手動開啟（話說我還不知道怎麼不用快捷鍵打開⋯⋯）

Postman

自從了解到 CRUD、以及用 Browser 輸入 endpoint 打開所見的內容，其實就是 method = GET、被 Browser render 後的結果，我對不使用 client、用單純的 API 可以交換到什麼資訊開始有濃厚的興趣，結果在 Huli [NET101] 網路基礎概論的推薦下，喜見 PokéAPI 的存在 XD

PokéAPI 是開源的神奇寶貝資訊查詢工具，我可以 GET 單一 pokemon species 的 ID 如下圖查到的皮卡丘，也可以 GET 個性、莓果、進化關係等資訊。作為想了解 API 使用方法的入門磚實在很有趣。