現職場の開発はガッチガチのウォーターフォールである。
開発・リリース後の障害が発生しようものなら開発フローを見直し、不足と思われる工程の補強・レビュー工程の追加など、開発に掛かる工数は年々増加している。

余計なことしなければ 2-3人月程度のボリュームであっても 4-6人月程度の工数で見積もりが行われいてる。

この問題点は開発手法にあるわけではないのだが、開発手法を変えることで本当に抱えている問題点が浮彫になるのではないか。

開発手法としてAgileが優れている、という話をしたいのではない。
完全分業した組織構造に変革をもたらすことを期待して開発手法をAgileに切り替えてみてはどうだろうか、と考えているのである。

実例に学ぶスクラム導入手順
この記事を読んでそんなことを考えさせられた。

開発期間の短縮によってクリティカルパスを検討するだろう。
週 1、隔週の定例会議では物事の進展が遅い、と気が付くだろう。
より早く要件を決め、課題を収束させることを検討するだろう。

機能拡張に耐えられるよう、モジュールの分解・結合度を検討するだろう。
テストの自動化を検討するだろう。

机上でいくら正論を述べ、それらしき対策を立てたところで効果を発揮させるには時間がかかりすぎる。
身をもって体験するのが一番早い。

失敗したなら戻せばいい。成功よりも失敗の方が学ぶことは多い。
年に 2-3程度の失敗ではなく、月 2-3度失敗すればいい。




なんて上から目線なんだ、俺。

CAPTCHA