➜ Old React website
Chung Cheuk Hang MichaelJava Web Developer
Java 測試(六):CucumberRailway 免費 DB PaaS

Jira 使用指引

Table of contents

1 Jira 簡介

Jira 係 Atlassian 公司旗下既一款產品,係一個專門用黎管理 IT 項目既各種「問題」既平台,呢啲同 IT 項目有關既「問題」包括但係不限於:
  • 開發新功能
  • 修復程式錯誤
  • 優化系統(技術負債)
註:Jira 既「問題」指既唔係真係有問題(problem),而係比較接近任務既意思,英文通常稱之為 issue、ticket 或者 task。

2 不同既 sprint 階段點樣用 Jira

我地需要透過 sprint planning、sprint grooming、backlog grooming 等等既討論環節,從中了解 product owner 對黎緊既 sprints 既期望,以及對於自己有信心同能力完成既 issues 同 product owner 達成共識。
呢啲 issues 可以黎自 project 既 backlog,亦可以係 ad-hoc 加入既,又或者係之前已經排好喺黎緊既 sprints 要做。

2.1 Sprint 開始之前

開始 sprint 之前(例如 grooming):
  • 盡可能將知道既野寫曬喺 description 裡面,並且揀選適合既 priority、epic、fix version 等等。
  • 可以先開定啲 sub-task issues。
  • 盡可能填寫準確既 time estimate。
    • 如果個 issue 超出一個 sprint 既時間,咁就應該將佢拆成幾個細啲既 issues。
  • 確保自己今個 sprint 既 issues 唔會超出一個 sprint 既時間。
    • 例如一個 sprint 為期 2 星期,最多就只可以接受 6080 小時(每日 68 小時,要計埋有啲時間可能用左黎開會)既工作量既 issues。
  • 確保 product owner 或者 team lead 同意自己今個 sprint 會處理既 issues。
  • 確保自己清楚今個 sprint 要做啲乜野,同埋有信心完成曬定好左既 issues,因為當 sprint 開始左之後先至搬走完成唔到既 issues 唔係負責任既表現,亦會整衰個 velocity chart。

2.2 當 sprint 開始左

  • 每日都要更新一下 issue 既 status,亦要善用 comments。邊啲 issues 有處理過既話就 log work 紀錄返工作數時。
  • 不時檢視下 issue 既 details,例如 priority、fix version 既資料岩唔岩。
  • 如果處理 issue 既時候發現有 blocker,就要以唔同既溝通渠道 raise 出黎,同埋喺 issue 既 description 或者最後既 comment 度寫清楚。
    • 如果有用 Risk Register 或者類似既 Jira plugin,亦都要用果啲方法 mark 好。
  • 不時檢視下有冇需要開新既 sub-task issues。
  • 當完成左一個 issue,喺 close issue 之前,先對比一下自己做左既野同 definition of done 有冇分別。
  • 唔好將唔喺呢個 sprint 完成既 ticket 移到呢個 sprint。
  • 唔好修改 time estimate,因為有可能會整衰個 velocity chart。

2.3 Sprint 臨完結前

  • 檢視下自己今個 sprint 啲 issues 既 statuses,絕大部分應該都處於已經完成或者即將完成既狀態。
  • 對於有信心完成既 issues,確保自己準備好需要既 test results、documentation。
  • 對於冇辦法完成既 issues,要喺 description 或者最後既 comment 寫清楚原因,甚至乎提供埋證據。

2.4 Ad-hoc 情況

  • 當 product owner 提出新 requirements 既時候,就開一個新既 story 或者 task 類型既 issue 喺 backlog。
    • 盡可能將知道既野寫曬喺 description 裡面,並且揀選適合既 priority。
  • 有需要即時處理既 issue 可以加入而家既 sprint;但如果唔係好急,可以放喺下個 sprint。

3 Jira issue 既各個部分

3.1 Description

  • 背景資料、原因、服務對象、報告問題既人名;
  • Internal/external dependencies;
  • 有邊幾方面既野要做;
  • 需要做既 testing、UAT 既人名以及程序;
  • 需要更新既 documentation 或者 release notes;
  • 完成呢個 issue 既具體條件(definition of done)。

3.2.1 Issue 與 issue 之間

我地可以將有關係既 Jira issues link 埋一齊,並且顯示 issues 之間既關係:
  • A associated with B 或者 A relates to B
  • A blocks B
  • A created B
  • A depends on B
  • A has to be done before B
  • A has to be finished together with B
  • A has to be done after B
  • A duplicates B
呢個關係係 bidirectional 既,link 左既另一個 issue 上面都會顯示邊啲 Jira issues link 左佢。

3.2.2 Confluence 文檔

我地亦可以將 Confluence 文檔 link 落我地既 Jira issue 度。
呢個關係係 bidirectional 既,link 左既 Confluence 文檔上面都會顯示邊啲 Jira issues link 左佢。

3.3 Activity

3.3.1 Comments

Comments 可以用黎紀錄:
  • 呢個 issue 進度上既變化;
  • 處理呢個 issue 果陣發生既大小事,包括 communication、發現到既 problems 或者 blockers 等等;
  • Test evidence;
  • 呢個 issue 既 requirements 或者 deadline 上既改動。
註:
  • 我地可以善用圖片或文本既 attachments 黎提供 testing、communication、blocker 既 evidence。
  • Comment 裡面引用圖片既時候,可以入 text mode 將佢改成 !<image file name>|thumbnail! 既格式,咁圖片就會以縮圖顯示。

3.3.2 Work Log

Work log 係用黎紀錄我地邊日處理過邊啲 issues,啲數字可以反映喺 dashboard gadget 或者 reports 裡面。

3.3.3 History/Activity

我地可以喺 history 或者 activity 度睇返邊個人改左啲乜野,包括但係不限於:
  • Status 既變化;
  • Details 既改變;
  • Description 既改動;
  • Comment 既增刪。
不過如果我地修改左現有既 comment,係冇辦法知道修改前既 comment 內容。

3.4 People

如果呢個 issue 改由其他人接手處理,咁應該將 assignee 改成其他人。
但如果只係短暫地需要其他人幫手,咁就唔應該將 assignee 改黎改去。

3.5 Time tracking

呢個部分包括:
術語解釋
Estimated我地預計呢個 issue 需時幾耐,可以用 h(小時)作為單位。
Remaining理論上等於 estimated 減 logged。
LoggedWork Log 度 log 左既工作時數。

3.6 Development

我地可以將 Bitbucket 既 commits、branches 顯示喺 Jira issue 上面。
  • 想顯示有關既 commits 既話,commit message 需要包括 Jira issue key,例如 ABC-123 Updated app config.
  • 想顯示有關既 branches 既話,branch 名需要包括 Jira issue key,例如 feature/ABC-123-refactoring
    • 如果有清除 short-lived branches 既習慣,就應該依賴 commit message 既方法去 link 落個 issue 度。