「重構」產品待辦事項項目是否應計入速度？

Question

假設需要重構（太大而不能作爲現有用戶故事的一部分） - 是否可以在產品待辦事項列表上重構「故事」？

重構的目的不是改變系統的行爲 - 因此根據定義，沒有給客戶直接的業務價值。

- 那麼重構'故事'有故事點，然後計算速度或這是不知何故作弊？

上下文： 我們在最簡單的結構中完成了一些存儲數據的初始故事。這些數據的結構不適用於即將到來的用戶故事，並且需要採用不同的方法，爲了適應這種新方法，需要更改現有數據結構的所有現有功能。

Answer 1

在我看來，在您的產品待辦事項列表中有這樣的項目是絕對沒問題的，因爲我總是將PB作爲軟件完成所需的一切。

我以前在產品待辦事項列表中經常有功能，bug修復，重構和研究任務。如果你沒有把它放在積壓之中，那麼這項任務將如何完成呢？您還需要爲任務定義「完成」，這有助於描述重構的目標（使代碼更快，代碼更具可測試性等）。

Answer 2

我看到這個問題靠不同的團隊以幾種方式接近。

1）將技術債務項目（如重構）作爲故事添加到產品待辦事項中，用戶類型爲「開發者」，業務價值表示爲直接成本或ROI。

這具有使每個人（包括客戶）都能看到技術債務項目（及其業務價值/存在理由）的優勢。它還使包括必要技術工作的速度得到考慮和可見。

但是，它們可能太過技術性，不適合每個人都理解，並可能浪費時間來解釋和談判這些項目。對於每個人來說，商業價值可能並不明顯或可以解釋，特別是那些注重功能的人。

2）爲技術債務問題預留一次'特殊'衝刺。

這些都是跟技術積壓完全分開的產品積壓。這消除了團隊爲他們制定案例的必要，推動技術債務項目被添加到基於業務價值的積壓中，或者迫使這些問題進入用戶故事形式。

缺點：社區中有些人反對任何一種特殊的迭代。它還要求客戶（以及所有人）接受'黑暗'迭代的生產力衝擊，其中沒有明顯的進展（和速度）。

3）將技術債務所需的時間捲入故事。

這允許團隊只承諾那些可以完成而不會招致技術債務的項目。因此故事點和速度將包括重構等內容。

我看到的一個很大的缺點是，它意味着故事應該在沒有技術債務的情況下完成......這似乎違反了只做足夠完成項目的原則。

Answer 3

這個問題有點過時，但主題本身不是這樣，我會冒險回答。

我認爲：不，重構是一個單獨的活動，在計算速度時不會考慮在內，因爲它不會帶來商業價值，也不會提供可用的增量。

這個數據的結構是不是要爲即將到來的用戶故事工作，需要不同的方法

那麼我會分別定義和估算的「即將到來的用戶故事」。