根據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年定義為 深入理解 的一年，那麼就從深入理解事務開始吧。正如文章開頭所說的 事務是一系列的動作，這些動作必須全部完成，如果有乙個失敗，那麼事務就會回滾到最開始的狀態，彷彿什麼都沒發生過一樣。...