以下是一個問題。 開發人員有一些任務（開發某些功能），這需要大約一個衝刺的長度。因此，在衝刺結束之後，開發人員因爲他們剛剛完成他們的部分而感到高興。Scrum方法中Sprint結束時未測試的產品
但是。該產品不是QAd，因此它不能被區分爲「潛在可交付」，因爲它很可能會包含一些錯誤。
所以，問題是：如果沒有自動化測試，只有人類QA工程師，計劃我們的衝刺的最佳方式是什麼？要有一個延遲衝刺（QA測試在先前衝刺中開發的項目）？
什麼可以幫助我們在這種情況下？在質量保證程序中開發人員應該做什麼？
Scrum的一個非常重要的方面是在Sprint期間讓事情「完成」，並完成定義。如果某個功能在衝刺期間完成，但未經過測試，則仍未完成。
你應該怎麼做不是這樣做是爲了增加Sprint的長度。短衝刺仍然主要是首選。我建議兩件事。
第一個非常重要，但不一定容易實現。將QA整合到您的團隊中。有一個單獨的質量保證部門，在你完成後驗證你的產品真的是瀑布。在您的產品發貨之前，您可能仍然希望進行質量檢查驗證，但衝刺中產生的內容應在衝刺期間完成並進行測試。爲此，您需要合格的質量保證人員加入您的團隊，否則您需要儘可能地培訓開發人員進行質量檢查。在我的公司，我們的QA部門太小，所以我們無法爲我們的團隊獲得一些。相反，我們瞭解了質量保證並在標題爲「準備驗證」的任務板中添加了一列。每當某個功能完成時，它就會轉移到「準備好驗證」的狀態，其他開發人員會對此進行審查。儘管我們可能沒有像專業QA那樣熟練，但是我們始終都會發現問題，將他們移回來進行修復，然後重新進行驗證。這個過程給了我們更多的信心，我們在sprint中被歸類爲已完成的功能，以及後來發現的bug的大幅下降。
其他的事情是開始定義更小的任務，或者更好地將功能分解成更小的部分。你不希望工作的功能可能會影響整個Sprint。如果你的「幾乎完成」你在衝刺期間還沒有完成任何事情。代替;將特徵分解成更小的部分並逐一解決。當有人在第二部分工作時，第一部分正由其他團隊成員之一進行驗證，從而使整個開發過程和QA更加集成 - 在衝刺結束時更好地將新功能稱爲「已完成」。
祝你好運！
我同意延長：外部質量檢查以驗證我的聲音仍然很好;只要該產品是'潛在可交付的'。因此，如果在sprint中完成驗證（單元測試，集成測試），它可能仍然可以。事實上，增加衝刺的長度應該是最後一項措施之一，而不是第一項措施。結對編程，測試驅動開發也是縮短交貨時間的方法。 – Adriaan 2009-09-29 12:27:17
您可能需要更改衝刺的長度，並將完成定義爲轉入QA或準備進行生產。
這很難做到，但這也意味着要確定你有任務在板上進行測試。
此外，這將意味着縮小規模，所以在中點檢查時要誠實，並刪除不會完成的任務，以實現完成的定義。
或者，這是不太理想的，基本上有兩個衝刺/功能。第一個應該是通過單元測試來實現它，第二個是通過質量保證。所以，第二次衝刺可能會更短，但是，如果你打算這麼做，那就把它們組合成一個更長的衝刺。
您的任務太大。您需要有較小的任務（最多幾天），爲客戶帶來價值（以便他們可以進行測試）。任務完成後，從開發的角度來看，QA可以開始驗證它。
也許您還需要爲Sprint計劃更少的計劃，以便在Sprint結束時增量得到驗證。
團隊過渡到敏捷使QA驗證上一次迭代中開發的內容並不罕見。但他們必須趕上。
開發人員在質量保證過程中應做些什麼？
Scrum與測試人員驗證時開發人員代碼沒有任何關係，測試人員在開發人員啓動代碼時正在測試。當完成計劃任務的開發時，他們可以編寫文檔，修復QA報告的問題，支持質量保證，估計下一個Sprint的任務...
+1。除非您不能將用戶故事切分爲仍然可測試的小塊，並提供某種真正的業務價值，否則將故事縮小爲**是正確的解決方案。增加衝刺長度是IMO的錯誤答案。無論如何，只要記住一個故事不應該超過你的速度的一半 - 你在一次衝刺中可以完成的工作量 - 或者你的衝刺將會非常危險。 – 2009-09-09 22:20:13
我們對Sprint期間的各個功能進行了質量檢查，發達。在Sprint結束時，我們確保我們的主要源代碼分支是最新的，然後開發人員繼續開發分支。這使QA能夠釋放測試，並且不會對它們進行計時。任何bug修復都可以輕鬆應用到主分支，而無需在Dev分支中「撤消」任何新的東西。
你的大問題可能是缺乏自動化/單元測試。這減少了你的QA員工必須做的工作量，因此，他們更有可能更快地完成他們的工作。
我也不認爲增加你的衝刺的長度將有所幫助。這將迫使您添加更多開發人員任務，或者在QA趕上時讓開發人員坐在他們的手中。
不幸的是，你只是沒有做Scrum。你在衝刺中做瀑布;又名scrum-fall。
1）將QA整合到團隊中。他們不應該是一個單獨的組，您可以「傳遞」代碼。他們應該每天與開發者合作來測試他們的工作。
2）讓你的故事遠遠更小。一個故事應該需要1-2天的時間才能完成（一個星期是絕對最大值，只有偶爾的時候，除非你在製作火箭）。您需要團隊努力改善垂直切片功能，以創建小型可測試，可用，增值的故事。
3）Scrum沒有職稱。如果一個開發者完成了所有的編碼工作，那麼他/她將測試其他人的代碼。或者，您可以創建自動腳本，並說您錯過了。
4）它可以在主要發佈之前進行「強化」衝刺，但是在開發的同一衝刺期間肯定要進行測試。每次檢入代碼時，測試都會完成。
5）修復「完成」的定義。完成意味着代碼是根據需要編寫，測試，部署和記錄的。
6）你需要做很多關於「團隊」和承諾的工作。你的評論認爲，只要編碼完成，開發人員都是「高興的」，這與scrum及其校長是完全相反的。
根據您的意見，我認爲如果您認真對待敏捷，團隊需要投資於培訓。
按照開發和測試（沒有錯誤或任何其他驗收標準）進行定義。將測試人員集成到您的團隊中。由於sprint正在規劃功能，將其劃分爲小任務並測試其中一項任務（或甚至多項測試任務）。因此，您將具有功能A，包括數據庫更改，UI更改，應用程序更改，測試 - 所有任務合計爲一項功能。另外儘早聘請測試人員，不要等到開發結束。當測試人員仍在測試時，開發人員已經完成了他們的任務（開發和測試之間總是會有一段時間的差距），因此開發人員可以使用其他功能。 「在質量保證程序中開發人員應該做什麼？」
將QA視爲瓶頸，將TESTED定義爲完成沒有意義。這一切都在我們手中。 Scrum的好處在於你可以按你想要的方式操縱國防部。實際上，它的確幫助了我們很多。現在我們定義一個範圍，並放置一個DOD。並且可以在此衝刺中，接下來或者甚至由另一個團隊進行QA。所以，即使你我們沒有「潛在的可發貨產品」，我們擁有獨立的軟件））） – 0100110010101 2009-10-24 14:51:40
如果它對你有用，那就太好了。敏捷也在於適應形勢，而不是以一種真正的方式做事。 Scrum可以通過各種方式實現，我只是給出了我的看法，它是如何完成的。然而，我有一個問題與你的方法 - 而不是消除瓶頸，你只是把它推到房間的核心，你覺得它不會阻礙你的方式。但它仍然存在。我的提議只是不同的解決方案，一個是解決問題的方案。那麼，至少它對我的團隊有效（不僅對DOD進行了重新定義，而且還提到了我所提到的每一步）。 – yoosiba 2009-10-26 17:59:31
「 - 爲下一次衝刺編寫單元測試？ – EBGreen 2009-09-01 18:41:50
它是用於TDD的。 Scrum並不總是TDD – 0100110010101 2009-09-01 19:22:22
這就是爲什麼這是一個評論，而不是一個認真的答案。 :) – EBGreen 2009-09-01 19:28:02