在我們的網銀開發例子裡，第一步是把產品需求以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裡哪一個是最新的？
這份requirement document是我上次寄給developer的那一份還是她修改後寄回給我的那一份？
Excel runbook裡紀錄的test step和Word的為什麼對不上？
John連不上shared drive?ok，我寄一份requirements document給你。什麼？！這份跟Leslie的那份內容不一樣？！

擁有一個中央管理軟體就能解決追蹤和分享的問題。任何人看到的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那些是一定必要的。

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

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

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