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

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

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

45個のプラクティスの紹介が、それぞれ悪魔の誘惑に始まり天使のささやきで終わる。具体例と実行時の気持ちまでが説明されていてとても楽しく読みやすい。(日本語訳がとても丁寧に行われたように思えます)
以下、本を読んだ感想やふと思ったこと。

アジャイルは開発手法ではない

アジャイルはチームを構成するメンバー各人の心構え、仕事に臨む態度である

・・・ここまで言い切ると語弊があるかもしれないが、この本を読むまではアジャイルというのがこんなにも人間にスポットを当てた方法論だとは思ってなかった。

TDD

TDDのいいところは自動的にテスト行われてデグレが自動的に見つかるとかいうところにあるのではない。
テストフレームワークにあわせてそれを意識して開発を行うことで、開発者の頭の中が整理されてアプリケーション(プロジェクト)自体が非常に整った、メンテナンス性の高いものになるところにある。
偉い人が「導入するぞ」って言うのを待たずとも、個人でできることはいろいろある。

レガシーの問題点

通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状態になっていないため、テストしにくく、結合度の高さ故、変更を加えにくく、予期しない箇所に影響が出やすい。
そのせいでストレスがたまる、なんか怖くて微妙に手がすすまない。

アジャイルのなにが優れているのか

技術者にとって

アジャイルの肝は各メンバーが前向きに生産的に常に前進しようとするところにある。
アジャイルの提唱するものが、よりよくあろうとする技術者の性質と相性がよく、アジャイルラクティスにしたがって開発していると心地よいとかそんな感じなんじゃなかろうか。
ただし、そんなにやる気もなく、言われたことだけやっていたいとか、向かない人もいる。

顧客にとって

より良い製品を得られる。
ただし、依頼を投げたらあとは勝手にやってほしいとか、そういう場合は向かない。
というか、この本にあるようなアジャイルなメンバーがそろったチームと、彼らといい関係を築けるような顧客だったら別に開発手法がウォーターフォールだろうがなんだろうが成功する気がする。

単に正しいやり方を適用すればいいってわけじゃない

16 頻繁なデモでフィードバックを得る
コードの変更がそうであるように、開発方法を変えようとする場合はそれが現在どのように機能しているか、なぜそうなっているのかを理解しなくては、効果的に変更を行うことはできない。

新しい手法だけ持ってきて「これで行くから」的なゴリ押しに走る人は肝に銘じておいてほしい。誰だって好き好んでレガシーでいまいちな状況に甘んじているわけではない。
いろんなのっぴきならない理由があるのです。

バックログの重要性

23 ありのままの進捗を計測する
見積もりの腕を上げるために。
最初からうまく行くはずもない。とにかく見積もってみよう。そしてその見積もりを記録し、実際にかかった時間と比較しよう。
バックログを活用して記録するのだ。回数を重ねれば上達する。

社内システムの保守とかで特に締切が付いてこない作業をしてるときでも、漠然と作業を進めるのはもったいない。見積もりの訓練と思って計画と振り返りを行うべし。
UnitTestがない場合もバグがあったらどこかにまとめておくと役に立つ。
(TDDの導入を進言するために過去のバグの分析をしたら自動化されたテストがあったとしても回避できなかったであろう問題ばっかりだった、とか :P)

まとめ

楽しく読めました。
悪魔のささやきにすごく共感してしまう・・・