影舞駆動開発

最近、とあるプロジェクトでおもしろい開発プロセスが確立されているのを知りました。その名も「影舞駆動開発(KDD)」。その名の通り、BTSである影舞を中心としたプロセスです。どういう物かというと、

1. 顧客の要求や仕様変更を全て影舞に登録する。
2. バグも影舞に登録する。
3. 登録内容はそれぞれカテゴリを分けて管理する。
4. 登録された内容をSEが、承認し作業分担やPriorityを決める。
5. フィードバック内容と決められたPriorityに従って、開発者(PG)が作業する。

こんな感じです。このプロセスの利点と欠点を書いてみます。

• 利点
  • BTSを介して、情報の共有化ができる。
  • 承認プロセスを採用しているので、無駄な作業は発生しない。
• 欠点
  • カテゴリ分けしているとはいえ、要求とバグを同じように管理しているため混在する可能性がある。
  • 「登録→承認→スケジュール管理→フィードバック」となるので、フィードバックされるまでに時間がかかる。
  • 登録内容(文章)の記述方法に個人差がでる。(これは記述ルールを決めれば問題ない？)

現状は、BTSに登録する作業に、コストと時間がかかってしまい、作業効率という面で如何なものか？という気がしますが、最終的にこのプロセスがどのような結果になるかを見守って行きたいと思います。