プログラマの思索

Redmineを初めて使う管理者が陥りやすいアンチパターンを見つけたのでメモ。

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

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

Twitter / @cointoss: アジャイルの導入に二の足を踏む現場において、チケット駆動開発(=TiDD)であれば受け入れやすい理由は、プラクティスが少なく実践的なものに絞っているからだろう。リリース予定をバージョンとすることでイテレーションやスプリントが定義できるため、そこだけはアジャイルっぽくはなる。

【1】僕がRedmineを設定する場合、あらかじめヒヤリングした後にプロジェクト設定画面でカテゴリ・バージョンは登録している。
全てのチームがアジャイル開発に慣れているわけではないので、あらかじめ対象バージョンには「2011年5月の開発」みたいなバージョンで期日を月末に作り、1ヶ月おきに故意に入れている。
意図としては、たとえWF型開発や運用プロジェクトであったとしても、イテレーションをチーム内で作って運用して下さい、という意味をこめている。

しかし、バージョンの使い方が分からない管理者は、期日である月末が過ぎても、バージョンを放置したまま、次々にチケットを登録して、チケット一覧やガントチャートでにらめっこしている。
チケットを定期的に棚卸しする発想がなく、ガントチャート上でタスクの依存関係の整合性を取ることばかりに気を取られている。
だから、チケットはどんどん溜まっていき、進捗がはかどっているかどうかもRedmine上では分からなくなる。
結局、Excelのガントチャートで予定・実績工数の管理に戻ってしまい、Excel上の集計から「今は5人日遅れています」という報告をするようになってしまう。

【2】Redmineでチケット駆動開発を運用する場合、バージョンをイテレーションに対応付けて運用するのが重要。
その理由は、ITSのバージョン(マイルストーン)機能が、Agile開発のイテレーションであり、構成管理上のリリースタグに相当するという意味が込められているからだ。

つまり、マイルストーン単位にリリースしていく開発スタイルはまさにAgile開発の小規模リリースであり、顧客へ価値あるソフトウェアを定期的に納品するという戦略にかなっている。

更に、マイルストーンの期日にチケットの棚卸しを行う作業も重要だ。
何故なら、マイルストーンの期日までに間に合わないと分かったチケットは次のマイルストーンへ繰越されて、次のマイルストーンで対応することになる。
駄目な管理者は、チケットの棚卸しを定期的に行わないので、せっかくタスクをチケットで見える化しても、チケットが乱発されて放置されてしまってRedmineがゴミ箱になってしまう。

棚卸しはそもそもどんな意味を持っているのか？

【3】チケットの定期的な棚卸しは、単にタスクを整理するだけではなく、開発チームのVelocity(開発したシステム規模、開発チームの生産能力)を確定することを意味していると思う。
そのイメージを下記のようにまとめてみた。

例えば、Sprint1というイテレーションで、イテレーション計画した時、20枚のチケットでイテレーションを開始すると決めたとする。(期首)
そして、チームは2～4週間のイテレーションで20枚のチケットをこなしていく。
しかし、途中で仕様変更が発生したり、予期しなかったタスクが発生して、イテレーション期間中に10枚追加になったとする。(当期発生)

これは、イテレーションを計画した時点のスコープから増えたことを意味している。
Scrumではスプリント実施中はスコープが変わらないことを前提にしているから、このような割込みタスクを発生させないように調整するだろうが、実プロジェクトではよくあることだ。
チケット駆動開発では、そのような割込みタスクを今のイテレーションで実施するか、次のイテレーションに回すべきか、という判断をチケットの取捨選択に置き換えることで、プロジェクト運営を見える化している。

そして、チームは何とかやりくりしながら、イテレーション終了間際に棚卸しして、5枚のチケットを残すだけとなり、それらチケットは次のイテレーションに回すと決めて、Sprint1は終了したとする。(期末残)
つまり、棚卸し時に、イテレーションの終了判断として、5枚のタスクが残ったとしても終わったという意思決定を含んでいる。
棚卸し作業にはイテレーション(バージョン)をCloseさせる意思決定が含まれている。

その場合、終了チケット数は25枚であり、残チケット5枚は次のイテレーションSprint2に組み込まれる。(次期繰越)
これらの作業は、イテレーション終了時と次のイテレーション計画作成時に行われる。

チケット駆動開発では、イテレーション期間中あるいはイテレーション終了時に必ず、チケットの状態を精査する作業、つまり棚卸しを行う。
棚卸しは現時点で残っているタスクは終わっているのか、そしていつ行うのか、というプロジェクト運営の意思決定を含んでいる。
Redmineでは対象バージョンのステータスを「終了」に更新すると、終了した対象バージョンのチケットは更新できなくなる。
つまり、終わったイテレーションのチケットは参照のみであり、イテレーション作業の実績値として確定される。
Sprint1の場合、終了チケット25枚が実績になる。

Sprint2では、前のイテレーションから繰越されたチケット5枚と、Sprint2で実施する25枚のチケットを追加して、計30枚のチケットでイテレーションが開始する。(期首)
同様に、当期増加のチケット5枚が発生して追加されたものの(当期発生)、Sprint2終了時には棚卸ししたら全チケット35枚が完了したとする。(期末残0)

上記の流れから、Sprint1の終了チケット25枚、Sprint2の終了チケット35枚が実績として確定する。
つまり、イテレーションの平均完了チケット数は30枚になる。
もしチケットの粒度がばらつきがなく一定ならば、チケットの枚数が開発チームの生産能力そのものになる。

30枚/イテレーションという値は、31枚以上のチケットを顧客が開発チームへ要求したとしても、開発チームはイテレーション期間内に完了できないことを意味している。
すなわち、開発チームの生産能力には限界がある。
開発チームの生産能力以上のタスクを課したとしても、タスクが溢れて、納期になってもリリースできないだろう。

これがScrumの言うVelocityを指しているのだろうと思う。

TiDDを実践して気づいたことpart9～Scrumのベロシティ #tidd: プログラマの思索

Mantisでは、平均完了日数というメトリクスがチケット集計機能の一部として提供されている。
下記の記事で書いたが、平均完了日数はソフトウェアのMTTR(平均修復時間)である。
この概念も、1プロジェクトないし1イテレーションの開発能力、すなわちVelocityと同一だと直感している。

Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索

【4】棚卸ししなければ、開発チームが今どれくらいのタスクを完了させたのか分からないから、自分たちの開発ペースや開発能力を自覚することができない。
自分たちの開発能力が分からなければ、結局、自分たちの能力以上の作業の負荷がかかり、残業や休日出勤に追いまくられる事になる。
特に、WF型開発の場合、イテレーションと言う概念がないから、Scrumの言うVelocityを測定するタイミングが無い。
だから、駄目なWF型開発のプロジェクトでは、自分たちの生産能力と言う実績値が分からないままだから、設計や開発はスムーズに進んだように見えても、単体テストや結合テスト、システムテストと本番リリースへ向けてどんどん進むにつれて、チームの生産能力以上の負荷がかかってしまう。
開発チームのVelocityを超えたタスクを設定しても、チームは混乱して、納期になってもリリースできないだけだ。

あるいは、WF型開発で実績値をきちんと取るような開発プロセスを持っていたとしても、メンバーに実績値を計測させて入力させる運用のコストが大きいため、頑張るほど、実際の作業時間以外の無駄な工数が増えてしまう。
チケット駆動開発では、実績値をチケットの自動集計という機能で透過的にサポートするので、メンバーはソースをコミットする時点で実績値を入力する習慣だけで十分だから、メンバーにあまり負荷はかからない。

結局、バージョンをCloseさせずにダラダラとチケット管理を続ける運用例の背後には棚卸しというチケットの終了基準、イテレーション(リリース)の終了基準を明確にするという意思決定が曖昧という事実が隠されている。
棚卸しするからこそ、自分たちの開発能力というVelocityが分かり、XPが言うように、チームにとって最適なペースで仕事できる環境が出来上がるのだ。