読者です 読者をやめる 読者になる 読者になる

アジャイルプラクティス

アジャイルプラクティス読了しました。

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

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

今、僕が携わっているプロジェクトにアジャイルな手法を導入しようとしているのですが、そんな時にすばらしい本に巡りあえました。ありがとう!

本書では45個のプラクティスが紹介されていますが、今のプロジェクトはかなり若いチーム(マネージャを除くと、入社4年目の僕が一番年上)なので、まずは「チームに投資する」、「メンターになる」あたりから始めようと思っています。
具体的にはプロジェクト内で勉強会を開催して自動化やユニットテストの話をしたり、社内blogでこの本のプラクティスの概要を1つずつ紹介してみてもいいかなと思っています。
本当はチームのメンバー全員にこの本を読んでほしいのですが、いきなり読めと言うのも難しいですし。まずは一歩ずつ。



ただし注意しておかないといけないのは、アジャイルという言葉に嫌悪感を示す人もいるということです。
恐らくそういう人たちは、「設計書を書かない」とか「仕様を決めるのは後でいい」とか、目先の楽さだけを追求したような似非アジャイルに対して、批判しているのだと思います。
この本を読めば、アジャイルはソフトウェア開発者が身に付けるべき習慣であり、決してサボろうとしているわけではないということが分かると思います。
本書の中でもこんな一節がありました。

アジャイル開発では、チームのメンバー(およびチームと共に作業するメンバー)全員が、プロジェクトで明確な結果を出すことを目指すプロフェッショナルであることを前提としている。必ずしも全員が経験豊富なプロフェッショナルではないかもしれない。しかし、プロフェッショナルとしての意識を持ち、自らの持てる力を最大限に発揮したいという意欲に満ちている。
だから、ずる休み、手抜き、あからさまなサボりに悩まされているチームには、アジャイル開発は合わないと思う。

アジャイルだって銀の弾丸ではないわけで、どんなチームにもただ適用するだけで上手くいくってものではないんですよね。逆にウォーターフォールなプロジェクトにだって、アジャイルは適用できるでしょうし、要はプロのエンジニアとしての意識なんだと思います。
そのような意識が身についたかどうかは、本書の「こんな気分」という項目で確認できそうですし、「バランスが肝心」という項目で思考停止していないか、やりすぎていないかを確認すると良さそうです。



ところで、最近のオーム社さんの本は良書ばかりですね。以下の本は全部読みましたが全部お気に入りです。


Joel on Software

Joel on Software


My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド

My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド


アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き


Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)


Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック