在Scrum項目中，測試和同行評審是否應作爲單個任務加入到每個衝刺中？

Question

這似乎是我工作的一個爭論點。有些人抱怨Scrum項目中缺少驗證結構，而Scrum純粹主義者則認爲這不是Scrum的內容。雙方都提出了很多要點，但我希望看到圈外的人對這個問題的看法。你怎麼看？爲什麼？

Answer 1

在一個Scrum項目中，任何需要完成的任務都應作爲一個任務輸入。

Scrum的關鍵之處在於能夠準確預測團隊在衝刺中可以完成的工作。爲了做到這一點，你必須考慮將消耗開發人員時間的一切。

這意味着文檔，測試和同行評審等內容都必須作爲任務考慮在內。

編輯：基於Mendelt的文章，我將澄清一些事情。

從Wikipedia：

產品Backlog：產品積壓是整個項目的高級文件。它包含了對所有必需功能，願望清單項目等的廣泛描述。它是將要構建的「什麼」。它由任何人開放和編輯。它包含粗略估計，通常以天爲單位。此估算有助於產品負責人衡量時間表，並在一定程度上優先考慮（例如，如果「添加拼寫檢查」功能估計爲3天與3個月，這可能會影響產品負責人的願望）。

Sprint積壓：衝刺積壓是一個非常詳細的文檔，其中包含有關團隊如何實施即將到來的衝刺的要求的信息。任務分解成幾小時，任務不超過16小時。如果任務超過16小時，應該進一步細分。 sprint backlog中的任務永遠不會被分配，相反，團隊成員會根據需要註冊任務。在產品Backlog不會顯示之類的東西文檔或測試

項目，但對代辦衝刺肯定應該的任務。

我舉個例子。假設產品待辦事項列表中有一個「功能A」，其預計時間爲1周。在Sprint Backlog中，這可能被分解成以下任務：

 
Initial design document:    4 hours 
Development of subset 1 of Feature A: 8 hours 
Peer review of subset 1 of Feature A: 2 hours 
Testing of subset 1 of Feature A:  6 hours 
Development of subset 2 of Feature A: 8 hours 
Peer review of subset 2 of Feature A: 2 hours 
Testing of subset 2 of Feature A:  6 hours 
User Documentation for Feature A:  4 hours 
--------------------------------------------- 
Total time       40 hours 

編輯＃2： Sprint Backlog中背後的想法是要具體力所能及的究竟，你必須花時間。這就是爲什麼任務長度不能超過16小時，而且這就是爲什麼你的日程表預測非常可靠。

如果按照宗教Sprint Backlog中的指導方針，並確保包括一切你花費的開發時間，那麼你將在你的計劃如何準確是實踐的幾個衝刺後驚喜。

Answer 2

它應該，因爲如果你沒有明確地輸入它們作爲任務，那麼它們可能不會完成。就如此容易。

Answer 3

認爲是垂直而不是水平層。

如果考慮設計，編程和單元測試，測試等爲層在發展蛋糕，我想你可以看到的功能（故事）您提交年糕片，每組由一個一小塊設計，代碼，測試，性能等等。這就像Pragmatic Programmer的「追蹤子彈」一樣。

Answer 4

在進行scrum之前，我們遵循了瀑布開發範例，其中包括在向版本控制提交任何內容之前的代碼審查。自從轉向Scrum以來，我們不會爲代碼審查分配單獨的任務，因爲它隱含在任何開發案例中。

Answer 5

Scrum內置的關鍵驗證結構之一是產品負責人接受故事。該團隊僅在提供業務價值的基礎上獲得速度信用。

Scrum團隊的一個常用工具是定義產品積壓項目的驗收測試（通常這些積壓項目以用戶故事的形式出現）。

作爲Scrum團隊的一員，您需要回答團隊將用什麼工程實踐來幫助提供高質量產品的問題。 Scrum本身在這些實踐中保持沉默（我認爲故意允許這些實踐隨着時間的推移而演化，因爲我們學習如何更好地完成任務）。

這些實踐可能是單元測試，結對編程，同行評審等等。通常這些都成爲團隊定義其要完成的事情的一部分。如果一個團隊正在努力完成估算或者完成任務 - 將其作爲sprint backlog中的任務進行調用會很有幫助。我的建議是保持流程輕量級 - 您不需要召集每一件小事（但您需要考慮在估計中執行常規項目所需的時間）。