プロジェクトの進め方は千差万別。
私自身もいろいろな進め方を経験してきました。
今回のプロジェクトは、「ウォーターフォールがいい」とか「XPがいい」とかっていうイデオロギーなところとは関係ないバグ、問題、仕様、改善等を管理するコミュニケーションツールですからそういった視点で見て生きたいと思います。
- きっちり設計してバグを0にして出荷する。
主にウォーターフォールの場合に行われる開発手法
- 問題点や、バグなどをとりあえず順位付けして指定の期日で出荷していく。
XPなどのイテレーション開発など
- 大きな機能があってそれを満たせば出荷する。そこにまぎれて細かい修正を行っていく。
- ひとつずつの細かい単位で修正したら出荷する。
オンラインソフト系の開発方法
こんなもんかなー。
次にバグの引継ぎなど
- バグはそのバージョンで完結。よほどの直すべき問題以外設計変更として開発を行う
バグは基本的に引き継がないためV1とV2にバグ管理の溝がある。
- バグはそのバージョンで完結。ただし残バグの中から新しいプロジェクトへの先送りバグとして送付する。
V1とV2の間には断絶があるが、V1の問題をV2設計に直接的に生かす。
- V1, V2等の区別無く常にバグは管理していく。
うーん結構いろいろなバリエーションがあるなぁ。
特にプロジェクトの考え方がぜんぜん違う。バージョン単位に切って考えるか、連続して考えるか。
テーブル構成を考えてみよう。