チケット駆動開発は計画の変更を恐れない #tidd

チケット駆動開発でのリスケについての質問を見つけたのでメモ。
下記はあくまでも僕の一意見。
ラフなメモ書き。

【元ネタ】
チケット駆動開発でのリスケジュール方針について | OKWave

【1】チケット駆動開発をAgileに運用しているなら、チケットのDoneの条件はリリースする事。
すなわち「バージョンをCloseする＝リリースした」「バージョンをCloseできない＝リリースしていない」になる。
もし、遅れたチケットを無視してリリースしたなら、チケットは延期されたことを意味している。
つまり、遅れたチケットは次のバージョンへアサインされることと同義だ。

チケット駆動開発において、リスケのタイミングといつだろうか？
Agileに開発しているなら、朝会だ。
Scrumならデイリースクラム、XPならスタンドアップミーティングに相当する。
PLは課題解決マシーン。実作業はメンバーにお任せ。
課題の無いプロジェクトは、メンバーが自己解決する順調なプロジェクトなのか、PLが裸の王様なのか、どちらかだ。

タスクが１MDでも遅延したら、そのタスクは2度と元のペースに戻ることは無い。
TOCの言う通り、スケジュールは遅延が伝播するだけだ。
朝会で課題を見つけて、チーム内で調整するか、上司や顧客へ調整するか、早く判断しなくてはならない。

【2】チケットが遅延した原因を分析するのが大事。
その原因は色んなパターンがある。

例えば、割り込み作業のためにチケットのタスクに専念できない人もいる。
つまり、その人はヤミ作業している。
チケット駆動開発の根本ルールである「チケットに起票してから作業を開始する」「No Ticket, No Work」に既に違反している危険な兆候。
PLはメンバーの作業を完全にコントロールできてないわけだから、体制そのものに問題がある。

あるいは、先行のチケットが終わらないので、タスクを完了できない場合もある。
つまり、タスクに先行・後行の依存関係（PMBOKの言うFSなど）がある。
この場合、基本はクリティカルパスに専念するのが最良の解決パターンだろう。
Agile開発はタイムボックスによる開発なので、チケットの総数を少なくすることで、依存関係を見やすくする利点がある。
プロジェクト内部の作業を見える化することで、自分の作業が誰に影響を与えているか、メンバー自身に喚起させることが自然にできる。
あるいは、TOCの言うクリティカルチェーンに従って、クリティカルパス上のタスクにバッファを作っておき、遅延が伝播しないような仕掛けを入れてもいいだろう。

遅延したチケットで危険なパターンは最低3つは経験している。
一つ目は、リファクタリングしないと機能追加できないチケット。
二つ目は、仕様変更に対応したら、デグレしたチケット。
三つ目は、バグを直したら、他画面の同類バグ調査が漏れていたチケット。

一つ目は、派生開発で起きやすい症状で、当初の設計が調査不足で、見積もりが甘かったことを意味する。
3MDで終わる予定が5MD以上も起きてしまうのはざらだ。
その場合は、リファクタリングのチケットと新規追加のチケットを分ける時が多い。
開発者も、リファクタリングの帽子と新規追加の帽子をかぶり直した方が、頭を切り替えやすくなる。

二つ目と三つ目は、ソース修正の影響範囲の調査漏れ、あるいは、テスト漏れを意味している。
いずれにしても、原因は根深いので、時間をある程度確保して、抜本的な調査を行わないと、バグがモグラ叩きのように出てきて、チームが疲労してしまう。

遅延したチケットに対する抜本的な対策は、最終的にはリスク管理につながる。
チケットが遅延しないように、あらかじめ何らかの対策を用意しておくわけだ。

PMBOKの言うリスクバリュー分析図では、影響度と発生確率の4象限で、リスクに対する態度を決める。
リスクが低ければ、無視 or 却下してもいいわけだ。
つまり、リスクを受容する場合もある。

【3】上記の質問を読んで思ったことは、何故、リスケを恐れているのだろうか？
PMBOK、WF型開発では、ベースラインを設定して予定・実績比較で管理していく。
予定がコロコロ変わっては、実績と比較しても差がなくなるので、差異分析がやりにくくなるからだ。

逆に、Agile開発は計画の変更を恐れない。
むしろ積極的に計画を変更して、プロジェクトをドライブする。
完璧な計画作りよりも、プロジェクトの成功を重視するのだ。

だから、Agile開発では、ロードマップというリリース計画をあらかじめ作るけれども、あくまでも大まかに作っておき、詳細な計画はイテレーション実施前に作り、イテレーションの実施中も頻繁に変更していく。
ITSによるチケット管理の利点は、チケットですべての作業が見える化されるだけでなく、状況の変化をチケットに即座に反映しやすい点もある。
優先度や作業内容、担当者、作業の開始日や終了日が変わったら、チケットの属性を変更すればいいだけのことだ。
ロードマップやチケットを現状に合わせて、チームの現状を誰もが同一に認識出来るようにすれば、自ずから何を解決しなければ前進しないのか、見えてくる。
ファシリテーションが教えるように、問題がはっきりして解ける問題へ変換すれば、人は自然に問題を解決しようとする。

変更されたチケットの内容はリアルタイムに反映されて全員に見える化されるので、部外者の上司や顧客もITSを閲覧できるとなおいいだろう。

丁度、下記のようなTwitterを見つけた。
まさに、ロードマップを第三者が見れば、プロジェクトの状況が単なる遅延だけでなく、遅延したチケットをどのように処理しようとしているのか、というチームの意思も見えてしまうわけだ。

Twitter / @アカベコ: 結局、Redmine 1.2.0 は GW 中にリリースされなかった。残り 3 件のチケットは、スケジュールより重要ということなのか？と書きつつ、こうやって詳細な進捗を世界に公開するのは勇気あるなぁと感じる。