プログラマの思索

チケット駆動開発を運用していると課題管理が難しい。
その難しさの理由の殆どは、課題や問題、リスクなどの概念をきちんと区別していないからだと思う。
以下メモ書き。

【元ネタ】
課題、問題、リスクを区別できていますか？｜プロジェクトマネジメントの現場

Redmineでスクラム実践！～アジャイル開発始めました～ (3/3) - ＠IT

課題管理のチケット駆動開発: プログラマの思索

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

「問題」とは目的を阻害するような「現象」「事象」「症状」。
「課題」とは「問題」を発生させる原因。
「リスク」とは現時点で顕在化していないものの、ある確度で将来課題になりうる事象。

RedmineやTracで課題管理を行う場合、問題という事象をチケットに登録してしまいがち。
でも、本来はいくつかの問題を分析して、どこにその原因があるかを見出し、その原因をチケットに登録して、チケットに対策の提案や対策を実施した履歴を記録していく。
例えば、バグが多い原因が単体テスト不足だったとしたら、それが課題となり、テストケースをきちんと書いて事前レビューするなどの対策が作られて実施していくだろう。

実際のチケット駆動開発では、タスクも課題も両方登録していく状況が多い。
課題があるからこそ、その課題を解決するためにタスクが発生し、そのタスクを実施した結果、課題が解決されたかどうか評価される。
そのサイクルを早く回しながら、次々に出てくる課題を消し込んでいく。
その課題を消し込む際に、課題チケットの内容はソースや設計書などの成果物にパッチあてのように反映される。
チケット駆動開発のトレーサビリティの機能を使えば、それら成果物の更新理由がどんな課題なのか、を後から追跡できるのもチケット駆動開発の利点になる。

Scrumを運用できるRedmineのBacklogsプラグインには「スプリント障害事項」というチケットを登録できるが、これがまさに課題に相当するだろう。
つまり、チームの開発の障害となる課題を登録して、スクラムマスターを中心として課題を解決していくわけだ。

また、チケット駆動開発の運用が慣れたら、リスクもチケットに登録していくようになる。
「この機能にはユニットテストが足りないかもしれない」「この実装部分は将来のためにリファクタリングした方がいいかもしれない」などのように、現在は大きな問題にならないが将来に問題となるような気づきは結構ある。
それらもチケットに備忘録として登録しておくが、リスクのチケットは優先度が低いから現在すぐに作業は実施しない。
次のイテレーション計画を作る時やリリース計画全般を見直す時に、それらリスクのチケットを入れるかどうか判断する運用になるだろう。