アジャイルプラクティスを有効に使うことはアジャイルプラクティスにはどんなものがあるかを知っていることほど簡単ではありません。テスト駆動開発を有効に活用することは、「レッド―グリーン―リファクタリング」というステップを繰り返すべきだということを知っているのとは異なります。どうすれば「アジャイルというのはなかなかよさそうな考え方ですね」という段階から「私たちはアジャイルプラクティスを活用して自分たちの組織にもたらす価値を著しく改善しています」という段階に辿り着けるのでしょうか？
アジャイル関連の文献には成功事例がたくさん取り上げられていますが、実際にやってみると失敗してしまいます。銀の弾丸など存在しないのです。別のチームの事例をあなたの手本にできるかどうかは状況によります。そのチームの状況はあなたと同じでしょうか？状況が同じでなければ、おそらく同じメリットは得られません。
Carel Lotz氏は自身の経験を基に、組織でスクラムを採用してから実際の価値を得るまでに数々の困難があることを報告(source)しています。
現在、私の所属するチームは自社のソフトウェア開発ライフサイクル(SDLC)の方法論を改定する必要に迫られています。既存の方法論はソフトウェア開発のウォーターフォールモデルに基づいていますが、私はよりアジャイルなSDLC (スクラム、オープンUP(source)など) の採用に大賛成です。過去2年間にいくつかのプロジェクトでSDLCをもっとアジャイルにしようと試みました。しかし、どのプロジェクトでも無惨に失敗するか、継続的インテグレーション (CI) (source)やテスト駆動開発 (TDD) のようないくつかの技術寄りのアジャイル開発手法の実践に成功するに留まっていました。
ここで本当に面白いのは「なぜ失敗したのか」という原因についての彼の分析です(終わってからの洞察はいつだって素晴しい)。
今朝、私は興味深いInfoQの記事(記事)を読みました。この記事では、自分たちの身の回りの状況が未だにアジャイルになりきれていない主な理由のうちの1つに焦点を当てていました。[ここで言及している記事は、先日InfoQに掲載された「責任、個人のアジャイル性、その他の親密なコミュニケーションのアイデア」(記事)のこと]
現時点で私たちの組織には、本当に理解した上で正しいアジャイルな考え方 (すなわち、スクラム(source)とウォーターフォールを折衷したような中途半端なものでない) を採用したことのあるような、中心となって周囲を引っ張っていく人物はそう多くいません。的確なガイドもいないわけですから、結果としてアジャイル開発のメリットを盲信するようになります。何もかもがガラっと変わるわけではありませんから、チームはすぐに幻滅してウォーターフォール・アプローチという「既知の」世界に戻ってしまいます。
これから数か月の間、私は主にアジャイルを採用することに焦点を当てて記事を投稿するつもりです。アジャイルになることで得られるメリットは明らかに大きいものです。しかしその一方で、落し穴もたくさんあります。人々がどのようにアジャイルプラクティスを採用し、適応しているのか。毎週火曜日のInfoQのAgile Queueの更新をお楽しみに！
それから、あなたがアジャイルの採用に重点的に取り組むことにメリットがあると思っているならInfoQであなたの考えを発表してみませんか？ あなたの意見や、興味深いブログ、役に立つニュースについてのメールもお待ちしています。
原文はこちらです：http://www.infoq.com/news/2008/02/agile-adoption-practice-distinct