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

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

ずいぶん前の話。とあるチームでアジャイル開発のアイデアを汲んでなのか、スプリントで工数管理をしているところがあった。ところが日々の進捗度合いが可視化されたことによって、それに対して重圧がかけられるなどの理由で不満が続出。結局、無くなっていったような。

そんなわけで、そういえばアジャイル開発って結局何なんだろうと思ったので何冊か読んでみることにした。まずは1冊目。

本書は、アジャイル開発に対しての心構えについて書かれている。その心構えの核となるのが、短期的フィードバック。短期的にフィードバックをこなすために、様々なアイデアや指針が書かれている。例えば、コードを明確に書く必要性、バージョン管理、スタンドアップミーティング、そして個人の学習の必要性。

これを読んで、ずいぶん前のスプリントがダメだった理由を少しだけわかった気がする。想像するにスプリントは、工数を可視化するものであると同時に、数字が見積もり通りに減らなかった場合、今後の見積もり精度を上げるためのものであって、決して時間を無駄にしているのを責めるものではなかったのだろう。

チームとしても、個人としても、活用できる考え方が多い良書。

ただ、これをどう現場に落とし込むか、のほうが問題なわけだ。

現場には、ローカルルールというべき独特の習慣が必ず存在する。長いプロジェクトになればなるほど、そういった傾向がある。そんな中で、改めて新しいルールを作るのは難しい。

新しきを学び、古きを捨てましょう

新しい技術を学ぶときには、足を引っ張りかねない古い習慣を捨てなさい。自動車は馬車とは別次元のものであって、単に馬のついていない馬車というわけではないのです。

(P 37 (7) 時が来たら習慣を捨てる )

これはとても難しいことだ。少人数で、かつ、本当に開発に対してプロフェッショナルな集団ならば、受け入れられることかもしれない。だけど、必ずプロフェッショナルな集団の中で働けるとは限らない。その中で、本書で書かれているようなことを浸透させるには、浸透させようとする人が回りにその習慣がどれだけ良いものなのかを伝える情熱、もしくは浸透させようとする人が強制的な権力を持っている必要があると思う。しかも、後者はアジャイル開発として似合わない気もする。

では、個人としてどうすればいいか。

機会が来るまで、機会を見逃さないために、学び続ける。

きっとこんな気分。

読書メモ