Redmineのバージョンはなぜ使われないのだろうか。
その事例を実際に見かけたのでメモ。
【参考】
チケット駆動開発の戦略: プログラマの思索
RedMineでチケット駆動開発！: プログラマの思索
【1】Redmineで一番重要な機能はバージョンだと思う。
バージョンがスプリントであり、イテレーションであり、マイルストーンであり、リリースバージョンになる。
バージョン単位にタスクをグルーピングし、小規模リリースする戦略がアジャイル開発だと考える。
よって、バージョンという機能はアジャイル開発と密接に関係する。
バージョンを使うことで、たとえば、LycheeRedmineでは、カンバンやバックログが使えるようになる。
つまり、1つのバージョンを特定すれば、カンバンになる。
複数のバージョン単位にカンバンを広げれば、バックログになる。
すなわち、カンバンやバックログのような機能を使うには、Redmineのバージョンを使う必要があるし、バージョンを使わざるを得ない。
【2】たとえば、Excelのタスク管理が混乱していて、何をすべきか分からないチームがいる。
PMOである僕は、彼らチームにRedmineを提供し、チケット駆動開発の運用ルールと運用ノウハウを伝える。
すると、若いメンバーほど、すぐにチケット管理に慣れて、タスクの消化が進んでチームが加速する。
彼らはすごく楽しそうにやる。
僕はさらに、リーダーである彼にカスタムクエリ設定、LycheeRedmineのガントチャートの操作方法を教える。
彼はカスタムクエリはSQLですね、と即座に理解し、PMOの僕が作ったクエリよりも、自分のチームなら彼が考えたクエリの方が便利だとクエリを追加する。
そして、実際に彼が作ったクエリを毎日の朝会で使って、昨日の実績、今日やること、をすぐに見える化した。
デイリースクラムが自然に身について、チームに一体感が生まれ、さらにチームが加速する。
しかし、PMOである僕が「バージョン」を設定するように説明しても、彼は納得しない。
チケットの期日から対象バージョンの期日が決まるから、機能が重複しているのでは？と彼は指摘する。
彼がカスタマイズし始めて運用を始めたRedmineでは、チケット一覧とガントチャートだけでタスク管理が回る。
ロードマップ、カンバン、バックログは使っていない。
そんな機能はなくても回るよ、と言いたげだ。
【3】では、なぜ、Redmineのバージョンは使われないのか？
理由は、バージョンを設定する人は、メンバーではなく、プロジェクトリーダー層であり、メンバーの自主性に任せて決定すべき機能ではないからだ。
バージョンはPJ設定画面でしか登録できないし、1個のプロジェクトで全てのチケットに横断して使われる。
さらに大規模PJになれば、ツリー構造のPJに対し、バージョンがPJ横断で設定される。
つまり、バージョンは、1つの案件に対し横断的に設定されて、統制をかける。
バージョンはスプリントであるから、大規模PJであれば、全ての子PJにて、基本は同じスプリントが強制設定されて、同期させることになる。
これがいわゆるアジャイルリリーストレインになる。
しかし、アジャイルリリーストレインとなるバージョンを設定できる人は、メンバーでもないし、サブチームのリーダーでもない。
1つの案件を担当するプロマネ、あるいは、プロマネの代理者でもあるPMOが担当すべきだ。
プロマネやPMOこそが、1つの案件のプロジェクトマネジメントをコントロールし責任を持つからだ。
だから、サブチームのさらにサブリーダーである彼にとって、バージョンは自分にとって身近なものではなかったのだろう。
【4】バージョンを使わない弊害は何か？
バージョンを使わないと、チケットがどんどん増えた時に収集がつかなくなる。
どのチケットを最優先にやるべきか、チケットの期日でしか優先順位の基準がない。
だから、毎日、1日分のタスクをどうやってこなすべきか、という観点しか身につかない。
1か月、数カ月レベルで案件を長く見る立場で、どのような戦略でタスクをこなしていくか、という考え方が出てこない。
スプリントという一定期間でチケットをグルーピングすれば、スプリントの中で、期日以外の優先順位付けを考えることができるようになる。
作業の優先順位は、期日だけではないからだ。
プロダクトバックログのように、1列に並べたチケットのスタックに対し、上から順に取り出せばいい。
それが唯一の優先順位であり、期日とは限らない。
【5】改めて、Redmineのバージョンは重要な機能だと思う。
今後も色々試していく。
最近のコメント