QAステージ付きスクラムタスクボード
私は読んでいます この記事 スクラムタスクボードについてマイクコーンによって。
私が持っている1つの質問は、開発者ではないテスターによって実行されるQAステージがあるワークフローにこれがどのように適合するかです。
多くのタスクを個別にQAするのは簡単ではないようです。
実用的な代替案は、「検証する」プロセスをチーム内の別の開発者が実行し、完了後にストーリー全体をQAするための追加のステージを用意することです（おそらくステージ/テスト環境に展開した後）。
これは正しいと思いますか？
私は、スクラムチームがWebアプリに取り組んでいる専任のテスターです。タスクボードのQAタスクに関して行うことは、最初にスプリントで取り組むユーザーストーリーを選択することです。次に、これらのストーリーをサブタスクに分割し、QAの2つのサブタスクを追加します。受け入れテストの開発と実行です。テストを開発するタスクは、通常、エンジニアリングタスクと並行してすぐに開始でき、受け入れテストを実行するタスクは、ストーリーのエンジニアリング作業が完了した後に実行されます。エンジニアリングチームには、ローカルマシンの展開で実行される受け入れテストタスクもあり、QAチームは、本番環境に近い展開でより詳細なテストを実行することに注意してください。
QAチームがエンジニアが行うすべてのタスクをテストしようとすることは役に立ちません。その多くはリファクタリングである可能性があるか、全体として取るのがはるかに良いような機能の小さな断片である可能性があるためです。とにかく、すべてのコミットはコードレビューを行います。 QAチームとEngチームの間を行き来して、テスト方法を尋ねたり、機能はバックエンドにのみあり、ユーザーには表示されないなどと言われたりすると、多くの時間が無駄になります。各機能はすでにきちんと分割されています。ストーリーに変換されるため、これらのストーリーは、スプリントの一部としてQAチームによってテストされる作業単位です。
このアプローチの唯一の欠点は、エンジニアリングがスプリントの最後の2/3日間で行うことがほとんどないままにできること、または次のスプリントにオーバーフローする可能性がある修正のためにスプリントのバグに簡単に圧倒されることです。ただし、バグを見つけるための非常に短いフィードバックループ（バグはコーディングからわずか1〜2日で見つかるため）は、よりクリーンなスプリントプランを作成するよりもはるかに望ましいことがわかりましたが、フィードバックループは最大2週間です。
実用的な代替案は、「検証する」プロセスをチーム内の別の開発者が実行し、完了後にストーリー全体をQAするための追加のステージを用意することです（おそらくステージ/テスト環境に展開した後）。
これは正しいと思いますか？
DONEを "各ストーリーが完了しました"として再定義し、 "Product Ready To Release"という新しい列を追加することを提案していると思います。チームが各スプリントでリリース可能なビルドをまだ提供していない場合、あなたの提案は非常に理にかなっており、実際にはかんばんボードで一般的に使用されています。
では、製品をリリースする準備ができていない場合はどうなりますか？そのような状況では、次のことを考慮してください。
- 各バグに対処するための作業項目の作成
- そのバグの原因となったストーリーを特定する
- 実際に「実行されなかった」ストーリーの「完了」状態を元に戻します
- 優先順位付けのためにバグをバックログに追加します
- ふりかえりで根本原因について話し合う
また、開発者は、各イテレーションの最後の最後まで開発することで有名です。これにより、 "リリースの準備ができていますか"非開発チームのメンバーが仕事をすることが難しくなります。かんばんはまた、アジャイルチームがタイムボックス化するのではなく、機能ボックスの反復を提案することによって、ここで役立ちます。ただし、製品がタイムボックスの反復を行う方が理にかなっている場合は、製品がリリース可能なレベルであることを顧客に示すことができるまで、次の反復で新しいストーリーを受け入れないことにチームとして同意することができます。もちろん、チームが新しい作業を受け入れることができない理由をPOに明確に示す必要があります。
実際、そうです、あなたの見方は正しいです。
スプリント中に、開発者は、完了したユーザーのストーリーが承認基準（完了の定義）を満たしていることを確認する必要があります。これは、自動テストを作成することによって実行する必要があります。製品の所有者は、ユーザーストーリーが実際に彼の期待を満たしていることを確認する必要があります。その後、それは完了したと見なされ、レビュー会議で提示できます。スプリント後、製品の出荷可能な増分があり、より集中的なテストを実行できるQAに「出荷」できます-これは実際にはフィードバックの収集です。これは、QAがバグまたはいくつかの欠落または不整合な機能を見つけて、このフィードバックを転送することができるためですチームまたは製品の所有者。 QAは、UIの使いやすさに関するフィードバックを提供することもできます。
このシナリオのQAはチームの一部ではありませんが、チームがコードをテストしないという意味ではありません。 QAは「エンドユーザー」または「顧客」として機能し、出荷された増分にフィードバックを提供します。