アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 を読んだ
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
- 作者: Venkat Subramaniam,Andy Hunt,木下史彦,角谷信太郎
- 出版社/メーカー: オーム社
- 発売日: 2007/12/22
- メディア: 単行本(ソフトカバー)
- 購入: 35人 クリック: 995回
- この商品を含むブログ (291件) を見る
45個のプラクティスの紹介が、それぞれ悪魔の誘惑に始まり天使のささやきで終わる。具体例と実行時の気持ちまでが説明されていてとても楽しく読みやすい。(日本語訳がとても丁寧に行われたように思えます)
以下、本を読んだ感想やふと思ったこと。
アジャイルは開発手法ではない
アジャイルはチームを構成するメンバー各人の心構え、仕事に臨む態度である
・・・ここまで言い切ると語弊があるかもしれないが、この本を読むまではアジャイルというのがこんなにも人間にスポットを当てた方法論だとは思ってなかった。
TDD
TDDのいいところは自動的にテスト行われてデグレが自動的に見つかるとかいうところにあるのではない。
テストフレームワークにあわせてそれを意識して開発を行うことで、開発者の頭の中が整理されてアプリケーション(プロジェクト)自体が非常に整った、メンテナンス性の高いものになるところにある。
偉い人が「導入するぞ」って言うのを待たずとも、個人でできることはいろいろある。
レガシーの問題点
通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状態になっていないため、テストしにくく、結合度の高さ故、変更を加えにくく、予期しない箇所に影響が出やすい。
そのせいでストレスがたまる、なんか怖くて微妙に手がすすまない。
アジャイルのなにが優れているのか
単に正しいやり方を適用すればいいってわけじゃない
16 頻繁なデモでフィードバックを得る
コードの変更がそうであるように、開発方法を変えようとする場合はそれが現在どのように機能しているか、なぜそうなっているのかを理解しなくては、効果的に変更を行うことはできない。
新しい手法だけ持ってきて「これで行くから」的なゴリ押しに走る人は肝に銘じておいてほしい。誰だって好き好んでレガシーでいまいちな状況に甘んじているわけではない。
いろんなのっぴきならない理由があるのです。
バックログの重要性
23 ありのままの進捗を計測する
見積もりの腕を上げるために。
最初からうまく行くはずもない。とにかく見積もってみよう。そしてその見積もりを記録し、実際にかかった時間と比較しよう。
バックログを活用して記録するのだ。回数を重ねれば上達する。
社内システムの保守とかで特に締切が付いてこない作業をしてるときでも、漠然と作業を進めるのはもったいない。見積もりの訓練と思って計画と振り返りを行うべし。
UnitTestがない場合もバグがあったらどこかにまとめておくと役に立つ。
(TDDの導入を進言するために過去のバグの分析をしたら自動化されたテストがあったとしても回避できなかったであろう問題ばっかりだった、とか :P)
まとめ
楽しく読めました。
悪魔のささやきにすごく共感してしまう・・・