昨天談完了agile planning，今天來看看如何紀錄user stories，然後把它們整合在application model裡。

一個良好的user Story需要遵循INVEST原則：
Independent - 每一個user story應該在順序上是獨立的。

Negotiable - user story裡的細節不是絕對的，而是用來開始對話的。

Valuable - 每一個user story必須是要對客戶有價值的，所以story中一定要紀錄why。

Estimable - user story應該是有辦法讓開發團隊估計effort的。通常不行的原因在於:

1. 故事描述不足，這時就該確定故事裡有著who，what，why和acceptance criteria
2. 團隊對此領域的知識不足，這時就該加入一個研究用的故事(spike)。新創的Spike也需遵循INVEST原則

Small - user story 應該要在工作量上夠小。在2 week sprint中一個故事應該只佔三到四天，這樣有足夠時間測試及修改。

Testable - user story一定需要擁有definition of done。也就是把test case直接以acceptance criteria的形式紀錄在user story裡。

要能達到以上幾點，溝通是非常重要的，也是DevOps的中心思想。

開發過程的三個主要角色(Three Amigos);Business，Development，Testing需要在每個步驟都參與，並定期討論產品如何開發，缺一不可。

我們來看一下實際的例子吧。第二天我們提到Product owner已經確定需要在我們的主頁上加入一個“記住選項”的checkbox，所以product owner，development 和 QA 正在開會為新功能創造user story。

記錄下來的user story如下：

As a user I want a remember me checkbox for the system to save my username at the login screen so I don't have to re-enter my username every time I log in.

Acceptance Criteria

• When selected, the system should pre-fill the username in the username field after first successful login
• users should be able to remove the selection and the system will no longer pre-fill the username

注意這個故事裡面提到who(As a user)，what(remember me checkbox to save my username)，why(so I don't have to re-enter my username) 和 definition of done (Acceptance Criteria)。

在大家都同意這個故事後，我們就該把這個故事加到我們的application model裡了。

Application model的用處是在於能整合所有到目前為止的所有user story，而讓所有人都能簡單明瞭的知道我們程式的行為(Behavior)是什麼。也就能滿足CALMS裡的Sharing以及three ways的amplify feedback loop。

本來想要在這一篇進入application modeling的細節，不過之前user story的部分比想像中的長，而modeling的內容也不少，只好分成兩篇了。

明天我們會看一個application model是什麼樣的和application model如何幫助我們減少溝通，開發及測試中的瓶頸。

< 上一篇 Day04 - Agile Project Management
> 下一篇 Day06 - User Story & Requirements Modeling (Part 2)