如何處理scrum中未完成的用戶故事？

你聽過柏林新建機場的故事嗎？機場原定2006年開工，2007年啓用，但因爲機場建設過程當中處處出現施工和安全問題，補東牆漏西牆，致使工期一拖再拖，預算一漲再漲，以致於2019年了還沒開張，預計開業時間已經被拖到了2020年10月。

不管是建機場仍是開發軟件，人們每每會低估未完成的工做量。即使沒有低估，也會盡量以能安撫老闆客戶的方式回覆，例如「我已經完成95%了」畢竟，這種粉飾太平的回答總好過「這個複雜的任務，我大概只完成了一半」、「是的，我低估了完成這項任務所需的工做量」、「老實說，我也不知道還會不會有其餘不可預見的問題出現」這些回覆。

雖然這種「即將完工狀態」聽起來很好，但它會影響整個項目狀態的透明度。這也是爲何在敏捷開發—如scrum過程當中，咱們只會關注完全完成的功能。完成與否只能二選一。在scrum演示會中，咱們會查看每一個用戶故事，根據全部的驗收標準和團隊制定的DoD（完成的定義）進行審查。只有在全部工做完成、全部的非功能性需求（NFR）和其餘部分的DoD知足的狀況下，用戶故事才能被認定爲完成並結束開發。

在敏捷軟件開發中，功能的狀態是非此即彼的，即要麼完成，要麼未完成——不存在任何中間狀態。

以工做流節點、業務規則或數據變化等做爲依據來拆解用戶故事，並將拆解後的用戶故事放到每一個sprint中完成，但被定義的範圍和質量必需要完全完工。所以不要由於用戶故事A已經快要完工，就讓團隊轉而開始其餘任務，與此同時在backlog中添加一個新的「完成用戶故事A的收尾工做」的故事。

這就意味着咱們須要知道如何處理未完成的功能。我參與過的不少團隊都對此進行過很激烈的討論。若是你只強調故事點，開發團隊可能以爲遭遇了不公平待遇，由於他們已經完成了「95%的工做」（詳見上文），但並無獲得應有的承認和確定。尤爲是在管理層對scrum和故事點的概念理解有誤差，僅僅經過scrum團隊的開發速度來評價團隊表現的狀況下，針對這一問題的討論則會愈演愈烈。

因此，到底應該怎麼處理scrum中未完成的用戶故事呢？

首先，我認爲：不要太在乎這個問題。由於團隊沒能完成用戶故事的狀況只是個例，不會常常發生。所以，不管採起什麼樣的解決方案，都不該該對團隊的任何指標產生重大影響。但若是團隊常常出現此類問題，那麼你實際上應該解決的是爲什麼團隊常常不能完工這一問題，而不是試圖經過接受團隊產出的半成品來妥協。

總之，不要過度在乎這種特殊的狀況！

其次，我認爲：未完成的用戶故事不該該在演示會議上展現。它們應該被移到Product Backlog的頂部從新評估規劃，而不是自動進入下個sprint的backlog。所以，沒有故事點會爲未完成的用戶故事標記「完成」。在下一次規劃會議前，PO（在與開發人員溝通後）決定是否須要花更多的時間在這個未完成的用戶故事上。若是答案是「須要」，那麼在下一次的規劃會議上，這個用戶故事就會被移到Sprint Backlog中，且保持原始估算值。即使開發人員自稱功能已經完成了90%，咱們也能根據全部的故事點預估當前sprint的開發速度。正如前面所說，未完成的用戶故事應該是個例，所以從長遠來看，團隊的速率應該維持在平穩水平。

 

做者：Felix Braun

翻譯/校對：Worktile

文章來源：Worktile敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。