QAに12週間かかる場合、アジャイルをやめる必要がありますか？
私の会社の誰かが最近、コア製品への変更を提案しました。マネージャーは、会社が完全なQAサイクル（つまり、製品スイート全体を最初からテストする）と見なすものをトリガーする必要があると感じています。どうやら私たちのQAは、私たちの製品の完全なQAサイクルを行うのに12週間かかります。これに関する私の問題は、私たちがアジャイル（私の意見では大部分が片思い）の開発をしようとしていることです。一連のスプリント全体を実行してからリリースを実行します。QAは完了するまでに時間がかかります。問題は、私たちのQAが12週間かけて仕事をするのであれば、アジャイルをやめることをあきらめるべきではないかということです。このような状況でアジャイルを実行しようとする意味は何ですか？
さて、あなたの質問への直接的な答えは M となるでしょう-申し訳ありません-情報をもとに推測を行うのに十分な詳細がありません。
私がかなり肯定的である唯一のことは、俊敏性のレベルは顧客/市場のニーズ（あなたが情報を提供しなかった）によって駆動されるべきであるということです。
- たとえば、IDEのユーザーとして、年に1、2回は新しいバージョンにアップグレードできてとてもうれしく、急いでそれを行うことはありません。つまり、リリースサイクルが3の場合月（12週間）それから私はそれで完全に満足しています。
一方で、ソフトウェアが市場の変化に適応するのに1か月以上かかると金融商社が倒産することは容易に想像できます-12週間この場合のテストサイクルは地獄への道でしょう。さて、この点に関してあなたの製品は何を必要としていますか？
考慮すべきもう1つのことは、顧客/市場のニーズに応えるためにどのレベルの品質が必要かということです。
- 適例-私がかつて働いていた会社で、ソフトウェアベンダーからライセンスされた製品に新しい機能が必要であることがわかりました。この機能がないとかなり苦しんでいたので、はい、本当にアジャイルにして、1か月以内に更新を配信したいと考えました。
そして、はい、彼らは機敏であるように見え、はい、彼らはその更新を1か月でリリースしました（QAサイクルが12週間の場合、おそらくスキップしただけです）。そして、私たちの機能は完全にうまくいきました-私たちは完全に幸せだったと思いますか？ no！以前機能していた一部の機能にshowtopper回帰バグが発見されたため、古いバージョンではstick-n-sufferにする必要がありました。
別の月が経過しました-彼らは別の新しいバージョンをリリースしました：私たちの機能はありましたが、同じ回帰バグもありました：再び、アップグレードしませんでした。そして別の月と別の。
結局、私たちは彼らの敏捷性のために、半年後にはそれほどアップグレードすることができませんでした。
さて、あなたが言及したこれらの12週間についてもう少し詳しく見てみましょう。
QAサイクルを短縮するためにどのようなオプションを検討しましたか？上記の例からわかるように、単にスキップするだけでは期待どおりの結果が得られない可能性があるため、agileとし、differentそれに対処する方法。
たとえば、製品の testability を改善する方法を検討しましたか？
または、より多くのQAを雇うだけのブルートフォースソリューションを検討しましたか？見た目はシンプルですが、場合によってはこれが実際の方法です。経験の浅い管理職が、平均的なプロフェッショナルテスターだけで十分である上級開発者を盲目的に採用することによって製品品質の問題を修正しようとしているのを見てきました。かなり哀れです。
最後になりましたが、アジャイル原則の適用についてはアジャイルである必要があると思います。つまり、プロジェクトの要件がアジャイルではない（安定しているか、ゆっくりと変化している）場合は、なぜ煩わしいのでしょうか。私はかつて、トップマネジメントがなくても完璧にうまくいっていたプロジェクトでスクラムを強制することを観察しました。なんて無駄なことだった。配信に改善がなかっただけでなく、さらに悪いことに、開発者とテスターはすべて不満になりました。
コメントで提供された説明に基づいて更新
私にとって、アジャイルの最も重要な部分の1つは、各スプリントの最後に出荷可能なリリースがあることです。それはいくつかのことを意味します。最初に、ビルドを顧客にリリースできると思われる場合は、バグを表示しないように、ある程度のテストを行う必要があります...
Shippable releaseなるほど。うーん。うーん。アジャイルカクテルに Lean を1つか2つ追加することを検討してください。つまり、これが顧客/市場のニーズではない場合、これはリソースの（テスト）の浪費のみを意味します。
私は、Sprint-end-releaseをチームを満たすいくつかのチェックポイントとして扱うことで、何の犯罪者も見ません。
- dev：ええ、テスターに渡すには十分によく見えます。 QA：そうです、さらに出荷可能なテストが必要な場合、ケースには十分に見えます-そのようなもの。チーム（開発+ QA）は満足です、それだけです。
...あなたがした最も重要なポイントは、要件がアジャイルでない場合、アジャイルを適用しないという点で応答の最後にありました。これはその場にあると思います。私たちがアジャイルを始めたとき、それをダイヤルインしてもらい、状況は理にかなっています。しかし、それ以来、状況は劇的に変化し、もはや意味のないプロセスに固執しています。
正解です。また、あなたの説明から、スクラムの代わりに通常の反復モデル開発を使用できる状態（チーム/管理成熟度および顧客関係）に到達したように見えます。もしそうなら、そのような場合の私の経験によれば、通常の反復がスクラムよりも生産的であると感じたことを知るのにも興味があるかもしれません。生産性が大幅に向上-オーバーヘッドがsoはるかに少なくなり、開発に集中することが非常に簡単になりました（QAがそれぞれテストに集中するため）。
- 私は通常、Ferrari（通常の反復として）対Landrover（スクラムとして）の観点から考えます。
高速道路を走っているとき（そしてプロジェクトがそのhighwayに到達したようです）フェラーリはランドローバーの地獄を打ち負かします。
スポーツカーではなくジープが必要なのはオフロードです。つまり、要件が不規則である場合や、チームワークや管理の経験がそれほど良くない場合は、スクラムを選択する必要があります。定期的に行くと行き詰まってしまいます-フェラーリがオフロードで立ち往生するように。
私たちの完全な製品は、実際にはすべて個別にアップグレードできる多くの小さな部品で構成されています。私たちのお客様は、これらの小さなコンポーネントをより頻繁にアップグレードすることを非常に望んでいます。代わりに、スプリントの最後にこれらの小さなコンポーネントをリリースおよびQAすることに焦点を当てるべきだと思います...
上記は良い計画のように聞こえます。そのようなプロジェクトで一度働いたことがあります。私たちは毎月のリリースを出荷しました。更新は小さな低リスクコンポーネント内にローカライズされ、これらのQAサインオフは非常に簡単でした。
- この戦略について覚えておくべきことの1つは、testable検証を行って、変更が予想どおりにローカライズされていることを確認することです。これが、変更されていないコンポーネントのビットごとのファイル比較にまで達したとしても、それを実行しないと出荷されません。ことは、リリースの品質を担当するのは私たちの開発者ではなくQAです。
予想外の変更がすり抜けないことを確認するのはテスターの頭痛の種です。率直に言って、開発者として私はそれについて心配するのに十分な他のものを持っているので、私にとってより重要です。そして、そのため、彼ら（テスター）は、リリースされた状態で物事が制御されていることを確実に証明することが本当に必要です。
ああ、あなたの痛みを感じます。これを機能させるには、QAチームにいくつかの重大な変更を加える必要があります。
私のアドバイスは、チームを3つのチームに分割することです。
機能テスト-新しい開発のテストの迅速なターンアラウンド。
回帰テスト-製品が出荷される前に製品を完全にテストします。ほとんどのバグは最初のチームによって発見されるため、チームサイズを縮小した後でも、3か月はかかりません。
自動テスト-回帰テストチームの仕事をスピードアップするために、回帰テストの完全なスイートを作成します。
3番目のチームはボーナスですが、最初の2つのチームを獲得できない場合は、ウォーターフォールになる可能性もあります。
例として：
おそらくQAチームは（ATDD）サークルの外で働いており、あなたは内部で働いています。
私はそのように働くことは問題ないと思います。自動テストで、各スプリントで顧客の要件を満たしていることを証明できる場合は、QAが余暇にテストを実行できるようにして、問題が発生した場合、次のスプリントに取り組むことができます。
「完了の定義」の問題があるようです。
QAグループが外部にあり、カスタマーリリースにのみ関与している場合、問題に関するタイムリーなフィードバックをそれらに信頼することはできません。つまり、迅速なフィードバックが必要な場合は、チームの「社内」である程度のテストを行う必要があります。
QAグループが存在しないかのように扱います。行為は、スプリントの最後のリリースが翌日に最も重要な環境に展開されるかどうかです。ソフトウェアは、顧客に提供する準備ができるまで完了しません。
QAは何も検出しないはずです。
これは手に入れるのが難しいでしょう。あなたはおそらく最初の数回をこっそりするいくつかのものがあるでしょう。自動受け入れテストと「リグレッション」テストは、ここでの親友です。 TDDは、そのようなスイートの大部分を構築するのに役立ちます。何かを壊した場合、すぐに知ることができるはずです。
特定のリリースを見ることができる顧客担当者/製品所有者はいますかbefore QAはそれで完了し、信頼できるフィードバックを提供しますか？そうであれば、QAを2次的なやや遅いフィードバックのソースとして扱いながら、アジャイルメソッドを実行して、その利点のほとんどを得ることができます。リリースは、QAが完了した後にのみ「公式に準備」されますが、次のリリースを開始する前にリリースを待つ必要はありません。
ただし、QAが完了する前にリリースを顧客に見てはいけないと会社のルールで定められている場合は、それらのルールを変更するまで、アジャイルであることをほとんど忘れることができます。
あなたが説明したプロセスはアジャイルなプロセスではありません。高度な俊敏性を備えたチームは、すべてのスプリントで信頼性が高く、リリース可能なビルドを提供できます。ほとんどのアジャイル実装では、QA機能はアジャイルチーム内に構築され、この目標の達成を支援します。
あなた、あなたのプロジェクトリーダー、あなたの製品所有者と開発者が一緒に働いておらず、あなたに改善計画（遡及的）がない場合は、あなたのプロセスに別の名前を付けて次に進んでください。チームの問題がマネージャーやQAのせいではないようです。彼らは開発組織から出てくるいくつかの体系的な問題に反応しているようです。チームが責任を取って利害関係者との作業を開始する意思がある場合、すべてが失われることはありません。
3つのことを試すことができます。 1つは、各利害関係者が簡潔に定義された役割を持っていること、および各人が自分の責任を理解していることを確認してください。 2つ目は、ビルドを安定させ、変更を追加せずにQAからサインオフすることです。 3つ目は、テストの自動化です。 QAチームはあなたを愛しています。
残念ながらフィードバックには時間がかかりますが、アジャイルで停止する価値はないと思います。スプリント（またはカップル）の最後に、市場に投入できると確信している製品をリリースします。チームにとってアジャイルは、実行する作業に集中し、製品をリリース可能に保つ能力をもたらします。 QAが問題を見つけたら、これらの問題のバグレポートを作成し、次のスプリントでそれらに対処することをお勧めします（優先度が十分に高い場合）。
当社の製品のフィールドテストには8週間かかります。さらに、外部の栽培者に依存しています。それでもアジャイルを実行することで、手元の作業に集中し続けることができ、必要に応じて新しいバージョンをすばやく作成できます。
問題は（あなたの目には）QA部門にあります。問題はそこで解決できますか？話し合いましたか？
12週間は長いですが、できればQAがその間（3か月後ではなく）フィードバックとバグレポートを提供できることを願っています。
そうすれば、最も重要な問題に俊敏に対応することができ、すべてではないにしても多くの問題を修正してから、問題が解決することさえあります。