眼尖的朋友看到，最近我開的兩堂課： Deliver Project on Time 敏捷專案管理實務 - 六月班 與 Intermediate Rails - Rails 實戰就業班（六月)，都加入了 User Story 撰寫的教學部分。紛紛偷問我為什麼要加這個東西進去？
Rails Meetup 三年多來，在輔導培訓過非常多 Rails Developer 之後，我開始發現當今的網站開發教育中漏掉了很重要的一環，就是「規劃 Application 開發的技術」。
線上教育什麼技術都有教：基本的 Ruby on Rails，基本的 jQuery，基本的 CSS。看起來好像你上了這些基礎班，就可以開始寫一個網站，找到一份工作。但這卻跟現實有一段相當大的差距。我訪問過很多徵才廠商和初級開發者，開始了解到問題出在哪裡。
具備網站簡單的開發能力只是必備的基礎，僱主最看重且會決定錄取的能力，卻是「把 Idea 變成實際 Application 的能力」。就是今天老闆開一個需求，員工要能做出規劃，並且在時間內執行完畢。
很多成長為 Senior Developer 的前輩沒有意識到這也是一門技術，所以面對「如何培養規劃實做能力」的問題，因此往往會覺得，你多寫習題就可以練成了，或找到一份工作被多操一下就會了。但這又回到雞生蛋、蛋生雞的問題，沒有能力寫出中小型 Application，又怎麼容易找到可以成長的工作。
打破雞生蛋、蛋生雞的循環：User Story as Architecure
我後來一直思考如何解決這個問題。才發現其實很久以前我已經解決了這個問題，只是我一直沒有意識到..，就是：「透過撰寫 User Story 的訓練，練習出如何設計架構的能力。」(這個技術四年來也一直在我部門/公司中施行訓練）
什麼是 User Story
User Story，是 Scrum 這個敏捷框架會用到的一個開發方法。具體解釋可以看ihower 曾經寫個的這份整理，寫的很棒。
傳統開發流程是 PM 花上很多的時間進行訪談寫成規格，RD 再轉成 Application。不過往往這個轉換過程中，卻容易出現相當大的風險。
當中的問題出在於 PM 的「規格」有很大的機會天馬行空，即使不天馬行空，也有可能不貼近使用情境，或者是根本脫離真實使用情境。RD 自然拿到規格和畫面 Workflow 進行「轉換」時，萬分痛苦。
當然，更多時候， RD 根本不知道要怎麼「轉換」。這就是為什麼每個專案都花了很多時間進行了需求訪談，也可能寫了詳細的規格，專案卻始終容易出包，都是在「轉換過程」中出現了問題。
User Story 強調透過一份簡單的情境規格，具體的描述出軟體在「使用者」的手上，是怎麼樣被「操作」的。能夠讓 RD 在開發時，能夠盡可能地貼近真實被需要的 Application。而不需要的功能，或者無法被實作的功能，將在一個一個循環之中，被捨棄。
初學的範本是：作為一個 (某個角色) 使用者，我可以做 (某個功能) 事情，如此可以有 (某個商業價值) 的好處。
幾個 User Stories 的範例如下：
- 使用者可以在網站上張貼履歷
- 使用者可以搜尋有哪些工作
- 公司可以張貼新工作
- 使用者可以限制誰可以看到他的履歷
為什麼 User Story 可以幫助培養開發能力
透過把冰冷的規格轉成具體的小情境，RD 可以更知道要怎麼將架構切分成較小且可以單次就開發完畢的小元件。利用一個一個小的故事，開發出一個一個的小功能，再堆疊成一個完成的網站。同時透過 User Story 的內容對比，RD 能夠開始有辦法排出輕重緩急，甚至估算出正確時程。
我發現很多入門的 Rails 開發者，在學完基礎的 Rails（ 比如說學完 Intro to Rails 、Rails turtorial。這些從 CRUD run 到 deploy 到 Heroku 的簡單一日課程之後。就無法再進行下去了....
根本原因是初學者不知道下一步如何進行自己點子的實作。
許多的書籍都有具體給定步驟與架構，因此在自行練習的時候沒有問題，但在自己自由設計題目時，卻不知道如何開展。或者是自己有了一點基礎想法，拍了某些網站的 screenshot & workflow。拿回家時卻不知道怎麼 breakdown。
這就是為什麼我在
都加入了 User Story 的教學部分。因為 breakdown to application, simple project management 就是新手進階成職業的一大瓶頸門檻。
為什麼非程式設計師也需要學習撰寫 User Story
在 Deliver Project on Time 敏捷專案管理實務 的五月班，有一位很有意思的報名者，他報名是因為長期參與 NGO 的活動，但卻覺得 NGO 的專案規劃以及執行專案能力不佳。因此想要透過上這個班，實際學習專案管理能力。
其實不只是 NGO，通常非程式設計師出寫出的規格通常都較脫離現實，是因為誤以為了軟體開發只要提供了「欄位」「畫面」「流程」「仿照知名網站的 Workflow），這樣就是完成專案的規劃。
事實不然，程式設計師往往希望你提供的是軟體使用「需求」，以及軟體「使用情境」，這樣他們才容易設計出好的軟體。很多規格書滿滿的 screenshot，或者是標注模仿某知名網站 Workflow。其實都不是程式設計師想要且需要的東西，他們希望你有辦法簡單敘述你要什麼，你想要的流程是什麼，你背後的生意邏輯是什麼。（a.k.a. 你真的知道自己在幹什麼）
好方便「程式設計師」後續「規劃」「軟體架構」。
User Story 可以很容易的協助雙方達成一致性的目標，因為User Story的書寫語言並不是什麼技術文字，而是一個又一個的情境。可以作為一個相當好，雙方又容易接受的橋樑。同時透過撰寫 User Story，自己也可以越來越釐清這個網站真正需要的東西是什麼，不需要真的實際寫程式，不懂程式也可以設計出合理的網站架構。
這就是我建議為什麼非程式設計師也需要學習撰寫 User Story 的原因。
學習資源
要學習撰寫 User Story 以及學習進行簡單的小專案管理。你可以購買 Scrum 系列的書，或者是以下幾本我覺得不錯的書：
- User Stories Applied: For Agile Software Development
- Extreme Programming Explained: Embrace Change
- Extreme Programming Installed
當然，如果你想偷懶，最快的方式，還是報名我以下的這兩個講座 / Workshop。我有直接整理好的講義以及結合 Project Management 的實戰技巧。
希望以上這些學習資源能夠幫助到你。
( 如果你有相關的疑問，歡迎透過這個表單 聯絡我）