アジャイル開発のインフラ

SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。
大量の印刷した紙、手作業の多い仕事に囲まれている。

ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。

一つは、ソースコード管理。
二つ目は、検証可能なビルド環境。
そしてBTS。

この3つについて考えてみる。

【1】ソース管理

プログラミングで仕事するならば、ソース管理(SCM)は必須だ。
ソース管理システムの本質は、前回のプログラムへUndoができること。
つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。

ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。

ソース管理で重要な作業はブランチやタグ付けができること。
ブランチは、枝分かれしたバージョンツリー。
タグは、ある時点でバージョン付けられたソース一式。ブックマークみたいなもの。

普通は、本番リリースや納品時にタグ付けして、バージョンをFixする。
そうすれば、同じモジュールを再リリースすることがいつでも可能になる。

ブランチを使うケースは、バグ修正と新規開発が並行して走っている場合。
特に運用保守フェーズでは、裏で仕様追加に伴う新規開発をしながら、緊急のバグ修正もこなさなければならない。
この時に本番モジュールと新規開発モジュールを区別するために、2系統のソース管理が必要になる。

普通のプログラマなら上記のことは行っているだろうが、実は、Webデザイナーの人たちにはソース管理と言う概念が無い。
だから、HTMLやCSSなどのViewソースは、実はソース管理がすごく難しい状況がある。

彼女たちにもSubversionをマスターさせればいいだけなのだが、彼女たちには難しいらしい。

【2】ビルド環境

ビルド環境の本質は、すぐにリリース可能なモジュールが作れること。
正しく動くプログラムを複製するソフトウェア工場のイメージに近い。

だめなプロジェクトは、すぐにビルドできない。
だから、バグ修正をすぐに反映できない。
結局、すぐに検証できないので、いつまで経ってもプロジェクトが収束しない。

最近のビルドは、単なるコンパイルだけでなく、ユニットテストも通すのが普通だろう。
つまり、回帰テストも通す。

これは、コンパイルの概念を拡張したものに相当する。
つまり、プログラミング言語体系に沿っているだけでなく、ユニットテストという仕様にプログラムが正しく合致しているか、Evaluateしているということ。

だから、最近のビルドは結構時間がかかる。

【3】BTS(バグ追跡システム)

BTSの本質は、アジャイル開発そのもの。
ドキュメント駆動ではなく、動くプログラムにどんどん手を加えて、多種多様な環境やフローにも耐えうるように品質を上げていくプロセスを補強する。

よくありがちなのは、BTSがないプロジェクト。

BTSがないプロジェクトは、結合テスト以降の開発がすごく弱い。
バグ報告からバグ修正、そして検証、リリースに至るまでのプロセスの状態と担当者をプロジェクトリーダーがきちんと把握できていない。

詰まる所、そのプロジェクトはおそらく殆どの場合、ウォーターフォール型開発。
だから、たくさんのバグ報告と修正に追われて、収束が付かなくなる。

Redmineには、バグ修正のステータスに特徴がある。
普通は、下記のバグ修正のフローだろう。

新規(Open)：テスト担当者がバグ報告する
↓
担当(Assigned)：プロジェクトリーダーがPGをアサインする
↓
解決(Resolved)：PGがバグ修正する
↓
検証(Verified)：テスト担当者がバグ修正を検証する
↓
終了(Closed)：プロジェクトリーダーがバグ修正内容を確認する

Redmineでは、更に「却下」「フィードバック」というステータスがある。
「却下」とは、バグ報告を修正せずに終了すること。
例えば、「このバグは仕様なのです」みたいなケースだろう。

「フィードバック」とは「差し戻し」。
例えば、バグ修正して検証したら、実はバグが直っていなかった場合、PGへ差し戻しになる。

上記2項目がデフォルト設定されているRedmineは、実に良く考えられている。

最後に、おそらく上記の3つのうち一つでも欠けたら、多分そこからプロジェクトは炎上する。
ソース管理、ビルド環境、BTSはアジャイル開発のインフラ。