透過協作產生敏捷需求

Nov. 26 17:48~18:35

不是需求

許多跑敏捷的團隊會使用user story（用戶故事、使用者故事）來表達「需求」，大家一般認為寫user story是Product Owner的責任，團隊只要照著user story所描述的內容就可以做出PO所希望的功能。

但實際上功能做好之後卻經常被PO要求改東改西，導致開發團隊抱怨：「Product Owner寫的user story太簡略，害他們不能『按圖施工，保證成功』，要不斷地重工」。PO則是不滿開發團隊都不動腦筋，遇到問題也不及時跟他溝通與釐清。

其實user story不算是傳統軟體開發所說的需求或規格，user story只是引發團隊討論需求的一句話。真正的需求，透過開發團隊、Product Owner與利害關係人的對話、討論、探索而產生。討論之後所產生的需求，可以透過specification by example（實例化規格）的方式記錄下來。

另外，撰寫user story的責任也不能全部推給PO。User story的「為了…（目的）」所描述的是使用者所遭遇的問題，這是PO需要負責搞清楚的部分。而「我想要…（做什麼）」這句話已經包含某種解決方案，則是需要PO與開發團隊一起討論，尋求各種可能的做法。

***

心態改變

上週Teddy在上【Scrum敏捷方法實作班】介紹user story的時候跟學員提到上述觀念，下課時有一位學員說…

以前團隊在product backlog refinement workshop的時候，我們都習慣要求PO要把user story寫清楚，如果有不清楚的地方，我們會責怪PO，覺得他沒有準備好就找我們來開會。但上完課之後，我才發現原來撰寫user story的責任不能完全推給PO一個人。下次再開refinement workshop，我會改變作法，多提供意見。

***

協作遊戲

敏捷開發是一種協同合作的活動，不是傳統瀑布式開發那種「透過文件溝通」的模式，更不是找個issue tracking system（議題追蹤系統）來「開票、領票」（分派、追蹤工作）。

只是做做敏捷的樣子，心態沒變，還是白搭。

***

友藏內心獨白：讓團隊每個人都動腦真的不容易。