iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 4
0
DevOps

DevOps平台的能力架構系列 第 4

Day04 - Agile Project Management

https://ithelp.ithome.com.tw/upload/images/20200924/20129694gggomkoOvO.jpg

在我們的網銀開發例子裡,第一步是把產品需求以user story的形式紀錄在agile planning software裡。為什麼需要那麼做呢?

回想到第二天所討論的CALMS framework,裡面的Measurement(測量)和Sharing(分享)這兩個部分。Scrum裡的三個主要支柱也提到:Transparency(透明化),inspection(檢查)和adaption(修正)。

Measurement

沒有記錄下來的東西是無法測量的,agile planning可以幫助你記錄和測量:

  1. Sprint的容量
  2. WIP
  3. Story測試結果
  4. Story如何引響OKR/KPI

Sharing

把所有的知訊都存在planning software的另一個效益就是知識分享。以前我在當Business Analyst時,最常用到的軟體三部曲就是Word,Excel及shared drive(ok,這個不算軟體,不過叫成“三部曲”聽起來比較殺)。

不過問題來了,我的50個word document裡哪一個是最新的?/images/emoticon/emoticon16.gif
這份requirement document是我上次寄給developer的那一份還是她修改後寄回給我的那一份?/images/emoticon/emoticon13.gif
Excel runbook裡紀錄的test step和Word的為什麼對不上?/images/emoticon/emoticon33.gif
John連不上shared drive?ok,我寄一份requirements document給你。什麼?!這份跟Leslie的那份內容不一樣?!/images/emoticon/emoticon04.gif

擁有一個中央管理軟體就能解決追蹤和分享的問題。任何人看到的requirements都是同一份,任何最新變動和進展大家都看得到,讓知訊透明化(transparency)。持續測量確保所有工作都朝著目標進行,檢查方向是否正確(inspection)。如果結果偏離目標,因為有紀錄,我們可以從中學習而修正下一個sprint的過程(adaption)。

所以一個好的agile planning software需要有下列的功能:

  1. 能夠紀錄各個不同層級的需求,並把他們連結再一起。例如:Vision > OKR > MVI/MVP > user story
  2. 每個user story要能紀錄相關的story point,test case和test result等。
  3. Status board (Scrum 或 Kanban,以開發方式為主)
  4. 整合報告功能(Burndown,Burnup,Velocity,Defect trend等。)
  5. 與其他開發功能的連結(CI/CD, testing)

當然,基本的story definition,user access,change tracking那些是一定必要的。

市面上的選擇也非常的多,例如RallyJiraGitLab boardsAzure boards等。選一個最適合自己公司的需求就好,重要的是一定要有。

談完了Agile Planning軟體,下一步就是如何紀錄user stories,然後把它們整合在application model裡了。

< 上一篇 Day03 - DevOps 平台
> 下一篇 Day05 - User Story & Requirements Modeling (Part 1)


上一篇
Day03 - DevOps 平台
下一篇
Day05 - User Story & Requirements Modeling (Part 1)
系列文
DevOps平台的能力架構19

尚未有邦友留言

立即登入留言