アジャイルソフトウェア開発の奥義を読み途中

　アジャイル開発とは変化を恐れる開発なんじゃなくて、変化を受け入れるためにはどうすれば良いのか？を考える開発手法なんだなぁ、と読み途中ながら、なんとなく雑感。非常に遅々としたスピードで読み進めているのですが、なんとか今、第2部の5つの原則を読み砕いているところです。

　今まで読んだところですと、第1部第6章のプログラミングエピソードがとても楽しかったです。Bob KossさんとBob Martinさんがペアプログラミングでボーリングのスコアを計算するプログラムを書いて行く様子が描かれているのですが、半ば喧嘩とも思えるぐらいにお互いの感情を発露させつつプログラミングを行っていく様子が人間くさくてグッドです。テストファーストな開発手法が、人間的な感情を発露させつつもシステムとしてしっかりと動作させる保証みたいな役割を果たしているのではないかと感じました。

　そういえば研修でV字モデルの説明を受けていて、仕様変更があるとどれだけの経費が生じる、納期の変化が生じる、プロジェクトとしてどう対応すればいいか、なんて話があったのですけれども、なんとなく違和感めいたものを感じていたんです。99%ぐらいのプロジェクトでは顧客の仕様変更によってプロジェクトの予定は適時変更されるという話もあったのですが、それでもV字モデルとはこれいかに、なんて印象だったのですね。まぁ関連会社に丸投げしやすいから、というのが一番大きな理由だと思ったのですが、変化に対応できないスタイルでは丸投げしたときの方がリスクが高いんじゃないか、なんて、まぁいろいろ思うところがあったのです。

　で、アジャイルなんですが、「ああ、だからこの単語をよく聞くんだね」と納得しました。とはいえ具体的にどうするかという話はこの後の章に描かれているところですので、わくわくしながら読み進めたいです。