[#agile #TiDD] 「リーン開発の現場」を読んで その3 - チケット駆動開発にあてはめる -

「リーン開発の現場」を読んでいると、プロジェクトがドンドン改善されていきます。それは、興奮する著者の話を飲み屋で聞いているように圧倒され、本当にプロジェクトに入ってミーティングに出ているような臨場感を感じます。

具体的な記述なので、すぐに実施できるように思ってしまいますが、前の記事で書いたように非常に多くの要素が組み合わされていて、さらっと読むだけでは構造がすこしわかりにくく感じます。

幸い日本語版の付録にはカンバンボードの解説がありますので、全体像がわかり易くなっています。この記事ではカンバンボードの解説を元に、Redmineでのチケット駆動開発にあてはめてみます。きっと、まだ見えていない特徴が見えてくると思います。

試行の目的

この試行はモデリングです。モデリングとは現実を単純化する事で可視化し、伝え、教え、議論し、改善する、ことを可能にします。

逆に同じ例題を言語でモデル化すると、その言語の特性も見えてきます。

一つ前の記事では、cshという言語を用いて「リーン開発の現場」の内容をモデル化しました。その結果、カンバンボードに含まれる構造が考え易くなったほか、cshの限界も見えてきました。

XPとチケット

かつて、共著者の@akipiiさんらとXPJUG関西でチケット駆動開発の議論していた頃、チケットをタスクカードと考えるとわかり易いのではないかと、アイデアを出しました。

タスクカードはその貼られる位置で、Ready、Doing、Doneと開発の状態を変えます。それはチケットのステータスと同じです。

タスクカードがチケットなら、タスクボードはチケット一覧です。タスクボードは全員で見る一覧になりますが、チケットなら個人別のいちらんやマイルストーンごとのロードマップとして見ることができます。

タスクカードをチケットにマッピングしたことで、チケット駆動開発の概念は大きく整理されました。意識せず、XPの言葉でチケット駆動開発をモデリングしていたのでしょう。

カンバンボードはチケットのステータスだけではない

「リーン開発の現場」のカンバンボードは、タスクボードのステータスが増えたように見えますが、それだけではありません。

1) エピックと呼ばれる大きめの仕様を表すカードが左に置かれ、それがアイデア、企画、定義に変わっていきます。

2) 準備できたものは小さな機能カードに分割されて、優先度の高いものとそうでないものに分けて並べられます。そして順に開発され、システムテストが可能な状態になります。

3) 最後に、システムテスト、受け入れテストと行われ、本番にリリースされます。途中の受け入れテストは時間がかかるので、今週分、来週分、実行中と分けられます。

この構造は全体が一つのタスクボードとは考えにくいものです。XPでのストーリボード、機能単位のタスクカードを貼るタスクボード、そしてテストボードとでも言うべきものが横に繋がった形になっています。

それぞれのボードをよく見ると、Ready、Doing、Doneに近い形になっています。大きく異なるのは、改善が進むに従ってステータスが増減する事です。特に待ち行列の領域を変化させることは、この本の改善ポイントの一つになっています。

さらに、ある状態の領域を狭くする事で同時実行が制限され、 WIP(仕掛り)制限が実現されています。

Redmineにあてはめてみる

Redmineで実現する場合、考えないと行けない事は以下の４点です。

• エピックカードから機能カードなど、カードの分割
• ステータスの増減
• 一覧性と順序付け
• WIP制限

では、これらを順に見ていきましょう。

エピックカードと機能カード

エピックカードと機能カードを、ストーリカードとタスクカードと考えると、Backlogsプラグインのように、概念的にはチケットの親子関係になります。しかし、親が閉じられなくなるので、後のチケットをブロッキングしていると考えるべきでしょう。

こうすると、どのエピックカードがどの機能カードに分割されたかをトレースできるようになります。これはタスクボードとテストボードの関係も同じです。関連チケットを相互に確認できますので、この点はカンバンボードより便利かもしれません。
（10月29日一部修正）

ステータスの増減

ステータスが増減することは、ステータスをすべてのプロジェクトで共有するRedmineには難しい問題です。

要求、開発、テストとトラッカー（チケットの種類）をわけると、ステータスは共通化できるかもしれません。しかし、ある程度の数のプロジェクトをこなさないと、安定するかどうかわかりません。

そこで考えられるのは、ワークフローとは関係がなくなりますが、サブステータスを示す属性を用意する事です。これは、カスタムフィールドでも実現できますが、カスタムクエリを個々に用意しないいけないでしょう。

もし、カテゴリが使われていないなら、サマリーで集計できますので、便利かもしれません。

一覧性と順序付け

しかし、一覧（クエリまたはレポート）を考慮すると、Redmineはいまひとつです。カンバンボードがステータスによって横方向に進むところが、チケットの一覧では縦方向の流れになってしまうのは許せると思うのですが、カンバンボードの縦方向の情報が表現できなくなってしまいます。

タスクボードの縦方向では、今週分と来週分など順序付けされています。これはチケットの優先順位と考えられます。チケットのステータス、サブステータス、優先度の３つのソートキーで並べると良いでしょう。

リリースの区切りはバージョンを指定すると、ロードマップで管理できます（11/7追記）。

WIP制限の与え方

RedmineにWIP制限の機能はありません。

ステータス・サブステータスごとのチケット数を数える必要があります。ステータスとカテゴリは、サマリーで総数を見る事ができますので、手動であればWIPを監視する事ができます。

できれば自動で、ステータス変更時に制限、あるいは、警告されるような仕組みが望まれます。より簡単な方法としてはWIP制限の確認が容易なカスタムクエリを用意する方法もあります。

まとめ

このように、制限はあるもののRedmineでも一通りは表現できそうです。また、Redmineであれば、さらに前後の制約を与えたり、ワークフローの管理もできます。

しかし、カンバンボードに比べると一覧性が悪く、WIP制限もスマートではありません。チケットを一覧で見ているなら、通常のチケット駆動開発と大差ありません。タスクボードのように視認性・操作性を高めたbacklogsプラグイン（リンク先はかおるんダイアリー）のようなプラグインが待たれます。

逆に言うと、全体を通して見える一覧性によって、プロジェクト全体で情報共有できることや、WIP制限が自然に行えること、さらには、ステータスの増減が容易なことが、「リーン開発の現場」で使われているタスクボードの特徴と言えるでしょう。

このように、Redmineの利用を想定してモデリングすることで、プロジェクトの特性と開発法の特性を知ることができました。これらの特徴を考慮するなら、よりふさわしいプロセスを実施する事ができるでしょう。

ソフトウェア工学の研究では現場のデータが公開困難である事が、大きな課題になっています。「リーン開発の現場」のような赤裸々な事例が公開され、共有されることで、ソフトウェア工学が大きく進化することを期待しています。

「リーン開発の現場」は、大学の先生方にもぜひ読んでいただきたい一冊です。