みんなアジャイルの意味って知ってますか？agileは下記のような意味です。私もモヤモヤのままだったので調べてみました。
【形容詞】
1(動きが)機敏な，はしっこい; 〔…に〕機敏で，はしっこくて 〔in〕.
用例
He's agile in his movements. 彼は動きが早い.
2頭の回転の早い，機敏な，明敏な.
-weblioから引用-
このagileの辞書の意味とアジャイルの定義「顧客満足を最優先し価値のあるソフトウェアを早く継続的に提供する」を一緒に見ると命名が上手いことがお分かりになると思います。アジャイルの原型とも言えるトヨタ生産方式はその名前を聞いても何を言っているかすぐ理解できませんが、アジャイルは英語単語の意味を知っている人には何を意味するかすぐ理解できると思います。
この本は現場開発者が実際のソフトウェア開発中に役立つプラクティス(習慣、実行、行為)が45個も紹介されています。(私は基本3個まで覚えられませんので全部は無理又は抽象化します。w)
達人プログラマやJoel on Software等を既読で自分なりに実践してたので「第6章 アジャイルなコーディング」と「第7章 アジャイルなデバッグ」は当然なことが書いてあったので一気に読んで飛ばしました。ただ一つVCS(Version Control System)へのコミットはコンパイルが通るものなら頻繁にしてましたが、この本では意味のある単位(タスクが完了したコード)でやるように書いてあります。ローカルマシン一箇所しか存在しないというシングルポイントは積極的に防げるため頻繁にやってましたが、これからはsvn等のVCSはbranch機能を活用してリスクを回避して行こうと思います。
心に響いたプラクティスは以下の5つでした。
> 1 成果をあげるのが仕事
カッコイイと思ったのでw
> 8 わかるまで質問する
モヤモヤな状態で開発しても間違ったものを開発する可能性があるので「正しいものをつくる」ためにも分かるまで質問してほしい＆質問します。実は前職で隣で座ってた方はこれが得意でした。最初は何を言ってるの？思いましたが、モヤモヤを無くすため彼が取った行動(しつこい質問、議論、勉強と調査)をみて、使い方だけ知って開発してた自分自身が恥ずかしくなりました。今はなぜこう動くかが理解できるまで調べようとしてます。(100%理解している訳ではありません。)
その意味では「> 41 メンターになる」もすごいいいプラクティスですね。w
> 12 テクノロジの採用根拠を明確にする
まさに私の話でした。恥ずかしいですが、今開発中のシステムを単純にScalaでやりたい気持ちで上司に申し込んだらその場で却下されました。興味本位でビジネスを行うのは危険です。
> 20 作る前から使う
つくるものが明確に理解している状態で開発すると最高のパフォーマンスを出せると信じてます。ただ実際にそれができるケースは少ないです。どうすればそれに近い状態で開発できるかを考えた際、目の前の小さいメソッド、クラスの役割を明確して開発するしかないと思います。テストも欠かせないのでTDDが現実かなと感じている最近でしたのでこのプラクティスは本当に習慣にしたいです。
> 38 定常的に顔をあわせる
一人で開発する時も必要だと思います。朝下記の3つを共有することで問題を早い段階で対応できます。一人の場合でも無意識の領域に隠した問題を表に引き出せるのでぜひ実施してください。(はい、私に対して言ってます)
昨日やったことは？
今日やることは？
進捗を妨げている問題点は何？
最後に
アジャイルはSilver Bulletではありませんが、トヨタをはじめ多くのプロジェクト、会社でその成果が見られている開発手法です。ビジネス環境が急激に変わっている今は機敏に対応できるアジャイルが一番現実的な選択だと思います。ただこの本にも書いてありますが、すべてのプラクティスを行う必要はありません。(すべてを行った場合、一番いいと言ってますが)プロジェクトに適したプラクティスを選んで導入すればその効果はあるはずです。
アジャイルプラクティスの目次
第1章 アジャイルソフトウェア開発
第2章 アジャイルの初心
> 1 成果をあげるのが仕事
> 2 応急処置は泥沼を招く
> 3 人ではなくアイデアを批判する
> 4 機雷がなんだ！ 全速前進！
第3章 アジャイルさを育む
> 5 変化に付いていく
> 6 チームに投資する
> 7 時が来たら習慣を捨てる
> 8 わかるまで質問する
> 9 リズムに乗る
第4章 ユーザが求めるものを提供する
> 10 顧客に決断してもらう
> 11 設計は指針であって、指図ではない
> 12 テクノロジの採用根拠を明確にする
> 13 いつでもリリースできるようにしておく
> 14 はやめに統合、こまめに統合
> 15 早いうちにデプロイを自動化する
> 16 頻繁なデモでフィードバックを得る
> 17 短いイテレーションでインクリメンタルにリリースする
> 18 定額契約は守れない約束
第5章 アジャイルなフィードバック
> 19 天使を味方につける
> 20 作る前から使う
> 21 違いがあれば結果も変わる
> 22 受け入れテストを自動化する
> 23 ありのままの進捗を計測する
> 24 ユーザの声に耳を傾ける
第6章 アジャイルなコーディング
> 25 意図を明確に表現するコードを書く
> 26 コードで伝える
> 27 トレードオフを積極的に考慮する
> 28 インクリメンタルにコードを書く
> 29 シンプルにすること
> 30 凝集度の高いコードを書く
> 31 “Tell, Don’t Ask” ――― 求めるな、命じよ
> 32 取り決めを守ってコードを置き換える
第7章 アジャイルなデバッグ
> 33 ソリューションログをつける
> 34 警告をエラーとみなす
> 35 問題を切り分けて攻める
> 36 あらゆる例外を報告する
> 37 役に立つエラーメッセージを提供する
第8章 アジャイルなコラボレーション
> 38 定常的に顔をあわせる
> 39 アーキテクトもコードを書くべき
> 40 共同所有を実践する
> 41 メンターになる
> 42 答えを見つけられるように力を貸す
> 43 コードの共有には段取りがある
> 44 コードをレビューする
> 45 みんなに知らせる
第9章 終章：アジャイルへ踏み出す
9.1 たったひとつの新しいプラクティス
9.2 窮地のプロジェクトを救う
9.3 アジャイルの導入：マネージャ向けガイド
9.4 アジャイルの導入：プログラマ向けガイド
9.5 これで終わり？
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣/オーム社
￥2,520
Amazon.co.jp