web-dev-qa-db-ja.com

JiraおよびGreenhopperのスプリントバージョンとリリースバージョン

GreenhopperをJiraで使用する場合、GreenhopperがJiraの問題の「修正済みバージョン」フィールドを使用して、問題が処理されているスクラムスプリントを表すことは明らかです。これ自体は少しハックです。問題は複数のスプリントで処理される可能性があり、問題とスプリントの関係は、スプリント中に作業済みであるためです。計画された時間内にタスクを完了できない可能性があるという認識。

しかし、少なくとも、「バージョンで修正済み」フィールドを他の目的で使用しようとするものが他にない場合は、それは生きていくことができるハックかもしれません。

しかし、「バージョンで修正済み」フィールドに基づく他の懸念もあることがわかりました。具体的には、どの問題が計画どの問題に対処するかリリースバージョン（実際のバージョン）を確認し、この情報を検証の手段として使用できる必要があります。/QA。

他のGreenhopperユーザーは、「バージョンで修正済み」フィールドのこれら2つの使用法をどのように組み合わせていますか？スプリントバージョンをリリースバージョンのサブバージョンとして設定していますか？リリースバージョンにカスタムフィールドを使用していますか？スクラムチームは独立してバージョン管理された複数のコンポーネントに取り組んでいるため、これは難しいと感じています。また、同じスプリントで発生する、同じコンポーネントでのバグ修正リリースと機能開発がある可能性があります。

要約すると、チームが同じスプリント内で「Some Product 3.4.0」（機能リリース）、「Some Product 3.3.1」（バグ修正リリース）、および「OtherProduct1.2」に取り組むことは避けられないと思います。 。このスプリントを、これら3つのバージョン（2つの異なるコンポーネント間）のそれぞれのサブバージョンとしてマークすることはできません。そして、Greenhopperで3つの異なるスプリントを作成すると、Greenhopperの価値が実際に薄れてしまいます。

他のGreenhopperユーザーも同じ状況にありますか？どのように対処しましたか？

project-managementscrumjiragreenhopper
20
harms

ここでは2つの問題が発生しています。

まず、スプリントバージョンは、実際にはリリースバージョンの「サブバージョン」です。これは、ストーリーが実際にfixVersionフィールドに2つの値を取得することを意味します。

マスターバージョンを設定することにより、Greenhopperでこれを構成できます。

したがって、バージョン1.0の3つのスプリントリリースがある場合は、リリース日を1.0に設定し、ストーリーをスプリント1、スプリント2、およびスプリント3に配置します。

  • 1.0
    • スプリント1
    • スプリント2
    • スプリント3
  • 1.1
    • .。

Sprint 1でSTORY-1をプレイすると、STORY-1のfixVersionが「1.0、Sprint1」になることがわかります。

リリースを追跡しているがスプリントではないアイテムの場合は、fixVersionを1.0に設定するだけです。

次に（これは単なるヒントです）、スプリント作業と制作サポート作業に別々のプロジェクトを使用できます。これは大規模な組織で役立ちます

13
mistermadpit

さまざまな組織で同じ問題に直面しています。チームは複数のリリースに取り組んでいるだけでなく（例で詳しく説明しているように）、顧客の問題が発生した場合やサポート組織の支援にチームが関与している場合もあります。以前のリリースのユーザー受け入れテストの場合、「すぐに対処する必要がある」問題を示します。

そのため、課題をタスクから分離し、JIRAの「課題リンク」機能を使用してリンクするという概念を導入しました。問題（または私たちがそれらと呼ぶ仕様）はリリースプロジェクトで管理され、タスクはチームプロジェクトで管理されます。

リリースプロジェクトのバージョン管理はリリースを示します（つまり、2.2-patch1、1.1 ...）チームプロジェクトのバージョン管理はスプリントを示します（スプリント10-15、スプリント10-20）

リリースプロジェクトには、バグ、機能のリクエスト、問い合わせのみが含まれます。チームプロジェクトには、タスク、ストーリー、...のみが含まれます。

自動化により、仕様と関連タスクの同期を維持できます。一般的なシナリオは次のように実行されます。

  • 仕様はリリースプロジェクトで作成されます。
  • サポート担当者は、チームプロジェクトで1つ以上のタスクを作成し、「実装者」リンクを使用して仕様をタスクにリンクします。
  • タスクの作業が開始された瞬間から、仕様は「開発中」の状態に進みます。
  • 関連するすべてのタスクが解決されると、仕様は解決されたと見なされます

仕様の遷移は自動的にトリガーされます。仕様とタスクを分離するというこの概念により、次のような多くの異なるプロジェクト組織をサポートできます。

  • 多数のスプリントで開発する必要がある叙事詩。
  • さまざまな場所にいる複数のチームが対処する必要のある問題
  • 新製品に取り組み、古いものを維持するチーム。

興味があれば、このテーマに関する詳細情報を提供できます。

フランシス・マルテンス

6
Francis Martens

私も同じ問題に悩まされており、jira/greenhopperの機能リクエストで、スプリントの新しいフィールドを追加して、スプリントの追跡とバージョン情報のリリースを個別に行えるようにする必要があることがわかりました。

これが私と同じように現実になるのを見たい場合は、 http://jira.atlassian.com/browse/GHS-945 にアクセスして問題に投票してください。この引用はそれを要約します： "GreenHopperが一級市民として反復を持っていた場合..."

ただし、現時点では、jiraでversionsという新しいフィールドを作成し、それを使用して、問題に関連する「実際の製品バージョン」を追跡する必要がある可能性があります。ソースコードリポジトリにもコミットフックがあるため、開発者がコミットすると、コミットしているソースコードに関連する「実際の製品バージョン」でjiraチケットが更新されます。この情報を構成ファイルに保存して、コミットフックがどのバージョンをどのソースコードリポジトリ/パスに使用するかを認識できるようにします。これは理想的ではありませんが、現時点では唯一の選択肢です。

5
AlexS

GreenHopperでラピッドボードを使用するだけです。それほど前に導入されたわけではありませんが、必要なものはほぼすべて揃っています。

たとえば、「sprint-1」、「sprint-2」などの問題に[〜＃〜] labels [〜＃〜]を付けることができます。次に、問題を作成します[〜＃〜] filter [〜＃〜]。次に、フィルターに基づいてRAPID BOARDを作成します。最後に、sprint-X バージョンやプロジェクトに関係なくの現在の問題を含むNiceボードを入手します。

Sprintが本質的にソフトウェアのバージョンではないことを確認してください。現実の世界では、複数の顧客がいる場合、多くのバージョンを修正してサポートする必要がありますが、それでもすべてを順調に進める必要があります。この場合、スプリントはまだ素晴らしいですが、それらは期間中に実行されるべき仕事の量を表しているにすぎません。とにかく、バージョンはあなたがあなたの開発時間外に誰かに提示するものです。したがって、ソフトウェアとスプリントのバージョンを混在させないでください（時間とタスクの間の「マッピング」）。スプリントバージョンが実際のソフトウェアバージョンの子である階層は使用しないでください。無関係なものを分離してください!!!

3
ruruskyi

スプリントは理論的には最後に「出荷可能な」製品を持つべきではありませんか？つまり、スプリントには問題が解決されているか、「失敗」しているということです。そのため、問題を細かく分割することをお勧めします。

1
Stefan Ernst

K.I.S.Sを使おうとしています可能な限り、リリースをマークするためにラベルフィールドを使用しています。スクラム/タスクボードのコンテキストでリリースを確認する必要はめったにありません。そのため、リリース内のすべてのアイテムを表示するときは、リリース名を検索するだけです。

0
Jody