スクラムでQAがどのように機能するかを理解してください
どうやらスクラム開発方法論を使用しているようです。一般的な方法は次のとおりです。
開発者は自分のタスクを達成しようと駆け巡ります。一般的に、タスクはスプリントのほとんどを完了します。 QAは開発者にテストできるものをリリースするようにせがむと、Devは最終的にスプリントが終了する1〜2日前にバグのあるコードをQAに投げ出し、残りの時間をQAが発見したバグの修正に費やします。 QAは時間どおりにタスクを完了できず、スプリントが時間通りにリリースされることはめったになく、DevとQAはスプリントの終わりに悲惨な数日間を過ごします。
リリース可能な開発タスクがスプリントの大部分を占める場合、スクラムはどのように機能するはずですか？
議論に参加してくれてありがとう。これは非常に自由回答形式の質問なので、「答え」が1つあるとは思えません。以下に多くの良い提案があります。私はいくつかの「持ち帰り」のポイントを要約し、いくつかの明確化を試みます。
（ところで-これはこれを置くのに最適な場所ですか、それとも「答え」に入れるべきですか？）
熟考/行動するポイント：
- 開発者のタスクが可能な限り小さい（粒度が小さい）ことを確認する必要があります。
- スプリントの長さは、平均的なタスクの長さに基づいて適切に設定する必要があります（たとえば、1週間のタスクを含むスプリントは少なくとも4週間必要です）
- チーム（QAを含む）は、推定の精度を高めることに取り組む必要があります。
- 個別のQAスプリントを並行して行うことを検討しますが、チームにとって最適な場合はオフセットします
- ユニットテスト！
私の意見では、推定に問題があると思います。各機能をテストする時間がないため、スプリントを計画する際に建物部分のみが考慮されているようです。
私はそれが解決するのが簡単な問題だと言っているのではありません。何よりも一般的だからです。しかし、役立つものは次のとおりです。
開発チームのメンバーとしてQAを検討し、それらをスプリントの計画および見積りにさらに密接に含めます。
「リリース可能な開発タスク」は、スプリントの大部分を占めるべきではありません。完全な作業機能が必要です。各種タスクの開発時間とQA時間に関するメトリックを収集し、将来のスプリントを推定するときにそれらのメトリックを使用してみてください。
バックログを確認して、非常に粗い機能があるかどうかを確認する必要がある場合があります。簡単に見積もり、テストできる小さなタスクに分割してみてください。
要約すると、スプリントの推定と計画を行う際に考慮されていないタスクがあるため、チームは実際の速度が何であるかを見つけていないようです。
しかし、最終的に、推定の不正確さは、アジャイルベースまたはウォーターフォールベースのプロジェクトで見られる難しいプロジェクト管理の問題です。幸運を。
ここでのパーティーに少し遅れましたが、あなたが書いたものに基づいた私の見解です。
現在、スクラムはプロジェクト管理手法であり、開発手法ではありません。しかし、私の意見では、開発プロセスを整えることが重要です。これがないと、構築するのではなく、大半の時間を費やしますreacting。
私はテストファーストです。開発プロセスでは、最初にテストを作成して、要件と設計決定を実施します。 yourチームはそれらを実施していますか？ここでやろうとしていることは、単純に"フェンスの上に物を投げる"ができず、失敗以外は発生しないことです。その失敗は、テストチーム（非常にうまくテストしていないために問題をすり抜けることによる）または開発者（問題を解決する製品を構築しないこと）によるものです。 must最初にテストを書く-私は過激派でもテストファーストの伝道者でもない-しかし、私はあなたに言っているmustプロセスが整っている反復の終わりに達したときに、品質の高いテスト済みのすぐに使用できるコードを生成します。
あなたがいる場所この開発方法論では死のスパイラル法と呼んでいます。私はそのようなモデルで長年政府（米国）向けのソフトウェアを構築しました。それはうまく機能せず、たくさんのお金がかかり、遅れたコード、貧弱なコードを生成し、士気のために何もしません。そもそも作るのを避けたかもしれないバグを修正するためにすべての時間を費やすとき、あなたは前進することができません。私はこの事件に絶対に打ちのめされました。
QAが問題を見つけたくありません。あなたは本当に彼らを失業させたいのです。私の目標は、すべてが正常に機能するため、QAを驚かせることです。確かに、それが目標です。実際には、彼らは何かを見つけます。私は超人間的ではありません。私は失敗する。
スケジュールに戻る...
私の現在の仕事では、私たちはスクラムをやっています。ここではラベルには興味がありませんが、時間通りに高品質のコードを作成することに興味があります。全員が乗船しています。 QAに、いつテストする準備ができているかを伝えます。彼らはそれのために2週間早くノックして来た場合、彼らは手に話すことができます。誰もがスケジュールを知っており、誰もがリリースに含まれるものを知っており、誰もが製品がQAに進む前に宣伝どおりに機能しなければならないことを知っています。それはどういう意味ですか？ QAに「XYZのテストを気にしないでください-壊れており、リリースCまで修正されません」と伝え、テストに出たら、その声明に戻って時間を無駄にしないように指示します。おそらく、厳しいですが、時には必要です。私は失礼なことではありませんが、誰もが「ルール」と何をテストすべきか、「既知の問題」は何かを知る必要があります。
経営陣が参加しなければなりません。そうでない場合は、トラブルが発生します。 QAはショーを実行できず、devグループも完全に実行できません。すべてのグループ（それらのグループがグループごとに1人または複数の帽子をかぶっている男性である場合でも）は、顧客、テストチーム、開発者、管理者など、同じページにいる必要があります。通常、戦いの半分以上はコミュニケーションです。
おそらく、あなたはスプリント中に達成できる以上のものを噛みしめているでしょう。そうかもしれません。どうしてそんなことをするのか？スケジュールを満たすために？その場合、管理者が介入して問題を解決する必要があります。 QAのバグのあるコードを提供している場合は、投げ返すことを期待してください。未完成の8つのものよりも、機能する3つのものを与える方が良い。目標は、各反復で完全に実装される機能セットを作成することであり、大量の半分の処理をまとめて行うことではありません。
私はこれが意図されたとおりに受け取られることを望んでいます-暴言ではなく励ましとして。私が言ったように、私はあなたがいる場所であり、それは楽しいものではありません。しかし、希望はあります。スプリントで物事を好転させることができます。おそらく、次のスプリントでは新しい機能を追加せずに、単に壊れているものを修正するだけです。それをチームとして決める必要があります。
テストコードを書くためのもう1つの小さなプラグ：「テストを最初に書く」アプローチを採用して以来、自分の製品にはるかにリラックスし、自信が持てるようになりました。すべてのテストに合格すると、私はテストなしでは絶対に手に入らない自信があります。
幸運を祈ります！
うまくいけば、各スプリントでより少ない開発タスクに取り組むことでこれを修正できます。それは質問につながります：誰が設定開発者の目標ですか？開発者が常にこれらの目標を達成できないのはなぜですか？
開発者が独自の目標を設定していない場合、それが常に遅れる理由です。そして、それはスクラムを実践する理想的な方法ではありません。それは、大きな、期限駆動型の成果物を使用した単なる増分開発であり、開発者側には実際の利害関係者の責任はありません。
開発者が十分な知識がないために独自の目標を設定できない場合、前もって関与する必要があります。
スクラムは、 アジャイルマニフェスト で概説されている4つの基本原則に依存しています。
相互作用は重要です。つまり、開発者、QA、プロジェクト管理、およびエンドユーザーは、より多くのことを話し合い、互いに話し合う必要があります。ソフトウェアは、コンピューターの不可解な言語で知識をエンコードするプロセスです。知識をエンコードするには、開発者が知識を持っている必要があります。 [なぜ私たちはそれを「コード」と呼ぶと思いますか？]スクラムは「書き込み仕様-トランサムを投げる」方法論ではありません。それはANTIです-「書き込み仕様-トランサムを投げる」
動作中のソフトウェアは重要です-つまり、開発者が噛み付いた各ピースはworkingリリースにつながる必要がありますQAが取り組むべきバグ修正のセットではなく、動作するソフトウェア。
顧客コラボレーション-開発者は、ビジネスアナリスト、エンドユーザー、ビジネスオーナー、彼らが構築しているものを理解するのを助けることができるすべての人と協力する必要があることを意味します。締め切りは、顧客に次に渡されるものほど重要ではありません。顧客がXを必要とする場合、それは誰にとっても最優先事項です。プロジェクト計画でビルドYが示されている場合、それはmalarkeyの負荷です。
変更への対応-これは、顧客が次のスプリントの優先順位を変更できることを意味します。彼らは進行中のスプリントを再配置することはできません（それはクレイジーです）が、以下のすべてのスプリントは優先順位を変更する候補です。
顧客が運転すると、締め切りは人為的な「プロジェクトのマイルストーン」になり、「最初にX、次にY、そしてセクションZのこのことが必要になります。これ以上は必要ありません。W、Z冗長です。」
スクラムのルールでは、すべてのスプリントアイテムは、完全と見なされるために、スプリントの最後に「完全にテストされ、実装可能な機能」である必要があるとされています。スプリントは常に時間通りに終了し、チームはクレジットを得られず、スプリントレビューで完了していないもの（QAを含む）を提示することはできません。
技術的には、必要なのはそれだけです。チームは一定量の作業をコミットし、最終的にスプリント終了の2日前にQAに送りますが、QAは間に合いません。したがって、スプリントからの出力はゼロであり、顧客の前に出て、1か月の仕事の間何も見せないことを認めなければなりません。
次回は、彼らがより少ない仕事を選び、それを時間通りに完了することができるようにQAにそれを得る方法を見つけ出すことを賭けます。
2。5年間アジャイルプロジェクトに携わったQAとして話すと、これは本当に難しい問題であり、まだすべての答えがありません。
私は「トリプレット」（プログラムとQAをペアにした2人の開発者）の一部として働いており、2週間のイテレーションの初めにストーリーを計画し、会議の計画を立てています。上記のadrianhが述べたように、QAが最初のスプリント計画で声を聞くことは不可欠です。これは特に、非常に強力な性格を持つ開発者と作業している場合は難しい可能性がありますが、QAはWordの真の意味で断定的でなければなりません理解）。テスト駆動型のメンタリティを奨励するために、計画中に最初にQAタスクを作成することを推奨します。多くの人がソフトウェア開発が機能していると考えるのとは反対ですが、いくつかの理由で利益を上げています。
QAは聞いたものであり、「それをどうやってテストするのですか？」開発者が自分の作品を言った後（滝の考え方）。
これにより、QAがテストのアイデアを提案し、同時に、真実/ POが存在している間に受け入れ基準のテスト可能性をチェックします（計画会議に出席することが不可欠であると言いましたね？）理解のギャップを埋めます。
テスト駆動型アプローチの基礎を提供します。テストアプローチが宣言され、タスクが実行された後、開発者は、それらのテストに合格するためのコードの生成方法について考えることができます。
ステップ1〜3が、残りの反復で唯一のTDDアクティビティである場合、最初の投稿でSteveが仮定したシナリオよりも何百万倍も良い結果を残しています。 「開発者はタスクを達成しようと急いでいます。一般に、タスクはスプリントのほとんどを完了します。QAはテストできるものをリリースするようデベロッパーを悩ませます。残りの時間は、QAが発見したバグを修正します」
言うまでもなく、これにはQAの注意事項がいくつかあります。
テストのアイデアを開発者と真実/ POが挑戦し、妥協点に到達できるように準備する必要があります。 「QA警察」の態度は、アジャイルチームでは洗い流されません。
QAタスクは、あまりにも詳細でも一般的でもないように難しいバランスをとる必要があります（タスクをカードに書いて「ラジエーターボード」に移動し、毎日のスタンドアップミーティングで議論できます-「進行中」から「進行中」に移動する必要があります反復中に「完了」）。
QAは、計画/推定会議の準備をする必要があります。目に見えないユーザーストーリーのために、頭に浮かぶテストアプローチを作成するだけでは期待しないでください！多くの場合、開発者はこれを行うことができるようです。 「xコンポーネントをzコンポーネントとインターフェースするように変更する」または「yメソッドをリファクタリングする」。 QAとして、計画する前に導入/変更される機能に精通している必要があります。そのため、テストの範囲と適用できるテスト設計手法を把握する必要があります。
テストを自動化し、イテレーションの最初の2、3日以内にこれらを記述して「失敗」させるか、少なくとも開発者がコードの準備が整ったときに一致させることがほぼ不可欠です。その後、テストを実行して、期待どおりにパスするかどうかを確認できます（適切なQA TDD）。これは、反復の終わりに小さな滝を避ける方法です。コーディングの開始前または開始時に、開発者にテストを実際にデモして、目的を理解してもらう必要があります。
期待される動作の手動チェックリスト（あえてスクリプトと言うこともあります！）で同じことが達成できる場合があるため、4は「ほぼ必須」だと言います。彼らと話し続けてください！
タスクの主題に関する上記のポイント2に関して、私はそれぞれが実証可能な作品に対応する30分から2時間のサイズのタスクを作成しようとしました。 「自動テストに誤ったパスワードのチェックを追加-2時間」。これは私の仕事を整理するのに役立ちますが、あまりにも詳細であると他のチームメンバーから批判されており、複数のタスクを前日から完了まで移動したり、タスクをまったく移動できないという私のスタンドアップで効果があります私はまだそれらに乗っていません。人々は実際に毎日の立ち上がりで着実な進歩の感覚を見たいので、1/2日または1日のブロックでタスクを作成する方が便利です（ただし、完了に向けて行う「マイクロタスク」の独自のリストを保持することもできます）スタンドアップで全体的な進捗を伝えるために使用するより大きなタスクの）。
上記のポイント4および5に関しては、早期に準備する自動化されたテストまたは手動のチェックリストは、本当に幸福なパスまたは主要な受け入れ基準のみをカバーする必要があります。これらのパスが完了すると、エッジケースをチェックするために、反復の終わりに向かって「探索的テスト」の最終ラウンドの追加タスクを計画できます。その間、開発者が行うことは、彼らが懸念する限り、バグを見つけない限り「コード完全」であるため、問題があります。一部のアジャイル実践者は、最初にEdgeのケースに進むことを提唱しますが、これは問題になる可能性もあります。これは、ユーザーストーリーのコンテキストとQAとしての経験に依存する、細かくバランスの取れた決定の1つです。
最初に言ったように、私はまだすべての答えを持っているわけではありませんが、上記が難しい経験から生まれたいくつかの指針を提供することを願っています！
この問題を次のように解決しました。-製品バックログのすべてのアイテムは適合基準または受け入れ基準を持っている必要があり、それらがない場合はスプリントを開始しません-テスターはチームの一部です。タスク（受け入れ基準に基づいて1つ以上）と推定、およびテストするアイテムへのリンク-毎日のスクラム中に、完了したすべてのタスクは「テストする」列に配置されます-タスクは実行されません16時間以上かかります。推定時間が長いタスクは分割されます
「リリース可能な開発タスクがスプリントの大部分を占める場合、スクラムはどのように機能するはずですか？」
あなたが知っているように-それはひどくうまく機能しません:-)あなたが説明しているプロセスは私にとってスクラムのように聞こえません-または少なくともスクラムがうまくいくようではありません。
QAのメンバーがチームの一員であるのか、それとも別のグループであるのかについて、あなたが説明したことはわかりません。
彼らが別のグループである場合、これはおそらく問題の大きな部分です。チームは、タスクの完了に対するチームのコミットメントや、製品所有者との関連するスコープネゴシエーションには関与しません。アジャイルグループがチームでQAスキルを持たずに成功するのを見たことはありません。開発者に多くのテスト/ QAスキルを持たせるか、チームに1人または3人のQAスタッフを組み込みます。
彼らがチームにいる場合、彼らは最初のスプリント計画で声をもっと聞く必要があります。今では、製品の所有者とチームには、あなたがオーバーコミットしていることが明確になっているはずです。
それが私だったら、いくつか試してみます：
- チームのQA /テスト担当者がまだいない場合は取得する
- 「完了」と見なされるものについて、製品所有者およびチームと十分に長いチャットを行います。一部の開発者はまだ「QAに引き継がれる」というスクラム前の考え方にいるようです。
- ストーリーを小さなチャンクに分割-推定の間違いを見つけやすくします
- 短いスプリントを実行することを検討してください-ほとんどの場合、追跡や学習が簡単になるためです。
また、これらを見つけることができます スクラムのバーンダウンをスムーズにするためのヒント 便利です。
QAへのリリース前に、開発チームが自分で十分なテストを行っていないように思えます。すべてのユニットテストに合格している場合、QAサイクルは比較的スムーズに行われるはずです。彼らはいくつかの統合エラーを見つけますが、そう多くはないはずですよね？
ここにはいくつかの問題があると思います。まず、開発者のタスクが十分にきめ細かくないか、十分に推定されていないか、あるいはその両方ではないかと思います。スクラムのスプリントの全体的な目的は、スプリントの終わりに実行可能なコードを実証できるようにすることです。私が言及した問題の両方は、バグのあるコードにつながる可能性があります。
開発者がスプリントの終わりに向かってバグのあるコードをリリースしている場合、私も見ます：
- 製品の所有者は、開発メンバーにタスクを実行する責任を負わせていますか。それがPOの仕事であり、そうでない場合、開発者は怠けます。
- 開発者はあらゆる種類のTDDを使用していますか。そうでない場合、それは問題を大いに助けるかもしれません。開発者にコードをテストする習慣を身に付けさせます。私はこの問題を抱えており、チームは重要な分野でTDDを行うことに集中しているため、後で他の人にやらせる必要はありません。
- タスク/ユーザーストーリーは一般的すぎますか？タスクの内訳に余裕があると、開発者はだらしないことになります。繰り返しますが、これはややPOの問題です。
過去に打たれたと聞いたアイデアの1つは、QAの人をスクラムマスターとして使用することです。彼らは毎日のスタンドアップに出席し、開発者がどこにいるのかを知ることができます。 POの問題に対処できます（POが適切に業務を遂行できると仮定）。
私は、QAとスクラムチームの間にもっと協力が必要だと感じずにはいられません。テストは最後にしか行われないように聞こえますが、これは問題です。 QAをチームの一員とすることで、より早くより良いテストが可能なものを特定するのに役立ちます。
また、製品の所有者に問題があるように感じます。全員が正しい方向に向かっていることを確認して、彼らはそこにいなければなりません。彼らは、QAと開発者の間だけでなく、開発者自身の間でも良好な協力関係があることを確認する必要があります。
タスクを小さなタスクに分割します。
また、QAは開発者がテストするテストケースを作成できます。
考慮すべき1つのアイデアは、QAがメイン開発の1回の反復で機能するようにすることです。それは私たちの環境でうまくいきます。
ここで私は言う、ワンサイズはすべてに適合しません。チームごとにQAの扱いが異なります。それはあなたが取り組んでいるプロジェクトに大きく依存しています。それは小さなプロジェクトでも大きなプロジェクトでもあります。広範な回帰、ユーザーの受け入れ、探索的テストが必要ですか、それともテストするシナリオがほとんどありません。アジャイルでは、スペシャリストではジェネラリストが好まれることを再度述べておきます。それは何ですか？プロジェクト中にテストするものがない時間があるため、その時点で何か他のことをしている可能性があります。また、ハードコアプログラマーであっても、テストを行っている可能性があります。
どのように処理しますか？定期的に2週間のスプリントがあります。 1週間後に開発者が完了したタスクのテストが1週間後に開始されます。テスターは引き続き課題トラッカーに問題を追加し、スプリントタスクを完了した開発者はそれらのバグの選択を開始します。スプリントの終わりまでに、私たちはほとんどスプリントタスクとすべての重大なバグと主要なバグを完了します。
では、スプリントの最初の週にテスター2は何をしますか？
さて、常にテストすることがあります。バックログにはテストタスクがあり、これにはいくつかの探索的テストが含まれる場合があります。多くの人々は探索的テストを評価しませんが、それは高品質の製品を構築するために非常に重要です。優秀なテスターは自分でタスクを作成し、問題が発生する可能性を見つけてテストします。
お役に立てば幸いです！