如何開發好的用戶故事:具有獨立性


本文是我在閱讀網上一些英文文章后的心得,以及收錄了在這些文章中讀到的很棒的一些知識/最佳實踐,結合我日常項目管理的經驗,一方面給我自己留下資料,一方面與大家共勉。

 

在InforQ上看到一篇文章,標題問的是,如果因為某種情況(在實際開發中,往往都是因為某個重要的User Story無法在當前sprint內完成) 而出現了延長迭代的需要的時候,究竟是延長當前的迭代,還是怎樣。

 

我個人是不贊同延長迭代的。大致上,如果因為某種狀況的出現,無法完成sprint backlog中全部的待辦事項的話,可以有以下的處理辦法:

1. 取消當前迭代,重新計划並發起新的迭代。在新的迭代中,針對前一次迭代出現問題的地方,可以

  a)將產生問題的高優先級任務放到新的迭代的開始去重點解決;

  b)擱置並排除產生問題的中低優先級任務,直到獲得更詳細的任務說明、制定符合Invest原則的用戶故事或優先級上升到高優先級為止。

2. 將產生問題的任務從當前sprint backlog中排除,將其余的可交付項交付給客戶。

 

推遲交付/演示是不可取的,這會給客戶一個糟糕的印象,即開發團隊無法控制流程,團隊的承諾是不可信的。因此,延長迭代是很糟糕的一個選擇。

 

鑒於很多時候,往往是在一個迭代即將結束的時候才發現出現了問題,這個時候取消當前迭代會打擊團隊士氣,同時額外的、非計划中的回顧和計划會議也會使得客戶變得不耐煩起來,所以我更傾向於第二種處理辦法,即把出現問題的User Story從當前 sprint backlog中排除,將其余的可交付項ship給客戶。如果User Story滿足INVEST原則,即Independent獨立的,Negotiable可商討的,Valuable有價值的,Estimatable可估算的,Small小的,Testable可測試的,那么即便把問題User Story排除掉,也不會對可交付項的數量以及ROI產生太大的影響(事實上如果User Story滿足了Small和Negotiable的原則,很難想象它會出現問題並阻礙整個迭代)。

 

本篇討論的是User Story的獨立性。具有獨立性的User Story在被排除於sprint backlog的時候,不會對其它backlog item產生影響。那么,什么樣的User Story是具有獨立性的呢?免去空談 ,我們直接看一個例子。

 

在一個最基本的用戶登錄的User Story中,User Story Card的正面如下(摘自Example of User Story):

 

卡片的背面則是Test Case:

 

這個User Story總的來講是很規范的,但是注意卡片正面的wireframe中的“Forgot password?”部分 ,這一部分指向的是另外的一個功能頁面,而該功能並不包含在User Login這個用戶故事中,因此,這個User Story的完成與否是依賴於Forgot password story的完成情況的。在糟糕的情景下,Forgot password功能沒有完成,那么即便User login部分其它的全部功能都已經完成,這個story也不能被視為完成並交付給客戶。

 

如果在User login story中,沒有forgot password部分,而是將這一部分放在單獨的user story中進行描述,那么事情就完全不同了。如果forgot password story沒有完成,客戶仍然可以獲得user login story的交付項,在下一個迭代中forgot password完成后將與user login集成。客戶看到的是新功能源源不斷地按時交付(當然不排除個別情況下部分功能會被取消並安排在下一個迭代中交付),這對於客戶滿意度而言是再好不過的正面影響了。

 

在開發user story的過程中時刻用INVEST標准做衡量 ,可以幫助我們開發出高質量的user story,並最終達到保證按時完成迭代、交付功能的目的。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com