アジャイルにおける罠や落とし穴（失敗例）
みなさんこんにちは。@ryuzeeです。
Sean Landis氏のTraps & Pitfalls of Agile Software Development - A Non-Contrarian Viewにて、 よくあるアジャイルに関する失敗パターンを挙げられていたので抜粋・意訳にてご紹介します。
個人的に大事だと思うのは4点目です。 「アジャイルはチームと個人の規律、コミットメントやオープンさを機能不全の組織が持つそれよりもより多く必要としている。 にも拘わらず機能不全の組織がまるで銀の弾丸かのようにアジャイルに対して希望をもってしまう。」というのは良く見てきた例のひとつで、こういう組織に限って、色々な理由をつけて教科書通りにやってみることなく、「自社の特別な理由」を盾にして最初から「破」の状態で始めてしまい、また短期的な評価のみで、アジャイルが有効だの効果がないだのと判断をしてしまったりします。
あとは8点目。 「人々はアジャイル開発がすべての問題を少ない努力で解決すると思っていて、期待にそぐわなかった時は幻滅してしまう。」 むしろアジャイル開発は必要な努力を正しいタイミングで行うものだと思うので、少ない努力ってなんだろう、と思います。
- アジャイルチームは技術的負債を速い速度で積み上げてしまいがちである。急いでソフトウェアの開発を始めてしまうことで、事前の設計が不十分であることがある。たぶんリファクタリングに過度な期待をしているかもしれない。ただしリファクタリングは完成を急いでいる状況では無視されるかもしれない
- うまくいくアジャイル開発ではチームメンバーが大人としてふるまうことを前提としている。そうではない場合はチームは素早い開発とはほど遠いものになる
- アジャイルなメソッドに対する誤解が「いつも緊急」という馬鹿げた文化をもとにチームを燃え尽きさせてしまう
- アジャイルはチームと個人の規律、コミットメントやオープンさを機能不全の組織が持つそれよりもより多く必要としている。にも拘わらず機能不全の組織がまるで銀の弾丸かのようにアジャイルに対して希望をもってしまう
- アジャイルチームにおける高い透明性によって低い生産性をひどく目立たせてしまう。利点としては組織が正しいアクションを取ることによって改善しうるということではあるが、正しいアクションがない場合は低い生産性をサボタージュとみなしてしまう
- アジャイルチームは戦略的なゴールを犠牲にして、戦術的な達成(技術的欲求の追及)にフォーカスしてしまいがちである。全体像が明らかでないままにすすめることは大きな損失を生んでしまう
- たくさんの責任を背負っているプロダクトオーナーにとってアジャイルは大変だ。プロダクトオーナーがチームに十分素早く情報を与えたり対応できないためにボトルネックになってしまうこともあり得る
- 人々はアジャイル開発がすべての問題を少ない努力で解決すると思っていて、期待にそぐわなかった時は幻滅してしまう
- 責任のなすりつけあいのようなことが他のビジネスユニットから発生したり、チームではなく、個人間で発生してしまうかもしれない
- 製品のかじ取りのためにプロダクトオーナーに多くの力が与えられすぎる
- アジャイルはプログラマー中心の話で、組織間どのようにバランスを取るかについては不明確なままにしてしまっている。開発者以外のためにドキュメントやコーチングが必要
それでは。
