無料ブログはココログ

« [Redmine] ワークフローの視覚化 | トップページ | [TiDD] 制約による高品質ソフトウェアの開発 »

[TiDD] チケット駆動開発の意義

方法論としてのチケット駆動開発の意義を考えてみました。

1.コンパクトな方法論

昔の方法論は今から比べるとコンパクトなものでした。構造化設計ならトップダウンにはトランザクション分割、ボトムアップにはSTS分割があり、あとはモジュール強度とモジュール間結合度を考慮できれば基本的に十分でした。

最近の方法論はプロセスの議論と結びついているので、とにかく巨大で、実施するのが大変です。このため、方法論は巨大なプロジェクトで実施されますが、普通のプロジェクトではフレームワークや開発環境をベースにした開発スタイルあるいは思想の導入にとどまっていると思います。

チケット駆動開発は技術よりはライトウェイトなプロセスのルールが中心ですが、開発全体を統率できる可能性を感じています。

2.高付加価値ソフトウェアへの対応

かつてのアーキテクチャを重視していた頃は、アーキテクチャの実現に多くの工数が必要でした。近年はフレームワークを用いることで、少ない工数で高付加価値ソフトウェアを開発できるようになりました。

このことは、プロジェクトの管理を困難にしました。従来は開発規模は行数で見積もることが多かったですが、行数に比較して多くの機能が実現できる用になったので、行数による管理は困難になりました。

そこで、画面数や機能数を元に見積もることも増えました。しかし、機能数や画面数と必ずしも比例しない環境の構築や運用テストなどの存在がプロジェクト管理を難しくしています。

チケット駆動開発はプロジェクトをタスク数や工数といった直接的な尺度で管理しますので、近年の高付加価値ソフトウェアに向いていると思います。

3.オープン環境

かつてのプロセス改善では、ツールによってプロセスを自動化することが多かったものです。しかし、最近はツールが肥大化し環境になっていますので、プロセスが特定の環境に依存しやすくなっています。

しかしチケット駆動開発は、ツールへの依存度が低い方法論です。どちらかというとRedmineが向いているのではないか、という個人的な感想はあるものの、Tracの方が自由度が高くて良いといわれる方も
おられます。

このように、チケット駆動開発は特定のツールに依存しないので、将来、利用しているツールの開発が中断された場合も、(環境の移行は必要ですが)方法論を大きく変える必要がありません。ツールの購入費用も不要ですので、安心して始めることができます。

このようにまとめてみると「さすが開発現場で生まれた方法論だなぁ」としみじみと思いました。

« [Redmine] ワークフローの視覚化 | トップページ | [TiDD] 制約による高品質ソフトウェアの開発 »

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

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

プログラミング」カテゴリの記事

コメント

コメントを書く

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

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

トラックバック

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

この記事へのトラックバック一覧です: [TiDD] チケット駆動開発の意義:

« [Redmine] ワークフローの視覚化 | トップページ | [TiDD] 制約による高品質ソフトウェアの開発 »