Help us understand the problem. What is going on with this article?

今年JIRAを使ってみて得たノウハウまとめ

More than 1 year has passed since last update.

何が書いてあるか

かねてから開発プロジェクト管理にBacklog(ツール)を使っていましたが、今年の4月よりJIRAへ移行することが決まりました。
それから試験運用をスタートし、現在は通常の開発で運用出来るようになったので、試行錯誤したJIRA活用ノウハウを整理しました。

会社の状況

ざっくりですが前提となる状況について書きます。

  • 開発の案件には大きく分けて3種類ある
    • 通年で戦略的に計画されている比較的大きめな開発案件
    • 週次で起案されるアジャイル的に進める案件
    • 日々の問い合わせから起案される不具合修正などの案件
  • 開発チームは開発対象のプロダクトで分けずに1チーム
  • 複数のプロダクトを跨いで全ての案件の中で優先度を決めて柔軟にリソース調整したい
  • マネジメント工数を抑えるためにも、スケジュール状況は常に可視化したい

ノウハウまとめ

現在、こういう使い方をしていて運用回っているというノウハウを以下にまとめます。
皆さんのお役に立てるかどうかという視点で考えると、環境や状況にとても左右されることなのでマッチするしないがかなりあります。
これは自分にとっての備忘録でもあるので、使えるところがあったらラッキーくらいの気持ちでご覧ください。

どの単位でJIRAプロジェクトを分けるか

  • 通常の開発案件(通年案件+週次案件)
  • 不具合修正系

他にもインフラや開発に直接関わらないプロジェクトもありますがここでは割愛します。
通常の開発と呼んでいるものは、同じ土俵でリソース管理をしたいので1つのプロジェクトにしました。
不具合修正系は現状では案件の隙間でやるような感じで、やるチームは同じでもリソース管理としては別概念になるので分けています。

チケットの種類をどう使い分けるか

現在はストーリーとタスクの2種類を主に使っています。

  • 開発する案件(機能)単位でストーリーを切る
  • ストーリー直下にタスクを切る

開発には、要件定義→設計→デザイン→実装→テスト→リリースという流れがあるので、最初は階層を設けていました。
XXXを実装する(ストーリー)
└設計(タスク)
 └PC(タスクかサブタスク)
 └SP(タスクかサブタスク)
 └App(タスクかサブタスク)
└デザイン
...

人によっては独自で更に階層を作って整理していたのですが、子チケットの進捗に合わせて上位チケットも一緒にステータスやスケジュールを管理するのが手間でした。
なので現在は 設計_App_xxxx という形でグルーピングを表現し、案件のメインチケットであるストーリーの直下に置くという運用をしています。
サブタスクも人によって使いどころが違うので基本的に使っていません。

ステータスをどう使うか

チケットの種類によって変えています。

  • ストーリーはBacklog→要件定義済み→概算見積り済み→進行中→完了
  • タスクはTODO→進行中→完了

企画チームが見る際にはBacklogを含めて全ての案件を表示。開発チームでは要件定義済み以降のステータスのストーリーのみ表示するフィルターを使っています。
タスクはシンプルに手をつけたら進行中、終わったら完了です。WBSの表示では完了を非表示にしています。

カスタム項目で何を追加したか

案件の各責任者が一目で分かるように、ストーリーへ開発リーダー/メインエンジニア/メインデザイナーを追加しました。
また、チケットのデフォルト項目である担当者にはPOを設定しています。

チケットの開始日/終了日をWBSの各項目に設定しますが、それとは別に期限日を追加しました。
どんなスケジュールでやるのかとは別に、そのチケットが完了すべき期限日を管理したかったためです。
ただし、現在はこの項目をほとんど使っていません。結局は、実際にいつ終わる予定なのかが重要なので、それが分かっていれば十分でした。

管理のためのフィルター

主に3つのフィルターをよく使ってます。

  • 全案件マスター

完了していない全ての案件を表示します。

  • 自分がリーダーの案件で未完了の全タスク

『自分がリーダー』は私の場合なので別な条件に差し替えてもいいのですが、対象案件の配下にある未完了タスクを全て確認する時に使います。
こちらを参考にさせていただきました。
JQLの副問い合わせ エピック>タスク>サブタスクを抽出するフィルタ
プラグインが必要ですが非常に便利です。

リーダー案件
status in (Backlog, "To Do", 要件定義済み, 概算見積済み, "In Progress") AND Leader in (currentUser())
その子タスク
issueFunction in linkedIssuesOfAllRecursive("filter={上記フィルタのid}") AND status in (Backlog, "To Do", 要件定義済み, 概算見積済み, "In Progress")
2つをがっちゃんこ
filter in (リーダー担当, リーダー担当子タスク)
こんな感じで作れます。

  • 個人の未完了タスク(プロジェクト跨ぎ)

WBSで担当者ごとにグルーピングできなかったので、リソース調整のために人単位でスケジュールを確認する時に使っています。
現在の人数ならまだ大丈夫ですが、人が増えると辛いので良い方法あれば知りたいです。

運用ルール

その他、JIRA管理をするためにいくつかのルールを作っているので記載します。

・基本的に1チケットのスケジュール粒度は2日以内
・毎日、帰宅前に最新ステータスに更新する
・レビュー依頼もラベルにレビュー依頼を付けて都度チケットを切る
・作業が終わった後、確認待ち状態でもそのタスクのチケットは完了にし、追加で修正などあれば別チケットを切る

終わりに

これらは難しい話ではないですが、記憶は薄れていくものです。
また違う現場でJIRA(もしくは違うツールでも)を使うことになった時には、自分でこの記事を振り返ってみます。
もし、『こういう時は他にこんな使い方ができるよ〜』といったご意見あれば是非教えてください!

tom_furu
大手企業からベンチャーへと、エンジニアとして紆余曲折あり現在はカナダにいます。 運動が好きです。スキー・スノボ・ランニング・登山・ゴルフ・ボルダリング・フットサルetc...いろいろやります。 あと、日本酒が大好き。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした