アジャイル開発の弱点をプロジェクト管理サーバーが助ける

Redmine、TestLink、Hudsonなどの各種ツールを運用してみて、これらはアジャイル開発を補強するツール群なのだと直感した。
アイデアをメモ。

【元ネタ】
Redmine - Overview

TEF有志によるテスト管理システムTestLink日本語化プロジェクト

Hudsonを使ったアジャイルな開発入門：第1回　Hudsonの導入｜gihyo.jp … 技術評論社

Perl製のソースコードレビューソフトウェア「Codestriker」

VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」

【1】アジャイル開発の利点

XPを代表とするアジャイル開発の有用性は、昨今、色々知られてきた。
アジャイル開発の中で最も有名と思われるXPで最も重要なプラクティスは、小規模リリースだと思う。

小規模リリースとは、イテレーションという短いサイクルで小さく作りこんで小刻みにリリースしながら、システムを機能拡張し、品質を向上していくプロセスを指す。
緊急のバグ修正、突然の仕様変更に対しても、次のイテレーションに取り込む手法で、柔軟に対応していく。

小規模リリースのプラクティスは、メインラインモデルと呼ばれる構成管理と密接に関係する。
メインラインモデルとは、本番環境で稼働中のモジュールと、裏で新規開発中のモジュールの2つのコードラインを並行開発するソース管理手法。
メインラインモデルのおかげで、バグ修正のbranchと機能追加のtrunkの2つのコードラインを小刻みにバージョンアップしながら、品質保持と機能拡張という矛盾した開発スタイルを可能にする。

また、イテレーションは２～４週間のリリース単位でもあるから、一つのイテレーションで実装可能な機能の数は限られる。
従って、ストーリーカードのサイズはおのずと分割され、更に、優先順位付けされて、イテレーションに取り込まれていく。
つまり、高度なマネジメント手法を小規模リリースは必要とする。

又、イテレーションを一つずつリリースしていくうちに、ビルド作業やリリース作業の重大な欠陥、仕様漏れや要件漏れをすぐに判明でき、そのフィードバックをノウハウとして蓄積していく。
これがプロセス改善になり、ナレッジデータベースにつながる。

【2】アジャイル開発の弱点

しかしながら、アジャイル開発を実際の現場に運用するのは難しいと思う。

小規模リリースを実現するには、メインラインモデルと言う高度な構成管理手法を必要とする。
Subversionを骨の髄まで知り尽くしておかねばならない。

小規模リリースしていくには、どの機能をどのイテレーションでリリースしていくか、というイテレーション計画を作らねばならない。
しかし、イテレーション計画は、緊急のバグ修正や突発的な仕様変更に対応せざるを得ないため、頻繁に変わる。
だから、タスク漏れしないようなリアルタイムなタスク管理のインフラを必要とする。
Excelによるスケジュール管理だけでは、イテレーションを管理するのは非常に難しい。

また、XPが提唱する継続的インテグレーションを実現するには、ビルド作業やリリース作業を自動化することが大事。
継続的インテグレーションは、コードラインの品質を保証してくれる重要なプラクティス。
継続的インテグレーションが実現されなければ、回帰テストが難しくなるから、テスト駆動開発のメリットも半減する。

そして、プログラマがあまり重要視していないXPのプラクティスの一つである受入テストが、実は大きな弱点の一つだと考える。
テスト駆動開発は単体テストの観点で、品質を保証するだけ。
XPでは、結合テスト以降のシナリオベースのテストの観点がは弱い気がする。
特に、普通の受託開発では、結合テスト以降のテスト工程で開発人員が最大化するため、メンバーの管理だけでマネージャは忙しくなる。
受入テストの進捗管理や品質管理の観点が弱いと思う。

そして、ペアプロのプラクティスもその重要性や有用性が直感できるにも関わらず、実際の現場では根付かない。
ペアプロの本質は、レビュー工程の代替手段にある。
しかしながら、普通のSW開発では、レビュー工程が実は最大のボトルネックになっていると思う。
設計書のレビュー工程は、要件定義の代替プロセスと化しており、実際の設計の品質向上につながっていない。
実装のレビュー工程は、レビューワーが業務ロジックを知り尽くしていないから、単なるコーディングルールのチェックに過ぎない。
また、従来のレビューでは、複数人が大量の紙を印刷して持ち寄って、長時間議論して、紙ベースでレビューの記録を残すから、レビュー漏れが発生しやすい弱点がある。

【3】プロジェクト管理サーバーがアジャイル開発の弱点を助ける

僕が考えるプロジェクト管理サーバーの概念は、SW開発のプロジェクトを立ち上げる時に必要な構成管理ツール群が乗っているVMwareイメージをWebサーバー上で動かすことだ。
つまり、現場リーダーがSW開発を運営するのに必要な開発インフラが、プロジェクト管理サーバーの機能を持つWebサーバーであるイメージ。

Redmine、Tracでチケット駆動開発を実践することで、イテレーション計画を制御し、小規模リリースを実現するためのタスク管理の役割を担う。

メインラインモデルの実現は、SubversionあるいはGitなどのバージョン管理を使う。
もちろんソースだけでなく、ExcelやWordの仕様書もバージョン管理する。

AntやMavenなどのビルドツールと、CIツールHudsonを組み合わせて、ビルド管理やリリース管理を自動化する。

TestLinkで受入テスト工程を管理することで、テスト工程の進捗管理と、発生したバグ修正をRedmineのようなBTSと連携する。

また、コードレビューはコードレビューWebシステムで行う。
例えば、VMWareの開発でも利用されているソースコードレビュー共有ソフトウェアReviewBoardやPerl製のソースコードレビューソフトウェアCodestrikerなどを使ってみる。

これらのツールの最大の特徴は全てWebシステム上で実現されること。
Webシステムであることの利点は二つある。
一つは、いつでもどこでも誰でもアクセスさえすれば、必要な情報を取得できて更新できること。
もう一つは、実績や作業履歴がDBに残るため、データマイニングを使って、品質や進捗に関するメトリクスを簡単に出力できること。

特に、メトリクスを出力できることは、高度なマネジメントを行うのに決定的に有効だ。

昨今、テスト駆動開発やRuby on Railsなどのように下流工程で大幅な技術革新が生まれているのに、プロジェクト管理やテスト管理は10年前と同じようにExcelで手作業で集計するなど、上流工程でボトルネックになっていることが多くないだろうか？

プロジェクト管理サーバーを導入することで、SW開発のうちで特にプロジェクト管理の部分を強化してみよう。