Training for D-Day

ブログの内容は個人の見解であり、所属する企業を代表するものではありません。

要件が変わりやすいときにだけアジャイルなのか

アジャイルなのかウォーターフォールなのか、という議論はしばしば熱く語られます。
よく言われるのが、要件ががっちり決まっているならウォーターフォールでしょ、ということです。
私は、違うと思います。

「要件と設計と採用技術が簡単(且つがっちり決まっている)であれば、ウォーターフォールでも良い」 と考えています。
いずれかひとつでも簡単ではないとなれば、スクラムなどの手法のほうが適していると思います。


f:id:kshimizu1226:20160802055125p:plain
ウォーターフォールが適しているのは、上記図の「単純」に相当するところですね。

簡単の定義は人のスキルに依存しますが、チームが複数人いて、全員が簡単と答えるなら簡単でいいと思います。
簡単の中身はしっかり確認する必要はありますが。

要件ががっちり決まっていても、チームとして設計または採用技術が簡単ではないと判断したら、スクラムを採用するべきです。
3~6ヶ月後に全く動かないシステムが出来上がる可能性が高いです。

逆にスクラムであれば、出来栄えは、少なくとも1ヶ月後、速ければ1週間で、そのチームが要望されているシステムを構築・実装できる力があるのかもおぼろげながらわかります。

逆にいうと、1-2週間でプロトタイプもしくは薄くスライスされた機能も作れないような実力では、予定通りシステムなんか作れないのです。絶対見積もりも甘いと思うし、計画に信憑性がない。マネージャーもメンバーのスキルを見誤っている可能性が高いです。だったら自分たち自身の実力を把握しながら、把握させながら、スクラムをやったほうがプロジェクトリスクが低いと考えます。
プロトタイプ作成時のコードもちゃんと見る必要があります。プロトタイプだから、スプリント1だからって構造がゴチャゴチャならすでに黄色信号です。