« 入門Mercurialの感想 | トップページ | TestLinkの運用例part2 »

2009/09/07

チケット駆動開発のベストプラクティスを収集したい

チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。
理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。

僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。
但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。

1・チケット・ファースト(Ticket First)

【説明】
基本は、プロジェクトの作業はチケットを受け取ってから始める。
チケット無しで作業はしない。
また、SVNコミット時に、チケット無しのコミットも不可。

【効用】
チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。
進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアルタイムに進捗情報を出力できる。

また、ソースや設計書などSVN管理下の成果物はチケットと連携しているので、作業の発生源と成果物のトレーサビリティを保障できる。
これによって、運用保守時にパッチの修正理由を探しやすい。
更に、ソースからリバースエンジニアリングする際に、チケットから仕様や要件を作りやすくなる。

BTSとバージョン管理の連携は、Redmine・Trac・Mantis・Jiraなど殆どのBTSで実現できる。

2・チケットで分割統治(Divide and Conquer)

【説明】
複雑なタスク、工数がかかるタスク、遅延したタスクは、追跡可能なタスクまでチケットの粒度を細分化する。
それらチケットを、リリースするバージョン毎にグループ化してまとめる。

【効用】
プログラミング作法の分割統治の概念をタスク管理にも応用する。
つまり、責務の多いクラスは結合度や凝集度の観点で分割するように、担当者一人に責務が集中して進捗が滞りやすいタスクは、分割統治を行い、チケットへばらす。

細分化されたチケットは、イテレーション計画又は、スパンの長いリリース計画に基づいて、どのバージョンでリリースするかという観点でグループ化する。
バージョンをXPのイテレーションに相当するように運用すれば、自然にアジャイル開発になる。

3・小規模リリース(Small Releases)

【説明】
バージョン毎に小さく作って小刻みにリリースする。
リリース結果は終了チケットの履歴として残る。

【効用】
XPの小規模リリースのプラクティスと同じで、チケット駆動開発はその実装プロセスになる。
リリース予定のバージョンと関連チケットの一覧は、BTSのロードマップ機能として表示できる。

そして、リリースしたバージョン、終了したチケットは、そのままリリース履歴として残る運用になる。
RedmineやMantisには、ロードマップと変更履歴(リリース履歴)が機能として存在しているので、自然に小規模リリースを運用できる。

4・ふりかえり(Retrospect)

【説明】
チケット集計結果からワークフローの運用などを次バージョンで改善する。

【効用】
バージョンをXPのイテレーションのように扱うと、自然にアジャイル開発で運用でき、イテレーションの開発リズムが生まれる。
イテレーションをリリースし終えたら、開発チームでKPTでふりかえりを行ってみよう。

バグが多く出たのは何故か?
特定の作業がやりづらかった理由は、ワークフローが現状と合っていないのではないか?
チケットの属性を、開発の現状に合わせて増やしたり削るべきではないか?

など色んな問題点、そして次のイテレーションで試したい事が出てくるはずだ。
このふりかえりプラクティスは、PDCAサイクルのCheck(評価)とAction(対策)に相当する重要なプロセスだ。
このプラクティスが上手く回れば、自然にプロセス改善できる。

でも、この4個だけで十分なのか、正直、自信は無い。
他人の運用例なども聞きながら、オブジェクト指向のデザインパターンのように、現場で役立つベストプラクティス集を作り上げたい。

【補足】
Shibuya.trac第4.5回勉強会~チケット駆動開発とTestLinkによる開発プロセスの改善~で、Shibuya.trac有志の方のおかげで、「TiDDのふりかえり」というパネルディスカッションを開くことになりました。
内容は、Redmine/Trac/Mantisでチケット駆動開発を実践した経験を、KPTの観点でパネラーがふりかえるものです。

そこで、勉強会の参加者からもパネラーへ質問したい内容を募集しています。
興味ある方は、Shibuya.trac第4.5回勉強会~チケット駆動開発とTestLinkによる開発プロセスの改善~のWikiへ直接書き込んで下さい。

|

« 入門Mercurialの感想 | トップページ | TestLinkの運用例part2 »

Redmine」カテゴリの記事

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

はじめまして。

2の分割統治についてですが、分割したチケットを管理する(分割元の親チケットとの関連づけなど)良い方法や、あるいはそれを支援するツールのようなものに関する情報は何かお持ちでしょうか。

私が使ったことあるのはTracだけですが、あれはチケット間の関連を管理する方法がなかったように思われます。

分割したときに元のチケット(親チケット)との関連が失われてしまうと、管理上問題があるのではないかと思います。

逆にチケットの親子関係を管理することによって、子チケットを全てクローズすると親チケットもクローズされるようにしたり、子チケットの見積もり時間と完了状態から親チケットの進捗状況(パーセント)を算出する、などという事も考えられそうです。

最初から全て適切な粒度のチケットを作成することは困難だと思われるので、随時分割していくべきだとは思う(バックログに入っている段階では粗粒度タスクにしておいて、今回リリースに含めるとなった場合にブレークダウンする等)のですが、どこから分割されたものか?というトレーサビリティがないと管理が難しそうな気がします。

投稿: Lizy | 2009/09/08 02:43

こんにちは

BTSというだけあって、フローの追跡機能が
素晴らしいですね。
カスタマイズできたら便利でしょうね~upwardright
進捗管理したい様々な事に応用がききそうです。営業の進捗管理なんかに使えないか
なと思いました。


後工程から投入するわけではないですが、
チケットは、TPSのかんばんに似ている
印象をうけました。

投稿: YF | 2009/09/08 12:55

◆Lizyさん

Redmineには、チケットの相互リンク機能として「関連する」「重複する」「先行する」「ブロックする」の4種類があるので、この関係を上手に使えばいいと思います。
ちなみにMantisにも、子チケットを親チケットでまとめる機能もあります。
しかし、分割したチケットをストーリーカードとタスクカードに関連付ける機能はRedmineにもまだありません。

チケットの発生源を記録するのは、最終的には要件管理につながります。
現状では、どのBTSでも実現できていません。
BTSでどのように運用するのか、今後の課題と言える部分です。

◆YFさん

Redmineのロードマップ画面がTPSのかんばんに相当します。
ロードマップ画面で、リリース予定のバージョンを見ながら、チケットを取捨選択するのが基本的な管理手法になります。

投稿: あきぴー | 2009/09/09 23:31

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/46147867

この記事へのトラックバック一覧です: チケット駆動開発のベストプラクティスを収集したい:

« 入門Mercurialの感想 | トップページ | TestLinkの運用例part2 »