Pivotal Trackerを使ったアジャイルでスクラムなイタンジ流プロジェクト管理

横沢です、いつもお世話になっております。

本日は少し趣向を変えてプロジェクト管理的な部分の記事を書いてみたいと思います。 ちなみにタイトルはナウい感じの横文字を適当に並べてみました(最近、弊社開発チームではナウいかナウくないかが活発に議論されております)

イタンジではPivotal Tracker(以下PT)とGitHubのissuesを使ってタスク管理しています。 PTでは様々なアジャイル手法論で解説されている通り、「ストーリー」というそれなりにまとまった単位のタスク(の集合ですね)を登録しています。この「ストーリー」についてはチームメンバーと共有し、優先順位の共有・確認、スプリントによるざっくり納期の共有・確認を行っています。とは言っても何もアクションが無いと放置されてしまいがちなので、週一でストーリーの実現状況をレビュー、いわゆる画面レビューと、翌週スプリントの優先順位を確定しています。大まかな流れを例示するとこんな感じです。

水曜日:前週(仮にweek1スプリントとする)で開発した機能をレビュー、翌週(week2スプリント)の優先順位確認@チームメンバー全員 ↓ 木曜日:week2スプリントのストーリー開発 ↓ 金曜日:翌週以降(week3スプリント以降)の優先順位を変更 ↓ 月曜日:新規ストーリーをICEBOX(冷蔵庫)に登録 ↓ 火曜日:登録されたストーリーのポイント見積もり ↓ 水曜日:以下略

PTの何が良いかというと大きく分けて三つあると思っています。 1:ドラッグドロップによる簡単な優先順位の入れ替え 2:ポイント見積もりによるベロシティ(1スプリントで行う作業量)の明示化 3:スプリント単位によるざっくり納期の可視化 この三つにより、非エンジニアメンバーでも気軽に優先順位を随時変更でき、かといってベロシティの目安が決まってるので無理に詰め込む事も出来ず、現実的な納期が見えてくる。エンジニアは優先順位が高いストーリーを、自分が見積もった現実的な納期で上から順番にやるので開発に集中できます。アジャイルの基本的な役割分担ではプロダクトオーナーが明示的に存在するのですが、イタンジではプロダクトオーナーが誰であるというのは確定していないので、ストーリーの追加や優先順位の見直しについては今のところメンバー全員が触れています。 この様な感じでチームメンバー全員に良い効果があると思いPTを採用しています。参考までにPTのスクショを貼っておきます、モザイクだらけで参考にならない感じもしますがw blog_1

さて、とは言ってもストーリーは大まかな単位なので実際に開発していくとなると細かいタスクが複数出てきます。それらの小さいタスクについてはGitHubのissuesに分割して登録しています。こう書くと二重管理でダメダメっぽい感じがするのですが、GitHubはコミットメッセージにPTのストーリーIDを記入することでPTのストーリーと関連づけが出来るんですね。これによってgit操作からPTのステータス更新が出来るので二重に操作する事を防げます。勿論、これだけで完全に二重操作を解消できる訳ではないので、その辺りが今後の課題です。

イタンジは4月から人員が増えたという事もあり、この辺りの「プロジェクトの進め方」というのはまだまだ手探りでやっている感じです。本記事への突っ込みや、ベタープラクティスが有れば是非教えて頂きたいと思っています。なおイタンジでは「教えるだけじゃ出来っこないから、俺がイタンジに入ってがっちりしたスクラム体制作ってやるぜ!」という異端なエンジニア・ディレクターを募集しております。