プログラマの思索

チケット駆動開発の記事があったのでメモ。

【元ネタ1】
チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead

kanu_orzさんによるTracのチケット管理の運用例。
インシデント管理や問題管理にTracを下記で運用していると思われる。

・チケットをExcelで一括インポート
・Tracで工数を入力、集計
・チケット集計結果をExcelで出力

特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。

これは、いわゆるエンドユーザコンピューティングかもしれない。
つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に帳票(ここでは月次報告用の工数集計)出力する
のは、Tracで行わず、ローカルPC上で作業しているから。
何でもかんでもシステムで作業してもらう必要はなく、スキルがあれば、元ネタから自分で作ればいい。

また、興味深いのは、インシデント管理と問題管理を分離しようという問題意識を持っていること。

「インシデントからそのまま問題管理へ移行してしまうので、初期対応状況の進捗把握が難しい。」
「他からみた場合、対処せず放置しているように見える。」
という指摘は、そうだと思う。

障害修正の発生源を探ると、顧客からのクレームや問合せが発端だった、という時は多い。
チケット駆動開発では、インシデント管理と問題管理のチケットを混在させると、ワークフローやチケットのライフサイクルが異質なため、扱いづらい弱点がある。

だから、ワークフローの単位でプロジェクト別に分けた方が、おそらく運用しやすいのではないかと思う。

僕の少ない経験では、チケット駆動開発のワークフローは、ITILの言うインシデント管理・問題管理・変更管理・リリース管理の4種類にまとめ上げられると思う。
つまり、SW開発や運用保守の日々の作業は、上記の4種類のいずれかのワークフローに帰結すると考えている。

【元ネタ2】
redmine勉強会に参加してきました－実践redmineカテゴリ設計にご用心 - かたるほどでもない技術系ブログ

20090612 実践Redmine @ Redmine勉強会

6月に開かれたRedmine勉強会でのRedmine運用例。
興味深いのは、「各画面で利用できる分類まとめ」のページ。
このページで、Redmineのチケットが各画面からどのように参照されるのか、が一目で分かる優れもの。
チケットという一つのインスタンスをこれだけ多くの観点から集計したり参照できるのだから、Redmineは優秀だと思う。

読んでみて、感想をメモ書き。

「なぜかバージョンに対してwikiが設定できる」とあるが、その理由は、バージョンをシステム開発のマイルストーンと考えれば、そのマイルストーンまでにやるべき作業の詳細や一覧をWikiに書きたい要望があったからではないか、と推測する。

「トラッカーはどの画面でも現れる。ただ、権限設定とセットとなっているので管理には注意が必要」という指摘は、トラッカー(チケットの種類)がワークフローそのものだからだ。
Redmineのトラッカーと言う概念は、Tracにおけるチケットの種類に相当するが、Redmineの方がはるかにワークフローという概念がはっきりしている。

「バージョンはプロジェクト毎に自由に設定でき、なおかつロードマップを利用されるために欠かせない分類」という指摘は、Redmineのバージョンが、XPのイテレーションやScrumのスプリントに相当するものだからだ。
Redmineのバージョンの概念は、Tracのマイルストーンやバージョンに相当するが、Redmineの方がはるかにアジャイル開発っぽいように思う。

「ステータスはあくまで状態でしかなく、後の分類には利用不可能」の指摘は本来の意図がよく分からなかった。
ワークフローの観点では、ステータスは非常に重要だ。
Redmineサマリでは、ステータスごとにチケット数を集計してくれる重要な機能だ。
だからこそ、進捗報告の資料の元ネタにもなりうる。
おそらく別の文脈で話されたのだろうと思う。

「カテゴリは、プロジェクトごとに柔軟に運用可能」の指摘は、参考になった。
RedmineのカテゴリはTracのコンポーネントと同じく、システムの機能の単位だ。
例えば、Javaのパッケージの単位、バージョン管理のtrunkやbranchのようなコードラインの単位、あるいは、jarやwar、DLLというコンポーネントの単位が相当するだろう。
だが、上記の例から離れて、成果物の単位、工程の単位、あるいは、1つのワークフローにおける種類にしてもよいと思う。

つまり、「新規→修正→解決→検証→完了」という問題管理のワークフローがあった場合、そのワークフローは障害修正だけでなく、新規開発やレビュー工程でも使える。
だから、例えば、「問題管理」というトラッカーがある場合、そのトラッカーには必ず「バグ修正」「新規開発」「レビュー」のカテゴリをアサインする運用があってもよいと思う。

他の人のチケット駆動開発の運用例は非常に参考になるので、共有していきたい。