第9回東京Redmine勉強会の感想 #redmineT

第9回東京Redmine勉強会の感想をメモ。

【参考】
第9回勉強会 - redmine.tokyo

参加者は80名と過去最高の人数、そして渋谷dotsという素晴らしい会場のおかげで、内容の濃いRedmineの議論ができたと思います。
手作りのクッキーやコーヒーなども協賛のおかげで参加者に配布でき、リラックスした雰囲気で議論できたかなと思います。

勉強会の講演やオープンディスカッションで気づいたことはいくつかある。

【1】チケットに書かれた情報は管理情報とは異なる、という@sakaba37さんの指摘。
チケットには、開発チームで必要な情報が記載されているので、必ずしも管理上必要な情報が書かれているとは限らない。

例えば、障害の症状や解決方法、問合せの内容とその対応の経緯などは、作業者が必要だから記録しておく。
しかし、その作業の実績工数、対応時間などの情報、あるいは障害管理に必要な区分や種類などの情報は、現場の作業者にとって、それほど重要ではなく、きちんと入力するほど面倒。
しかし、その情報がなければ、いろんな観点のメトリクスを集計して分析するのは難しい。

そのトレードオフの関係があるのは僕も認識している。
そのトレードオフのデメリットを、チケット駆動の運用ルールや、Redmine本体のチケット入力の機能改善などである程度は改善できるのではないか、と思っている。

【2】親子チケットをツリー構造ではなく、多対多のような関係で表現したくなる場合の対処。
ゲームシーンでキャラクターが出る作業チケットの例を@agilekawabataさんがあげられた。

例えば、あるゲーム会社のゲームソフトを作る作業チケットがあったとする。
この時、キャラクター1は複数のゲームシーンで使われるので、複数のゲームシーンのチケットに紐付けて、進捗を管理したい場合があるらしい。

例：親1--子1--子2
ゲームシーン1を作る--キャラクター1を作る--キャラクター1の動作1を作る
ゲームシーン2を作る--キャラクター1を作る--キャラクター1の動作1を作る

対処方法としては二つあるだろう。
一つは、Redmineバージョンを親・子チケット全てに対応づけること。
そうすれば、ロードマップ画面で、EVベースの進捗率と見かけ上の進捗率の2種類で見れる。

もう一つは、「ゲームシーン1」配下の子チケット「キャラクター1」をコピー(複製)し、「ゲームシーン2」の配下に対応付けた後、コピー元の子チケットに「重複する」関連機能を持たせること。
すると、コピー元のチケットをCloseする時、コピー先のチケットも同時にCloseできるので、完了ステータスは同期できる。
但し、それ以外の属性情報は手作業で移す必要があるだろう。

MAEDA, GoさんはTwitterを使っています: "重複元をcloseすると重複先のチケットもcloseされる性質を利用 #redminet"

チケット同士の関連づけ | Redmine.JP Blog

この問題の根本解決方法は、チケットにエイリアスないしファントムのような機能があるといいのだろう。
つまり、オリジナルのチケットがあれば、そのチケットが更新されると、エイリアス先のチケットの進捗率やステータスも連動して欲しいわけだ。

【3】WF型開発における工程をチケットにマッピングさせるための方法。
@agilekawabataさんがあげた例では、①親子チケット、②バージョン、③トラッカーの3つをあげていた。

僕個人の経験では、MSProjectに慣れたマネージャは、親子チケットで階層化するタイプが多い。
つまり、親チケット＝工程、子チケットに作業、機能、管理などを割り当てる。
進捗率が親チケット(工程)に集計されるメリットがある一方、ある工程に基づく子チケットを探すのが非常に面倒なデメリットがある。
但し、Ver3.1から、親チケットに紐付く子チケットを検索できるように改善されている。

Redmine 3.1新機能紹介: 親チケットおよび子チケットによるフィルタ | Redmine.JP Blog

アジャイル開発を知っているマネージャは、工程をバージョンに割り当てる。
僕個人もこちらの方法を勧めている。
Redmineのバージョンは「リリース予定バージョン」であり「XPのイテレーション(Scrumのスプリント)」であり「マイルストーン(進捗報告のタイミング)」である、という性質を利用して欲しいからだ。
但し、「工程単位のバージョン」というアンチパターンもあるので注意が必要。

【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

WF型開発にとらわれすぎたTiDDのアンチパターン #tidd: プログラマの思索

3つ目は、トラッカーに「基本設計」「詳細設計」「開発」「単体テスト」のように割り当てる方法。
トラッカーをワークフローではなく、作業の種類に割り当てる考え方。
チケットの画面を開いた時にチケットの種類がすぐに分かるメリットがある一方、似たようなワークフローのトラッカーが多くなりがちなデメリットもある。

このやり方に近い現場では、チケットのタイトルに「【詳細設計】」のようなプレフィックスを入れる運用もあった。
つまり、トラッカーはワークフローに合わせるが、工程名をチケットのタイトルに入れることで、一目で分かるようにしたい意図がある。
アジャイル開発のように短期間の高速開発よりも、工程にこだわった開発が主流の場合は、こちらの方がやりやすいのかもしれない。

似たような話として、@mattaniさんの講演で、親子プロジェクトを案件の中で「課題管理」「インシデント管理」「障害管理」に分けているのに使っているという話があって、面白いなと思った。
つまり、チケットの種類をワークフローやカテゴリではなく、Redmineプロジェクトで表現しているわけだ。

逆の意見としては、@akahane92さんの話のように、一つの製品開発では親子プロジェクトは使わず、一つのプロジェクトで管理し、チケットのコメントに作業の履歴を記録していく、という運用ルールもある。
製造業では、受託開発で多い製番管理が主流だが、製番をRedmineプロジェクトに対応付けて運用する方が管理しやすい、という主張。
この意見も、僕も納得しているし、そのように運用している。

【4】他のスライドはコチラ。

Redmine.tokyo 09 questionnaire from Jun Naitoh

チケット駆動開発導入のヒント - 自律と規律 - from Makoto SAKAI

講演２ 実例に基づくRedmine管理者入門 r2 from Hidehisa Matsutani

ある工場のRedmine +(Plus) from Kohei Nakamura

Redmine 310 320_new_feature from Jun Naitoh

View Customize Pluginで出来ること from onozaty

インフラエンジニアから見たRedmine redmine.tokyo #9 from Sho Douhashi

第9回東京Redmine勉強会オープンディスカッション「お菓子を食べながらRedmineを語ろう」 #redmineT from akipii Oga