目前分類:scrum教學 (5)

瀏覽方式: 標題列表 簡短摘要

User Story的細節呢?

很多人會說這樣的一句話,怎麼足夠表現出需求詳細的內容呢?很多細節我們還是不知道。那到底要怎麼辦呢?

其實User Story的重點是在於溝通。也就是希望程式設計師和顧客好好坐下來,一起談論想要的功能是什麼,想要拿它來解決什麼問題。也就是真正去了解整個來龍去脈,而並不是花時間去把文件寫的盡善盡美。所以這句話只是開頭,接下來的交談才是重點。

當然User Story並不是這麼不負責任,讓我們來看可以怎麼做。

User Story通常是寫在小卡片或是便利貼上面,因此在正面寫完User Story的描述後,在背面我們可以再增加一些資訊來說明的更清楚。

那要增加什麼資訊呢?User Story的作法是把客戶會滿意的條件加進去,也就是考量哪些事情是顧客所顧慮的,把它們都一一列到卡片的後面。這不但可以讓你知道這需求更詳細的內容,也知道哪些是它們要的優先順序,最後還可以把它們視為驗收測試的標準。但是不要忘記這些都是溝通後所得到的結果。

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

使用者故事(User Stories)

前面談完Product Backlog,可是我們並沒有說明要如何撰寫Product Backlog。在Agile中我們通常是以一個叫User Story的東西,來描述Product Backlog的內容。

這也就是說,你是可以以別種方式來描述Product Backlog的內容,例如use case或是傳統的需求規格書。Agile並沒有做限制。

可是你會什麼問那我們為什麼要用User Story?為什麼要多學一個新的東西呢?那什麼又是User Story呢?接下來就讓我一一道來。

什麼是使用者故事
在wiki中的定義大致如下:

kojenchieh 發表在 痞客邦 PIXNET 留言(1) 人氣()

Product Backlog所面臨的問題


1. Product Backlog的來源有很多個
一般來說,資料的來源有以下幾類:
(1) 產品功能:在這一次版本中需要實作的功能。

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Product Backlog
在專案一開始時,需要有一份要處理的工作項目。在傳統專案中,我們會使用需求規格書,或是者是使用個案。可是在Scrum的軟體開發中,我們使用的是Product backlog這個東西。你會問說這又是什麼新的名詞呢?讓我們來看看大家怎麼定義它:

A. Wiki上的定義
- 對於整個專案來說,它是一個較高層次(high-level)的文件。
- 包含了所有想要功能的描述,或者是wish-list等等。
- 是根據商業價值來排定優先順序

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

功能, 時程, 和成本

在專案管理中, 功能, 時程, 和成本, 一直是最重要的三個要素, 也是不容易取得平衡的三個要素. 因此你可以看到你的專案經理, 常常痛苦掙扎要如何在三者間取捨, 到底要犧牲那幾個, 保留哪幾個.

傳統的一種作法(waterfall)是將要交付的功能固定, 然後在成本和時程間做調整. 主要是以計劃導向(plan-driven), 來導出時程和成本的規劃.

不過這種作法, 往往犧牲的是成本. 因為通常時程無法做大幅變動, 因此只好在成本上考量. 這時候你會做的一件事情, 就是犧牲品質這項成本. 少點測試, 沒有檢視, 或是一寫完就交付.

可是這樣的東西會真的是你要的嗎? 這樣不好的循環, 真的無法打破嗎?

在agile中, 它試著改變這樣的假設, 認為交付功能是可以變動的. 因為功能這種東西不見是越多越好, 適用最重要.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

找更多相關文章與討論

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼