スプリント間のバージョン番号
私の質問は、ブランチ、バージョニング、アジャイル開発全般について少しですが、3つすべての中心は私が思うバージョン番号です。
現在、私は内部バージョン番号（例えば1.0.4）を使用しています。これは、QAが取得するものでもあります。しかし、修正プログラムが必要な場合はどうでしょうか。 3番目の番号は既に使用されているため、もう使用できません。だから私は別のメカニズムが必要です。しかし、どのように各スプリントにブランチをタグ付けまたは作成しますか？使用しているバージョンは何ですか？
QAには複製可能なバージョン番号/ブランチ/タグが必要ですが、必要に応じて同じバージョンでバグ修正する必要もあります。お客様には内部バージョン番号が表示されないはずです。代わりに、彼は例えば1.1。
2番目の問題は、スプリント間の待機時間を防ぐ方法です。例えば。開発者はすでに終了していますが、QAはまだテスト中です。開発者は次のスプリントのタスクから始めますか？または、開発者とテスターがすでに作業を終えている場合はどうなりますか。彼らは次のスプリントの開始を1週間待つべきではありません。または、1つのスプリントまたはそのバグ修正で機能を完了できない場合...
継続的なテストとスプリントでの作業リリースの作成は、アジャイル開発の要件ですか？テスターが入手できるのはビルド番号だけですか？ Jenkinsは最後の5つのビルドのみを保存するため、ビルド番号を使用できません（後で何らかの形でタグ付けされている場合を除いて、このバージョンを復元することはできません）。代わりにコミットIDを使用する必要がありますか？また、QAにバグ修正バージョンを提供する場合、新機能を追加する必要はありません。
そのためにリリース候補の概念を使用しました。
QAに向けてリリースする一連の成果物ごとに固有のバージョン番号が必要だと思います。例を見てみましょう：
スプリント5を開始します。スプリント5で作業しているバージョンは1.0.0です。このリリースは機能リリースであると想定しているため、スプリント5以降のソフトウェアのバージョンは1.1.0になります。したがって、チームは現在1.1.0-RC1に取り組んでいます。
チームはスプリント5の最後のストーリーを終了します。そのコミット/リビジョンにバージョン1.1.0-RC1を割り当てます。 1.1.0-RC1の成果物はQAに送られ、スプリント5の残り2日以内に修正できる3つのバグが返されます。
ただし、他のチームメンバーはすでにスプリント6の作業を開始しています。ここに新しいVCSブランチが必要です！ sprint 6が別の機能リリースになることを期待しているため、sprint 6はバージョン1.2.0;を生成します。したがって、これらのチームメンバーは1.2.0-RC1に取り組んでいます。
バグ修正（1.1.0-RC1のテストの結果）は別のブランチで行う必要があります。それらが入るバージョンは1.1.0-RC2です。
1.1.0-RC2の作業が完了します（つまり、すべての既知の問題が修正されます）。 1.1.0-RC2の成果物はQAに合格しています。 VCSの1.1.0-RC2と同じコミット（またはバージョン管理下のバージョン番号を保持している場合は新しいコミット）は1.1.0になります。そのバージョンは、顧客/エンドユーザーに対して使用するものです。
基本的に、QAが成果物に満足するまで-RC数を増やし続けます。最新のRCは、-RCサフィックスなしで出荷できる同じコードバージョンです。
スプリントに10以上のRCが必要な場合（これは許可されません。私に尋ねるとバグが多すぎます）、RC番号の先頭に0を使用する必要があります。これにより、バージョン番号が時系列に並べ替えられます。 1.1.0-RC01から1.1.0-RC26まで。
スプリントの作業をエンドユーザーにリリースしない場合については、リリースするかのようにバージョン管理を続けます。もちろん、これは公開バージョン履歴にギャップを作りますが、それは完全に私見です。
経営陣が一貫した公開バージョン番号を望んでいる場合でも、繰り返しごとにリリースしたかのように、バージョンにラベルを付け続けます。多分-INTサフィックスを付けます。同時に、内部バージョンと公開バージョンのマッピングを維持します。ややこのような：
o @1.1.0-INT @1.1.0
|
...
|
o @1.2.0-INT
|
...
|
o @1.3.0-INT
...
|
o @1.4.0-INT @1.2.0
もしそのルートを選択する場合は、関係するすべての人（開発チーム、管理、サポートスタッフ、マーケティング担当者など）が認識していることを確認してくださいこれを理解し、必要に応じて内部<->外部マッピングを検索する方法を知っています。そうでなければ、あなたは想像できるでしょう...
分岐について
RC2をRC1から分岐し、メインブランチで1.2.0を続行することを強くお勧めします（gitフローのdevelopなど）。 1.1.0がQAに合格すると、それをmainブランチにマージできます。以下は、上記のgitフローを実装する方法を示すgitグラフの束です。
1.1.0のすべてのストーリーが完了しました。開発のヘッドに1.1.0-RC1でタグ付けします。 1.2.0の作業は開発中です
o branch develop @1.0.0
|
... implement stuff
|
o @1.1.0-RC1
|
o
|
o
1.1.0-RC1のQA結果が出たら、1.1.0-RC2に分岐します。その後、作業を並行して続行できます。 1.1.0の最後のRCをメインブランチにマージして、そのQAに合格したら（または、別の緊急の必要がある場合はより簡単に）できます。
o @1.0.0
|
...
|
o @1.1.0-RC1
|\
o o branch release/1.1.0-RC2
| |
o o
| |
o o @1.1.0-RC2 @1.1.0
|/
o merge release/1.1.0-RC2 into develop
|
o @1.2.0-RC1
Gitフローでは、realease/*ブランチのバージョンにタグを付けるのではなく、masterにマージして、1.1.0でコミットするタグを付けます。
ほとんどの質問はスプリントプロセスに送られます。チームの入力を使用して、チームのこれを定義するかどうかは、スクラムマスター次第です。
しかし、どのように各スプリントにブランチをタグ付けまたは作成しますか？
これは非常に多様で、私が使用したアプローチの1つは、安定したメイン（ここではGitと対話）からPBIごとに分岐し、メインにブランチポリシーを設定して、不安定になるのを防ぐことです。次に、PBIがDoneになったときに、PBIに群がり、PRをメインに戻します。これは、一度に数個のPBIしか開いていないことを意味します（6 + 3人の「標準」スクラムチームサイズに基づく）。重要な要素は、PBIを小さく保つことです。メインへ/から。
使用しているバージョンは何ですか？
通常、使用されているビルドシステムからのビルド番号。ビルド/リリース/デプロイパイプライン内で必要な場合は、公開バージョン番号にもタグを付けます。ビルドシステムは通常、高度に構成可能です。私はJenkinsを使用していませんが、高度な自動化を維持しながら、ニーズに合わせてカスタマイズできます。
スプリント間の待ち時間を防ぐ方法
これは直接処理されます。両方の役割の開発とテストの間に大きな遅れがないようにするには（これは2つの異なるチームであるとは言いません）、同時にPBIに群がる必要があります。テストは開発ですが、テストと開発のアーティファクトは、PBIがDoDを満たし、Doneであることの条件です。これは、最終的には自動テストによって決定されます...その他の手動による考慮事項。最終的に、スプリント内で行われるPBIは、そのスプリントの最後にshippableになるはずです。これは、それらを出荷しているという意味ではありませんが、できるはずです。テスト（テストを作成し、その出力をすぐに利用できるようにする行為）がプロセスの第一級市民として扱われない場合、スプリントはめったに終了しません。今後のスプリントでこのスプリントが達成されたことをテストしている場合、両方のスプリントが壊れています。
継続的なテストとスプリントでの作業リリースの作成は、アジャイル開発の要件ですか？
いいえ。ただし、顧客第一、自動化第一の戦略を開発に取り入れれば、人生ははるかに快適になります。 1つ目は要件に焦点を当て、2つ目はそれらの要件をより速く提供することに焦点を当てています...関係者による検証のために。
継続的なテストは、RCの爆発的な増加を防ぐのに役立ちます。テスト（およびフェイルファスト）すると、同じスプリント中にチームが現在のスプリント（PBI実装から）内に作成したすべての欠陥に対処できます。欠陥が解決されるまで。いくつかの欠陥は、新しい実装が他の（または同じ）領域の「古い」欠陥を発見したことであり、修正または優先順位付けの決定のためにPOおよびSMにすぐに持ち込まれる必要があります。理想的には（常にではありませんが）、スプリントの前のPBI設計および計画段階でこれを明らかにすることを望みます...もちろん、それは常に起こるとは限りません。
テスターが入手できるのはビルド番号だけですか？
これは、何かをコーディングしてからフェンスを越えてテスターに投げたいように思えます。これが事実である場合、あなたはあなたの戦略を再考したいかもしれません（そしてあなたのSMとこれを話し合ってください）。テストを作成する開発者は、機能実装を作成する開発者と緊密に連携している必要があります。また、（可能な場合は）同じ部屋で互いに緊密に連携している必要があります。
TDD：テストが記述され、VCSにプッシュされ、開発者がテストをプルし、コードを記述し、PCとビルドサーバーの両方でテストを実行して、コードをプッシュします。
NON TDD：TDDと同じですが、テストが最初に書き込まれない場合があります。
どちらの場合も、テスト開発者、実装開発者、およびビルドサーバーはすべて、いつでもテストを実行し、要件を検証できる必要があります。PBIは、これがすべて調和するまで完了とマークされません。
チームが地理的に配置されている場合は、次のような条件に基づいてチームメンバーへの電子メールを自動化するようにパイプラインを設定できます。ビルドが失敗し、私が取り組んでいるPBIにリンクされたコードがコミットされました。
開発者は次のスプリントのタスクから始めますか？
POとSMでこれをクリアすることなしではありません。理想的には、常に何かすることがあります。ログのチェック、クリーンアップ、ドキュメントの校正。これらすべてが面白すぎたり、時間を割いて予備のジョブを実行したりする場合は、通常、PBIをチームが決定した現在のスプリントにドラッグします。理想的には、その中でDoneあなたがスプリントを壊していないようにスプリント。チームが「開発者」と「テスター」の観点から考える場合は、「開発者」にいつでも「テスター」がテストを作成して検証するのを手伝ってもらうことができます。
バグ修正については、これもさまざまな方法で処理できます。 1つの方法は、PBIとすでに優先順位付けされたバグの実装で「通常の」スプリントを実行させることです。次に、計画中にバグ/欠陥がトリアージされ、今後のスプリントのバックログに優先順位が付けられます。バグのトリアージは、カンバンを使用して行うことができ、別のチームにこのタスクを実行させるか（多数のバグがある場合）、または1人（またはそれ以上）のメンバーをスプリントからローテーションしてカンバンを実行し、全員に与えることができます。残りの彼の自然な生活のためにバグ修正を行う1つの貧しい唯一の代わりにかんばんをオンにします。
バグは、何かを修正するのに必要な時間を常に見積もることができるわけではなく、調査に深く首を突っ込んだら、同じように続行しやすいので、カンバンに適しています。修正を簡単に特定できるバグや優先順位を簡単に設定できるバグは、優先度の高いEBFの場合はすぐに取得するか、または優先度の低い場合はバックログに残して、簡単な調査またはほぼゼロの調査が必要です。
EBF（Emergency Bug Fix）は、安定したメインから分岐し、PRしてメインASAPに戻す必要があります。これにより、コードの同じ領域にある可能性がある開発中のPBIのマージ競合を最小限に抑えることができます。
@marstatoがRCの説明に私を打ち負かしたので、ここでは触れません。
お役に立てば幸いです。
このルールを変更できれば、問題はすべて解消されます。
お客様には内部バージョン番号が表示されないはずです。代わりに、彼は例えば1.1。
GitFlowを使用します。リリースブランチはQAに進み、4番目（Appleの3番目）のバージョン番号がホットフィックスに使用されます。つまり1.1.5677
QAのサインオフ後に、バイナリを後処理して顧客のバージョンを変更できますか？