問題タブ [greenhopper]

私たちはバグ追跡とリリース管理に JIRA を使用し、JIRA 内のプロジェクト管理に greenhopper を使い始めましたが、ユーザー ストーリーとそれらのユーザー ストーリー内のタスクの考え方が欠けています。ユーザーのストーリーとタスクを完全にサポートし、ユーザーにとって高速でシンプルなアジャイル プロジェクト管理ツールのような他のタスク ボードを推奨する人はいますか? 私は targetprocess を調べ始めたので、特にそれについてフィードバックがあれば、それも素晴らしいでしょう。

誰かがアジャイルを行おうとしている場合、私はこれに JIRA / Greenhopper を使用する方法を見つけようとしています。私たちはグローバルな開発チームであるため、ここでは分散型の性質が非常に重要です。

当初はスクラムワークスを使用していましたが、チームは、JIRA とスクラムワークスに常に重複した情報があり、冗長であると考えていると不満を漏らしていました。

私たちは Greenhopper を手に入れ、それで問題が解決すると考えましたが、これに関して私が抱えている問題は次のとおりです。

1. JIRA にユーザー ストーリーの概念がない
2. Greenhopper も、ユーザー ストーリー レベルでの集計なしで「タスク」に焦点を当てています。

JIRA でこれを成功させた人はいますか、それともスクラムワークなどの他のツールに戻って、サポート チームが提起したバグに JIRA を使用することを検討する必要があります。

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 ユーザーは同じ状況ですか? どのように対処しましたか？

私は Jira を使用していますが、システム管理者から GreenHopper がインストールされていると言われました。

ただし、GreenHopper がインストールされているという証拠はありません。

GreenHopper がインストールされているかどうかを判断する簡単な方法はありますか?

私は、当社の Jira 実装の管理タスクを与えられています。役に立たない前の人からの引き継ぎはありません。

前の人は、タスク ボードに 4 つの列を持っていました。

1. すること
2. 進行中
3. 検証します
4. 終わり

ここで、「To Do」と「In Progress」の間に別の列を追加する必要がありますが、その方法について途方に暮れています。

これを行うと、ワークフローが台無しになる可能性があるため、注意するように言われました。これが、私がこの質問のためにここに来る理由です。

どんな助けでも大歓迎です。

デプロイ/変更管理にも JIRA と GH の使用を開始したいと考えています。タスク/ストーリーの提案されたワークフローは次のとおりです:
バックログ -> オープン (スプリントに追加) -> 進行中 (コーディング) -> 解決済み (コードがコミットされ、作業が完了) -> 変更を要求する (Issue RFC を作成する) -x (スプリントの問題のグループを含む) ->

ここから、この RFC-x を新しいワークフローで追跡します。
テスト システム内 -> テスト中 -> QA による検証 -> 経営陣による承認 -> 本番環境への展開 -> エンド ユーザーによる検証

1 つのスプリントまたはバージョンの問題のグループを問題と簡単にリンクする方法はありますか?

サブタスクを 2 つの異なるユーザー ストーリーにリンクできるようにしたいと考えています。設定画面で簡単に利用できるそのようなオプションを見つけることができませんでした..
何かアイデアはありますか?

グリーンホッパーのリストビューにもっとアイテムを表示したい。叙事詩や物語など（そして物語を叙事詩に折りたたむことができない）では、整理すべきアイテムがたくさんあります。ページ間をドラッグできないように見えるので、ページにもっと多くのアイテムを表示したいと思います。それを設定する方法が見つかりません。誰か知ってる？

グリーンホッパー ビューに表示されるカードをエピックに限定したいと考えています。これは可能ですか？

合流スイートがあります。

これを使用して、どのクラスが変更されたかを強調したレポートを作成できますか?

SVN + JIRA 参照を介して GreenHopper にリンクされた JIRA アイテムは、まさに私が必要とするタイプの情報です。

そのようなレポート テンプレートは存在しますか?