先に結論から書いておく。
作業はきつかったが、デスマーチではなかった。
良かったっぽいところ
- マネージャはエンジニアの見積の3倍を客に提示した。そしてそれでちょうど良かった。
- チーフプログラマはかなり我儘だったが、マネージャは決して彼の意見を否定することはなかった。(マネージャの意見を通すときはプログラマの意見を「拡張する」形をとった)
- ログ分析機能などは「ダウンロードしてExcelでやったほうがいいよ」でばっさり。
- 可変要素をとにかく無くす。 可変の要素は上限を設ける。(テストがすごく楽になった)
- ペアプロはやはり良い。 ソースコードの品質のそろい方は半端じゃない。
- S2Daoがすごく良かった。 私が新人だった頃SQLはViewであると教えられたが、初めてその意味が分かった。
- モックアップで客と話をする。 仕様書ではなくマニュアルで打合せをする。
印象に残ったところ
- プロジェクト中に「嘘」が無かった。 意図的に言わない場合はあっても、異なる情報が伝わる事は無かった。
- 会議(フェーズ移行判定会議など)の権威が最後まで失われなかった。 新人が作ったグダグダのテストプロセスでさえメンバーはその権威を尊重した。
他にも色々あったと思うが4年ほど前のことなのでこれくらいが精一杯っぽい。
で、プロジェクトの流れ
二つ目のサービス開発開始までの期間
一つ目の時は受注確定前に一ヶ月ほど要件を煮詰める時間があったが、今回は前サービスのリリースと同時に開発開始となるので、テスト期間中に要件詰めを同時に行わなければならなかった。
かつ、客先で行うのでチーフプログラマとマネージャのみで詰め、テスト終了後に開発メンバーに展開する事になる。
その結果、要件は詰め切れないまま開発が始まる事になる。
二つ目サービスの概要
一つ目サービスの約3倍の機能。 要件のうち三分の一はペンディング。
いくつものクラス(エンティティ)が複雑に状態遷移し、相互に関係するような割とめんどくさいビジネスだった。
たとえばサービスを受けている会員と会員に対するサービスがあり、それぞれ複数の状態をもち、一方の状態が変わる際に関連する相手方の状態も特定のルールに従って遷移するようなイメージ。
開発開始
開発メンバーは2倍に増える。 マネージャにもサポートがつく。
開発用データベースはバーチャルマシンで展開。 eclipseはzip解凍一発で開発環境になるように固めて展開。
機能が大きく分けて5つ。 独立した1機能は1ペアに任せ、あとの4機能を2ペアで一週間に一つのペースで実装する方針。
土日に要件を詰め、月曜に設計して、水曜日までにビルドして木金でテスト&デバッグ。
ペアプロの効率を上げるために、一人はテスト実装で一人はコーディング(これは最近では普通に行われているだろう)。
設計は全員参加。
一週間毎にベース部分にどんどん機能が追加されるような実装。
既存機能を「修正」することはせず、かならず「追加」して対応。 これでテスト済みの部分との品質を分離した。