3
Scrum和敏捷表示，當前sprint積壓的項目應按優先級順序進行處理，並且整個團隊一次處理一個項目。團隊如何處理當前的衝刺積壓物品？
實際上，這似乎從來沒有爲我們的團隊工作。對於所有團隊成員來說，這些項目都太小（包括考慮配對）。所以我們最終可能在同一時間在整個團隊中做兩三件。
我很想聽聽其他團隊是如何做到這一點的，以及他們通常會在給定的衝刺中承諾多少件物品。在目前的衝刺積壓
A
回答
1
整個團隊接近每個項目的建議是爲了避免在衝刺內創建迷你瀑布，其中項目從一個專門組傳遞到另一個專門組。這導致測試人員在短跑的第一天無所事事，然後在最後幾天編程人員擺弄他們的大拇指時加班。團隊應該把整個問題作爲一個整體來處理，即使在各自的「專業化」之外，每個人都會參與其中。是的，編程人員可以測試，測試人員可以編寫代碼，兩者都可以設計架構等 - 並在過程中學習新的東西（令人驚歎）。這並不是說每個人都應該很擅長所有事情 - 只是說像「我不測試，我是編碼員」或「我不會寫這個腳本，我是測試人員」這樣的態度在Scrum團隊中沒有地位。
建議在衝刺內逐個處理項目，以確保最終實際上有東西被傳遞。限制進行中的工作（WIP）可以防止每個人都在每個項目上執行一些任務但沒有任何項目在衝刺結束時完成的情況。
但是，這不應該被視爲建議，而不是一個非常嚴格的規則。例如，當你有兩個小故事和一個10人團隊時，讓所有團隊都集中在一個故事上可能沒有意義。
底線是：沒有人應該告訴團隊如何在他們自己之間劃分工作，但應該期望他們在Sprint計劃中交付他們的承諾。
3
項目應按照優先順序在時間整個團隊上前，和一個項目。
我不知道這是誰說的，我至少不記得聽過或讀過類似強調文字的東西了。當然，這也取決於您的商品是的故事還是單個任務。
如果它是一個故事（通常由多個任務組成），可能有實現這個目標的機會。然而，正如你所說，有時候這個故事並沒有包含足夠的任務來保持每個人的忙碌。通常與故事有關的任務強烈地依賴於彼此，例如，可能會有一個設計會議（涉及部分或全部團隊），然後是一個或多個編碼任務，然後是代碼審查，功能測試，文檔編制等。顯然，在編碼之前不能進行功能測試等等。
由於每個人都必須做某些事情，所以在任何給定時間至少有多少任務會與團隊成員（或對）一起打開。考慮到有時任務由於各種原因（任務間依賴性，外部方需要的信息等）而被擱置，通常甚至更多。
在一個由4名開發人員組成的團隊的一個Scrum項目中，我們遇到了非常相似的情況。我們的確努力按照優先順序儘可能地講故事，並且通常我們有多個故事和幾個任務隨時開放。一開始我們在衝刺結束時經常遇到幾個半完成故事的問題。所以我們意識到將開放任務/故事的數量保持在最低限度是很重要的，也就是說，在開始新任務/故事之前，總是試圖完成開放任務/故事。但實際上，這個最小值從來沒有達到1.
至於每個sprint的故事數量，我們只是根據我們的（故事，然後是任務級別）估算，儘可能多地放入適合的數量。這當然很大程度上受到我們的速度的影響，這在一開始估計過高。幾個月後，我們將其降至60％，而這一價值似乎對我們有用。
+1
同意，我不記得曾經聽說過。 – Cowan 2010-07-02 11:50:03
1
我認爲這取決於你的團隊的構成。如果你有一個團隊，任何人都可以在用戶故事中接受任何給定的任務，那麼這很有效。如果你不這樣做，那麼有些人可能會有空閒時間。
根據優先級來處理用戶故事的要點很簡單...您將獲得首先完成的最高優先級的用戶故事。這從實際設定優先級的客戶角度增加了最大的價值。
至於在衝刺期間需要承諾多少用戶故事，取決於以下幾個因素： 團隊可用性，團隊速度和衝刺持續時間。所以，我不確定你會知道在衝刺期間有多少人遇到了多少故事。
0
Noel，您的團隊是否受過在Scrum團隊中工作的培訓？我的意思是你在開始這個項目之前把它們發送給了Scrum課程嗎？
我見過這麼多的團隊因爲錯誤地理解了博客上的書而寫錯了Scrum。
另外有一個經驗豐富的Scrum Practitioner或Scrum Coach會幫助你很多。
具體回答你的問題，看看這個漂亮的免費的電子書，是不同比別人：
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
我投票的，因爲它不是關於編程關閉這一問題作爲題外話。 – 2017-11-02 08:12:16