XPのトラッカーの役割はTiDDがサポートする
平鍋さんのBlogを読んでいたら、「XPのマネジメントの役割は2つに分けられる。コーチとトラッカー」という言葉に出会った。
考えたことをメモ。
【元ネタ】
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)」の方が好きです。
一番好きな箇所は下記かな。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント