プログラマの思索

チケット駆動開発についての質問のうち、「チケットが放置されがちだがどうすればいいか？」「チケットの粒度はどれくらいがいいのか？」の二つはいつも聞かれる。
最初の質問について、自分なりに考えたことをメモ。

【元ネタ】
チケット駆動開発を導入しても変わらないこと - Basic

まずは箇条書きより始めよ - Basic

デベロッパーズサミットまとめ【チケット管理システム編】 ? prototype002

【1】「チケットが放置されがちだがどうすればいいか？」という質問の背景を類推すると、チケットを起票する運用はできているものの、チケット管理ができてないことを意味する。

チケット一覧画面で、一生懸命チケットをフィルタリングしながら、どのチケットが遅れているのか、どう対処すればいいのか、必死になって考えている間にも、どんどんチケットが増えていってしまっているのだろう。

チケットが放置されがちな状況では、下記の記事のように「Redmineプロジェクトにバージョン(イテレーション)という概念が無い」「工程単位にBTSプロジェクトやBTSバージョン(イテレーション)を作っているのでバージョンに紐づかないチケットが散乱している」アンチパターンが多発しているだろうと推測している。

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

TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

Agile開発の肝はイテレーションにあり: プログラマの思索

【2】放置されたチケットは不良在庫と同じだ。
つまり、たくさん製品(設計書やソースという成果物)は作っているものの、売れない製品(顧客へ納品できる品質でないモジュール)をたくさん作っているのと同じ。
不良在庫が増えすぎれば製造業の会社がつぶれるように、放置されたチケットが開発チームの能力を超えた枚数になってしまえば、プロジェクトは破綻する。

デスマーチプロジェクトでは特にそういう状況に陥りがちで、もはやどのタスクをどの順番からこなせばいいのか、プロジェクトリーダーですら分からなくなる。
そんなデスマーチプロジェクトに火消しリーダーが入った場合、一番最初にやるのが課題や作業(チケット)の棚卸しだ。
つまり、プロジェクトが今どんな状況になっているのか、どの成果物は信用して使えるのか、今後のタスクや残課題は何か、を逐一洗い出す。
そうしなければ、火消しリーダーも、何から作業すればよいのか分からないからだ。
この作業が意味するのは、チケットの棚卸しという作業は定期的に行うべきということだ。

製造業や小売業でも、倉庫にある在庫の製品や商品を月末に必ず1回は数えなおして、帳簿上の在庫数と合っているか確認して、間違っていたら実際の数値に合わせ直す。
この作業は実地棚卸し、略して実棚と言われる。
実棚の作業を月末に行って、当月末繰越残高を決定して、当月の売上原価と利益を計算する。
そして、来月に前月末繰越残高として来月の月初の在庫数として確定させて、来月の売上原価に入れる。

実棚の作業が意味するのは、在庫は定期的な棚卸し作業が必須で、それがなければ、自分たちの会社が今どれだけの売上や経費がかかっているのか分からないことだ。
最近の製造業ならば、月末1回の棚卸し作業はビジネスの速度に遅すぎて、毎日頻繁に実棚をチェックする継続的棚卸しが普通になっているだろうと思われる。
そうでなければ、デフレでこれだけ製品が売れなくなっている状況では、タイミング的には高く売ってもいい状況で安く売ってしまって逆に損する場合も多い。

製造業や小売業の実棚作業のように、チケットも定期的な棚卸し作業が必須だ。
その実棚の作業も最低でも週1回、できれば毎日やった方がいい。
放置されたチケットはすぐに不良在庫になるから。

【3】ファウラーは、今リファクタリングすべきソースをやらずに先延ばしすることを技術的負債と呼んだ。
今やるべきタスク(チケット)を先延ばしにするのは、利子をつけて負債にしてしまうのと同じ。
実際、IF文がネストして汚いソースをリファクタリングせずに先延ばしして、仕様変更が来てから修正しようとすると、当初見積もった工数よりもはるかにかかってしまう場合が特にそうだ。

Martin Fowler's Bliki in Japanese - 技術的負債

InfoQ: 技術的負債、マネージャの視点

InfoQ: 技術的負債は技術的な問題か？

InfoQ: 技術的負債を貨幣化する

とはいえ、普通はタスクがどんどん増えがちなので、優先度の低いタスクは潜在的リスクとして後回しにする意思決定も多い。
その場合、優先度の低いチケットをバックログという袋(TiDDなら特別なバージョン)に一旦入れておく。
バックログに入れられたチケットは、プロダクトオーナーの役割で、顧客価値に直結する機能や製品は何か、という観点でタスクを優先順位付けし、どのスプリント(イテレーション)で実施するか決める。
優先順位付けするという意思決定プロセスを含むがゆえに、Scrumが編み出したバックログという概念はとても重要だ。

バックログというプロセスには、リリース計画作りという計画プロセスが含まれている。
放置されたチケットが多いという事実は、それらチケットをどのスプリント(イテレーション)で実施すべきなのか、という判断が入っていないことを意味する。
つまり、リリース計画が立てられていないので、イテレーションという概念がプロジェクトに存在しないのだ。
いつまでに何をリリースするのか、という意思決定ができていないのだから、タスク(チケット)が放置されるのも当たり前だ。

【4】Agile開発では、イテレーションというタイムボックスにタスクをアサインしてから開発を始める。
すなわち、タスクのスコープをコントロールしていることを意味している。
放置されたチケットが多いという状況は、PMBOKの言うスコープ管理というマネジメントの基本ができていないことを意味しているのだ。

定期的なイテレーションのサイクルで、チームが解決できる能力のレベルに合わせたチケットの枚数をアサインしてから作業を始める。
この概念は、最終的にはScrumの言うベロッシティ(Velocity：開発速度)に関係すると思う。
ベロッシティを超えたタスクの量を開発チームはこなすことができないのだ。

チケット駆動開発を実践しているならば、例えば1ヶ月単位でチケットの消化枚数を数えてみると良い。
僕の限られた経験では、チームの規模にもよるけれど、1ヶ月という長く思える期間ですら、チケットの消化枚数は50枚ぐらいでしかない。
すると、開発チームのチケット消化速度が大体分かるので、それ以上のチケットを発行しても消化できないので無理と分かる。
だから、リリース計画を立てて、1ヵ月後、2ヵ月後のイテレーションで実現するタスク、今は未決定のタスクはバックログというように、チケットを大きく分けてこなした方がはるかに現実的。

まとめると、「チケットが放置されがちだがどうすればいいか？」という質問には、「不良在庫」「技術的負債」「棚卸し」「リリース計画」「スコープ管理」「バックログ」「ベロッシティ」というキーワードを覚えておけば、何かしらのヒントが隠れているはず。

【5】チケット駆動開発では、プロジェクト管理をチケット管理に置き換えて、マネジメントを見える化する。
チケットの取捨選択こそがXPの計画ゲームであり、マネジメントそのもの。
チケット管理こそ、Agile開発チームの腕の見せ所なのだ。