sqz777 der 技術小本本

今天參加這個活動目的是想要更了解敏捷，來的時候遇到了很多之前實習公司的人 XDD
從實習結束之後第一次遇到 哈哈哈哈哈哈
實習也剛好差不多結束滿一個月了呢 www

今天這一個活動的主題是 User Story 的那些人與那些事
主要講述的是關於 User Story 的事情，什麼是 User Story ，為什麼要有 User Story ，如何寫，誰寫 等等之類的討論分享

在講師的簡報裡面有定義什麼是 User Story 也就是所謂的 3C

• 卡片(Card)－用一張卡片的大小簡述用戶的需求
• 交談(Conversation)－重點在於透過 User Story 作為溝通基底，而非直接交棒
• 確認(Confirmation)－透過用戶角度來進行驗收，看有沒有達到他們的需求

今天聽完這個分享就發現自己在實習的半年裡，想起來之前團隊裡的 Story 都是寫成 Spec，雖然這點對於團隊中沒有什麼不好，因為我們的PO 也是懂技術相關的人，且在需求的討論中獲得了這一個 Story 的價值，所以才會說沒有什麼不好。
不過我覺得還是得花時間去練習寫好的 User Story 或許會更好，畢竟 User Story 他本身存在的意義依然有他的原因，不然就寫 Spec 就好啦。

在整個分享過程之後，發現User Story 其本身存在的意義是為了讓大家都看得懂，他是一個溝通的媒介，也可以透過他來用客戶的角度來驗收。

講者有提到的Spec 和 Story 之間的差異的一個例子，如下

• Spec => 身為一個求職者，我想在搜尋篩選器多一個學歷的選項，以至於我可以篩選出符合我學歷的工作。
• Story => 身為一個求職者，我想要找到符合我學歷的工作，以至於我可以縮小合適的職缺範圍。

中間有一個人提出發問「不寫成 Spec 的其中一個原因是否是因為寫成 Spec 可能會限制開發者的彈性」
還有另一個人做出提問「在團隊跟業務之間如果對於需求非常的明確，是不是寫成 Spec 會比較好? 因為這樣就不用再花時間去理解Story所要描述的需求」
這兩個問題我個人覺得，其實要去追求 User Story 他本身存在的意義，如果知道他本身存在的意義，以及定義如何，那這兩個問題就可以很簡單的解決了
(如果有大大覺得不是這樣的話可以討論一下XDD 因為我也不知道我這個想法是不是對的

最後要提到的是簡報裡說的 很難撰寫「好的User Story 」的原因，總共六大項，總稱為INVEST，這六大項反過來想也可以翻解成，怎麼定義這是一個好的 User Story

• Independent－非開發團隊的人很難理解需求是否獨立

• Negotialble－撰寫時容易落入Spec 細節，不易進行討論

• Valuable－通常是假設性的，因此不確定此價值是否存在

• Estimable－非開發團隊很難理解何謂「可估計」的大小

• Small－非開發團隊很難確認此需求是否「小」

• Testable－非開發團隊很難理解何謂「可測試」

以下是我的理解

• Independent，一個好的 User Story 會是一個獨立的需求
• Negotialble，一個好的 User Story 會是容易進行討論的
• Valuable，一個好的 User Story 會是可以知道他的價值的
• Estimable，一個好的 User Story 會是好估計的
• Small，一個好的 User Story 是適度的「小」的
• Testable，一個好的 User Story 是一個可以被測試的需求

最後Q&A的部分我詢問講師一個問題「如果是傳統公司，適不適用 User Story?」
他回我說 「不適合，因為一般的傳統公司還是習慣寫成 Spec ，寫成 Spec 就會比較難以看出這一個需求的價值」
這個問答中我得到了 User Story 其實不只是要描述客戶的需求和溝通的媒介而已，重要的是它可以讓大家知道這一個需求的價值在哪裡，不是單純的「需求」而是「價值」

經過今天的整個活動的過程，自己對於 User Story 有更大的認識，至少不會像以前一樣，只知道要把需求寫出來，卻不知道其存在的意義到底是如何
不過要把 User Story 就需要花很多的時間來去把他撰寫出來，並且要透過許多的練習，才能寫出一個被定義為「好的 User Story」