QAに12週間かかる場合は、アジャイルをやめるべきですか？

私の会社の誰かが最近、コア製品の変更を提案しました。マネージャーは、私の会社が完全なQAサイクルと考えるものをトリガーする必要があると感じています（つまり、製品スイート全体を一からテストする）。QAが製品のQAサイクル全体を実行するには、12週間かかります。これに関する私の問題は、アジャイル（ほとんどの意見では半分ですが）開発をしようとしていることです。スプリント全体を実行した後、リリースを実行します。QAはこれを完了するまでに時間がかかります。問題は、QAが仕事をするのに12週間かかる場合、アジャイルをやろうとするのをあきらめてはいけないということです。このような状況でアジャイルをやろうとすることの意味は一体何でしょうか？

まあ、あなたの質問への直接的な答えは、私は恐れているMuです-あなたが試してみるべきかどうかを十分な情報に基づいて推測するのに十分な詳細はありません。

私が非常にポジティブなのは、敏a性のレベルが顧客/市場のニーズに左右されるべきだということです（これについては情報を提供していません）。

• ^{たとえば、IDEのユーザーとして、1年に1回または2回、新しいバージョンにアップグレードできてとてもうれしく、それを急ぐことはありません。つまり、リリースサイクルが3か月（12週間）の場合、私はそれに完全に満足しています。
   
  一方で、たとえば、ソフトウェアが市場の変化に適応するのに1か月以上かかると、金融商社が破産することは容易に想像できます。この場合、12週間のテストサイクルは地獄への道です。今-この点であなたの製品は何を必要としていますか？}

考慮すべきもう1つのことは、顧客/市場のニーズを満たすために必要な品質レベルです。

• ^{適切な事例-かつて働いていた会社で、あるソフトウェアベンダーからライセンスされた製品に新しい機能が必要であることがわかりました。この機能がないと、かなり強く苦しんだので、はい、実際にアジャイルであり、1か月以内に更新を配信することを望んでいました。
   
  そして、はい、彼らはアジャイルであるように見え、はい、1か月でその更新をリリースしました（QAサイクルが12週間の場合、おそらくそれをスキップしました）。そして、私たちの機能は完璧に機能しました- 私たちは完全に幸せだったはずだと思いますか？いや！以前は正常に機能していたいくつかの機能に、トップレベルのリグレッションバグを発見しました。そのため、古いバージョンを使い続ける必要がありました。
   
  別の月が過ぎました-彼らは別の新しいバージョンをリリースしました：私たちの機能ありましたが、同じリグレッションバグもありました。再び、アップグレードしませんでした。そして別の月と別の。
   
  最終的に、俊敏性のために半年後にアップグレードすることができました。}

さて、あなたが言及したこれらの12週間をもう少し詳しく見てみましょう。

QAサイクルを短縮するためにどのようなオプションを検討しましたか？上記の例からわかるように、単にスキップするだけでは期待どおりの結果が得られない可能性があるため、アジャイルでさまざまな方法で対処することをお勧めします。

たとえば、製品のテスト容易性を改善する方法を検討しましたか？

または、より多くのQAを雇うためのブルートフォースソリューションを検討しましたか？見た目は簡単ですが、場合によってはこれが実際の方法です。平均的なプロのテスターで十分な上級開発者を盲目的に雇って、製品品質の問題を解決しようとする経験の浅い経営陣を見てきました。かなり哀れ。

少なくとも最後のではなく-私は1つがあるべきだと思うアジャイルアジャイルの原則の非常にアプリケーションに関する。つまり、プロジェクトの要件がアジャイルでない（安定している、またはゆっくりと変化する）のであれば、なぜ面倒なのでしょうか？私はかつて、トップマネジメントが、スクラムを無理なく完璧に実行しているプロジェクトで強制しているのを観察しました。なんて無駄だった。配信が改善されなかっただけでなく、さらに悪いことに、開発者とテスターは皆不満になりました。

コメントで提供される説明に基づいて更新する

私にとって、アジャイルの最も重要な部分の1つは、各スプリントの最後に出荷可能なリリースを用意することです。それはいくつかのことを意味します。最初に、ビルドを顧客にリリースできると思われる場合、目立つバグがないことを確認するために、テストのレベルを実行する必要があります...

出荷可能なリリース、私は参照してください。ふむ うーん。アジャイルカクテルにリーンを1 つか2つ追加することを検討してください。つまり、これが顧客/市場のニーズでない場合、これは（テスト）リソースの浪費だけを意味します。

私は、スプリント終了リリースをチームを満足させる単なるチェックポイントとして扱うことに関して、犯罪者はいないと考えています。

• ^{開発者：はい、テスターに​​渡すのに十分なようです。QA：出荷可能なテストをさらに行う必要がある場合、そのケースには十分に見えます -そのようなもの。チーム（開発者+ QA）は満足しています、それだけです。}

...最も重要なポイントは、要件がアジャイルでない場合にアジャイルを適用しないという点で、応答の最後にありました。これはスポットだと思います。アジャイルを始めたとき、私たちはそれをダイヤルインさせ、状況は理にかなっています。しかし、それ以来、物事は劇的に変化し、もはや意味をなさないかもしれないプロセスに固執しています。

あなたはそれを正確に得ました。また、あなたが説明したところからは、状態（チーム/管理の成熟度と顧客関係）に到達したように見え、スクラムの代わりに定期的な反復モデル開発を使用できます。もしそうなら、その定期的な反復のようなケースでの私の経験によると、スクラムよりも生産性が高いことを知りたいと思うかもしれません。はるかに生産-単にありましたので、はるかに少ないオーバーヘッド、（QAは、それぞれのテストに集中するために）開発に注力するだけでそんなに簡単でした。

• ^{私は通常、フェラーリ（通常の反復）とランドローバー（スクラム）の観点から考えています。
   
  高速道路で運転しているとき（そしてあなたのプロジェクトがその高速道路に到達したように見えるとき）、フェラーリはランドローバーの地獄を打ち負かします。
   
  スポーツカーではなくジープを必要とするオフロードです-要件が不規則であるか、チームワークと管理の経験がそれほど良くない場合は、スクラムを選択する必要がありますスタック-フェラーリがオフロードでスタックするように。}

私たちの完全な製品は、多くの小さな部品で構成されており、すべて個別にアップグレードできます。私たちの顧客は、これらの小さなコンポーネントをより頻繁にアップグレードしたいと思っています。おそらく、スプリントの最後にこれらの小さなコンポーネントをリリースし、QAすることに集中する必要があるように思えます...

上記は良い計画のように聞こえます。私はそのようなプロジェクトで一度働いたことがあります。毎月のリリースでは、更新プログラムをローリスクの小さなコンポーネント内にローカライズして出荷しました。これらのQAサインオフは、可能な限り簡単です。

• ^{この戦略で留意すべきことの1つは、変更が予想どおりにローカライズされていることをテスト可能な検証で確認することです。これが、変更されていないコンポーネントのビットごとのファイル比較に至ったとしても、そのままにしておかないと、出荷されません。開発者ではなく、リリースの品質を担当するのはQAです。
   
  開発者として率直に言って、私はそれを心配するのに十分な他のものを持っているので、予期しない変更がすり抜けないことを確認することはテスターの頭痛です。そしてそのため、彼ら（テスター）は、出荷するテストで物事が制御されているという確かな証拠を本当に本当に必要としています。}

ああ、私はあなたの痛みを感じます。これを機能させるには、QAチームに重大な変更を加える必要があります。

私のアドバイスは、チームを3つのチームに分割することです。

機能テスト -新規開発のテストの迅速なターンアラウンド。

回帰テスト -製品が出荷される前に完全にテストします。ほとんどのバグは最初のチームによって発見されるため、チームのサイズを縮小した後でも、これには3か月はかかりません。

自動テスト -回帰テストチームの仕事をスピードアップする回帰テストの完全なスイートを作成します。

3番目のチームはボーナスですが、最初の2つのチームを獲得できない場合は、滝になることもあります。

例として：

QAチームはおそらく（ATDD）サークルの外側で作業しており、あなたは内側で作業していることに注意してください。

そのように働くことは問題ないと思います。自動テストで、各スプリントで顧客の要件を満たしていることを証明できる場合は、QAが自由にテストを実行できるようにし、欠陥を見つけたら、次のスプリントに取り組むことができます。

「Definition of Done」の問題があるようです。

QAグループは外部であり、顧客リリースのみに関係しているため、問題に関するタイムリーなフィードバックをそれらに頼ることはできません。つまり、迅速なフィードバックが必要な場合は、チームに対して「社内」である程度のテストを行う必要があります。

QAグループを存在しないものとして扱います。行為は、スプリントの最後のリリースが翌日に最も重要な環境に展開される場合です。ソフトウェアは、顧客に提供する準備ができるまで完了しません。

QAは何も見つけられないはずです。

これに到達するのは難しくなります。おそらく最初の数回はこっそりいくつかのことをするでしょう。自動化された受け入れテストと「回帰」テストは、ここであなたの親友です。TDDは、このようなスイートの大部分を構築するのに役立ちます。あなたが何かを壊したかどうかを、すぐに知ることができるはずです。

QAが完了する前に特定のリリースを確認し、正式なフィードバックを提供できる顧客担当者/製品所有者がいますか？その場合、QAを副次的なやや遅いフィードバックのソースとして扱いながら、アジャイルメソッドを実行し、その利点を最大限に活用できます。リリースは、QAが完了した後にのみ「公式に準備完了」になりますが、次のリリースを開始する前にリリースを待つ必要はありません。

しかし、QAが完了する前にリリースを顧客に見せてはならないと会社の規則が定めている場合、それらの規則を変更できるようになるまで、アジャイルであることをほとんど忘れることができます。

説明したプロセスは、アジャイルプロセスではありません。俊敏性の高いチームは、すべてのスプリントで信頼性があり、リリース可能なビルドを提供できます。ほとんどのアジャイル実装では、QA機能はアジャイルチーム内に構築され、この目標の達成を支援します。

プロジェクトリーダー、製品所有者、および開発者が協力しておらず、改善計画（後向き）がない場合は、プロセスに別の名前を付けて先に進みます。チームの問題がマネージャーやQAのせいではないようです。彼らは、開発組織から出てくるいくつかの体系的な問題に反応しているようです。チームが責任を引き受け、利害関係者と協力し始めるなら、すべてが失われるわけではありません。

3つのことを試すことができます。1つ目は、各利害関係者が役割を簡潔に定義し、各人が自分の責任を理解していることを確認してください。2つ目は、ビルドを安定させてから、変更を追加せずにQAからサインオフします。3つ目は、テストの自動化を実施することです。QAチームはあなたを愛しています。

フィードバックには非常に時間がかかりますが、アジャイルでやめる価値はないと思います。スプリント（またはカップル）の終わりに、市場に投入できると確信している製品をリリースします。あなたのチームにとってアジャイルは、行われる作業に集中し、製品をリリース可能な状態に保つ能力をもたらします。QAが問題を見つけたら、これらの問題のバグレポートを作成し、次のスプリントで対処することをお勧めします（優先度が十分に高い場合）。

当社の製品フィールドテストには、8週間がかかり、さらに外部の栽培者に依存しています。それでもアジャイルを行うことで、手元の作業に集中し続けることができ、必要なときに新しいバージョンを非常に迅速に作成できます。

問題は（あなたの目には）QA部門にあり、そこで問題を解決できますか？話し合った？

12週間は長いですが、QAがその期間中（3か月後ではなく）フィードバックとバグレポートを提供できることを願っています。

そうすれば、最も重要な問題に機敏に対応することができ、完了しないうちにすべてではないとしても多くの問題を修正できます！

複数のスプリントを実行している間、QAの人々は何をしていますか？すべての変更後にすべてをテストする必要があると感じているように聞こえます（これが、多くの変更を待つ理由です）。

開発チームはアジャイルですが、会社の他のチームはそうではありません。

QAを担当している人は、自分が何をしているのか分からないか、上級管理職でジェダイマインドトリックを実行し、甘い時間を取ることができます。QAは開発よりも時間がかかりますか？