透過協作產生敏捷需求

原文转载自 「搞笑談軟工」 (http://teddy-chen-tw.blogspot.com/2019/11/blog-post.html)

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)

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(議題追蹤系統)來「開票、領票」(分派、追蹤工作)。

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

***

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

more_vert