アジャイル開発実践

アジャイルと一言で言っても、手法にはいろいろある。

XPでしょ、クリスタルでしょ、スクラムでしょ、リーンでしょ、・・・全部入りだと収拾付かないよね。
だから、教科書的な本が今のところバイブルになっていて、プロジェクトマネジメントフレームワークとしてスクラム、実装のプラクティスはXPを中心に。

ってことで皆、適用を試みる。

でもね、ウォーターフォールもそうだけど、RUP（UPか）もそうだけど、開発方法論とか手法って、ある程度前提となるアーキテクチャとか、システム特性とか、顧客特性とか、ビジネス特性とか、そういったものを語らずに話をすると、いざ、実践でぶれる。

最初はね、小規模でやるでしょ、で、やれそうな気がするでしょ、
でも、現実のビジネス、特に商用アプリを開発するときに、ターゲットが製品開発だったり、顧客向けアプリだったりすると、とたんにいろんな開発方法論とは別のところが気になるわけさ。

それってね、ターゲットを絞って考えていないからさ。

RUPが出てきたときは、アーキテクチャが中心にあった。それは、アーキテクチャが、そのときの技術背景では、不安定になりがちだったこともあったから。

では、アジャイルはどうする？

基本に立ち戻れというだけさ。
今の技術環境ならかなりのことがかんたんに検証できる。デザインと実装のペアで作りたいものを確認していけば、無駄なことをやらずに済むでしょ。なによりも動くのだから、システムを成長させることができるでしょ。

それにあうところに、適用すればいいわけさ。
実践するには、適用先をもっと考える必要があるってこと。
契約面はあと。
作りたいシステムの特性からまず特徴を捉えなければ。

何に適用できるじゃなく、どういったシステムを作りたいか、
それに対してどのような開発方法がいいだろうか、と考える。
そのとき、アジャイル的なやり方が適しているのなら、適用する。
それも、いろいろあるアジャイル手法から選ぶ力を持てればいいんじゃないの？

それって、プロジェクトごとに考えるのは当たり前だよね。
適用パターンをいくつかもって、やり方の引き出しを増やして、
適時適用するってなんで考えられないんだろう？

不思議な議論をやっているな世の中のメディアが問題なのかな