上周我參加了C.C Agile的活動
我覺得那次活動內容不錯，只是很可惜的是時間掌控得不是很好
導致講主題的時候，也沒講很多(我對主題怎麼實現還不是太了解>"<)
那次活動提到了user story的撰寫，這讓我發現我之前對user story的理解有問題
我之前對user story沒甚麼感覺，感覺只是一個形式上的格式
覺得那不過就是身為甚麼角色，我想要甚麼
很抽象、很模糊，可能還是需要use case來描述細節
如果有好好寫過系統分析文件與規格的話，你可能會發現到一件事情
要寫好SPEC，花的時間非常可能比工程師實作花的時間更多
如果訪談對象很搞不清自己要甚麼或無法描述清楚的時候，很可能SPEC一直大翻
而且依照公司分工情況，搞不好還得去想對於系統與結構上的影響(沒有SD時)
我是認為即使如此，有把系統分析做好也是有價值的，
因為如果SPEC描述的內容夠確實，準確度夠高
能夠減少實作上的白工，進而避免開發的士氣低落
(試想一下，如果你做的東西很可能隨隨便便就被翻掉白費，你還會想做好嗎？)
而且也能夠避免對系統架構的影響，進而提升程式品質
但對於不理解的人，仍然會覺得很怪，「不過就寫個系統文件，花的時間是開發的好幾倍，花那麼多時間做啥？直接開發不就好了嗎?」
他們可能會無法理解與認同寫SPEC比開發時間多很多這種事情
User Story算是另一種描述需求的做法，我當初去上課時，學的就只是要寫下身為甚麼角色與想要甚麼而已
這很抽象，讓我一直在想這樣描述會不會變成需求不明確
參加完活動之後，比較好的寫法有兩種，拿想徵求有英文能力的系統分析師來舉例好了
1.身為主管，我想要一個具有能夠進行英文對話與書信往來的系統分析師，這樣就能讓他跟外國人進行需求訪談與合作
2.為了跟外國人進行需求訪談與合作，身為主管，我想要一個具有能夠進行英文對話與書信往來的系統分析師
第1種寫法增加了目的，讓人更明白為什麼要這麼作與朝這個目的前進
如果不寫，可能會讓人想說，該不會是為了要看技術文件寫程式吧？
又或者讓人想說，這是一種壓薪水的手段嗎
還是這可能只是公司就是想要而已，沒有任何理由
第2種寫法雖然只是把目的寫在前面，卻帶來了另一種意義
就是整個實現是著重於實現目的而非方法
以這例子來說，這會變成也能改成說：「為了跟外國人進行需求訪談與合作，身為主管，我想要一個具有能夠進行英文對話與書信往來的翻譯人員」
搞不好找翻譯人員更好
每個功能的實現與開發通常都是為了某種目的
Use Case是使用者的操作過程就是這樣，做就對了
User Story是給開發者們去實現目的，要使用者採取甚麼樣的操作還有調整空間
如果是一般專案，尤其是政府專案，我想user story很可能不適合(要看使用時機點)
如果是產品研發，那user story會很適合
因為user story是採取價值驅動，價值會比規格更加重要
我覺得user story的用法如果是一般開發方法的話，SA在跟提需求的人確認需求時會比較好用(估時程前)
這可以有利於SA進行規劃與設計
但如果要當規格開給PG的話，變質的可能性很高
因為一般開發時，專案的時程與PG的時程都是定下來的
你要PG思考怎麼實現目的，又要掌控開發時間，其實並不合理，結果一定是能簡單好實現就往好實現的方式實作
這就偏離了使用user story該有的目的
但如果使用scrum的話，因為scrum本身就是一種不太受限於時程的開發做法，甚至連估時程都是不實作的人都不能干涉的，至於有多少管理者能夠接受不掌控時程這件事情，那就另一回事了。
雖然無法理解user story map怎麼使用有些遺憾，但我覺得理解user story與價值驅動對我幫助還是蠻大的
題外話:
那天因為講者想拿拼湊的事情做舉例說明，所以問有沒有人看過科學怪人
我本來想說我有看過科學怪人-驅魔大戰
不過還好沒說，不然講者應該接不下去吧XD
留言列表
