XPのトラッカーの役割はTiDDがサポートする

平鍋さんのBlogを読んでいたら、「XPのマネジメントの役割は２つに分けられる。コーチとトラッカー」という言葉に出会った。
考えたことをメモ。

【元ネタ】
XP 祭り X に参加して、XP白本読書会の前説やりました。：An Agile Way：ITmedia オルタナティブ・ブログ

アジャイル開発「エクストリーム・プログラミング（XP）」の価値を再認識する - プログラマ 福重 伸太朗 ～基本へ帰ろう～

XPが登場して10年たった今振り返ってみると、XPが生み出した直感的な概念をScrumが精緻に作り直して、新しい概念で補強しているように思える。
XPではプロジェクトリーダーの役割はコーチとトラッカーの二つだが、Scrumではスクラムマスターという概念で統一されている。

トラッカーの役割は、イテレーション計画と実際の結果の差異を追跡するためにメトリクスを収集することだ。
彼はメトリクスを収集するために朝会で進捗や課題を収集したり、メンバー一人一人に進捗や課題を聞いて回る。
僕はトラッカーの役割を持っているプロジェクトリーダーを「お巡りさん」「Police(警官)」と呼んでからかっていた。
つまり、進捗一覧や課題一覧を作るために情報収集しているのだ。

従来のアジャイル開発では、ホワイトボードにPostItを貼り付けて、タスクを見える化する運用をしていた。
僕もこの運用を試した時もあったけれど、うまくいかなかった。
PostItを更新していく作業に僕もメンバーも慣れていなかった。仕事が忙しくなると、PostItすら更新しなくなったり、PostItにないタスクを始めたりする。
また、作業完了したPostItを集めて進捗を集計しなおすのはとても手間がかかった。かと言って、進捗報告の義務は残っているから、作業完了したPostItを捨てるわけにもいかない。

チケット駆動開発なら、実績工数が発生するタスクや成果物を変更する場合は必ずチケットを起票する規律があるから、作業履歴を追跡しやすくする仕組みがある。
そして、トラッカーの役割はRedmineやTracのようなITSで自動化できる。
ITSにたまったチケットを進捗や課題、品質、コストなどの観点で集計し直せばいいだけだ。

トラッカーの役割がそもそも必要な理由は、マネジメントの基本が予定・実績の差異分析にあるからだ。
当初計画した予定と作業した実績に差異がなければ、思い通りに進んでいるが、普通のソフトウェア開発はそんな単純なものではない。
初めての顧客との距離やポーカーフェイス、初めての技術へチャレンジ、初めて一緒に仕事するメンバーのように、リスクを孕む要因はいくらでもある。
BTSがバグ追跡システム、ITSが課題追跡システムと日本語訳されるように、バグや課題の変更履歴を追跡していくのはソフトウェア開発の基本。
計画外の作業や計画外の変更を把握して、逐一追跡していくのが変更管理であり、ソフトウェア開発のプロジェクト管理の基本だ。

チケット駆動開発では、バグや課題や作業などプロジェクトで発生するすべての情報はチケットに一元化され、チケットで追跡していく。
チケットには成果物の変更履歴がリンクされているので、本来の要件がどんな改善要望や技術要件から変化してこんな複雑な実装に至ったのか、を探るインフラになりうる。
SEの基本作業は、変更履歴を追跡しながら、仕様の整合性を取って設計していくのが主な仕事だから。

チケット駆動開発では、進捗一覧や課題一覧を出力するのは簡単だ。
イテレーションごとにステータス単位でグループ化すればタスクボードになりうるし、トラッカー(チケットの種類)＝課題で出力すれば課題一覧になる。
つまり、欲しいと思う情報はSQLの仕様さえきめればワンクリックでExcelやPDF出力できるはずだ。
Redmineでは@naitohさんが次々にPDF改善パッチを作られているが、マネージャへアピールするためにはとても重要な作業だと思う。

トラッカーの役割がITSで自動化されることによって、プロジェクトリーダーの役割は進捗管理ではなくコーチやファシリテーターへ変化する。
進捗報告や課題一覧がワンクリックで出力できる環境にあるので、そもそもメンバーを管理する必要もない。
メンバーは自発的に作業をチケットに登録して作業し始めるから、リーダーはそれらチケットの整合性をチェックするだけでいい。
むしろ、メンバーから自分では解決できない課題を拾い上げて、それら課題を顧客や社内部署へ調整したり、課題解決へ向けた方針を決定する役割へ変わる。
つまり、チームをどのような方向へ進めるべきか、というリードする立場へ役割が変化するのだ。

チケット駆動開発でアジャイル開発のプラクティスを理解できるようになって初めて、アナログのタスク管理の意味が分かってきた気もする。
アナログであれデジタルであれ、「No Ticket, No Commit」「Ticket First」「No Ticket, No Work」のプラクティスは同じであり重要だ。
計画された作業を追跡していくこと、更に計画外の作業も追跡していくことがマネジメントの基本。
変化を抱擁するには、変化を追跡していくインフラが大事なのだ。

ちなみに、僕は「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」(白本)よりも「XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)」の方が好きです。
一番好きな箇所は下記かな。

プログラマにとって人生で一番悲しい言葉、そしてプログラマの権利: プログラマの思索