我已經在我的項目上申請了agile幾個月。然而，我們看到我們的迭代焚燒問題存在一個穩定的問題。每次迭代都不會達到零。如何在敏捷項目中打破開發與質量保證之間的障礙？
剩餘的任務是QA任務。諸如寫作測試，測試等。
現在，組織對「跨職能團隊」敏捷理念存在一些組織抵制。 Dev爲單個項目開發，但測試人員爲多個項目共享。這與Dev和QA共同合作的敏捷理念完全相反。
事實上，我的測試人員的時間分散在很多其他項目中，這是我們減速的原因。開發人員正在測試儘可能多的鬆懈，但一些任務仍未完成。
從我所看到的，我可以做兩件事情：
我寧願避免做＃2，因爲我重視我們正在進行的測試協作。
你對我的困境有何建議？
這是一個艱難的情況，不幸的是，很多試圖關注敏捷的公司都不認識它。 您不必擁有專門的QA人員 - 即使敏捷資源可以在不同的任務之間分配。您需要將您的質量檢查包含在您的進度跟蹤中。
是的，你的進度會變慢。這是一個很好的理由（你沒有足夠的質量保證資源），你應該用手中的數字向組織管理層解釋。它會幫助你說服一些變化必須發生。
此外，您還可以進行更多自動化測試，並使用開發人員幫助測試人員進行測試自動化。這將更均勻地分配負載，並將提高項目質量保證的質量
我不認爲你可以調用你正在做的敏捷，除非每個人都參與其中。讓測試人員靠近開發人員（至少在測試人員爲他們的項目執行任務時（例如創建測試計劃），這可能會導致溝通並讓QA購買。
他位於同一地點（2立方下），並正在與我們合作制定測試計劃。這是偉大的，而且是我在談論的合作。但是，當橡膠遇到道路時，測試不會被寫入/執行。 – 2008-09-18 16:45:25
您可以將QA視爲Devs的客戶。所以當Devs在迭代結束時發佈到QA時，迭代就完成了。
來自客戶的反饋（需要修復的錯誤）可以用於下一次迭代的工作。
爲了實現這個目標，您必須獲得質量保證，爲項目投入足夠的時間。您可能需要與他們的管理人員合作，以便獲得一定的時間讓他們爲您的項目工作。通過這種方式，您可以安排時間，並確切知道開發人員可以做多少工作，以便QA團隊有時間進行測試。這可能要求您縮小開發範圍，以補償質量保證減少的支持。
你沒有提到你的測試有多少是自動化的。您可以增加測試自動化，以減少QA團隊驗證項目所需的時間。您可以使用部分開發時間爲QA團隊準備質量檢查測試以運行。不是最佳的，但它可以幫助。
在短期內，停止使用不適合您的流程的QA資源，並根據需要將這些任務用於專用任務。我意識到這並不理想，但是存在一個次優情況，即您的組織結構與您的流程不匹配。你可能會發現它會工作得很好（並且學習過程中的測試）。
從長遠來看，你的選擇是
我認爲QA在敏捷環境中提供的內容要遠遠多於測試工作。如果QA對工作流程及其不同部門有足夠的瞭解，可以通過司機座位來驅動其餘的scrum流程。 QA可以與開發人員合作設計邏輯工作流程，最終驅動測試用例。通過這種方式，可以在開發過程中消除大量與設計和工作流相關的錯誤，然後進入QA環境。
您是否嘗試過賄賂+威脅？有時舊的方式是最好的... – Shog9 2008-09-19 00:59:08
這可能與其他顧問，但可能不是我的客戶;） – 2008-09-19 01:58:55
至少爭取你的項目有專門的測試人員。隨着時間的推移，這將成爲知道系統的人。誰知道在哪裏看。哪些部分一起交互。其他系統的某個部分會發生什麼樣的後果。無論如何，通過敏捷的短迭代，我將專注於項目作爲跟上的唯一途徑。從測試人員的角度說。 – yoosiba 2009-11-03 19:39:56