チケット駆動開発のナビゲーションマップ #Redmine

Redmineによるチケット駆動開発のプラクティスをパターン言語で表現したら、ナビゲーションマップでどう描けるか、試してみた。
Slideshareにアップして、ダウンロードできるようにしたので、ご参考下さい。

【参考】
パターン言語の構造と事例集: プログラマの思索

チケット駆動開発のナビゲーションマップ from akipii Oga

【１】チケット駆動開発のナビゲーションマップを作成した意図

「デザインパターン」や「ドメイン駆動設計」や「組織パターン」を読んでみると、最初のページにパターンの関連を表した地図のようなものが出てくる。
それがナビゲーションマップ。
パターンの全体像みたいなもの。

僕は、Redmineによるチケット駆動開発がアジャイル開発ととても相性が良いことを経験した後、そのノウハウを他人に説明し、共有できる方法はないか、とずっと思索していた。
その方法として、パターン言語が一番有効ではないかと思い続けてきた。

元々、XPやScrumを代表とするアジャイル開発はパターンコミュニティと密接に絡んでいる。
XPやScrumでは、重要なプラクティスをパターンという形式でその概念で呼ぶことで、その内容を他人に共有しやすくするだけでなく、こうすれば実践できるよ、というHowも一緒に伝えている。

たとえば、テスト駆動、ペアプロ、継続的インテグレーション、デイリースクラム、小規模リリースなど、そのプラクティスを連呼するだけで、その概念の実体もメンバーで共有できる。

しかし、これがCMMI、PMBOKやBABOK、ITILのような知識体系では、うまく説明できないように思っていた。
アジャイル開発もチケット駆動開発も、理論から生まれたアイデアではない。
現場で試行錯誤しながら、こんな方法でやればうまくいくよ、というプラクティスを抽出し、体系化づけたもの。
決してトップダウンではない。
でも、ボトムアップで生み出された概念は、それを綺麗にまとめる手法があまりないのも事実。

パターン言語は、経験から生み出された暗黙知を形式知に変換する上でとても有効な手法だと思っている。
チケット駆動開発も、XPやScrumのように、パターン言語で表現できたら、もっと伝わりやすくなるのに、とずっと思い続けてきた。

そこで、自分の考えを元にナビゲーションマップで描いてみた。

【２】チケット駆動開発のナビゲーションマップに出てくるプラクティスは下記の通り。(順不同)

1）Ticket First
　チケットから始めよう。
　チケットはタスクカードと同じ。(@sakaba37)

2）No Ticket, No commit
　チケット無しのコミット不可。（@machu）
　トレーサビリティの実現。

3）No Ticket, No Work
　チケット無しの作業不可。(@mrgoofy33)
　チケットに書かれていない作業をやっている人は、「ヤミ作業」している。

4）チケットで分割統治
　タスクはチケットに分割して統治せよ。
　「肥大化したチケット」「停滞したチケット」は分割しよう。

5）チケットはワークフローに従う
　作業手順は、アクティビティ図・チケットの状態遷移図・ステータスのデシジョンマトリクスと同じ。
　ワークフローが１種類しかなければ、「問合せはバグ修正なり」というアンチパターン。
　「モンスターチケット」は、チケットが頻繁に差し戻しされて復活してしまうアンチパターン。

6）チケット集計はワークフローに従う
　進捗一覧、障害一覧、課題一覧などの帳票は、ワークフロー（Redmineならトラッカー）ごとに集計される。

7）棚卸し
　「放置されたチケット」は定期的に棚卸ししよう。
　店舗や工場、倉庫における商品や製品の実地棚卸しと同じ。

8）ペア作業
　チケットはふたり以上のメンバーのやり取りを通してCloseされる。
　チケットは作業のキャッチボール。

9）チケットはシンプルに
　アジャイルに作業したいなら、チケットのカスタムフィールドは最低限にする。

10）ロールでビューを切り替える
　顧客、リーダー、開発者のロールごとに、見たいチケット集計結果は違う。

11）私に聞くな、チケットに聞け
　担当の作業、過去の情報はチケット管理システムに全て記録されている。
　RSS、更新メールで担当の作業は通知される。

12）バックログ
　リリース時期不明のチケットは、バックログや内部課題のような特別なイテレーションで保留する。
　PivotalTrackerならアイスボックス（冷蔵庫）になる。

13）プロジェクトは製品に従う
　プロジェクト（チケットの集合）は、製品単位・顧客単位に分けて管理する。

14）イテレーション・リリースバージョン・マイルストーン一致の原則
　XPのイテレーション、ブランチのリリースタグ、工程のマイルストーンは同期する。
　「Version is Iteration」でもある。
　Redmineのロードマップで実現される。
　バージョンやロードマップ機能を使っていない「空っぽのロードマップ」というアンチパターン。
　手戻りが発生するたびにバージョンがReOpenされる「工程単位のバージョン」というアンチパターン。

15）小規模リリース
　バージョン単位にチケットをグループ化して、定期的に小刻みにリリースしていく。
　開発のリズムが生まれる。
　リリースされるチケット数はVelocityとほぼ同じ。

16）プロジェクトとブランチ一致の原則
　プロジェクトは、リリース可能なブランチと同期する。
　リリース可能なブランチは製品単位になる。

　Conwayの法則、派生開発、ソフトウェアプロダクトラインに通じる考え。
　工程単位のプロジェクト、セクショナリズム、サイロというアンチパターン。

17）No Ticket, No fork
　masterからフォークされた「トピックブランチ」は、チケット単位に作る。
　「トピックブランチ」をマージするタイミングで、チケットはCloseされる。

18）Scrum of scrum
　大規模プロジェクトにおける複数チームの課題管理は、プロジェクトを２層構造にする。
　第１階層を課題管理プロジェクト、第２階層を各チームのタスク管理プロジェクトにする。
　CCB(変更管理委員会・PMBOK)、CAB(変更諮問委員会・ITIL)と同じ。

19）朝会
　XPの朝会、Scrumのデイリースクラム。

20）ふりかえり
　リリース後にKPTでふりかえり。
　得られた知見は、次のイテレーション計画へ反映する。

21）No Ticket, No Release
　チケット無しのリリース不可。(@kuranuki)

22）進捗率・ステータス一致の原則
　進捗率とステータスは連動させる。
　チケットの完了基準を明確にする。
　停滞したチケットというアンチパターン。
　進捗率が９０％のまま停滞したチケットは、90％シンドロームと呼ばれる。

23)プロジェクトで分割統治
　複数チームのタスク管理、複数の製品における派生開発は、プロジェクトで分割して統治せよ。
　一つのプロジェクトにまとめると、「肥大化したプロジェクト」というアンチパターン。

多分、チケット駆動開発のプラクティスは他にもあるだろう。
上記はあくまでも一つの案。
今後ブラッシュアップしていきたい。