20

Greenhopper を Jira で使用する場合、Greenhopper が Jira 課題の「fixed in version」フィールドを使用して、課題がどのスクラム スプリントに取り組んでいるかを表していることは明らかです。課題はおそらく複数のスプリントで取り組まれる可能性があり、課題とスプリントの関係はまさにスプリント中に取り組まれているということなので、これ自体は少しハックです。予定時間内のタスク。

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

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

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

要約すると、チームが同じスプリント内で「一部の製品 3.4.0」(機能リリース)、「一部の製品 3.3.1」(バグ修正リリース)、および「その他の製品 1.2」に取り組むことは避けられないと思います。 . このスプリントを、これら 3 つのバージョンのそれぞれのサブバージョン (2 つの異なるコンポーネントにわたる) としてマークすることはできません。また、Greenhopper で 3 つの異なるスプリントを作成すると、Greenhopper の価値が大幅に低下します。

他の Greenhopper ユーザーは同じ状況ですか? どのように対処しましたか？

4

6 に答える 6

13

ここには 2 つの問題があります。

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

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

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

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

スプリント 1 で STORY-1 をプレイすると、STORY-1 の fixVersion が "1.0, Sprint 1" になることがわかります。

リリースを追跡しているが、スプリントでは追跡していない項目については、単純に fixVersion を 1.0 に設定します。

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

于 2011-09-29T01:04:45.570 に答える
6

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

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

リリース プロジェクトのバージョニングは、リリース (つまり、2.2-patch1、1.1 ...) を示します。チーム プロジェクトのバージョニングは、スプリント (スプリント 10-15、スプリント 10-20) を示します。

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

自動化により、仕様と関連タスクを同期させることができます。典型的なシナリオは次のように実行されます

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

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

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

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

フランシス・マルテンス

于 2010-07-09T07:06:34.593 に答える
5

私も同じ問題に悩まされており、jira/greenhopper でスプリント用の新しいフィールドを追加して、スプリントとリリースのバージョン情報を個別に追跡できるようにする機能リクエストを見つけました。

私と同じようにこれが実現するのを見たい場合は、http://jira.atlassian.com/browse/GHS-945にアクセスして、問題に投票してください。この引用は次のように要約されています。

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

于 2010-08-10T10:07:28.067 に答える
3

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

たとえば、'sprint-1'、'sprint-2' などのように、課題にLABELSを付けることができます。次に問題FILTERを作成します。次に、フィルターに基づいてRAPID BOARDを作成します。最後に、バージョンやプロジェクトに関係なく、sprint-X の現在の問題を含む素敵なボードを取得します。

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

于 2011-12-20T15:43:35.850 に答える
1

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

于 2010-07-08T05:36:44.257 に答える
0

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

于 2011-09-29T12:13:40.900 に答える