プログラマの思索

「アート・オブ・プロジェクトマネジメント」を読み直して、チケット駆動開発を運用した経験から、そうだよ！と何度も頷くところがあった。
ラフなメモ書き。

【元ネタ】
「 アート・オブ・プロジェクトマネジメント」の検索結果1 - 脱・下流エンジニア (仮)

「 アート・オブ・プロジェクトマネジメント」の検索結果2 - 脱・下流エンジニア (仮)

【12章 リーダーシップが信頼に基づく理由】

「表明」とはコミットメント、約束を意味する。
メンバーが表明することによって、小さな約束が積み重ねられて、一つのシステムが完成する。

チケット駆動開発では、チケットファーストの原則に表明の概念が組み込まれている。
プロジェクトで発生する全ての作業は、チケットに起票してから開始する。
WBSから起こされたタスクも、突発的な事件によって発生したタスクも、まずチケットに起票する。
そのチケットには、開始日と終了日、そして担当者が必ずアサインされている。

チケットを見れば、誰が何をしているのか、誰でも分かる。
開発者がチケットを担当して作業していることをプロジェクトリーダーも信頼しているし、そのアウトプットが納期通りに高い品質であることを期待している。
逐一進捗報告をもらわなくても、Redmineの優れたチケット集計機能によって、リアルタイムに知ることが出来るからだ。

チケットでタスクを見える化することは、単にプロジェクトの風通しを良くすることだけではない。
チケットをこなしていくことによって、プロジェクトリーダーとメンバーの信頼関係を育むのだ。

【13章 ものごとを成し遂げる方法】

「アート・オブ・プロジェクトマネジメント」の中で僕が好きな章の一つだ。
この章は「優先順位は力なり」の言葉で集約されている。

「優先順位付けによって物事が成し遂げられる」という言葉は、チケット駆動開発を経験して実感する。
実際のプロジェクトでは、コロコロ変わる顧客の要望、仕様変更や突発的なタスクによって、優先順位はコロコロ変わる。
駄目なプロジェクトリーダーは、今何を優先すべきか、という判断材料を持っていないから、決断できない。

Redmineならばロードマップこそが、そのチームの優先順位付け一覧に相当する。
ロードマップは単なるリリース計画だけではない。
そのチームの意思決定の源。
直近のバージョンでリリースするには、いつまでにどんなタスクをこなさないといけないのか、がロードマップで一目で分かる。

この優先順位一覧表は、目標・機能・作業項目などの観点に別々に作られる。
Redmineならば、チケット一覧は、ロードマップ・ガントチャート・カレンダー・サマリ・変更記録など各種のチケット集計画面に表示できるから便利。
各種のチケット集計画面を見ながら、プロジェクトリーダーは、優先順位を決めていくのだ。

プロジェクトリーダーの最優先の仕事は、ロードマップの作成とその最新化にある。
チームの羅針盤がロードマップ。
その羅針盤は状況で頻繁に変わるために、チケットの作業順序を入れ替えたり、チケットを捨てたり、チケットを変更・追加したりして、状況をロードマップへ反映する。
このチケットの取捨選択こそが、マネジメントそのものになる。

「PMは優先順位付けマシンとなるべし」とは、プロジェクトリーダーの仕事は、ロードマップを見ながら、チケットを取捨選択して、チームの方向性を提示することを意味している。

すると、チケットの作業順序からクリティカルパスが見えてくる。
クリティカルパスにあるチケットを抑えれば、優先順位の低いチケットは自ずから解消される。
個人的には、Redmineにクリティカルパスを計算するプラグインがあればいいだろうなと思う。

【14章 中盤の戦略】

この章も「アート・オブ・プロジェクトマネジメント」の中で僕が好きな章の一つだ。
プロジェクトが立ち上がり、ある程度進行している状況でのマネジメントが書かれている。

「飛行機の前方を飛行する」とは、戦闘機のパイロットが一歩か二歩先を読みながら操縦すること。
突発的な仕様変更やリスクによって、プロジェクトはすぐに傾く。
だから、その慣性力に負けないように、早めに手を打つ必要がある。

チケット駆動開発では、この作業はロードマップの最新化の作業に相当する。
イテレーションをバージョンに見立てて、現在作業中のバージョンだけではなく、その一つ二つ先のバージョンのチケットも見ながら、先手を打つのだ。
チケット駆動開発ならば、イテレーション単位にバージョンをリリースできる。
ウォーターフォール型開発ならば、段階リリースに相当するだろう。

この章で重要な言葉は「コーディングパイプライン」。
UnixのPipeのように、複数の担当者が連携して作業することを示す。
設計者が設計書を用意して、開発者が設計書に従ってコーディングし、テスターがそれをテストする。
このパイプラインがスムーズに流れるように、プロジェクトリーダーはあらかじめ準備しておく。

コーディングパイプラインは、Redmineの優れたワークフロー管理機能によって、意識しなくても、チケットの作業状態によって自動的に置き換わる。
駄目なプロジェクトは、このワークフローのバリエーションが少なすぎてチームが回らなかったり、逆に多すぎて混乱する。
コーディングパイプラインは、バグ修正と検証のワークフローにもなる。

「表明を破棄する」は、状況によって以前約束した作業を変えることを意味する。
チケット駆動開発ならば、チケットの見積もりよりも工数がかかった場合、チケットを分割したり、担当者を入れ替えたりするだろう。
この作業は、変更管理につながる。
「変更のマネジメント」はPMBOKやITILの変更管理で既に具体化されている。
そのフローをチケット駆動開発上で実現すればいいだろう。

「動いている標的を狙う」はまさに「変化を抱擁せよ」。
最初に作ったロードマップ(計画)がその後も変わらないことはありえない。
むしろ、状況に応じてロードマップも変えていく。
だからと言って、ロードマップ(計画)は不要ではない。ロードマップはチームの羅針盤だから。

実際のプロジェクトでは、リスクを見つけたものの、現時点では優先順位が低い場合がある。
でも、後になったら、そのリスクが大きくなるかもしれない。
だから、そのリスクは課題として一旦チケットへ登録しておき、後のイテレーションでそのチケットを作業すればいい。
チケット駆動開発では、チケットという単位は作業だけでなく、リスクとして扱える。

【15章 終盤の戦略】

この章も「アート・オブ・プロジェクトマネジメント」の中で興味深い章の一つだ。

「大きな期限は小さな期限の集合体にすぎない」とは、「最終リリースは小さなイテレーション単位のリリースの積み重ね」を意味している。
XPの小規模リリースを実現していれば、リリースをこなすたびに品質も使い勝手も向上していく。

終了条件の定義は、リリース判定条件でもある。
Redmineによるチケット駆動開発ならばその条件は明確だ。
「バージョン(イテレーション)に属する全てのチケットが100％で終了したこと」になる。
Redmineのロードマップを見れば、バージョンが100％であるかどうかはすぐに分かる。

プロジェクト終盤になると降下速度の調整が重要になる。
残作業がたくさんあるのに急角度で終わらせようとすれば、メンバーに負荷をかけることになる。
かといって、納期が迫っているのに、のんびり作業することもできない。

降下速度の調整では、Velocity(チームがタスクをこなす速度)が重要になってくる。
Velocity以上のスピードでチームがタスクをこなすのは無理。
Redmineで、チケットに予定工数をきちんと入力する運用をしていれば、Velocityを計算出来るし、どれだけのチケットをこなせるのか、判断する材料になる。

この時期では、残ったチケットを今のバージョンに含めるのか、次のバージョンで対応するのか、精査する作業が重要になる。
そして、その作業は顧客の合意を取る必要もある。
プロジェクトリーダーの政治力が問われる時期でもある。

バグのマネジメントは、まさにBTSによる障害管理そのものだ。
駄目なチームは、バグを番号で管理していないために、無駄なコミュニケーションロスが生じる。

そして、BTSに貯まったチケット数から、アクティブ(未完了)なバグ数を累計すれば、アクティビティチャートを出力できる。
残バグ数はバーンダウンチャートに相当するだろう。
全バグ累積数を時系列に出力すれば、バグ収束曲線になるだろう。

これらの指標の利点は、まだやるべき作業があるのか、あるいは、やるべき作業はもうすぐなくなるのか、傾向が分かること。
ハードウェアの信頼度成長曲線のように綺麗な図にならないだろうが、バグが収束しつつあるのかどうか、傾向を知ることはできる。

「アート・オブ・プロジェクトマネジメント」で面白いのは、いくつかの指標が書かれていること。
「バグ修正のペース」は修正率、つまりMTTR(平均修復時間)に相当する。
修正率がバグ発生率よりも高ければ、バグはどんどん減っていくはず。
MTTRを短くするには、元々のプログラムの保守性を良くしておくとか、コーディングパイプラインを上手に流用するなどがあるだろう。

「発生されたバグと承認されたバグの数の比率」も興味深い。
「発生されたバグ」は、テスターが発見したバグ。
「承認されたバグ」とは、「発生されたバグ」を分析して、同種バグをまとめたり、仕様そのもので正しいバグなど、判断を下したもの。
バグの分析では、類似のバグを見つけて、同種バグを徹底的に洗い出すのが重要。
ゴキブリ退治のように、卵から潰さなければ、何度も同じようなバグが出てしまうからだ。

「バグがアクティブになっている期間」とはバグの残存期間。
バグの残存期間が長いほど、発見して直すのが難しくなる。

「開発者あたりのバグ数」とは、開発メンバーの作業負荷の分散に関連する。
一人のメンバーにアクティブなバグが集中していると、コーディングパイプラインが停滞する原因になる。
だから、定期的にバグのトリアージを行って、作業負荷を下げる必要がある。

「欠陥フィードバック率(FFR：Fault Feedback Ratio)」とは、バグ修正によって引き起こされるリグレッション率。
1個のバグ修正で2個のバグが引き起こされたら、FFRは2.0になる。
ワインバーグによれば、FFRの受け入れ可能な値は、0.1～0.3らしい。
つまり、10回バグ修正したら、1～3回もデグレ又は別のバグが発生するが、まだフォローできることを意味している。

テスト管理や品質管理でよく知られているのは、バグ修正の時に、別のバグを埋め込んでしまいがちなこと。
仕様を正しく理解していても、プログラムの修正の影響範囲まできちんと分からない時が多いのだ。
だから、バグ修正する時は、別のバグを埋め込んでしまわないようにレビューするのも重要。

Redmineを使っていれば、バグ管理にも使えるから、上記のメトリクスも原理的に計算できるだろう。

Redmineによるチケット駆動開発を実践すれば、単にアジャイルに開発できるだけでなく、プロジェクト管理の奥深さも実感できると思う。