Agile手法の採用 -Part 2-

Part-1(id:masayang:20060426#1146094908)の続き。

Agile手法の採用 Part-2

Alan S. Koch, http://www.ASKProcess.com

プロジェクトいろいろ
世の中にはいろいろなプロジェクトがあるけど、同じプロジェクトは存在しないし、個々のプロジェクトはそれぞれ独特の課題や目的を抱えているもんだ。にも関わらず、多くの組織は比較的予測可能な特性を持ったプロジェクト群を引き受けようとするよね。主に金融の事務システムを開発する企業があるかと思えば、リアルタイムの組込系に強いところもある。あなたの開発チームは主にどんなシステムに関わっているかな？どんなプロジェクトであれ、そこには一定の不確定要素があるはずだよね。これらの不確定要素はプロジェクトの抱えるリスクの主たるもので、そこには技術的改革なども含まれているんだ。

もともとのAgile手法は小規模だけど途中での大幅な変更が予想されるようなプロジェクトに適合するように作られたものだけど、それ以外の環境でも活用することはできるんだ。多くのAgile手法は開発チームメンバーが毎日顔を合わせて仕事することを想定している。あなたの組織がこのケースに当てはまらない場合、いくつかのAgileプラクティスを分散チーム用に修正する必要がでてくるね。

Agile手法を奨励する人達は、Agileはどんなプロジェクトでも使えるはずだと言うことが多い。実際、いくつかの分散Agileチームの事例はあるんだ。Agile手法はどんなプロジェクトにも使えるというのは事実かもしれないけど、これらのAgile手法が処方するプラクティスを自分のプロジェクトで使うべきかどうかが問題になるよね。

この答を得るは、どのAgile手法を採用するか、そしてそのプラクティスはゴール到達に役立つかを考えるところまで戻る必要がある。個々のプラクティスを吟味し、プロジェクトの現実に照らしあわせ、それらが使えるかどうかを検討し、それなりの利益が得られるかどうかを見極めることだ。

ツールとプロセス
手法は何もない空間の中にポツンと存在しているわけじゃないよ。手法は使い手の環境に強く影響を受ける。とりわけ利用するツールやプロセスに受ける影響は大きいものがあるんだ。

普通の組織なら、すでに馴染みのツールやプロセスを抱えているはずでしょ。これらのツールやプロセスをどう拡張すれば、これから採用するAgileプラクティスとの互換性やサポートを確保できるのか？今使っているプロセスやツール(例えば要件管理やQA)は、Agileプラクティス採用の邪魔になっていないか？ 邪魔になっているのなら、それらのプロセスやツールをよりAgileプラクティスに合うように変更する（あるいは排除する）ことはできないか？

逆の視点もまた正しいんだな。Agileプラクティスをより効果的に使うためには、専用のツールやプロセスを必要とすることが多い。例えばXPではプログラミングチームがテスト自動化ツールを激しく使うことを想定している。このようなツールはあなたの組織で利用可能かな？使えるとしても、大勢が使えるくらいのライセンスを確保しているかな？

まだ他にも例があるよ。コードコントロールのツールだ。ほとんどのAgile手法は強力なコードコントロールシステムの活用を前提としている。リファクタリングとかコード所有権の共有などは、コードコントロールのツールとプロセスなしには成立しない話なんだよね。

個々のプラクティスを吟味し、ツールやプロセスの現実に照らしあわせ、それらが使えるかどうかを検討し、それなりの利益が得られるかどうかを見極めること。

人員
前のほうにも書いたように、Agile手法では自律型の開発チームであることが求められている。 つまり、何をするかを言われなくとも、開発チームはプロジェクトの目的を理解し、顧客やチーム客員と協力しあいながら個々の局面において最適な手を打っていくわけだ。

自律的に行動していくためには、開発メンバーが新しいレベルの責任感を持つ必要がある。これは（プログラマの日頃のぼやきに比べれば）簡単なように思えるが、現状について愚痴るというのと、新しい現状を作りだす責任を負うのとは天と地ほどの差があるのだ！

多くのプログラマはそんなに強くはない。プログラマ達は何かを変えるためのアイデアは持っているかもしれない。でも、そのアイデアを実現するために意思決定者を説き伏せることには消極的なんだな。技術的な挑戦を好む人達の多くは、プロジェクトのゴタゴタとか顧客との切った張ったの世界は結構恐い世界なのかもしれないね。

さらに、開発チームにはいろいろな能力の人がいるよね。実際にスーパースターな人もいるよね！ でも、そうじゃない人達は万能ではない。ぶっちゃけて言えば、平均的なプログラマは平均レベルでしかないわけだし、ざっと半数は平均以下なわけだ。

Agile手法は（顧客との協業により）開発チームが自らを指揮できるようにしてくれる。開発チームがこういった環境で働くうちに、開発メンバーがプロジェクトの意思決定をうまくやっていくような能力を身につけていく、というのは事実なんだ。でも、そうやって育つまではどうやって成功するんだろう？どの程度経過すれば、能力が最大になるのだろう？

個々のプラクティスを吟味し、開発チーム人員の現実に照らしあわせ、それらが使えるかどうかを検討し、それなりの利益が得られるかどうかを見極めること。

Agile手法の採用
ここまで述べてきた全てのことを検討することで、自分達に合ったAgileプラクティスを決めることができるようになるわけだ。その検討材料には、文化、顧客、プロジェクト、ツール、プロセス、そして人員などの要素がある。こういった情報をもとにして、自分達の目的に合ったAgileプラクティスを吟味し、どれを採用するべきか、どんな改良をすべきかを決めていくのだ。

大事なことは、「自分自身のAgile手法を編み出していく」ということ。でも、それは自分達が必要なものじゃないかもしれないよね？他の組織でなら機能するような手法なんか採用したくはないよね。自分の会社で機能する手法を採用する必要があるのだよ。正しいAgile手法の採用で、自分達のゴールを達成し、より良いソフトウェアを開発するという能力を向上させていきたいもんだね。