まちゅダイアリー

■ 「Tracではじめるバグ管理入門」を書きました

ITpro のサイトに、Tracではじめるバグ管理入門という記事を寄稿しました。 とりあえず Trac をインストールしてみたけど、Wikiとリポジトリブラウザしか使っていないという人向けに、チケットの使い方を説明したものです。 以下のようなことを書いています。

• バグ管理が必要な理由とその課題
• Tracのチケット機能を使うメリット
• チケットを使ってバグを管理してみよう
• ちょっと便利な機能（Wikiにチケットを表示、権限の割り振り、Subversionとの連携、ワークフローのカスタマイズ）

特に、複数の開発メンバでチケットを運用するときのイメージがわくように心がけました。 去年のITpro ChallengeでLTしたチケット駆動開発と一緒に読んでもらえると嬉しいです。

■ チケット駆動開発について

「本日のリンク元」で見つけたサイト。

• プログラマの思索

以前からチケット駆動開発について何度か言及されている。 特に、アジャイル開発とチケット駆動の親和性について、経験を元に考察されている。

• チケット駆動開発の背景
• チケット駆動開発の戦略
• ウォーターフォール型開発はバージョンの概念が無い

個人的にはウォーターフォールでも、５人くらいの開発であればチケット駆動は有効だと思ってる。 WBS (Work Breakdown Structure) の最小単位が開発を駆動するチケットと考えればいいし、レビューのコメントもチケット化することでその後の追跡は容易になる。 「ストックとフロー」論でいくと、チケットがフローなので仕様書がストック。 「ミクロとマクロ」だとすると、チケットがミクロでプロジェクト計画がマクロ。

でも、開発メンバの人数が数十人規模になると、チケットによるタスクの割り当てだけでは回らなくなる。 マクロ的な視点での作業の割り当てやスケジュール管理には、やっぱりそれ専用の仕組みが必要になる。 例えば、100ページのドキュメントを20日間で作成するタスクがあったとして、チケットだけではその進捗状況を管理することは難しい。 100個のチケットに分割すればページ単位の進捗状況を把握できるんだろうけど、それって現実的じゃない。 とすると、両手の指で数えられるくらいのチケットで収まるかどうかが、一つの判断基準になるのかもしれない。