プログラマの思索

Redmine 2.3が先日公開されて、かなり機能拡張されている。
内容をリンクしておく。

【元ネタ】
Redmine 2.3のCHANGELOG (新機能のみ・日本語訳付き) | Redmine.JP Blog

【1】Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog

今回の大きな目玉は、ガントチャート機能の強化だと思う。
Redmineを初めて導入する時、Redmineならガントチャートが使えますよ、と言う謳い文句をよく使うので、正直ありがたい。
イナズマ線でタスクの遅延が一目でわかるし、チケットに付けられた先行・後行の関係がガントチャートで表示されれば、MSProjectのように扱うこともできる。

とはいえ、チケット管理していくと自然にアジャイル開発に近くなっていくため、チケットをWBSと同一視して、計画重視でやっていくのは向いていないだろうと思う。

@yusuke_arclampさんが「チケット駆動開発で作業管理はしないほうがいい - arclamp」で述べているように、WBSとチケットはアンマッチ。
チケットという概念そのものが、WBSのようなガチガチの概念とアンマッチな部分があるから、と思っている。

WBSはそもそも管理者の観点で全体的に抜け漏れないように管理したいのに対し、チケットは開発者の観点で都度発生したタスクを起票し、その後の作業内容を記録していくためのもの。

チケット駆動開発では、そもそもビューの観点が違うのだ。

【2】Redmine 2.3新機能紹介: 親プロジェクトのメンバーを子プロジェクトで継承 | Redmine.JP Blog

Redmineでチケット駆動開発を実践していると、バージョンやプロジェクトをどのように使いこなしているか、という観点でチケット管理の習熟度合いが見れると思う。

アジャイル開発の最大の特徴であるイテレーション単位のタイムボックス開発が分かっていないチームは、バージョンという機能を理解していない。
だから、リリース計画という概念が希薄であり、そこから派生したVelocityという概念も出てこない。

バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索

TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない: プログラマの思索

TiDD初心者が陥りやすい罠～バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

また、複数チームのプロジェクトや、会社ないし事業部全体でRedmineを使っている場合、Redmineプロジェクトをどのような観点で分割すべきか、という問題がある。
チケット駆動開発の基本的な考え方としては、Conwayの法則に従うように、技術よりも機能の観点で分けた方がいいと思う。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

レイヤの多い組織は無駄に複雑なシステムを作る～Conwayの法則: プログラマの思索

チケット駆動開発がもたらした新しい観点part1～Redmineプロジェクトへ案件や組織構造を反映する: プログラマの思索

【3】他にも使い勝手が改善されている。

Redmine 2.3新機能紹介: ドラッグ&ドロップでのファイル添付 | Redmine.JP Blog

Redmine 2.3新機能紹介: プロジェクトの全メンバーにニュースを通知 | Redmine.JP Blog

今後の機能改善にも注目していく。