アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。
なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。
タイトルですべてです。それ以上のことはない。
スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。
それだけなのですが。
設計ができない
アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。
設計書という体裁では不要の場合もありますが、設計は必要です。
思いつく限り書き上げると以下の通り。
- プロダクトオーナー(お客さん)との合意形成のため
- 全体で何を作るのかを明確化するため
- 必要に応じて作る優先度を明確化するため
- 作るためには予算、人、時間など何が必要なのかを明確化するため
- 作ったものが何であるかを明確化するため
ウォーターフォール開発を主体にしている人からすれば当然考えてからつくりはじめる事です。
これから何を作るのか、何をしなければいけないのかが判らないまま始めるというのは厳しすぎる。
予定に厳密に従う必要はないと思いますが*1、予定を立てないとずるずると延々と工期が延びてしまうわけですよ。
せめて、何をいつまでに作りたいのかだけは最初に考えましょう。
失敗ができない
イテレーションで前回の失敗を引きずり続けるという話を聞くことがあります。
企業文化によるところが大きい。
失敗を失敗として認められない文化。
スクラムという最新の開発手法を導入することを偉い人が決定をして高い金を払ってコンサルタントに入ってもらったのだから失敗することがあるのだろうか。いや、ない。*2
冗談みたいな思考ですが、こういった思考が蔓延している場合があります。
実際問題失敗することは多数あるわけで。
そもそもプロジェクトが成功する確率なんて微々たるものだったりします。
(参考)成功率は31.1％ 第2回 プロジェクト実態調査（対象800社）
アジャイルの原則において、動くソフトウェアを短期間でリリースするようにしているのは、失敗を明確化するためです。
失敗した後に、舵を取り直して、成功する方向へ導く。
ユーザーがほしいものと作ってしまったのものが別であった場合に、ユーザーがほしいものに近づける、近づける必要があるかを判断する。
スケジュールが遅延した場合に、人員を増強する、もしくはリスケする、機能を削る必要があるかを判断する。
逆に、スケジュールが進みすぎた場合に、作る機能を追加したりとか・・・・・・
そういったところを全く考えず、良いものが作れています、進捗問題ありませんとだけ伝えなければいけない組織で短期間のイテレーションを導入することの不幸よ。
