Ruddy Lee 分享空間

Emergent Design 演化設計

使用者會加入你的開發團隊嗎?

leave a comment »

在微軟Techdays 2012之後,持續收到學員的問題。這是其中最頻繁被提出來的問題:

使用者會加入你的開發團隊嗎?」

如果團隊中沒有使用者加入,你會擔心沒有足夠的user story來作需求描述嗎?

沒有User story怎麼辦 — 那就,自行搜集User story。

在敏捷開發的領域裡,使用者的需求總是要靠user story來作描述。萬一遇到客戶不會或不願意開出較詳細的user story時,也就是當沒有user story時怎麼辦呢?答案是:去搜集啊!軟體的目的是要為各行各業解決問題。 使用者往往不是programmer岀身,即使是資訊中心的人員,對不同專業領域的需求,依然很難將需求表達得夠清楚,因此工程師想要依靠它來break down 成為可以工作的task就更難了。沒有了足夠的user story來說明需求,需求一旦不夠明確則工程師作錯方向的機會自然變大,專案浪費的資源自然變多,專案就更難成功了。這也正是說明了scrum的多個會議裡,以sprint的planning meeting是最重要的原因之一。

該如何進行user story 的搜集呢?不如來開個「user story 工作坊」

這是Mike chon 想出來的點子。集合大家(使用者、scrum master、開發人員)的力量一起來作腦力激盪,共同思考該有哪些個user story。藉此寫出一大堆使用者故事,然後在一起由這些個功能共同來描繪出產品的模型,過濾岀產品的初步雛形。用這個方式來彌補使用者無法在一開始提供足夠 user story 的問題。(要是始終沒有使用者願意參加呢,如何是好?那就找一個最適合的人來扮演這個角色。在new startup 新創公司的時候,為了開發新產品,往往在還沒有找到真正的客戶群之前,虛擬一個角色來進行摹擬的動作常常是必要的方法)。

User story 太重要了
但或許是"故事"這二個字太通俗,常常叫人忽略了它的重要性,也忘了「講故事的人」是應該先受過訓練的。話說;雖是攸關生死的需求,但可能只是yes/no的簡單描述。例如:看著出生的嬰兒,他不會說話,如何表達他的需求呢?只有依靠哭跟不哭來表達他的需求,但隨著時間及前後的關係,母親還是能明確的抓出,這個是哭肚子餓、還是尿布溼了…。但user story大致上都是抽象的描述。為什麼要抽象呢?是為了彈性跟稍後的回饋所作的保留。少了這一層抽象,工程師breakdown 時的疑慮少了,解題的範疇也跟著縮水了,方向變得更明確了,但走錯路線的機率也相對的提升了不少。所以,今天如果你已經很清楚該作的事了,這時後還不如直接畫流程就開幹了來得有效率。

故事就是要當作工程師跟客戶之間溝通的基準,工程人員必須依靠客戶來回答自己種種的疑慮,近而完成自己對問題外觀雕塑然後才能夠去breakdown ,挖掘出該有的種種架構。沒有了問答,少了較深入的溝通,問題的抽象性便始終存在,就很難去設定工作的方向了。
一定要呼籲那些開班在教授scrum的講師們,務必把user story教好,它包括: 思考如何把需求寫成故事,如何把故事拿到台面上進行討論、breakdown ,如何讓故事成為工程師跟客戶之間共同認知的需求,以及如何驗證它,讓它轉化成為測試案例(test case ), 並成為驗收的依據,如此便大工告成了。

Written by ruddyllee

2012 年 10 月 21 日 於 13:06:44

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: