Jiraの機能はTracに似ている気がする #redmine

最近、Jiraを触り始めた。
Jiraの感想は一言で言えば、昔のTracにすごく似ている気がする。

Redmineユーザの観点では、Jiraは非常に使いにくい。
Jiraのどこが使いにくいのか？

使いにくい原因は、Jiraがアジャイル開発機能に特化していること、Tracのような古い機能が残っていることだと思う。

Tracのワークフロー: プログラマの思索

RedmineとTracの機能比較: プログラマの思索

Jira Cloud ユーザー向け 入門ガイドブック第２版 : リックソフト株式会社

Confluence ユーザー向け 入門ガイドブック | リックソフト株式会社

【1】一般に、JiraはScrumのようなアジャイル開発、カスタマーサポートのようなサービスデスクなどのユースケースに特化している。
Jiraには、アジャイル開発の機能がすでに盛り込まれている。
チケットと呼ばず課題（Issue）と呼ばれている。
課題には、エピック、ストーリー、タスクが既に存在していて、ストーリーポイントのような見積もり項目もある。
課題のビューには、バックログとスプリントバックログが既に存在している。

しかし、一般の日本企業では、WF型開発が主流であり、ExcelのWBSとかガントチャートを使いたい。
結局、リックソフト社のガントチャートプラグインを入れて、Scrumの機能は全く使わず、ガントチャート上でタスク管理している事例がすごく多い。
つまり、日本企業の現場では、実際のタスク管理とJiraのアジャイル開発機能にギャップが発生している。

しかも、日本企業の現場では、Jiraのスプリント機能を使っていない。
スプリントをなぜ使わないのか？

Jiraではプロジェクトを階層化できないため、１個のプロジェクトで１つの大規模案件をアサインする。
すると、１個のプロジェクトに複数チームのタスク管理に使うため、複数チームのタスクが混在してしまう。
だから、複数チームのタスクを区別するために、WBSのトップ階層を各チームに割り当てて、タスクを階層化して使っている。
非常に使いにくいこと極まりない。
Redmineならプロジェクトを階層化できるので、子プロジェクトをチームごとに割り当てることで、タスクを分別できるし、親プロジェクトで横串で横断して管理もできるのに。

しかも、JiraのスプリントはRedmineのバージョンと同様に、１プロジェクトに依存するために、複数チームのタスクに１つのスプリントがアサインされる。
しかし、現場では、チームごとにチーム特有のスプリントを決めたいケースは多い。
大規模案件ではリリースバージョンというメインターゲットが決まっていても、各チームのタスク管理では、各チームごとにこまめにリリースしたいバージョンがあって、それをスプリントにアサインしたいが、スプリントはPJ固有であるために、チームごとにスプリントをアサインできない。

Redmineならば、親子プロジェクトができるから、子プロジェクトでチーム独自のバージョンをアサインできる。
つまり、全チームはアジャイルリリーストレインのごとく、最終ターゲットであるリリースバージョンに向けて作業していく。
ただし、チームごとにリリースバージョンに向けて細かなバージョンを作成してマイルストーンを決定したいし、各チームごとにロードマップを詳細化すればいい。
そういう作業計画がJiraでは非常にやりにくいと感じる。

【2】Jiraのチケット項目には、解決状況というバグ管理システムの遺産みたいな項目がまだ残っている。

たとえば、TracやMantisでも解決状況の項目があったし、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできなかったり、ロードマップの画面に取り消し線でCloseされた意図が表示されない機能があった。

Jiraでも同様に、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできない。
チケット駆動の初心者にとって、チケット完了させるためにはステータスを完了にするだけでは不十分なのはなぜ？　解決状況って何なの？と思うだろう。
Redmineのようにシンプルに、解決状況はステータスと同一視して、無くしてしまえばいいのにと思う。

RedmineとTracの機能比較: プログラマの思索

また、チケット管理ツールで最重要な機能であるワークフロー管理機能は、JiraではUIエディタ上で設定する仕組みになっている。
UIエディタ画面上で、ステータスに先行後続の関係を線で引っ張るのが鬱陶しい。
Redmineならば、状態遷移表のようにステータスの先行後続はチェックボックスをつけるだけなので、状態遷移図をイメージできれば記入しやすいし、事前にチェックリストのように作っておけば間違えにくい。

たぶん、TracのワークフローはINIファイルにPlantUMLみたいに記述するやり方だったが、Jiraもそのやり方を踏襲しているが初心者でも使えるようにUIエディタ上で見た目は分かりやすく表現しているのだろうと想像する。
正直使いにくくて鬱陶しい。

Tracのワークフロー: プログラマの思索

さらに、Tracのチケット集計ビューはSQLで直接書くことができたように、JiraでもJQLというSQLに似た構文を使って、ダッシュボードというビューを自由自在に作れるメリットがある。
Jiraを使う場合、Confluenceとセットで使う場合が多いので、Confluenceにダッシュボードを埋め込んで、Wordみたいにきれいに文書化できる。
この点はRedmineよりも優れている点だろうが、解決状況やワークフロー機能の使いにくさを思い出すと、改めてTracにすごく似ているように思える。

【3】とは言え、たぶん僕がまだJiraを使いこなせていないだけなのかもしれない。
自分がやりたいのは、Jiraでスプリント機能を使って、複数チームのタスク管理をイテレーション単位に管理して、アジャイル開発のペースを実現したいことだ。
その観点でさらに試してみたいと思う。