Sprint工作項目 - 敏捷Scrum

哪些類型的任務可以作爲Sprint Backlog中的工作項目加入和跟蹤？Sprint工作項目 - 敏捷Scrum

能分析，審查和單元測試（的用戶故事）被列入或只能核心編碼任務，包括在Sprint Backlog中跟蹤？

基本上我打破用戶故事到技術任務更新Sprint Backlog中，並想知道是否有非編碼的角色任務可以被更新，並在衝刺積壓跟蹤。

來源

2010-10-22 jcs

我可能會建議：http://area51.stackexchange.com/proposals/9543/development-methodologies – gbjbaanb 2010-10-22 16:02:30

+1同情你打算從成員那裏用這種方式來表達你的問題，特別是最後一句段落:) – sjt 2010-10-22 20:16:36

@gbjbaanb你可能會建議，但在SO上提出這個問題沒有任何問題。 – 2010-10-23 18:27:12

什麼任務可以作爲Sprint Backlog中的工作項目進行包含和跟蹤？

按照Scrum指南 - >在計劃會議第2部分，團隊確定任務。這些任務是將產品待辦列表轉換爲工作軟件所需的詳細工作。任務應該已經分解，以便在不到一天的時間內完成任務。這個任務列表被稱爲Sprint Backlog。因此，無論符合上述指南的任何任務都需要包括在內。

是否可以包含分析，審查和單元測試（用戶故事）或者只能在Sprint積壓庫中包含和追蹤核心編碼任務？

是的，他們可以也應該包括在內，如果這樣做會導致將Backlog轉換爲工作軟件。 Scrum從不建議在Sprint Backlog中只包含編碼任務。實際上Scrum要求團隊是跨職能的。

基本上我打破用戶故事到技術任務更新Sprint Backlog中，並想知道是否有非編碼的角色任務可以被更新，並在衝刺積壓跟蹤。

這聽起來對我來說很可疑。只是「你」分解任務嗎？應該是整個團隊在計劃會議的第二部分分解任務。 Sprint中也可以包含非編碼任務。只是給你一個現實的例子：在我的Web開發團隊中，一個典型的Backlog有以下任務。 1.定義和Discover 2.設計和創建測試矩陣 3.寫單元測試來測試矩陣 3.代碼進行單元測試通過 4.測試 5.迴歸測試 6.調試 7.去了「工作軟件與PO（如果需要的話，以確保這是PO想要什麼）

編輯

還有一點有關任務。在計劃過程中添加的任務應該在必要時不斷分解/更新/重命名。整個過程就是添加一組透明的事物來完成，這些事情完成後，最終會導致工作軟件遵循質量保證標準，最有效和最有效。這些任務應該在功能上交叉使用並且不應該在團隊成員中被阻止。

希望這會有所幫助！

來源

2010-10-22 16:05:32 sjt

你有這些任務，你想跟蹤作爲工作項目。小心這樣做。

爲什麼？你開始具體化一個過程。這裏有一個滑坡。只要你開始具體化這個過程，你就會停止實際上敏捷並開始創建一個強制性連續步驟的不靈活的瀑布。

如果你認爲這些東西太重要了，你必須寫下來或者開發人員會忘記它們，那麼你就不會讓開發人員承擔敏捷的責任，或者有權做出自己的決定。

你正在把他們視爲不可信。

分析用戶故事。無論如何，他們會這樣做。爲什麼把它寫下來？他們會忘記嗎？關鍵是瞭解。沒有文件。不是時間管理。
代碼審查。你希望他們這樣做。你必須創造這種文化，結果是獎勵。

如果代碼審查的結果是「你的代碼太爛了，再做一次」，那麼沒有人蔘與，它不只是菲亞特做得到。

如果代碼審查的結果是「給大家一個新的最佳實踐借鑑」加「也許你應該重新考慮這個根據其他最佳實踐」，也許人們會參加。
單元測試是sprint中的一部分，沒有任何問題或討論。
事實上，它可能是 - 衝刺的重要組成部分。在幾乎任何其他代碼之前，單元測試都是第一次。你不需要說這個。事實上，它說它聲稱你的開發人員不能被信任測試。

當你覺得急於爲程序員寫下任務時，你還必須考慮問題的原因。

爲什麼你必須寫下來？他們不是在幹什麼？

這裏是重要的部分。

他們爲什麼不首先這樣做？

他們沒有分析嗎？爲什麼不？你難以分析嗎？用戶是否無法使用？

他們沒有做代碼評論嗎？爲什麼不？什麼是代碼評論的路障？不夠時間？沒有足夠的合作？沒有足夠的獎勵？什麼阻止他們？

他們沒有進行單元測試嗎？爲什麼不？什麼是測試的路障？不夠時間？靈活性不夠？首先沒有足夠的積極反饋來進行測試？

爲什麼你覺得需要「控制」和「強迫」你的開發者？爲什麼他們自己不這樣做？

來源

2010-10-22 12:23:38

感謝您的回覆。我的意思是需求分析，代碼審查和單元測試代碼。是的，他們不是敏捷方面的交付成果，但對於確保我認爲的代碼質量至關重要，我們將不得不爲此付出努力。 – jcs 2010-10-22 13:28:37

@jcs：請**更新**您的問題，使其完全清楚。 – 2010-10-22 14:10:10

+1我愛你如何將一切都視爲一個問題，很好的回顧材料 – DancesWithBamboo 2010-10-22 19:22:03

簡短的回答是 - 無論哪一個最適合您的團隊和用戶故事。例如，如果我們正在將一段代碼作爲用戶故事的一部分進行重構，那麼我們可能會分出一個單獨的任務來處理首先處於測試狀態的問題。但是，如果它是新開發者，我們推斷它將被測試（並且通常用TDD完成）作爲我們的過程的一部分。

其他例子包括有時會分開一個單獨的任務來涵蓋花費在協調與編碼上的時間，與外部供應商的集成測試等 - 基本上，任何有助於彌補特定故事的謹慎和可測量的任務（包括上面包含的示例）。

底線是，沒有一個每個故事應該具備的設定公式，而是根據每個故事的個別需求（即使這些任務不是與代碼相關的）調整任務。

來源

2010-10-22 12:26:12

謝謝。感謝您的迴應。 – jcs 2010-10-22 13:30:31

如果您在每個用戶故事中爲分析，編碼，檢查，測試等創建任務，您將接近所謂的Scrumfall（每次迭代劃分爲瀑布階段）。這是Scrum的氣味之一。基本上這樣的活動應該包含在單一任務中：「做某事」意味着完成「某事」所需的一切=您是專業開發人員，並且您知道（或者由政策說）完成任務需要做什麼。

這是一般情況。有時你確實需要把任務分成「活動」，但首先你應該從普通過程開始，並且只有在你有真正的理由時才使用這個工具 - 例如一次迭代中的尖峯任務和第二次迭代中的實際任務。

編輯：我用任務分爲一次活動。我們沒有做TDD，但測試是在完成任務後編寫的。所以每個開發任務都與測試任務配對，以表明它可以由另一個開發人員完成，有時與開發並行。但是另一位開發人員測試的責任是團隊決策和他們真正做到的複雜任務。

來源

2010-10-22 15:57:59

我只同意你暗示每個Backlog都不應該遵循任務的模板形式。但有時積壓可能實際上需要分析，編碼和測試，並且沒有任何缺陷。我的理由是什麼？在瀑布中 - 整個組織結構是不同的 - 分析團隊，編碼團隊，qa團隊都是傻乎乎的。在scrum中，團隊是跨職能團隊的，理想的情況是每個人都在從積壓到開始的每個階段都參與其中。 – sjt 2010-10-22 18:35:51

僅當其他團隊成員在團隊中阻止任務時纔可以將其稱爲Scrum氣味，並且不會對每個人都保持透明。我可以給出實現與瀑布不同的實例。它當然不能稱爲Scrumfall或迷你瀑布。 – sjt 2010-10-22 18:36:43

@sjt：我沒有寫他正在做Scrumfall，我寫到他越來越近了。但是非常好的一點，因爲問題沒有提及每項任務是否可以由任何成員或特定成員完成。我的答案僅僅是關於敏捷原則之一：賦予人力。創建高層次的任務，並將選擇活動的責任交給將完成任務的人。 – 2010-10-23 08:12:34

如果您將所有應用於任務跟蹤的努力都集中在較小的範圍內（1-3分），那麼您將致力於變得更加靈活。小故事幾乎不需要任務級別的估計或跟蹤。您的PO受益於能夠優先考慮更小的功能集，並且您專注於提供價值，而不是反覆記錄明顯的步驟。當然，按照每個小時的小時數跟蹤一個團隊達成一致的標準做法並沒有什麼用處。

來源

2010-10-22 19:20:18 DancesWithBamboo

Sprint工作項目 - 敏捷Scrum

回答

相關問題