David Ko的學習之旅

在敏捷開發中, 需求是否要一開始就要齊全呢? 當然不是這樣的, 沒有人能一開始就可寫出所有事情的. 即使你想要這樣做, 所花費的時間可能也會超出你想像的久. 所以在 agile 中, 需求是逐步演進的.
這樣的想法, 我想大多數的人是可以接受的, 但是大家會問那要怎麼做呢? 讓我們一步步道來.
 

使用者故事(User Story) 是敏捷社群用來描述需求的 practice. 它非常容易上手, 但是也容易犯下錯誤, 以下便是常見的問題:
 
 
1. 都是使用者
User story 有個範本: 
     as a <role>, I want to <action> because of <business value>. 
大家可以根據這個來撰寫使用者故事. 可是很多人在寫的時候都會變成這個樣子
     身為一個<使用者>, 我想要<可以根據關鍵字查詢書籍>, 因為<大多數時候我只記得一些關鍵字, 這樣對我比較方便>
也就是說, 大家都不區分你的使用者是誰, 都把它泛稱使用者, 也起來比較快速, 因為不用大腦. 可是這會讓你損失很多了解系統的機會. 因為不同角色的人, 會有不同的考量和需求, 並且也會有不同的優先順序, 混為一談, 只是讓你迷失在一大包功能列表中, 而無法掌握重點一刀斃命.
2. 不是從客戶角度出發
本來應該要從不同角色的角度出來, 來思考他想要的需求是什麼. 可是總是會有些是技術債, 或者是 product owner 自己想要的東西. 這些東西不是不能寫, 而是要寫的時候, 還是要站在客戶的角度, 想想客戶會希望你這個東西做成什麼樣子. 
例如, 有些 debug log 資訊不完整的技術債, 開發人員一開始可能會寫成
     身為開發人員, 我要能產生一些 debug logs, 這樣好讓我再出錯時可以方便除錯.
如果你若是能再進一步從使用這個機制的客戶來思考, 他可能要的會是像這樣
     身為開發人員, 我要能產生一些可以分層且方便下載的 debug logs, 這樣好讓我再出錯時可以方便除錯, 並且不用看太多訊息, 或是收集太大的 debug log.
因為有時候產生 debug log 不是問題, 問題是產生太多, 短短時間內就產生了幾 G 大小的檔案, 在某些環境下, 你要使用者如何把這玩意下載交付到你手上. 
所以你如果能異位思考, 同一個功能, 你做出來會更貼心.
3. 沒有商業價值
另外一個問題, 就是沒有撰寫商業價值的部分. 當我們沒有這部分的資訊, 我們就無法判斷他到底有多急, 或者是在該做到多少才足夠.
例如: 身為系統管理人員, 我需要產生日報表.
如果只是這樣就呆呆地去實踐日報表的功能, 通常出來的都不會是客戶要的. 你需要知道這報表出來是要給誰看的, 是要那它來做什麼, 大多時候我們都是一廂情願的給很多資料, 可是你有想過上百頁的報表他會看嗎? 或者是有時候客戶也不見得確定他想看什麼資料, 或是想交付什麼資料給老闆看, 這時候一份固定格式的報表, 對他來說效益不大.  
所以我們需要有商業價值的部分, 並且那只是起始點, 我們還需要根據這個起始點, 來和客戶好好溝通, 他們內心真的在想什麼.
 
4. 沒有驗收條件
寫過使用者故事的都知道, user story 只是很簡單的一兩句話, 他希望的就是你要去跟利害關係人討論, 要去了解他們著遇到什麼問題, 要這個功能的動機是什麼. 此外還有一件重要的事情, 就是要列出驗收條件, 也就是定出要做的功能的範圍, 如果沒有這個框框, 在大家認知不同的狀況下, 便會有不同的產出. 
例如: 
使用者故事
身為一個<使用者>, 我想要<可以根據關鍵字查詢書籍>, 因為<大多數時候我只記得一些關鍵字, 這樣對我比較方便>
是只針對書籍名稱找尋, 還是對作者或是書籍簡介也搜尋? 此外找出的書目, 是根據出版時間, 還是根據書籍名稱的字母順序排列?
雖然這些功能不見得難做, 可是一開始沒有做對, 等到事後才來修改, 不僅浪費工程師的時間, 也讓使用者覺得很不貼心. 為什麼不一開始就把驗收條件確認好呢?

上 CSPO 在練習撰寫使用者故事 (user story) 時, 被老師質疑一個很根本的問題: 你是在思考問題, 還是在思考解法?
 
 
當你是 product owner, 你需要撰寫使用者故事, 來描述系統所要提供的功能. 所以你可能會用以下方式來述說:
As a [Role], I want a [function] because [business value]
所以訂旅館的系統來說, 你可能會寫出:
身為一個背包客, 我需要[系統列出最便宜的房間], 因為我沒有太多錢.
我想大多數人會覺得這應該不錯的敘述, 把要做的事情, 以及背後的理由都寫了出來. 所以到時候, 你就是時做一個功能, 列出最便宜房間, 這樣他就可以下訂單.
你再想想這真的是好的方式? 尤其你是一位 product owner, 尤其你在 start up 公司時, 你認為這樣的產品客戶就想要買? 你的產品就會與眾不同嗎?
由上面的範例來說, 背包客考量的是沒有太多錢, 這是他擔心的. 而提供找最便宜的房間, 是其中一種解法. 如果你做出這個功能, 我想不太有人會覺得你的系統有多特別. 你想得到, 別人也想得到. 所以做出來系統會大賣嗎? 不會的機率其實很高!!
所以當你是 product owner, 應該多思考的要解決的是什麼問題, 而不是只在思考如何解決. 你在列使用者故事時, 不該光都列的是解法.
以上面的定義來說, 你可以改寫成:
身為一個背包客, 我需要[訂最便宜的房間], 因為我沒有太多錢.
這 2 個故事差別在哪裡呢? 這時候的差別在於, 你不一定是實作"列出最便宜房間清單"的功能, 你可能會思考是否有其他做法. 像是合住的可能, 或者其他提供折價服務的整合, 這樣才可能會有差異化出現.
為什麼我們要這樣思考呢? 在早期你還搞不清楚你要幹嘛時 你會列出正確的故事嗎?  或者即使那時候, 你很清楚要做什麼, 但是過了一段時候後, 那些肯定的東西是否還是正確的? 所以對於不清楚或是後期的項目, 我們應該以列要解的問題為主, 而不該以列要做的解法為主.
Agile 很重要的一個觀念叫做延遲決策. 這就是延遲決策, 我們只對很確定的東西, 或是很近的東西, 花時間處理. 但是對於叫後面的事情, 我們只需要概念性的東西. 
學習 agile 真的很傷腦筋, 我是否可以退回 command and control, 當個小白癡照做好了 (誤)

身為開發人員的我們, 在列 user story 時, 常常會做出功能拆解的事情, 而不是找出一個 end to end, 對使用者有意義, 可以單獨展示的功能. 
 

這次在 Agile Meetup 五分鐘分享會要分享的內容, Enjoy it
https://www.facebook.com/AgileCommunity.tw
http://www.slideshare.net/ssusere62027/user-story-mapping-14846349

User Story 的缺點
這周找了一些人, 來進行user story 的workshop. 人數剛好有兩組人馬, 剛好可以比較彼此做的結果.
這裡是我整理出大家討論的結果
1. 大小不一
有的user story很大, 有的user story很小. 排在一起時看起來很不搭. 太大的user story, 之後會很難進行評估, 也無法放在一個iteration內完成.
2. 很難找關聯性
有些user story 之間是處理相同性質的事情. 可是當user story 的數目大到某個程度時, 我們已經很難找出彼此之間的關聯性.
3. 不知道是否已經完整了
同樣當user story 的數目大到某個程度時, 你很難檢查是否該想到都有想到. 只知道數量很多, 但不知道哪裡有缺
4. 不容易排出重要性
同樣當user story 的數目大到某個程度時, 你很難對100-200個user story 排出整體的重要性. 排到最後時, 你已經迷失在便利貼當中
5. 不容易解釋給使用者聽
當你列的很細小的user story後, 會造成每個user story都是破碎的片段. 這時候你要講解給客戶或是prouct owner聽, 他們無法看到一個較大的全貌, 或者這小段事情和她痛苦的地方的關聯是甚麼

Gathering User Stories
摘錄至User Stories Applied: For Agile Software Development, 第四章
http://www.slideshare.net/ssusere62027/user-stories-applied-ch4

5 Common Mistakes We Make Writing User Stories
http://www.scrumalliance.org/articles/366--common-mistakes-we-make-writing-user-stories
 

常見的User story問題
有些時候很多user story, 它們會有共同的task, 例如架構設計, 撰寫測試程式.
有些人會將這些task變成user story. 理由可能如下:
(1) 他們認為這樣要交付的東西很明確, 例如要有設計的產出, 要有測試程式的產生.
(2) 並且不用頻繁更動user story. 這些可以一直擺在tas board上面, 只要內容不一樣就好, 這次是feature 1, 2, 3的設計, 下次是feature 4, 5, 6的設計.
這樣的作法, 一開始看起來很合理, 也很方便, 所以還看到不少團隊這樣使用.
可是大家卻很容易忘了一點, 那就是你想要交付怎樣的business value給顧客. 若是這些東西都沒有價值, 我們做得再快再好也是沒用的.
User story本身就是希望從顧客價值的角度, 讓我們隨時隨地思考customer到底要的是甚麼. 或許我們在一開始的時候不容易做到, 不容易知道真正customer想要甚麼. 但是比起從不把它列入考量的好.
另外一種user story是看不出想要交付甚麼. 例如IPv6, Active Directory, 或是MS SQL等等.
原意或許是要提供IPv6的支援, 和Active Directory的整合. 但是寫的這麼模糊, 不只customer看不出你要交付甚麼, manager也不確定你要產出甚麼, 以及跟你合作的夥伴要如何一起配合規劃.
最慘的是通常你會一直保留這個user story, 因為這個user story會很大, 你會要花好幾個iteration才能做完, 這會讓你很洩氣. 並且因為你無法在一個iteration完後去demo它, 所以你也無法及早確認, 是否目前做的是正確的.
所以千萬不要隨隨便便寫個user story 就貼上task board.

Use Case和User story的差別 - 範例篇
很多人常常會問use case和user story有甚麼差別, 之前在這兩篇中有些解釋
http://www.wretch.cc/blog/kojenchieh/13288119
http://www.wretch.cc/blog/kojenchieh/15451296