アジャイル

アジャイル系の本を2冊、ようやく読み終えたのでメモ。

今回読んだ本は以下の2冊。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

頭に残っていたのは、「アジャイル開発において、進捗をはかるのは動いているものだけ。中途半端に実装したものなどは進捗0%とみなす。」ってこと。う〜〜〜ん、この考えはすごい決断が要りそうだなぁ。できるだけ自分の作業高を高めたいと思うし。

でも、ちゃんと筋は通っていて、納得できる。で、このアジャイル開発についてうちのプロジェクトでどうやって生かそうかを考えてみた。

今の仕事の進め方としては・・・

ドキュメント修正→プログラム修正→レビュー→テスト→レビュー→リリース

という流れ。ただ、レビューをのぞく作業すべてがひとりでの作業。ペアプログラミングじゃないけど、もうちょっと他の人と相談して作業が進まないかなぁと思う。

なんでこんなことを気にしているかというと、修正内容に対する影響調査が適当であるため。レビュアーの負担が高いという思いが有る。ってか、僕の負荷が高いんだよねぇ。

ひとつのプログラム修正はだいたい2〜3日程度で終わり、一週間で作業は2〜3回転でき、リリースも毎週可能・・・だと思う。あんまりアジャイルって言う意識は無いけど、振り返ってみればそこそこアジャイルっぽい感じがする。

結局、よりコミュニケーションが必要ということか。それをどうやって実践まで持っていくか、もっと考えんとあかんなぁ。勉強会みたいなもの（メンターとの会話）があれば参加してみたい。

ちなみに、アジャイルっていうと、以前アジャイルプラクティスって本を読んだ。あの本はサラッって読めて、アジャイルの空気がよく分かる名著だと思うんだけど、今回のアートオブアジャイルデベロップメントは、良い点／悪い点をちゃんと明らかにしてさらに詳細に書かれている。本は厚いけど、何度でも読むべき本だと思う。

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