JIra + Greenhopper-アジャイルを正しく行う方法
JIRA + Greenhopperのアジャイルフローは初めてです。 JIRA + GHでアジャイルを操作するための正しい/より良い方法を理解しようとしています。私はいくつかの情報をネットで読んだことがあります-これまでのところ、ストーリーとエピック（大きなストーリー）があることを理解しています。タスクを作成するフローは何か知りたいと思いました。
- まず、ストーリー/エピックを開き、非技術的なテキストで定義します。
- ストーリーのサブタスクを作成できます（技術サブタスクは現在しかありません）。
- ストーリーを開いた後-開発のために、新しいチケット（バグ/新機能/タスクなど）が作成され、ISSUELINKINGを使用してストーリーにリンクされます。
これは正しいフローですか？私の質問は次のとおりです。
- （2）で、開発チケットを個別に開いてそれらをリンクする場合、技術的な問題のサブタスクを開く必要がある理由がわかりません。ストーリーのサブタスクの目的は何ですか？
- GHから直接開発チケットを作成するためのより良い/簡単な方法はありますか？または、それらを個別に開いて、ストーリーの親の問題にリンクする必要がありますか？
迅速な対応ありがとうございました。
これまでの使用方法は次のとおりです。
- 機能リクエストを定義するストーリーを作成します（あなたの言葉での非技術的なタスク）
イテレーションを計画するときは、達成したいストーリーに優先順位を付けます。チームはストーリーごとに、ストーリーの作成方法に関するタスク（サブタスク）を作成します。これらのタスクは、実行する特定の作業です。データベーステーブルの作成、コントローラーコードの変更、機能のQA、公開ドキュメントの更新など。タスクを実行する人と時間通りに彼らの見積もりと一緒に。
反復が進むにつれて、各チームメンバーは、各タスクで行われた作業をログに記録し、より多くの情報があるため、タスクの見積もりを調整します。タスクが完了すると、タスクは閉じられます。すべてのタスクが完了すると、ストーリーを展開する準備が整います。
また、サブタスクを作成しているときに、歯車の下のカードビューからサブタスクの追加を選択すると、タスクのアイテムを入力するためのカードが表示されます（カードの作成と同様）。完了するまでサブタスクカードを作成し続けることができます。私たちの意見では、タスクを入力するための非常に迅速で簡単な方法です。
うまくいけば、これが役立つでしょう。ご不明な点がある場合や、その他の詳細が必要な場合はお知らせください。
フローはチームごとに異なることに注意することが重要だと思います。
たとえば、一部のチームには、Epicから始めて、それをストーリーに分解し、受け入れ基準/成功の条件を追加する製品所有者がいます。多くの場合、このシナリオでは、チームは計画セッションに集まり、それらのストーリーをサブタスクに分解します。
一部のチームはストーリーにストーリーポイントの見積もり（通常はフィボナッチ）を与え、他のチームはサブタスクに1時間の見積もりを割り当てます。 1時間の見積もりを割り当てる場合、チームは進行に応じて残りの見積もりを更新することがよくあります。これにより、時間バーンダウンチャートでスプリントの進行状況がわかりやすくなります。
また、製品の所有者が多くのストーリーを作成し、後でそれらを手動でエピックに集約するチームを見てきました。私が好ましい方法を持っていれば、それは簡単にするための最初のアプローチですが、見逃されたり忘れられたりして、計画セッション中に追加されるストーリーが必ずあります。
エピックは通常、複数のスプリントバックログにまたがるため、リリースバックログ以外のものにスケジュールされます。スプリントとリリースの両方がJIRAの修正バージョンとして処理され、親/子バックログのネストは、計画されているものに関する視覚化を提供するのに役立ちます。
これはスクラム用です。かんばんに興味がある場合は、そのシナリオでチームが行っていることを共有できます。Wordとだけ言ってください。
乾杯、ニコラス・マルドゥーン