アジャイルとウォーターフォール
笑った。
ウォーターフォール大好き人間達にいつも言われたことは
■ - ( ・ω・)ノ＜しすてむ開発。
「リスクと問題点は全て洗い出して解決しなきゃいかんのです。
随時解決するなんてリスクはとれませんよ」
こいつは将棋を指す時「詰み」まで読み切ってから始めるのか？
それはさておき
・某大企業でのとある大規模プロジェクトをagileでやった。開発人数は50〜80人。
大規模プロジェクトでagileやった結果がこのざまだよ - World Digger
・クリティカルでないシステムだったため、SI側/会社側もagileでやることをOKした。
ざまも何も、Agile失敗パターン三部作 - サンフランシスコ出羽守手記(masayangの日記に書かれていることですべてだと思いますがね。
文句付けるだけだと無価値エントリなので経験したアジャイル開発の事例を紹介させていただきます。
要約よりも状況を時系列で書く事で、「これはよくないんじゃない？」とか「これはいいんじゃない？」とか言ってくれる人が現れる事を期待。
それはあるＷＥＢサービスの開発で、期間は６ヶ月。 これから作成予定のサービスは２つ。
発注元はそのサービス提供会社のシステム部門で予算は１億円行くかいかないか。
要件定義書（と彼らが呼んでいたモノ）を元に設計開発テスト導入をお願いしますというプロジェクト。
すでに去年から別ベンダーにより進められており、１サービス＆１管理システムがリリースされている。
が、大炎上した結果１社がリタイア（逃げた？）したのでこちらに話が来たという状況。
残ったベンダーは既存機能の拡張がお仕事。
発注元のそもそもの非システム要望として「超短期開発」がやりたいとのこと。
３ヶ月に１本サービスをリリースできればビジネス的に超有利じゃない？ ってことらしい。
それに対するこちらの状況は、
- 客先まで新幹線で４時間
- 地元は零細（といっては失礼だが）ベンダーばっかりなので、４社で連合してそのうち１社からマネージャが一人
- ベンダー間は車で２０分程度の距離
- 開発者はマネージャ含め５〜１０人前後（時期により若干増減）
この体制で３ヶ月に１本システムをリリースしようというプロジェクト。
結果から言うと「成功」だった。*1
作業の内容
ほとんどがマネージャの力量で決まってしまったのだが…。
まずは要件の再定義
これは受注のちょっと前から着手。
マネージャと主要プログラマ２名ほどで１件目の要件を分析。
やりたい事とシステムに行わせたい事の間に齟齬、漏れ、過剰があるのでそこを「理解して」いただいた。
まずこの時点で、追加を併せても機能を３分の１に削減。（お値段据え置き）
リハビリ
言語はJavaで、というご指定だったのでプログラマーみんなでJavaのリハビリ。*2
という名目で、要件の再定義と平行して管理系の機能を実装開始。 全員で一カ所に集まって作業。
この時点でソースコード管理ツールにSubversion、BTSにmantisを使う事に決定。
アーキテクチャもドメインロジック形式をとる事に決定。
テクノロジーにはstrutsとvelocityとS2daoを使う事もこの時点で決定。（理由は「使ってみたかったから」）
コーディング規約はJavaの標準を採用。 パッケージ構成は簡単なルールだけを決めた。
この辺を決めたのはチーフプログラマ１名。
開発
ユニットテストのレイヤーを「DAO」「ドメインロジック」「Action」の３層に分けて、それぞれテストの粒度と方針を決定。
開発部分の担当は「機能別」ではなく「レイヤー別」に決定。
開発においてTDDとペアプロを実施することに決定。（チーフプログラマは別プロジェクトでの経験有り）
コミット時のコメントルールを策定。
これもチーフプログラマが決定。
がしがし作り込む。
一つ目のサービスリリース
受け入れテストはマネージャ１名とプログラマ２名が現地作業を一ヶ月。
この辺からきつくなる。
なぜなら２件目の要件分析を平行して行わなければならなくなったから。
テストは発注元主体で実施されるが、かなりグダグダ。 社会人２年目の若手が責任者。
テスト項目が記載されたExcelのブックが多数、不具合管理表もExcelシート、管理番号も適当、不具合のマスタも無し。
不具合発見から報告、クローズまでのフローも未定。 というか適当。
だれがいつどこで何のテストしてるのかもよく分かってない。
マネージャはここでmantisと報告用Excelの同期、及びメール捌きを担当。
つづく…。
