アジャイル開発
アジャイルソフトウェア開発（略：アジャイル開発）はソフトウェア開発を行う軽量な開発手法群の総称です。
アジャイル開発手法は沢山のものあり、今後Windows8時代などでもこの手法を巡って色々な議論を世界各地で繰り広げられているところです。
#ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (比較.jpg)
アジャイル開発手法の中で代表的なところで「エクストリーム・プログラミング」と呼ばれるものがある。
一度は耳にしたことがある人も多いことだろう。
エクストリーム・プログラミング
エクストリーム・プログラミング(略：XP)は、
ユーザー要求や仕様の変更リスクを軽減するために、顧客や開発者間のコミュニケーションを重視し、コーティングとテスト、リファクタリングに重点を置いて、短期間のリリースを繰り返して開発を進めて
いくソフトウェア開発方法です。
きちんとドキュメントを書き、顧客に承認を得、実装をし、テストするようなウォーターフォール型の開発は、突然の仕様変更に柔軟に対応できず、再設計やパッチをあてて無理やり実現に近づけていくような危ないものも多かった。
オブジェクト指向で汎用的な構造にしたところで、顧客による相次ぐ突然の仕様変更などで柔軟に対応できなくなり、納期との兼ね合いもあり、無理やりな作りとなり、結果大変な作りになることも多かった。
顧客が本当に求めているものを設計段階で完全に読み取るのは難しく、開発側とのコミュニケーションのあり方も大変重要になってきます。
形になるものを簡易的に作成し、顧客側の運用イメージ、開発すべきものを
明確にしていくこの手法は画期的だと考えられ、導入されるプロジェクトも
多くなってきました。
このXPは10人程度の比較的少人数のチーム開発に適しており、小規模のソフトウェア開発に向いた手法という認識の方も多いだろうが、提唱者の1人であるケント・ベックは、大規模システムの開発でも十分実現可能な手法としている。
はたして、実際に現場でこの手法を実施し、成功を収めたプロジェクトはあるのだろうか？そして、失敗してしまった原因はどこにあるのか？
ペアプログラミング
XPの最大の特徴の１つにペアプログラミングがある。
簡単にいうと、コーディングを２人で行うことだ。
どのような性格２人で行うかまでの定義はない。
異性の場合も考えられる。
１人でプログラミングをするよりも利点はなんだろう。
コーディングとレビューアを分ける体制より品質や工数はかからないのだろうか。
おそらく、自立したプログラマには必要ないと考えられる
たとえば、プロジェクトに途中から参加した人やプログラミングをあまり組んだことがない人は作り方のルールがわからず困惑しながら作るだろう。
それを回避するために熟練者とペアにする、ペアプログラミングは確かに効果的であるが、熟練者は、その方のレクチャーおよび、自分のタスクもあると、大変な負荷が生じてしまう。
人材を育てるという視点では、とてもよい手法だと考えられる
しかし、余裕のあるプロジェクトなら考えられるが、工数が２倍考えられてしまうため、なかなか実際の現場では適用しづらいと考えられる。
また、熟練者の場合、そこにかかる工数は見てもらえないことが多い。
コーディング規約
このルールを取り決めないと色んな人が色んな癖で作ってしまい、
別の人が担当したときに困惑するなんてことありますよね。
作業の細分化をするにあたってもとても重要になってきます。
また、あればいいってものでもありません。
コーディングのレビュー実施の際にも利用できるような
簡潔な
コーディング規約が必要だと考えられます。
書籍などにあるものをそのまま流用するのではなく、プロジェクト
で品質につながるようにじっくり吟味が必要です。
シンプルデザイン
リファクタリング
煩雑なプログラムは書かない。仕様変更、メンテナンスを考慮した作りを作り手が心がけるだけでも幾分違うと考えられます。改修が容易なプログラムであれば、テストも楽になりますし、いいことばかりです。そのためには設計がとても大切でオブジェクト指向の理解者であり、よいものを作ろうと考えられる人でないといけない。シンプル is BESTの精神が大切であろう。
短期リリース
定期的にリリースすることで、顧客との意識のづれを軽減することができます。
また、成果を形にできることで、ビジネス的にも大きな意味があります。
コードの共有所有
SVNやVSSなどのファイル管理ソフトを利用することで、複数人での開発工数を軽減することができます。品質のチェックやレビューが容易に行えます。
比喩（メタファ）
ユーザテスト
最終更新：2012年03月21日 15:38
