“計画に従うのではなく変化に対応する”ことはアジャイルの強みだと考えられている。しかし、このような柔軟さは実践では上手く機能しないと考える人もいる。そのような人々はアジャイルプロジェクトは変化を管理し、プロジェクトの遅延や品質問題を引き起こしかねない過度の柔軟性を想定する顧客や、困難な価値提供を抱えるチームを管理しなければならないと考えている。アジャイルは期待される効果を発揮できないのだろうか。それとも、チームや組織がアジャイルを導入する方法に問題があるのだろうか。
CIO.comのwhy agile isn't workingという記事で、Lajos Moczar氏はアジャイルの手法には欠陥があると書いている。
アジャイルは多くの成果を約束しますが、実践の場では期待から大きくかけ離れています。私はアジャイルは、アジャイル登場以前の太った手法と同様に失敗するだけでなく、ITをより悪いものにしてしまうと思います。
氏が説明するのは“計画よりも開発”を優先することだ。
理論的には、プロジェクトを進めながら要件を定義し磨き変更するなかで開発者はコードを書きます。しかし、アジャイルは小さな変更と大きな変更を区別しません。すべての変更にはコストがあるのに、アジャイルはそれを考慮しません。その結果、アジャイルプロジェクトであるという根拠をもって、プロジェクトの後半に大きな変更を行うことになります。このような事態に対処するにはイテレーションを追加するしかありません。しかし、そうするとある時点では簡単に修正できた欠陥が、コードベースが変化し続けるがために、修正し難くなります。
これは従来の古い方法とは大きく異なります。従来の方法はしっかり定義した要求に基づき、変更は変更管理プロセスを通じて管理されます。このプロセスは複雑になる場合もありますが、変更を実現するのに必要な時間とコストを明確にします。
Shane Hastie氏はplease don’t equate tragile with agileというブログ記事でLajos氏の記事に反応している。
Lajos氏はアジャイルマニュフェストを誤解していますし、自分の結論を正当化するために根拠のない議論をして、アジャイルの実践を完全に文脈から切り離しています。この記事はLajos氏に対する私の返答です。氏の論点と氏が喧伝した神話について論じるつもりです。
氏はLajos氏の“計画より開発”を優先する原則の欠点の指摘に対して次のように言う。
現在のビジネス環境では、ビジネスのニーズは変化しやすいです。現在のビジネス要件の“半減期”はだいたい6ヶ月程度なので、ニーズを特定し、それを実現するのに12ヶ月かかったとしたら、成果の75%は間違っていることになります。これは純粋に時間が経過したからです。
アジャイルは規律と注意深さを持って顧客のニーズに対処する。この点については計画を立てることと反対ではない。
アジャイルは優れた設計原則を無視するための言い訳ではありません。影響度の分析をせずに大規模な変更を認めることでもありません。アジャイルは特定の範囲内での適応的な振る舞いであり、大きい変更はビジネス価値に影響があることを認識し、変化に抵抗するのではなく査定と評価を行うことなのです。
アジャイルマニュフェストには最初からプロジェクト全体の構造を計画することを否定する文言はありません。おそらく、この分野の尊敬を集める著者やリーダーの中には“詩を書くように自由に”コードを書くことから始めるのを推奨する人はいないでしょう。どのようなプロジェクトでもある程度の事前の設計は必要です。アジャイルプロジェクトでは大きな事前設計を回避します。私たちを取り巻く世界は変わり続けるからです。
ITworldの記事why your users hate agile development (and what you can do about it)でEsther Schindler氏はアジャイルに対する開発者とユーザの見方の違いについて書いている。氏が説明している違いのひとつは反復についてだ。
アジャイルの黎明期には、アジャイルは開発地チームが見積もりやドキュメント、計画を作成しないことの言い訳だと言われていました。現在は状況は改善しましたが、開発者コミュニティの中ですら、このような悪い評判は潜伏し続けてしまいます。
アジャイルチームはユーザにニーズを満たすため可能な限り柔軟に動こうとする。しかし、ユーザはこの柔軟性に対して過大に期待してしまい、結局チームは価値の提供を継続的に行うのが難しくなってしまう。
"アジャイルは組織化しないという意味"だという考えによって、ユーザや顧客が"気まぐれでもいいんだ"と考えてしまうこともあります。もちろん、アジャイルはユーザが大きなプロジェクトの終わりに優先順位を変更することを許容します。しかし、Sorin Costeasi氏は事態がスムーズに進展してしまうことの悪影響を指摘しています。"価値提供のための力に限界があることが理解できなくなってしまっていました。速度やタイムボックスを把握していないのに、いつでもストーリーを追加し、それが期限内にできると思っていたのです"。そして、その理由が"アジャイルだからできるでしょ"というものでした。
Corbin Norman氏はacknowledging the common good of agile: praising the good of agile and abrogating the minuscule negativity it bringsと題したブログ記事を書いている。氏はアジャイルが否定的に見られる場合もあることを認識している。
アジャイルを批判する人はこの開発手法がある種のソフトウエア開発者にとって最悪であると言います。出来ないソリューションを約束し、いい加減に要求が認められ、本当のコストはわからず、効率的な管理ができないからです。コストがわからず、管理ができないプロジェクトは長くなってしまい、顧客の不満とIT全体の非効率性を導くというのが批判者の主張です。
現在、アジャイルの実践やアジャイル開発の両サイドからかなり多くの議論がされています。しかし、コミュニティは多くの優れたアジャイルの実践が行われていることを知っているはずです。
氏によれば、アジャイルの優れた点のひとつは柔軟性だ。
アジャイルを実践すれば、スケジュールとコストが大きな決定要因になり、可能なビジネスニーズを受け入れるための変更にも対応できます。成熟したアジャイルチームにとっては、このような柔軟性は長年一緒に働いてきたことから生まれています。従来のウォーターフォール開発ではプロジェクトが一度始まってしまうとこのような柔軟性を発揮できません。ひとつの段階/プロセスが終わったら、戻ることはできないという考えが支配的だからです。