SPIDR 完美分割使用者故事的五種簡單技巧

2021-09-12 18:12:15 字數 1089 閱讀 2864

根據invest原則,對使用者故事的要求是它必須「足夠小」或具有合適的大小。使用者故事應該足夠小,可以在衝刺中完成6-10個。當然這也取決於開發團隊的速度。為了原則上實現這一目標,必須相應地分割大型故事。在下文中,我想向您介紹mike cohn的簡單快速的spidr方法。他總結了五種技術,幾乎每個大型使用者故事都可以分為幾種。

spike是敏捷軟體開發中使用的術語。尖峰是功能的小型原型實現,通常用於新技術的評估和可行性。

該方法涉及調查和建立知識。如果其他spidr方法效果不佳,則應該使用它。借助這些新獲得的知識,可以更好地理解一些故事,並可能更容易地**。然而,該方法相對抽象,因此比其餘方法更難應用。

在該上下文中的介面可以是例如不同的裝置或裝置型別,例如由ios或android供電的智慧型**。使用者故事也可以根據這種多樣性進行劃分。讓我們堅持使用不同作業系統的示例:例如,在專案中,可能存在僅與android裝置的使用相關的使用者故事,或者專注於web瀏覽器的其他使用者故事。為了避免使故事過於龐大和全面,您應該問自己要開發哪些裝置或介面。也許第乙個開發結果應該只引用ios裝置,因為可能更大的目標組。

當初始故事僅涉及相關資料的子範圍時,可以使用另一種用於分割使用者故事的技術。以乙個旨在吸引遊客到特定城市的**為例。例如,如果它是以博物館而聞名的城市,那麼第乙個故事可能包括該地區不同博物館的資訊。隨後的故事可能包括穿越城市的各種旅遊,以及另一項戶外活動。

有了這個故事,可以想象開發團隊省略了這個限制,允許每個訪客購買盡可能多的門票。然後可以在第二次迭代步驟中新增限制。像這樣的增量交付意味著初始故事不會立即完全實現,而是以幾個較小的步驟提供。有時忽略技術規範或業務規則是有意義的,如果通過這樣做,您可以更快地實現滿足使用者或客戶的可呈現結果。可以在以後檢索省略的故事。

使用者故事**並不總是那麼容易:許多初學者傾向於將他們的故事過於全面而且過於龐大。但是,當涉及到開發團隊的改進,並最終實現故事時,很快就會發現必須製作更小的故事。在我之前關於寫(好)使用者故事的博文中,我堅持認為故事應該是「可估計的」和「小的」。如果您知道如何分割大型故事,則更有可能發生這種情況。正如編寫使用者故事一樣,練習也是完美的。

敏捷軟體開發

SPIDR 完美分割使用者故事的五種簡單技巧

根據invest原則,對使用者故事的要求是它必須 足夠小 或具有合適的大小。使用者故事應該足夠小,可以在衝刺中完成6 10個。當然這也取決於開發團隊的速度。為了原則上實現這一目標,必須相應地分割大型故事。在下文中,我想向您介紹mike cohn的簡單快速的spidr方法。他總結了五種技術,幾乎每個大...

Xml Xsl 內容與形式的完美分離

在製作網頁的時候,我們希望它能夠互動性好 快速響應和易於維護。xml xsl可以更好的解決這個問題。xml是內容,負責內容的生成 從後台資料庫讀取資料生成xml檔案儲存到伺服器相應目錄,或者在使用者瀏覽時動態讀取資料,生成xml格式的字串。xsl是形式,負責內容的展示,由技術人員定義模板的資料,由美...

接受「不完美」 分布式事務學習總結

作為乙個前端專業的人來說,對於事務的理解,一直停留在 要麼都成功,要麼都不成功 的小白階段。既然自己將2018年定義為 深入理解 的一年,那麼就從深入理解事務開始吧。正如文章開頭所說的 事務是一系列的動作,這些動作必須全部完成,如果有乙個失敗,那麼事務就會回滾到最開始的狀態,彷彿什麼都沒發生過一樣。...