BT

アジャイルにすべてを導入する

| 作者: Mike Bria フォローする 0 人のフォロワー , 翻訳者 大田 緑 - (株)チェンジビジョン フォローする 1 人のフォロワー 投稿日 2009年2月15日. 推定読書時間: 6 分 |

2ヶ月前、InfoQはJim Shore氏の人気の記事「The Decline and Fall of Agile」を紹介した (参考記事)。それは、組織が「アジャイル」を名前だけで導入し、実際にアジャイルであるために本当に意味するものの導入に失敗するという、現在増えているコミュニティの傾向を強調するものであった。この記事は、InfoQとJim氏のブログの両方で数多くのレスポンスを集めている。あなたがまだ見ていないならば見る価値があるものだ。

しかし、あぁ、まだこの話は続きがある。Martin Fowler氏(リンク)、Joshua Kerievsky氏(リンク)、Ron Jeffries氏(リンク)等のコミュニティリーダーとその他の人たちは、この状況で何が起きているのか彼らの考えを投稿し、Shore氏の最初の立場から、最近さらに数歩踏み出している。

Flaccid Scrum(リンク)」の記事の中で、Martin Fowler氏は主にShore氏の意見を繰り返している。多くのアジャイル導入でしばしば欠けているのは、ペアプログラミング、継続的統合、テスト駆動開発といったエクストリームプログラミングにおいて強調される技術的なプラクティスについての見解だ。Shore氏のように、Fowler氏は、推奨された方法論としてスクラムを選択する組織において、この問題がどのようにもっとも広まるのか認識している。しかし、そうであっても、これはスクラムの中やスクラム自体の欠点ではない。改善策と注意として、とりわけ、これらのスクラムの導入を指導する人たちが、さらに注意深く、適切な技術的プラクティスを推し進めるようFowler氏は力説する。

スクラムコミュニティは、人々が強固な技術的プラクティスの重要性を理解するように一層努力する必要があります。必ずどのプロジェクトのレビューでも、どのような技術的プラクティスがあるか確かめるようにすべきです。そのようなプロジェクトに巻き込まれていたり、関係があったりする場合に、技術的な面が軽視されているならば抗議しなさい。

Fowler氏は、成功した時も、失敗した時もアジャイルの採用は人々が行うものであり、成功や失敗をもたらすのはチームであるということを思い起こさせた。  

Fowler氏がこの記事を発表したすぐ後に、Industrial Logic (リンク)とIXP (リンク)の設立者、Joshua Kerievsky氏 (リンク)がこの話題をXP Yahoo Groupに持ち込んだ。最初の投稿、「The Whole Enchilada(リンク)」の中で、Kerievsky氏はあるメッセージを繰り返した。それは、同じ名前の非常に有名な話の中でAgile 2006においてコミュニティに最初に与えられたもので、主に「すべてやろう、初めからすべてやろう」というメッセージであった。

だらけたスクラム? アジャイルの衰退と凋落?
組織と開発コミュニティがすべてを必要としているさらなる証拠だ。それは、管理上と技術上のアジリティであり、どちらか一方ではない。

「彼らは技術的なことを導入するように進化するだろう」という考えは、私の謙虚な意見と経験によると、世間知らずな思い込みです。大体の場合、そのような導入は起きないか、起きたとしても、まるでまったく起きないほどの偶然でしかありません。

革新的なスクラムは技術的なアジリティについては何も言いません。それは、シートベルや他の重要な安全機能を持たずに自動車を売るようなものです。あなたは、技術的なことも必要であると教えてくれるような信用できるスクラムの人たちを運良く知っている必要があります。(その人たちがこの「技術的なことは後で導入する」という考えを信じさせるのだとしても)

XP (このメーリングリストのみなさんが知っている通り、XPはただ単なる技術的なプラクティス以上のものです)、スクラム+XP、Industrial XPなどは、アジャイルにすべてを導入する例です。

私たちは、組織や開発コミュニティが、アジャイルにすべてを導入し、彼らのアジャイルプロセスがどれだけ不十分であるか彼らが気づくまで待つことでずっとうまくいくことを何度も見つけています。

だから、私たちは、良いプロセスが重要なことに対応し、技術的なアジリティがソフトウェア開発において間違いなく重要なことだと認識する必要があります。それを導入の後期に延期するのは賢明ではありません。

Kerievsky氏の投稿が激しい議論の嵐の幕開けとなり、Joshua氏の提案の利点と適用について議論するおおよそ90の投稿があった。なぜアジャイルにすべてを導入することが多くの組織で実際に起きたり、起きなかったりするのか考えられるだけの様々な理由も挙げられた。
このスレッドは見逃せないものだ。

Context, My Foot! (リンク)の記事の中で、Ron Jeffries氏は、失敗するアジャイル導入のほとんどにおいてその中心にあるのは、本当にアジャイルであるために必要なすべてのことを導入しないからだというShore氏、Fowler氏、Kerievsky氏に同意する。

成功するためには、正しいことをしなければならず、物事を正しくしなければなりません。
...
スクラムやXP、その他のどんなアジャイルでも成功させるために、リファクタリングしなければなりません。申し訳ないが、選択の自由はありません。それは必須です。
...
一般的にXPや他のところで説明されるさらに多くのプラクティスがあります。それらは、リファクタリングと同様必ず必要なものです。本当に、選択肢はありません。成功したいならば、ただこれらをしなければならないのです。

しかし、Jeffries氏の投稿の本当に素晴らしいところは、「全部しなくちゃ」のメッセージの後にやって来る。それは、彼が、アジャイルにすべてを導入する組織の失敗の中心に本当にあるものは、組織そのものであることを説明したときだ。
部屋の中の幻を指摘して、Jeffries氏が言う。

XP / アジャイル / スクラムの人気がさらに上がり、多くのチームや個人はそれらを実行したい、または、それらでありたいと思っています。
このため、結局、「状況に依存する」と言われるようなアジャイル手法の集まりになりました。この考えは、議論されているアジャイルのブランドが何であれ、「あまりにも融通が利かず」、「私たちの状況に合わない」ということです。だから、私たちはアジャイルを修正しなければなりません。神様は私たちが状況を修正することができないと知っているのです。
さて、私のいとしい小さな子供たち、あなた方に悪い知らせがあります。修正しなければならないのは、あなたの行動を制限している大事な状況です。責任と権威を人々に委譲することができない経営幹部やハイレベルなマネージャたちです。あまりに忙しすぎて、本当に何がなされるべきか説明する暇のない製品を作る人々です。作業空間を作業に合わせられない設備関係の人々です。成功するために必要な技術を学ばないプログラマです。プロジェクトにおいて品質にこだわることができなくなるまでプレッシャーを強めるマネージャやプロダクトオーナーです。

従って、この議論は、非常に注意する必要があるものだ。アジャイルは危機に直面している。私たちが方向性を求めて関心を向ける専門家は、これについて話し続ける。そして、あなたもそうすべきだ。私たちみんなが話すべきなのだ。ここでも話そうではないか。

 

原文はこちらです:http://www.infoq.com/news/2009/02/whole-enchilada-and-context

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT