QAと反復のジレンマ
私の会社では、アジャイルプラクティスの使用に成功していますが、反復を使用していません。主な理由は、反復サイクルでQAに適合するクリーンな方法を見つけることができないためです。
QAは、特定のビルド（リリース候補）をこのビルドがお客様にデプロイされる前に検証するための追加のビットとして理解しています。ポイントは、1つの悪意のあるコミットがリリース全体に損害を与えることを回避することです。それがどれかわからないため、QAは、リリースのall機能/コミットがビルドに含まれるまで待機する必要があります。 （「ほんの小さな変化だった」という有名な最後の言葉は許可されていません。）
QAがリリース候補でバグを発見した場合、開発者はそれぞれのリリースブランチでこれらのバグを修正します（そしてトランクにマージします）。すべてのバグが修正されると、QAが再テストするための新しいビルドがデプロイされます。特定のリリース候補にバグが見つからない場合のみ、検証のために顧客に提供されます。
これには通常、リリースごとに約2〜3つの候補、約1週間かかります。修正を作成する時間は、通常、テスト作業よりもはるかに短くなります。したがって、開発者を忙しい状態に保つために、QAがNで作業する一方で、開発者はリリースN + 1で作業します。
イテレーションを使用しなくても、リリースNとN + 1の作業をオーバーラップできるため、これは問題ありません。しかし、私が理解していることから、これはスクラムやXPなどの反復ベースのアプローチと互換性がありません。彼らは、すべてのテスト作業をイテレーションに組み込むために、イテレーションが最後にリリース可能であることを要求します。
これは必然的に次の望ましくない結果の1つにつながることがわかりました。
（A） QAはリリース候補を確認するための時間を必要とし、バグ修正作業が開発者を忙しくしていないため、開発者はイテレーションの最後でアイドル状態です。
（B）最初のリリース候補の準備ができる前に、QAはすでに機能し始めています。これは、Stack Exchangeで主に推奨されるものです。しかし、テストされた特定のリリース候補がないため、QAとして私の会社が理解していることではありません。そして、すべてを壊す「小さな変化」は、気付かれないまま導入される可能性があります。
（C）バグは次の反復に持ち越されます。これはStack Exchangeでも推奨されます。それが解決策になるとはまったく思いません。バグ修正が行われるたびに、検証されていない新しいコミットも同じブランチに追加されるため、基本的には検証済みビルドが取得されないことを意味します。
このジレンマから抜け出す方法はありますか？
QAは、特定のビルド（リリース候補）がこのビルドが顧客にデプロイされる前の追加の検証であると理解しています。
この形式のQAとスクラムのような反復ベースの方法論の間に本質的に互換性はありません。
チームはスクラム内で、X週間のサイクルで成果物を顧客に提供します。ここで重要なのは、開発チームがスクラムを実行している場合、その顧客はQAチームであり、製品のエンドユーザーではないということです。
開発者として、すべてのテストに合格する可能性がある場合、QAに出荷可能な製品を検討します。これはおそらく、QAテストの一部がすでに毎日のビルドで実行されていることを意味しますが、QAチームによる公式のリリーステストにどのように影響するかは、組織次第です。
ほとんどの実際の状況では、アジャイルはQA/UATまたはそれが呼び出されたものへの配信時に停止します。
実際の環境でQAから本番環境に移行する取り組みは、過小評価されていることがよくあります。多くの場合、これには実際のビジネスユーザーのテスト、管理者による実際のビジネスマネージャーからの承認、運用によるリリースのスケジュール設定などが含まれます。これは簡単なことではありません。
極端な場合、ソフトウェアは外部機関による認定が必要になるか、または厳格なセキュリティテストの対象となる場合があります。
このような状況では、バグ修正を除いて、四半期ごとに複数のリリースを想定することは不可能です。
深刻なソフトウェア製品ではさらに悪化します。文書は証明され、公開される必要があります。マーケティングパンフレットを修正する必要があります。営業担当者は、何を売っているのか（簡単な作業ではありません）などを伝える必要があります。1年に1回以上、これをビジネスに利用したくない場合があります。
非常に短期的な解決策は、テストを完了するための反復の後、QAに追加の期間を与えることです。すなわち。 2週間の反復がある場合は、第3週までリリースしないでください。とにかく、最初の週の間に、QAは次の反復に向けてテストするものは何もありません。
しかし、何が起こるかを前もって警告します（これをいくつかのチームで見た場合）：1反復で2週間の作業が完了し、QAが過負荷になり、そのために彼らがあなたのところにやって来るという状況になりますQA週全体、および次の反復では、1週間の作業のみが完了します。その反復では、QAは何もする必要がなく、問題を解決したと思います。ただし、次の反復ではサイクルを再び開始します。
したがって、その週に追加したらすぐに、リリースが安定していることを確認するために（私が学んだことの1つは、ビジネスの信頼を失うと、アジャイルは指数関数的に実装が難しくなるためです）、まっすぐに進みます長期計画に。
Jez Humbleの Continuous Deliveryのコピーを購入し、読み、カバーツーカバーで、チームに渡します。みんなに刺激を与えましょう。次に、そこから可能な限りすべてを実装します。
できる限りビルドプロセスをスムーズにします。単体テストポリシーを実装し、すべてのビルドでそれらを実行します。導入プロセスを今まで見た中で最も洗練されたものにします。 3クリック？十分に滑らかではありません。
これがすべて完了したら、時折回帰バグが発生してもそれほど問題になりません。あなたが理由を知っている？ビジネスが崩壊する前に、（オプションで）ロールバック、修正、再デプロイが可能になるためです。実際、夜の管理人があなたのためにロールバックできるようになり、プロセスはとても簡単になります。
私はあなたが何を考えているのか知っています：私たちはそれをすべて行う時間はありません。教えてあげましょう。 QAを過負荷にしている場合は、反復ごとにデプロイしすぎています。そうしないでください。まだオーバーロードしていない場合は、なぜ自動テストスイートがまだないのか尋ねてください。あなたはすぐになります。
これらすべてを、ビジネスを完全に可視化して実行します。見積もりを低くして、この作業の一部を反復に注入します。または、さらに良いことに、それをストーリーに分割し、他のすべてのものと一緒に優先順位を付けます。
A）リリースの安定性が向上し、b）問題に対する対応能力が向上すること、およびc）後で速度が上がることを説明します。これらを望まない珍しい会社です。それを望まないのは確かにアジャイル企業ではないので、抵抗を受けると、別の問題があることがわかります。
継続的デリバリーが順調に進んだら、反復の最後にQAが取得する時間の短縮を開始できます。できるだけ早く反復を並列に戻すことは、すべての人の利益になります。たぶん、反復の最後に1日あり、そこで時間を記入する必要があります。 私はすでに他の場所で何をすべきかについて答えました 。
イテレーションを使用しなくても、リリースNとN + 1の作業をオーバーラップできるため、これは問題ありません。
work for release Nを正確に構成するものを決定する方法に問題があるようです。
なんらかの奇妙な理由で（特定のアジャイルレシピの誤解があると推測できます）、アジャイルアプローチにすべてのQAチームの取り組みを組み込むことを義務付け反復。
- それが本当だとしたら、アジャイルの人気は今見ているものにさえ近づかないと思います。開発チームのイテレーションとQAテストサイクルの必須の同期を「生き残る」ことができる多くのプロジェクトを想像することはできません。
agilityについてはもう少し詳しく説明しますが、最初にwork for release N...を整理しましょう。
見て、開発チームが仕事をそのように定義するための説得力のある理由はありません。まったく反対ですが、あなたの説明から、モノリシックな「作業単位」の代わりに、感じやすいマイルストーンを備えたそのようなユニットがいくつかあることは明らかです...
- たとえば、最初の「ユニット」はcandidate buildがテスターに渡されたときに明確なマイルストーンで示され、それ以降のマイルストーンはQAなどによって実行されるテストサイクルに関連する変更に対応します。
work for release Nの定義方法も、QAワークフローによって強制されないことに注意してください。あなたが言うことから、物事は彼ら自身の（そしてかなり合理的な）スケジュールを持っているように見えます。
上記の場合、ケースで作業単位を定義するより現実的な方法は次のようになります。
- ビルドがQAに渡されるまでの開発活動
Release Candidate N - 最初のQAテストサイクルに関連する開発アクティビティ
Release Candidate N patch 1 - 2番目のQAテストサイクルに関連する開発アクティビティ
Release Candidate N patch 2 - など、最終ビルドまで
上記は、アジャイルを実行するかどうかに関係なく、ワークユニットです。
これらは自然で、便利で定義、追跡、追跡できます。これはQAスケジュールとも調和し、ODF開発者とQA作業の調整を便利にします。
しかし、私が理解していることから、これはスクラムやXPなどの反復ベースのアプローチと互換性がありません。彼らは、すべてのテスト作業をイテレーションに組み込むために、イテレーションが最後にリリース可能であることを要求します。
アジャイルとの互換性の理解の上では、根本的に間違っているように見え、ここに理由があります...
あなたが作った仮定はアジャイルとは何の関係もありません。 哲学 をその名前で示されている額面で取ると、それは好意的で実践的なアプローチです敏捷性。
その観点から、特定の「固定」ワークフローにこだわり、それが便利かどうかを無視することは、アジャイルの精神に反するだけです。怠惰に「手順」に従うと、プラクティスにつながります denigrated 雄弁に Half-Arsed Agile Manifesto"...これらを制御するための必須のプロセスとツールがあります個人（「リソース」という用語を好む）は相互作用する]。
これについて詳しくは、以下に引用されている 別の質問への回答 を参照してください。 「出荷可能なリリース」に関するメモを見てください。OPは同じように混乱しています。
agileは、アジャイル原則の非常に適用についてです。つまり、プロジェクトの要件がアジャイルではない（安定しているか、ゆっくりと変化している）場合は、なぜ煩わしいのでしょうか。私はかつて、トップマネジメントがなくても完璧にうまくいっていたプロジェクトでスクラムを強制することを観察しました。なんて無駄なことだった。配信に改善がなかっただけでなく、さらに悪いことに、開発者とテスターはすべて不満になりました。
私にとって、アジャイルの最も重要な部分の1つは、各スプリントの最後に出荷可能なリリースがあることです。それはいくつかのことを意味します。最初に、ビルドを顧客にリリースできると思われる場合は、バグを表示しないように、ある程度のテストを行う必要があります...
出荷可能リリースなるほど。うーん。うーん。アジャイルカクテルに Lean を1ショットまたは2ショット追加することを検討してください。つまり、これが顧客/市場のニーズではない場合、これはリソースの（テスト）の浪費のみを意味します。
私は、Sprint-end-releaseをチームを満足させるcheckpointとして扱うことに犯罪者は何も見ていません。
- dev：ええ、テスターに渡すには十分によく見えます。 QA：そうです、さらに出荷可能なテストが必要な場合、ケースには十分に見えます-そのようなもの。チーム（開発+ QA）は満足です、それだけです。