プログラマの思索

以前、平鍋さんが翻訳されたジム・ハイスミス著「アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則」を読み返した。
アジャイル開発を経験したからこそ、購入して5年もたってようやく理解できたのでメモ。

【参考】
アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則, ジム・ハイスミス の感想 - ブクログ

(引用開始)
アジャイルプロジェクトマネジメントのバイブル的な一冊。
タイトルにもあるように、プロジェクトマネジメント向けの内容となっており、実践を想定した具体的な記載と共に、アジャイルの原則（考え方や哲学と言っても良い）についてとても良くまとまっている。
ただし、アジャイル経験が無い状態で本書を手にとっても、そのエッセンスのほとんどは理解できないであろうと想像する。
私が本書に出会ったのは一度アジャイルプロジェクトを実践した後のこと。
経験を踏まえて本書を読むと、各ページ一言一句から得るものがある。
実践を行うにあたって、そばに置いておきたい一冊。
(引用終了)

製品開発にアジャイルなプロジェクトマネジメントの流れや概念を導入して解説してくれている。
再読してみると、PMBOKの流れや概念を連想させるものがある。

アジャイルプロジェクトマネジメントの「構想→思索→探索→適応→終結」という流れは、PMBOKの「立ち上げ→計画→実行→監視・コントロール→終結」の流れに似ている。
PMBOKもアジャイルプロジェクトマネジメントと同様、スコープ管理を重視しており、スコープ外の作業や要求された品質以上の作業を金メッキと呼んで、無駄な作業と見なしていた。
これはXPのシンプルさの重視に似ている。
「アジャイルプロジェクトマネジメントはアジャイル時代の PMBOK」という感想は確かにそうだとうなずける。

又、アジャイルプロジェクトマネジメントに出てくる数々の概念は、Scrumの用語を連想させる。
機能リストはプロダクトバックログだし、リリース計画はスプリント計画、探索はスプリント実施、適応はレトロスペクティブ(ふりかえり)にまさに置き換えられる。

顧客チーム・開発チームのインターフェイスに出てくるプロダクトマネージャとプロジェクトマネージャは、Scrumのプロダクトオーナーとスクラムマスターの関係に似ている。
お互いが対立しあうのではなく、Win-Winの関係に持っていけるように、「何を作るか(機能の優先順位の決定)」「どのように作るか(機能の実装)」の役割を分ける。

だが、アジャイルプロジェクトマネジメントがPMBOKと決定的に違うのは、計画は頻繁に変更されるのを前提としていることだろう。
計画と実績の差を管理していくのではなく、顧客へ提供する機能や価値がどれだけ反映されたのか、を見ていく。
その差を見るために状況報告の道具の一つとして、イテレーションごとのパーキングロットレポートが紹介されているが、これはパーキングロットチャートと同様だ。

Redmineでチケット駆動開発を実践してみて、どの運用がアジャイルプロジェクトマネジメントのどこに当たるのかを想起させるから、自分の中で理解できるようになったのだろうと思っている。