需要一些關於制定衝刺隊伍速度的建議。衝刺速度計算
我們的團隊通常由大約4名開發人員和2名測試人員組成。 Scrum大師堅持每個團隊成員都應該對速度計算作出同樣的貢獻，也就是說，在計算我們在衝刺中能做多少時，我們不應該區分開發者和測試者。根據Scrum的說法是正確的，但這是問題所在。
儘管有相反的建議，但測試人員從不幫助開發非測試任務，開發人員也從不幫助開發非開發任務，所以我們根本不是跨功能團隊成員。此外，儘管有各種建議，測試人員通常會在每個衝刺的前幾天等待測試。
最終的結果是，我們通常會承擔比我們在衝刺中的實際能力更多的開發工作。例如，開發人員可能會爲速度計算貢獻20天，測試人員可能貢獻10天。如果在sprint計劃之後添加任務，則dev任務最多可以添加25天，而測試任務最多可以添加5天。
你們怎麼處理這種情況呢？
FogBugz使用EBS（Evidence Based Scheduling）根據現有的性能數據和估算值創建了何時發運給定項目的概率曲線。
我想你可以做同樣的事情這一點，只是你需要爲測試輸入：「瀏覽互聯網等待開發商（1周）」
的聲音，我喜歡你的系統是否正常工作，只是不如你想要的。這是一個付費項目嗎？如果是這樣，你可以使薪酬成爲精英分子。根據他們完成多少工作來付款。這會鼓勵交叉紀律工作。儘管它也可能鼓勵人們從事不屬於他們的內容或內部破壞。
很明顯，你必須尋找人們試圖遊戲系統，但它可能會工作。測試人員肯定不想賺取開發人員所做的一半。
由於敏捷開發是關於透明度和問責性，聽起來像測試人員應該已經分配任務來說明他們的速度。即使這意味着他們有上網等待測試的任務（儘管我認爲他們會更好地爲開發團隊的任務制定測試計劃）。這將顯示您的組織中效率低下並不流行，但這正是Agile所關心的。其中不好的部分是你的測試人員可能因爲某個組織問題而受到處罰。
我工作的公司有兩個不同的（dev和qa）團隊，有兩個不同的迭代週期。 qa週期抵消了一週。這個不幸導致了接受任務時的複雜性，因爲一個產品直到qa迭代結束時才準備好發佈。這不是一個適當整合的團隊，但你的聲音也不是。不幸的是，qa團隊從來沒有真正遵循過scrum的實踐（沒有真正的計劃，站起來或回顧），所以我不能確定這是否是一個好的解決方案。
我們也在處理這個問題。
這就是我們所做的。當我們將能力和任務加起來時，我們將它們分別加在一起。這樣我們知道我們沒有超過每個組的總時間。 （我知道這並不是真正的混亂，但我們有質量保證人員不會編程，所以爲了最大限度地利用我們的資源，他們最終會進行測試，我們（開發人員）最終會放棄。）
第二種認爲我們做的是我們真的專注於切片。我們嘗試選擇首先完成的任務，以便快速轉到質量檢查人員。訣竅在於，您必須專注於獲得最少的可測試數量，並將其轉移給測試人員。如果你試圖獲得一個完整的「功能」，那麼你就錯過了這一點。當他們等待我們時，他們通常會制定測試計劃。
對於我們來說，這仍然是一項正在進行的工作，但我們正是這樣做的。
這可能是稍微偏離你問什麼，但這裏有雲：
我真的不喜歡使用速度爲多少工作在未來衝刺/迭代做的措施。對我來說速度更像是投影的工具。
團隊負責人/項目經理/ scrum master可以查看最近幾次迭代的平均速度，並有一個相當好的趨勢線來投影項目結束。
團隊應該按照承諾作爲團隊來構建迭代。繼續挑選故事，直到迭代完成團隊承諾完成的大量工作。這是你作爲一個團隊的責任，要確保你不會因爲挑選少數人而懶惰，也不願意挑選很多人。當團隊承諾迭代時，不同的技能水平和專業會自行解決。
在這種模式下，一切均衡。團隊有一個合理的工作量來完成，項目經理有承諾完成。
使測試人員配對程序爲被動對等體。如果他們沒有什麼可以測試的東西，至少他們可以留意現場的錯誤。當他們有一些東西要測試時，在本週的第二部分，他們轉向功能/「用戶故事合規性」測試級別。通過這種方式，您可以使兩組都具有生產力，並且基本上測試人員在繼續進行代碼梳理時會「梳理」它們。
速度的第一個答案，比我個人對scrum非跨職能團隊和每個衝刺初期的測試人員的洞察力。
我看到那裏不一致。如果團隊不能跨職能，你可以區分測試人員和開發人員。在這種情況下，您必須在速度計算中區分它們。如果團隊不是跨職能的，測試人員不會真正提高你的速度。您的速度將是開發人員可以實現的最大速度，但不超過測試人員可以測試的內容（如果所有內容都必須測試）。
與您的scrum master交談，否則總是會出現速度和估計問題。
現在作爲測試者和衝刺初期。我作爲測試人員與5個開發人員不交叉功能團隊，所以這個答案可能有點個人化。 您可以通過兩種方式解決此問題：a）通過添加單獨的測試衝刺來更改工作組織或b）更改測試人員的工作方式。
在a）你創建單獨的測試衝刺。它可以平行於開發者的衝刺（剛剛移動那幾天），或者你可以每兩到三次開發衝刺就發生一次。 我聽說過這個解決方案，但我從來沒有這樣工作過。
b）您必須要求測試人員檢查他們的測試活動方法。也許這取決於你使用的實踐和工具，或者你遵循的過程，但是在早期他們怎麼能做到無關呢？正如我之前提到的那樣，我與5名開發人員一起擔任測試人員，而非跨職能團隊。如果我等待開發人員結束自己的工作，我將永遠不會測試給定sprint中的所有功能。除非您的測試人員僅執行探索性測試，否則在功能發佈到測試環境之前，他們應該做些事情。在測試人員將特徵/代碼放入他的手中之前，有一些活動可以完成（或必須完成）。下面是我做的功能被釋放到測試環境之前：
- 經歷要求的功能被實現
- 設計測試腳本（高層設計）
- 準備草案測試用例
- 經歷可能的測試數據（如果正在執行的更改是操縱系統中的數據，則需要對此數據進行快照，稍後將其與此數據的特定功能進行比較）
- 將測試套件中的所有內容合併起來
- 通信開發人員作爲功能正在開發 - 通過這種方式，您可以更好地理解已實施的解決方案（而不是詢問他何時已將自己的思想放在其他f eature）
- 你可以作出必要的變更作爲特徵的發展
然後測試情況下，當功能完成後，您： - 充實測試用例與早不知道你的任何細節（這是小事，但按鈕名稱可以更改，或者出現嚮導中的一些額外步驟）
- 執行測試
- 上升問題
。 事實上，我發現我的自己比第一部分花費更多的時間（設計測試，並在適當的工具中準備測試腳本）而不是實際執行這些測試。
如果他們所有，他們可以馬上而不是等待代碼被髮布給測試環境應該幫助這個初始間隙，它會減少的衝刺結束前測試沒有完成他們的活動的風險。
當然總是會有更少的測試人員在年底開始和更多做，但你可以儘量減少這種差異。即使上述情況仍然讓他們在開始時浪費大量時間，您可以不給予任何與編碼有關的任務。一些配置，一些維護，文檔更新，其他。
的解決方案是從來沒有黑色和白色作爲每個衝刺可能包含需要測試的和其他人不的故事。例如，在分配測試人員的敏捷中沒有問題;在衝刺中有50％的時間，在下一次衝刺中有20％。 嘗試將測試者100％的時間分配給衝刺並嘗試證明它是合理的。時間管理是關鍵。
測試人員和開發估計故事點數在一起。衝刺的速度總是一個綜合的努力。質量保證/測試人員不能進行單獨的速度計算。這是根本錯誤的。 如果您有3個開發人員和2個測試人員，並且您包含測試人員的能力並將其與您的輸出相關聯，那麼生產力總是會很低。測試人員參與測試案例設計，缺陷管理和測試，這不直接歸因於開發。您可以對這些測試任務進行跟蹤，但無法分配速度點。
好了，什麼測試人員的一週的第一部分嗎？填字遊戲？ :) – 2009-08-14 01:36:05
如果上一次衝刺沒有結轉，我們讓他們設置測試計劃。 – Vaccano 2009-08-20 04:36:27