QAと反復のジレンマ

私の会社では、アジャイルプラクティスでの作業に成功していますが、反復は使用していません。主な理由は、反復サイクルでQAに適合するクリーンな方法を見つけることができないからです。

QAは、特定のビルド（リリース候補）に対する追加の検証として、このビルドが顧客に展開される前に理解します。ポイントは、1つの悪意のあるコミットがリリース全体に損害を与えることを避けることです。あなたはそれがどれであるかを決して知らないので、QAはリリースのすべての機能/コミットがビルドに含まれるまで待つ必要があります。（有名な最後の言葉「それはほんの小さな変化でした」は許可されていません。）

QAがリリース候補でバグを見つけた場合、開発者はそれぞれのリリースブランチでこれらのバグを修正します（そして、トランクにマージします）。すべてのバグが修正されると、QAが再テストするために新しいビルドが展開されます。特定のリリース候補にバグが見つからない場合にのみ、検証のために顧客に提供されます。

これには通常、リリースごとに約2〜3つの候補、約1週間かかります。通常、修正を記述する時間は、テスト作業よりもはるかに短いです。したがって、開発者を忙しくしておくために、彼らはリリースN + 1に取り組み、QAはNに取り組みます。

反復を使用しなくても、リリースNとN + 1の作業を重複させることができるため、これは問題になりません。しかし、私が理解していることから、これはスクラムやXPのような反復ベースのアプローチと互換性がありません。彼らは、すべてのテスト作業がイテレーションに組み込まれ、イテレーションが最後にリリース可能であることを要求します。

これは必然的に次の望ましくない結果のいずれかにつながることがわかります。

（A） QAはリリース候補を確認する時間が必要であり、バグ修正作業が開発者を完全に忙しくしていないため、開発者はイテレーションの終わりにアイドル状態です。

（B）最初のリリース候補の準備が整う前に、QAがすでに機能し始めています。これは、Stack Exchangeで最も推奨されるものです。しかし、テストされた特定のリリース候補がないため、それは私の会社がQAとして理解しているものではありません。そして、すべてを壊す「小さな変化」は、気付かれずに導入される可能性があります。

（C）バグは次の反復に引き継がれます。これはStack Exchangeでも推奨されます。私はそれがまったく解決策だとは思わない。基本的に、バグ修正が行われるたびに、新しい未検証のコミットが同じブランチに追加されるため、検証済みビルドが取得されないことを意味します。

このジレンマから抜け出す方法はありますか？

QAは、特定のビルド（リリース候補）に対する追加の検証として、このビルドが顧客に展開される前に理解します。

この形式のQAと、スクラムのような反復ベースの方法論との間に本質的に互換性のあるものはありません。
スクラム内で、チームは顧客に週1回のサイクルで成果物を提供します。ここで重要なのは、開発チームがスクラムを行っている場合、顧客は製品のエンドユーザーではなくQAチームであるということです。

開発者として、すべてのテストに合格する可能性がある場合、QAに出荷可能な製品を検討します。これはおそらく、QAテストの一部がすでに毎日のビルドで実行されていることを意味しますが、それがQAチームによる公式リリーステストにどのように影響するかは組織次第です。

ほとんどの実際の状況では、アジャイルはQA / UATまたはその呼び出しに応じて停止します。

実際の環境でQAから実稼働に移行する努力は、多くの場合過小評価されています。多くの場合、これにはテストにおける実際のビジネスユーザー、実際のビジネスマネージャーからのサインオフ、運用などによるリリースのスケジュールなどが含まれます。これは簡単なことではありません。

極端な場合、ソフトウェアは外部機関による認証を必要とするか、厳しいセキュリティテストの対象になることがあります。

このような状況では、バグの修正を除き、四半期ごとに複数のリリースを想定することは不可能です。

深刻なソフトウェア製品ではさらに悪化します。ドキュメントは、校正して発行する必要があります。マーケティングパンフレットを修正する必要があります。営業担当者は、彼らが何を売っているのか（簡単な仕事ではありません！）などを知る必要があります。あなたは本当にこれを年に1回以上やりたいとは思わないでしょう。

非常に短期的な解決策は、テストを完了するために、反復後にQAに追加の期間を与えることです。すなわち。2週間の繰り返しがある場合は、3週目までリリースしないでください。とにかく、最初の1週間はQAが次の繰り返しに向けてテストするものは何もありません。

しかし、私は何が起こるかを前もって警告します（複数のチームでこれを見た）：あなたは、2週間の作業を完了する1回の反復、QAが過負荷で、そのためにあなたにやってくる状況になりますQAの1週間全体で、次の反復では、1週間の作業しか完了しません。その反復では、QAには何の関係もなく、問題を解決したと思われます。しかし、次の反復では、サイクルを再び開始します。

そのため、その週に追加したらすぐに、リリースが安定していることを確認するだけです（私が学んだことの1つは、ビジネスに対する信頼を失うと、アジャイルの実装が指数関数的に難しくなることです）長期計画に。

Jez HumbleのContinuous Deliveryのコピーを購入し、カバーツーカバーで読んで、チームに回してください。みんなにインスピレーションを与えてください。次に、そこから可能なすべてを実装します。

ビルドプロセスをできる限り滑らかにします。単体テストポリシーを実装し、すべてのビルドでそれらを実行します。展開プロセスをこれまでで最も洗練されたものにします。3回クリックしますか？十分に滑らかではありません。

これらすべてを実行したら、たまに発生するリグレッションバグが解消されても、それほど問題にはなりません。あなたが理由を知っている？原因は、ビジネスがバラバラになる前に、（オプションで）ロールバック、修正、再デプロイできることです。実際、夜の管理人はあなたのためにロールバックすることができます、プロセスはとても簡単です。

私はあなたが何を考えているのか知っています：私たちにはすべてをする時間がありません。教えてください、そうです。QAをオーバーロードしている場合、反復ごとに展開しすぎています。そうしないでください。すでにそれらをオーバーロードしていない場合は、なぜ自動テストスイートがまだないのかを尋ねます。すぐになります。

これをすべてビジネスに完全に可視化して行います。見積もりを低くし、この作業の一部を反復に注入します。または、さらに良いことに、それをストーリーに分割し、他のすべてと一緒に優先順位を付けさせます。

a）リリースの安定性が向上すること、b）それらの問題に対応する能力が向上すること、c）後で速度が上がることを説明します。これらのことを望まない珍しい会社です。確かに彼らはそれを望んでいないアジャイル企業ではないので、抵抗があれば、あなたは別の問題を抱えていることを知るでしょう。

継続的配信が十分に得られたら、反復の終わりにQAが取得する時間の短縮を開始できます。できるだけ早く反復を並列に戻すことは、すべての人の関心事です。たぶん、あなたは時間を埋める必要があるイテレーションの終わりに一日を過ごすでしょう。私はすでにそのほかの場所について何をすべきかを答えました。

反復を使用しなくても、リリースNとN + 1の作業を重複させることができるため、これは問題になりません。

正確に何を構成するかをどう決めたかに問題があるようですwork for release N。

何らかの奇妙な理由（特定のアジャイルレシピの誤解があるとしか推測できない）のために、アジャイルアプローチではすべてのQAチームの努力をイテレーションに組み込む必要があると何らかの形で決定しました。

• ^{それが本当に当てはまる場合、アジャイルの人気は、私たちが今見ているものにさえ近くないと思います。開発チームのイテレーションとQAテストサイクルの必須の同期を「生き残る」ことができる多くのプロジェクトを想像することはできません。}

以下に敏 on 性についてもう少し説明しますが、まずは整理しましょうwork for release N...

見て、開発チームが仕事をそのように定義する説得力のある理由はありません。まったく逆に、あなたの説明から、モノリシックな「作業単位」の代わりに、感じやすいマイルストーンを持ついくつかのそのような単位があることは明らかです...

• ^{たとえば、最初の「ユニット」は、候補ビルドがテスターに​​渡されたときに明確なマイルストーンで示され、さらにマイルストーンはQAなどによって実行されるテストサイクルに関連する変更に対応します。}

また、定義する方法がwork for release NQAワークフローによって強制されないことにも注意してください 。あなたが説明するものから、彼らは独自の（そしてかなり合理的な）スケジュールを持っているように見えます。

上記で与えられた、あなたのケースでワークユニットを定義するより現実的な方法は次のようなものです：

1. ビルドがQAに渡されるまでの開発アクティビティ
   Release Candidate N
2. 最初のQAテストサイクルに関連する開発アクティビティ
   Release Candidate N patch 1
3. 2回目のQAテストサイクルに関連する開発アクティビティ
   Release Candidate N patch 2
4. など、最終ビルドまで

上記は、アジャイルを実行するかどうかに関係なく、作業単位です。

これらは、定義、フォロー、追跡するのが自然で便利です。これはQAスケジュールともうまく調和しており、ODF開発とQAの取り組みを簡単に調整できます。

しかし、私が理解していることから、これはスクラムやXPのような反復ベースのアプローチと互換性がありません。彼らは、すべてのテスト作業がイテレーションに組み込まれ、イテレーションが最後にリリース可能であることを要求します。

上記のアジャイルとの互換性の理解は根本的に間違っているように見えますが、ここに理由があります...

私たちはその取る場合は、あなたが作った仮定は、アジャイルとは何の関係もありません哲学をまさにその名が示すよう額面で好意と実践というアプローチであること、敏捷性。

その観点から、特定の「固定」ワークフローに固執し、それが便利かどうかを無視することは、単にアジャイルの精神と矛盾します。盲目的プラクティスに「手順」のリードを次中傷ので、雄弁でハーフArsedアジャイルマニフェスト 「...我々はどのようにそれらの個人（私たちは用語『リソース』を好む）相互作用制御に必須のプロセスとツールを持っています」。

これについては、以下に引用する別の質問への回答で見つけることができます。「出荷可能なリリース」に関するメモを見てください。OPは同様の方法で混乱していたようです。

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

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

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

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

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