Redmine導入でいつも問題なること～ワークフロー管理とDoneの条件

あちこちの現場に行くたびに、僕がRedmineのサーバーを立てて、運用を開始して、チケット駆動の運用を軌道に乗せる。
僕がいなくても運用は回るようになるが、導入後にいつも問題になることがある。
ラフなメモ書き。

【1】Redmineは、特に小規模なSI案件のプロジェクト管理に使いやすいらしい。
僕はRedmineとチケット駆動開発を組み合わせた運用をベースにアジャイル開発を導入したい動機で、Redmineを使っているが、他のプロジェクトリーダーは、チームの進捗管理を見える化するのを目的としているらしい。

そんな要望を受けて、Redmineをインストールして、チケット駆動の運用ルールを作り、チケット駆動開発を始める。
すると、いつも問題になることが2つある。
それは、ワークフロー管理とDoneの条件。

【2】開発現場の運用をスムーズに回すことをRedmineの目的の一つにしているので、リーダーや開発者からヒヤリングして、現状のワークフローを洗い出す。
その現状のワークフローをRedmineで実現して、運用を開始する。

すると、使っているうちに、ステータスを増やしたいとか、ワークフローの種類を増やしたいなどのフィードバックを受けて、Redmineのワークフローをカスタマイズする。
運用しながら、少しずつRedmine自体を改善していき、チームの作業管理はスムーズに流れるようになる。
そこまではいい。

そんな運用事例を後で上司に報告する機会があり、僕は、Redmineのワークフローによる運用ルールとその成果(チケット集計によるメトリクスやKPTのヒヤリング結果)を報告した時がある。
自分としては、どうだ、チケット駆動開発は現場のチームをかなり改善させているんだぞ、という思いがあった。

しかし、上司から言われたのは、現状のワークフローをそのまま実現して、それが本当に正しいものなのか？
本来のあるべきワークフローから考えて、Redmineの運用ルールを考えるべきではないのか？
現状のワークフローには、無駄が多いのではないか？
現状のワークフローをそのままRedmineに乗せて、運用がうまくいった、というのは、単に効率化しただけであり、現状の課題をそのまま置き去りにしているのではないか、と。

アジャイル開発は、ボトムアップ志向が強いと思う。
チケット駆動開発も、あるべきモデルやワークフローを考えて、綿密に計画してから実行するよりも、まずは運用しながら少しずつ改善する方が向いている。
チケット駆動開発は、ボトムアップ志向の方がやりやすい。

でも、本来は、現場の課題に対して、Redmineをどのように導入すれば解決できるのか、という観点をもっと入れるべきなのだろう。
そうでなければ、現場の課題が残ったまま、局所最適化しているに過ぎない。

しかし、ワークフローのあるべき姿を決めたとしても、その運用はそう簡単には回らないと思う。
ワークフローは、開発チームの体制や役割に大きく依存している。

例えば、ワークフローにあるステータスを減らすとしよう。
すると、減らされたステータスのロールの人の作業は不要になる。
つまり、ワークフローを整理して、あるべきワークフローにシンプルにすると、不要なロールの人はチケットに出てこなくなるので、チームから除去しても良いことになる。
すなわち、チームの組織体制が大きく変えることを意味している。

Redmineのあるべき姿のワークフローにチームを合わせるべきなのか？
それとも現場のチームに合わせてRedmineをカスタマイズすべきなのか？

ケース・バイ・ケースとは言え、この問題は根本的な問いであると思う。

【3】Redmineの親子チケットを用いて、ストーリーカード(親チケット)とタスクカード(子チケット)を実現して運用したとする。
この運用ルールは、元請けの設計チームと下請けの開発チーム、または、プロジェクトリーダー・サブリーダーと開発者という関係のように、ストーリーカードとタスクカードのロールが違う時に運用しやすい。

Redmine Backlogsプラグインで、スクラムを用いて、実行注のスプリントで当初見積もったストーリーを実施し、スプリント最後にストーリー内の殆どのタスクは終わったものの、たった一つのタスクが未完了になったとする。
その場合、そのストーリーは一旦完了にして、その残タスクのみを次のスプリントに持ち越しにしたい時がある。

さほど優先度の高いタスクでもないし、顧客に見せるほどのタスクでもなく、すぐに終わりそうなタスクならば、そのストーリーは完了にして、残った一つのタスクは次のスプリントに持ち越しにしたいのだ。

すると、Redmine Backlogsプラグインでは、ストーリー無しのタスクはチケット登録できないのだ。
どう運用すればいいのか？

Redmine Backlogs :: Home

backlogs/redmine_backlogs

かんばん！～もし女子高生がRedmineでスクラム開発をしたら（3）：「スクラムやるならRedmineとALMinium！」～新キャラ登場！ 無表情なあの人が笑う日は来るのか？ (1/3) - ＠IT

その答えは以下に書いた。
つまり、「その他」「管理」などのようなストーリーを作り、それにタスクを入れて管理すればいい。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

この問いの本質は、ストーリーやタスクの完了条件は何か？という問題につながる。

ストーリーの完了条件は普通は、全ての子チケットであるタスクが完了することだ。
しかし、実際の運用では、運用中に優先度が変わったりして、実行中のスプリントでタスクが未完了でもよい場合もある。
そうならば、そのタスクをストーリーから切り離すか、そのタスクを一端却下とし、次スプリントに「管理」「その他」などのストーリーと共にタスクを起票すればいいだろう。

もしチケット駆動開発で工数管理を厳格にやっている場合、未完了のチケットで実績工数が発生していれば、そのチケットは仕掛中を意味する。
だから、そのスプリント終了時に、未完了チケットは全て却下とし、次スプリントで新たに起票し直す運用が本来は正しいだろう。
そうしなければ、バーンダウンチャートの予定・実績工数の表示はおかしくなるだろう。

チケットのDoneの条件は、チームの成長に伴って変わる。
スクラムでは、スプリントレトロスペクティブで、Doneの条件を見直す。
最初はDoneの条件は緩く狭いだろうが、チームが成長し、フレームワークに慣れて、ドメイン知識を身につけるようになれば、Doneの条件はどんどん追加されていくようになるだろう。

例えば、機能を実装しただけではなく、自動テストを実施し、ビルドが通り、リリースできた、とか、原因結果グラフのテストケースも残す、などの条件が加わる、とか。

Doneの条件は案件やチームによって大きく変わる。
Doneの条件を見ると、チームの成熟度がよく分かる。

成熟したチームは、Doneの条件が厳しくても運用できる。
逆に未熟なチームほど、Doneの条件があいまいだったりするので、ワークフローにレビューや検証のステータスがたくさん加わり、ワークフローが複雑になりがち。
つまり、未熟なチームほど、Doneの条件の不備をワークフローの複雑さでカバーしようとする傾向が見られる。

【4】Redmineを導入すると、そのチームの開発プロセスがチケットのワークフローで見える化されるため、そのチームの組織構造やプロセスの構造がとてもよく見える。
だが、Redmineを導入したとしても、現場の課題をうまく解決できなければ、現状の課題を残したまま運用して、ごまかしながら何とか回していることになる。

本来は、Redmineというツールを業務改革のためのERPのように用いて、現場のソフトウェア開発プロセスをあるべき姿に変えたいのだ。
でも、チケット駆動開発はボトムアップ志向なので、あるべき論から攻める方針は、僕の経験上あまり成功していないように思う。

この辺りは今後も考えてみる。