Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ
Redmineの運用の現場を見ていると、チケットをストックとして見る場合とフローとして見る場合で観点が異なるように思えた。
ラフなメモ書き。
【1】Redmineを運用し始めた時に、チケットよりもRedmineプロジェクトの分割に重きを置いたり、チケットをWBSと一体視して、1チケット=1担当者で運用する現場を見かける時がある。
たいてい、上手く回っていない。
本来のチケット駆動開発では、チケットを経由して一つの作業を複数人が分担してやり取りする。
その流れがチケットで表現されるから、今誰がボールを握っているのか分かるのに、チケットをWBSで固定化してしまうと、手戻り作業が発生するたびに、現状を把握しにくくなる。
このアンチパターンを「WBS駆動」「担当者固定」と僕は呼んでいる。
【2】@akahane92さんも言っていたが、Redmineでは、チケットのコメントが長くなるような運用の方がやりやすい。
チケットのコメントに、障害の原因や解決方法を書いたり、ソース修正した後のテスト結果やフィードバックを書いたりする。
あるいは、仕様の質問に対し、回答や疑問点をやり取りする。
つまり、チケットのコメントが作業履歴になる。
さらに、チケットの担当者がステータスごとに複数人でやり取りされるようにすれば、チケットのコメントとステータスが紐付けられるので、読みやすくなる。
チケットをWBS駆動で運用して上手く回らなくなる原因は、チケットの担当者が固定されてしまうために、ペア作業のように複数人でチケットをチェックできなくなるから。
また、チケットに作業履歴が集約されず、複数のチケット(WBS)に作業記録が散らばってしまう。
【3】そんな症状の本質を考えてみると、チケットはストックなのか、フローなのか、という問題にぶち当たると思う。
【3-1】一つのチケットを複数人でやり取りしながら、ペアプロないしペア作業のように運用するなら、チケットはフローだ。
ステータスがどんどん変わる方がいい。
つまり、サイクルタイムは短い方がRedmineの運用は上手く回る。
すなわち、チケットはフロー。
【3-2】チケットをフローとしてとらえる場合、カンバンやGTDみたいな運用に近くなるように思う。
カンバンみたいにチケットを扱うならば、リードタイムやサイクルタイムが短くなるように運用する方針になる。
つまり、チケットを停滞させてストックするよりも、流通させる方が良い点がマッチする。
また、GTDでも、一旦Inboxに必要なタスクをチケットに書いて、それらを週1回のように定期的に精査して、チケットを棚卸する。
GTDでも、チケットがどんどん生まれては消える運用の方がやりやすい。
チケットをストックして停滞させる運用はあまり向いていないのだ。
【3-2】一方、一つのチケットを障害管理票のように扱い、障害の発見から修正、再テスト、リリースまでの作業を記録するなら、チケットはストックだ。
もちろん、チケットを作業指示書、課題管理票、顧客からのインシデント管理票として扱う時も、チケットに一つの作業やインシデントのやり取りを集約させるので、同じ。
つまり、チケットはストック。
チケットのコメントは、メーリングリストのメールのスレッドみたいに扱う方がいい。
【3-3】チケットをストックとしてとらえる場合、一昔前の掲示板みたいな運用に近くなるように思う。
チケットは一つのテーマに限定し、一つのスレッドの中で、皆が議論してやり取りして記録を残す。
そのスレッド(テーマ)の内容は、後から全文検索できるし、たくさんのスレッドのログがあるほど、その掲示板は価値が増す。
過去にこんなスレッドがあったから、見ておいたらいい、というアドバイスもできる。
特にソフトウェア保守では、過去の障害修正や仕様変更の経緯が記録されているとすごくありがたい。
このIF文を修正して良いのか、何故こんな汚いパッチが当てられたのか、という変更理由が数年後でも把握できるからだ。
また、チケットはストックの性質を持つから、記録されたチケットの属性を元に、メトリクスを採取できるのも良い。
特に、障害分析や生産性の分析では、メトリクス集計が威力を発揮する。
Velocity(スループット)、サイクルタイムを定期的に採取できれば、開発チームの生産性の傾向をモニタリングすることもできる。
【4】「チケットはフローでもありストックでもある性質を持つ」という二重性が、チケット駆動開発に大きな利点を与えているように思える。
フローの側面はアジャイル開発の利点につながる。
頻繁にリリースしていくために、チケットをどんどん流通させて完了させていくスタイルに都合がいい。
ストックの側面は、アジャイル開発をベースにしたチケット駆動開発に、従来のソフトウェア工学の観点を注入して強化する点につながる。
プロセス分析やメトリクスの性質については、既にたくさんの知見があるので、それらをアジャイル開発へ適用することで、より安定して開発できるようになるはずだ。
| 固定リンク
「Redmine」カテゴリの記事
- 第24回redmine.tokyo勉強会の感想 #redmineT(2023.06.03)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
コメント