はじめに
個人的に失敗するアジャイル開発あるあるだと思っていることを記載していきます。
原則
まず、アジャイル開発の原則の一つとして、以下があります。
計画に従うことよりも変化への対応を
引用: https://agilemanifesto.org/iso/ja/manifesto.html
開発中により良い品質のための仕様変更は歓迎すべきで、スコープや期日を都度調整する、という意味だと捉えています。
失敗する原因
上記原則があるにも関わらず、なんちゃってアジャイル開発の典型的なパターンって以下じゃないだろうかと思う。
・仕様変更は開発途中でもガンガン入れるね♪
・あっ、でも元々のスコープは変わらないよ♪♪
・あっ、もちろん期日なんて変わらないから♪♪♪
・あっ、もちろん要員も今のままで宜しくね♪♪♪♪
ゲロ吐きそう。。
肝入りの案件だから、とか、期日を変えるためには上を説得しなきゃいけなくて難しんだよ〜、とかそういうのも分かりますよ？
でも、これって失敗するの当たり前ですよね？
紐解いていく
まず、これは正しい真のアジャイル開発ではないです。
仕様変更は歓迎すべきであるならば、当然スコープや期日を都度調整すべきです。
調整しないとアジャイル開発の原則に反し、
且つそれってただのブラックな案件ですよね。。
経験談
私の経験で、以下のような案件に遭遇したことがありました（だいぶぼやかして書いてます）
①１ミリも見積もっていないのに期日は決まっていて、且つ厳守の案件
→もはやここからおかしくて、リーダーが勝手に上が求めている期日に当てはめただけっぽい。
→つまり、何の根拠もないスケジューリング🔥🔥🔥
②案件が始まる前にリーダーに理論立てて"期日に間に合わせるのは難しい"ことを報告し、以下を提案
→スコープを狭める、要員の追加、期日を延ばす、仕様変更を極力無くすといった調整をして欲しい
→結果的に仕様変更が少しだけ減るだけでした。。
③当然のように開発中に入る仕様変更、、
④しかも仕様通りに作って触ってもらったら、
"デザインが間違ってました、直しておいてねｰ(⁎˃ ꇴ ˂⁎)"とこれまた当然のように言ってくる
⑤リーダー自身がメンバーのタスクを巻き取るから！というものの、一番簡単な１画面をバグ付きで上がってくる始末（バグ修正は私が行い、なんなら私がやったら30分で出来る簡単な画面作成）
案件始まる前からやばそうだなーと思っていたので、案件始まる前から私自身のタスクを前倒しで進めるようと思い、バッファを捻り出しました。
このバッファを遅れている要員のタスク巻き取りに当てて、結果的に無事期日までに間に合うことが出来ました。
対策
・開発メンバだけでなく、このヤバい状況を関係者全員に共有する
・なんならリーダーだけじゃなく、もっと上の層まで巻き込んで共有する
→巻き込むタイミングは早ければ早いほど良い（例えばPJ開始前とかに分かるのであれば即リスクとして挙げてみる、とかね）、
逆に遅ければ遅い程リカバリができなくなる可能性があるので良くない
以上！