■
開発手法と構成人数の話。
大人数でやるにはウォーターフォールモデルだ！
っというのは世の中一般的に聞ける話だ。
が。
最近つくづく思うところがある。
ＸＰやアジャイルは大規模に向かないのではなく、
大規模＝大人数と思われている辺りの大人数になる必要がないんだろなーと。*1
何時でも現状のプロジェクトの反省点を模索するもの。
今改善できなくても次回以降に生かせればよし。
ってことで。
現状はウォーターフォールだけれども、当初予測されたとおりに終わっていない。
ＸＰのほうがよかったんじゃねーかって、技術者側からのナイショ話もある。
もし。
いまのプロジェクトを自分がこなすならどうするか？
そしてそれはどうなっているだろうか？
段階的リリースが行われ、何度か仕様の話変更の話のために遅れるだろうが現状よりははるかにましだ。
書類しかできていなくて、書類すらそろっていなくて、開発に入るためには
初回300ページを越える文書を読み、毎回20枚程度の設計書と格闘する手間が想定されるどころか目に見えている。
類似プログラム、画面を参考にしてソースを作る手間と大差ない効果しかない、
共通化という名の無駄な方式を覚える手間があり、
類似プログラム、画面を参考にしてソースを作る手間もあり、
素人お断りな設計書の難易度とプログラム難易度が保たれ、
見た目のスケジュールを削るために詳細設計、プログラム設計まで落とすことすらしないプロジェクトの現状。
昔見てきたウォーターフォールの大勢と大差ない状況である。
現状の人員でアジャイルな開発をやるとしたら。
人員は抜粋する。絶対にする。
アジャイルについてこれる人材だけでやる。集中的にやる。
そーゆー人員だけで行えばプロジェクトは必ず収縮の方向に向かう。
モチベーションに気を使い、終わりまでの道のりを示し続けるのが当たり前な風潮があれば必然としてそうなる。
そして３ヶ月という時間があればいかようにも出来た。
それを思えば。
人材のそろった状態のアジャイルなら大規模にする必要が無くなると思える。
ひとりの人員が行える作業は必ず１であるという幻想に縛られたモノたちには想像もできないだろうけど。*2
それらを自己の教訓に取り込んで。
ウォーターフォールモデルで工数見積もりして、
アジャイルな開発を行うってのは発注者も開発者も両者ともにやりやすい形態なんでねーかな〜っと思った。
