アジャイルプラクティス

監訳どうもおつかれさまでした! 買ったけど献本ももらいました。ありがとうございました。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

改めてこの本を読みながら、<泥の中の一歩>のことを考えていました。
http://www.dodgson.org/omo/t/?date=20071103

この本は教科書的ないいプラクティスが満載なのですが、ただ、いかんせん「教科書的」なことは弱点にもなっているように思います。要するに、読んでもなかなか実行できないんですよ、こういうプラクティスは。上の記事から引用してみます。

ソフトウェア開発について言えば, 正解の多くは教科書に書いてある. ただ現実の <泥> の中で教科書どおりに振る舞うのは難しい. 足に絡む <泥> はやる気のない同僚や無能な上司, 不条理な顧客かもしれないし, まあ多くの場合は自分自身の能力不足でもあるだろう. 教科書どおり振舞うには能力が必要で, 能力を身につけるには訓練がいる. しかしフォーマルな訓練を受ける余裕はない.<泥の中で一歩を踏み出す> とは, そうした制限の中で実現可能な定石のサブセットを探すこと, それを実行することを言う. 高速な "単体" テストが無理でも少し時間のかかる自動テストならできるかもしれない, インスペクションが無理でもウォークスルーならできるかもしれない...(略)

ただ、泥の中でもがきながら「実現可能な定石のサブセットを探す」ときのリファレンスとして、この本は役に立つことは確実だと思います。そういう意味で、やはりいざという時に役立つ本であり、その「いざという時」はもちろん「まさに今」以外にないので、手ごろな分量的にもまず読んでおくべき一冊だと思います。

……と思ったらomoさん本人がレビュー書いているんですね(http://www.dodgson.org/omo/t/?date=20071222)。なんかこっちを読んでいただいた方が早いかも。

あと、この本に限った話ではないですが、アジャイルを進める人たちにとって、「アジャイル(であること)」が価値判断を含んでいることが気になりました。アジャイルでないと駄目、とはいわなくても、少なくともアジャイルであることが問題を引き起こすことはないように書かれています。こういった考え方は、うまくいかない環境を「ちゃんとアジャイルしていない・なっていない」と判断するような論法にのっとっているような気もします。あるいは、「よい開発」を単に「アジャイルな開発」と呼び変えているとか。でも、それって言葉の使い方としてどうなの? という気もします。