ここに問題があります。 開発者は、ある種のタスク（特定の機能を開発する）を持っています。これはスプリントの長さになります。だから、スプリントの終わりには、開発者は彼らの一部を完成させてから幸せです。スクラム方法論のスプリントの終わりにテストされていない製品
しかし、この製品はQAdではないため、バグを含む可能性が最も高いので、「潜在的に出荷可能」とは区別できません。
したがって、問題は、人間のQAエンジニアだけがオートメーションテストがない場合、私たちのスプリントを計画する最良の方法は何ですか？ 1つのスプリントを遅らせる（QAは前のスプリントで開発されたアイテムをテストします）？
このような状況で私たちを助けることができるものは何ですか？開発者はQAの手順で何をすべきですか？
スクラムの非常に重要な側面は、スプリント中に「完了」し、完了の定義です。フィーチャーがスプリント中に終了したが、まだテストされていない場合は、まだ完了していない。
あなたがするべきことあなたのスプリントの長さを増やすことです。ショートスプリントは依然として大部分が好むだろう。私は2つのことをお勧めします。
最初のものは本当に重要ですが、必ずしも達成するのは簡単ではありません。 QAをチームに統合する。あなたが「完了」した後であなたの製品を検証する別のQA部門を持つことは、本当に滝です。製品が出荷される前にQA検証が必要な場合がありますが、スプリントで生産されたものは、スプリント中に完成してテストする必要があります。そのためには、資格のあるQA担当者があなたのチームの一員であることが必要です。あるいは、QAを可能な限り最善に行うように開発者を訓練する必要があります。私の会社では、QA部門が小さすぎるので、私たちのチームには手を差し伸べることができませんでした。代わりに、QAについて学習し、タスクボードに「確認の準備ができました」という見出しを付けて列を追加しました。機能が終了するたびに、それは「検証の準備ができました」に移動し、他の開発者がこれを見ていました。私たちは専用のQAの人ほど熟練していないかもしれませんが、私たちは常にこのように問題を発見し、修正のために戻してからもう一度検証に移りました。このプロセスにより、私たちはスプリント中に分類された機能にはるかに自信を持ち、後で発見されたバグは劇的に減少しました。
小さなタスクの定義を開始するか、機能を小さな部分に分割することでより良い仕事をすることです。エジプトに合わせてスプリント全体を占める可能性のある機能に取り掛かることは望ましくありません。あなたの "ほぼ完了した"場合、あなたは本当にスプリント中に何も完了していません。代わりに;フィーチャーを小さな部品に分割し、フィーチャーを1つずつ解決します。誰かがpart2に取り組んでいる間、part1は他のチームメンバーの一人によって検証されているため、開発とQAのプロセス全体がより統合され、スプリントの終わりに新機能を「完了」する機会が増えます。
幸運を祈る！
私は拡張に同意します。製品が「潜在的に出荷可能」である限り。したがって、検証（単体テスト、統合テスト）がスプリント内で実行されても、それでも問題はないかもしれません。実際、スプリントの長さを長くすることは、最初の手段ではなく最後の手段の1つでなければなりません。ペアプログラミング、テスト駆動開発は、リードタイムを短縮する方法です。 QAをボトルネックとする – Adriaan
あなたのスプリントの長さを変更し、QAに行った、またはプロダクションの準備ができていると定義する必要があります。
これはやりにくいですが、それはテストのためにボードにタスクがあることを確認することも意味します。
また、これは縮退を意味するので、mid-pointチェック中に正直で、完了しないタスクを削除して、doneの定義を達成します。
またはこれはあまり理想的ではありませんが、基本的に2つのスプリント/フィーチャーがあります。最初は単体テストで動作させるべきであり、2つ目はQAでテストすることです。だから、2回目のスプリントは短いかもしれませんが、もしそれをやるつもりなら、それをより長いスプリントに組み合わせるだけです。
あなたのタスクが大きすぎます。顧客に価値をもたらし（テストできるように）、より小さな仕事（最大数日）を持つ必要があります。タスクが完了すると、開発の観点から、QAはタスクの検証を開始できます。
おそらく、スプリントの計画を立てて、スプリントの最後にインクリメントが有効になるようにする必要があります。
チームがアジャイルに移行しても、以前の反復で開発されたものがQAで検証されることは珍しくありません。しかし、彼らは追いつく必要があります。
QA手順の際に開発者は何をすべきですか？
テスターが検証している間に開発者コードがあり、開発者がコードをクランキングしている間にテスターがテストしています。計画されたタスクの開発が完了すると、ドキュメントを作成し、QAによって報告された問題を修正し、QAをサポートし、次のスプリントのタスクを見積もることができます...
+1。ユーザーのストーリーをまだテスト可能な小さなチャンクにスライスして実際のビジネス価値を提供できない限り、ストーリーを小さくすることは**正しいソリューションです**。スプリントの長さを増やすことは間違った答えです。いずれにしても、ストーリーは速度の1/2（1回のスプリントで行うことができる仕事の量）を超えてはならない、またはスプリントが非常に危険な状態にあることを覚えておいてください。 –
私たちは、発展した。そのスプリントの終わりに、メインのソースコードブランチが最新であることを確認してから、開発者がDevブランチを使い続けるようにします。これにより、リリーステストを行うためにQAが解放され、タイムテストは行われません。すべてのバグフィックスは、Devブランチの新しいものを元に戻す必要なく、メインブランチに簡単に適用できます。
大きな問題は、自動化/単体テストの不足の可能性があります。これはあなたのQAの人がしなければならない作業の量を削減し、したがって、仕事をより早く完了する可能性を高めます。
私はあなたのスプリントの長さを長くすることが助けになるとも考えていません。これは、あなたが開発者のタスクを追加するか、QAが追いついている間に開発者が自分の手に座るように強制します。
残念ながら、あなたはただスクラムをやっていません。あなたはスプリントで滝をしています。別名スクラムフォール。
1）QAをチームに統合します。コードを渡す別のグループであってはなりません。彼らは彼らの仕事をテストするためにdevsと毎日一緒に作業する必要があります。
2）あなたの話をはるかに小さく、はるかに小さくします。ストーリーは完了するまでに1〜2日かかります（1週間は絶対最大であり、ロケットを構築していない限り時折しかありません）。テスト可能で有用な付加価値のある小さな物語を作成するためには、機能を垂直にスライスすることでより良いチームを得るためにチームが必要です。
3）スクラムには役職がありません。開発者がすべてのコーディングをやり終えたら、他人のコードをテストします。または、欠けていると言う自動スクリプトを作成するために働きます。
4）メジャーリリースの直前に「ハードニング」スプリントを持つことはOKですが、確かにテストは開発と同じスプリント中に行われなければなりません。コードがチェックインされるたびに、テストが完了します。
5） "done"の定義を修正してください。完了とは、コードが必要に応じて作成、テスト、デプロイ、および文書化されることを意味します。
6） "チーム"とコミットメントに関する多くの作業が必要です。あなたのコーディングが行われている限り、開発者があなたのコメントは「幸せ」であるというあなたのコメントは、スクラムとそのプリンシパルとは全く反対です。
あなたの意見に基づいて、チームが機敏になることを真剣に考えているなら、チームはトレーニングに投資する必要があると思います。
定義済みの開発済みおよびテスト済み（バグも受け入れ基準もありません）。チームにテスターを統合する。機能がスプリントのために計画されているので、小さなタスクに分割し、それらのタスクの1つ（または複数のテストタスク）をテストします。したがって、DB変更、UI変更、アプリケーション変更、テスト - 1つの機能まで追加するすべてのタスクで構成される機能Aが表示されます。さらにテスターとできるだけ早く関わり、開発が終わるまで待たないでください。テスターがまだテスト中で、開発者がタスクを完了すると（開発とテストの間には時間差があります）、開発者は他の機能に取り組むようになります。
の場合、「定義済み」としてテストを行う意味がありません。それはすべて私たちの手の中にあります。スクラムの良さは、あなたが望むようにDODを操作できるということです。実際に、それは私たちの多くを助けました。今はスコープを定義し、DODを配置します。このスプリント、次の試合、あるいは別のチームによってQAedされる可能性があります。だから、たとえあなたが "潜在的に出荷可能な"製品を持っていなくても、私たちは独立したソフトウェアを持っています））） – 0100110010101
機敏であることは状況に適応することでもあり、事実を真の方法で行うことではありません。スクラムはさまざまな方法で実装することができます。しかし、あなたのアプローチには1つの問題があります。ボトルネックを解消する代わりに、あなたの道を妨げないと感じている部屋のコアラに押し込むだけです。しかしそれはまだそこにある。私の命題はただの解決であり、問題を攻撃するものでした。まあ、それは私のチームのために働いた（DODの再定義だけでなく、私が言及したすべてのステップ）。 – yoosiba
"QAの手順で開発者は何をすべきですか？" - 次のスプリントのユニットテストを書く？ – EBGreen
TDD用ですスクラムは必ずしもTDDではありません – 0100110010101
これが深刻な答えではなくコメントである理由です。 :) – EBGreen