で、プロジェクトの流れ

二つ目のサービス開発開始までの期間

一つ目の時は受注確定前に一ヶ月ほど要件を煮詰める時間があったが、今回は前サービスのリリースと同時に開発開始となるので、テスト期間中に要件詰めを同時に行わなければならなかった。
かつ、客先で行うのでチーフプログラマとマネージャのみで詰め、テスト終了後に開発メンバーに展開する事になる。

その結果、要件は詰め切れないまま開発が始まる事になる。

二つ目サービスの概要

一つ目サービスの約3倍の機能。 要件のうち三分の一はペンディング
いくつものクラス(エンティティ)が複雑に状態遷移し、相互に関係するような割とめんどくさいビジネスだった。
たとえばサービスを受けている会員と会員に対するサービスがあり、それぞれ複数の状態をもち、一方の状態が変わる際に関連する相手方の状態も特定のルールに従って遷移するようなイメージ。

開発開始

開発メンバーは2倍に増える。 マネージャにもサポートがつく。
開発用データベースはバーチャルマシンで展開。 eclipseはzip解凍一発で開発環境になるように固めて展開。
機能が大きく分けて5つ。 独立した1機能は1ペアに任せ、あとの4機能を2ペアで一週間に一つのペースで実装する方針。
土日に要件を詰め、月曜に設計して、水曜日までにビルドして木金でテスト&デバッグ
ペアプロの効率を上げるために、一人はテスト実装で一人はコーディング(これは最近では普通に行われているだろう)。
設計は全員参加。

一週間毎にベース部分にどんどん機能が追加されるような実装。
既存機能を「修正」することはせず、かならず「追加」して対応。 これでテスト済みの部分との品質を分離した。

設計や要件のペンディング事項などもすべてBTSにあげて管理。

テスト開始

内部テスト要員にはバーチャルマシン化した開発環境を展開。
一部のサービスが未実装のままテスト開始。 内部テストもなぜか現地作業。
テストしながら追いつかれる前に実装。 またはテストでNGだして「デバッグ」名目で実装。
チーフプログラマと他メンバーが地理的に別れるので以下の工夫をする。

  • subversionのhookでコミットログをgtalkに流す。
  • 1コミット1作業を徹底させる。(複数のバグを同時に直さない)
  • どの作業がどのバグのためか必ずコメントに記載する→BTSのコメントに載るようにしてある。
  • ドキュメント化が必要になるような作業はソースコードJavaDoc)に書く
一つ目サービスの機能追加案件発生

ここからそれぞれ一回づつ機能追加案件が発生するが、基本的には以下の方針で対応できた。

  • 週初めに設計して一週間でマイルストーン
  • テストと実装を同時に行うタイプのペアプロ
  • 機能をBTSにあげて追跡
  • アトミックな作業を心がける(1コミット1作業)


とりあえずこんなところ。