アジャイルソフトウェア開発の奥義・感想その1

今日は、業務を途中で抜けて部の社員会なるものに出席しました。事業部とかのレベルだとちょっと粒度が粗すぎてピンとこないのですが、部レベルの話だと結構仕事に直結するのでためになります。少なくとも、上の人がどのような未来を描いているのかが分かるのは大きいことですね。その未来が、自分が思い描く未来とリンクしていない可能性もなきにしもあらずですが…


で、ちょっと早く帰ってこれたので、いろいろ家での時間が増えました。連日でブログでも書いてみましょうか。



さて、ここからが本題。昨日紹介した、「アジャイルソフトウェア開発の奥義」という本。今は40ページぐらい?あと15分の14ページくらいかな…orz


6部立ての第1部は「アジャイル開発」という名前で、要はアジャイルプロセス、特にXPの各プラクティスについて淡々と述べている部です。


その中で、読みながらいくつか心に浮かんだことを、メモがてらに書きなぐってみます。

プランニング(計画ゲーム)

直接的にはXPやアジャイルには関係ないのですが、読んでる途中に思ったこと。


私はPMでプロジェクトの人・時間・コスト等をコントロールするより、アーキテクトとしてエンジニア魂を貫きたいと思っています。けど、私自身がプロジェクト全体は管理しないとしても、PMが管理するためには(私を含めた)個々人ができるだけ詳細な作業見積もりを立てる必要がありますよね?*1


こういうことを考えると、全体のコントロール力はそこまで必要ではないけど、自分自身の見積もり能力は高めておく必要があるかと。今までその辺を考えてなくて、「プロジェクトの管理はどうせPMがやるんだから、PMに全部任せておけばいいじゃん、へへへん」みたいなのりでした。なんで、自分が行った作業、例えばこれだけの設計に○時間、開発に△時間、テストに□時間という計測をやってませんでした。


だめだめですね。早急に、日々の作業時間を計測するやり方を見つけないと!できれば、計測すること自体に楽しみが見出せるようなツール&手法がいいな…

ペアプログラミング

ペアプログラミングを取り上げた例だと、知識・技術が一人に属人化せずにチーム内みんなの理解が深まってハッピー!ってな記事をよく目にします。


けど、そもそもペアプロってペアを組む二人のレベルがあまりにかけ離れていると不可能じゃない?極端な例だと、大学教授の話を小学生にしても無駄という感じ。例えがあれですが、この業界レベルの差が激しいことも承知の事実。ある程度のスキル・知識がないと、そもそもペアとしてやっていけないのではないかと。


じゃあ、ある程度ってどの程度なのさ、って話があります。これも明確な基準は難しいですが、必要条件として「基本情報が取れるレベル」ぐらいかな?*2その程度の基本知識がないと、話していても一から説明しないといけないし、応用もきかないのではと。なお、これはあくまで必要条件であって、十分条件ではないでしょう。


テスティング

最近、自分の中で密かにマイブーム。残念ながら、現在のプロジェクトではいわゆるxUnit系が入ってないので仕方なしに自分で書いているのですが、その辺はまた別のエントリにでも。

テストプログラム、それは実行可能なドキュメント

本文の一文を引用。

テストはプログラムの内容を説明してくれるだけでなく、コンパイルも実行も可能なドキュメントなのだ。

ちょうど似たようなことを、ある社内講座中に講師の方が話されてたんですよ。それ聞いたときも、あーなるほどねと思いましたが、このような著名な本の中でも取り上げられているのを目の当たりにすると、うちの会社の講師陣もまだまだ捨てたものじゃないですね*3

テストのレベル

XPとかのテスティングというと

  1. ユニットテストの自動化 ⇒ リファクタリングデグレード対策
  2. テストドリブン     ⇒ 設計の早期検証

という二段階を踏んでいると認識してます。自分の現状は、一段階目はだいぶ意識づいて実践するようになってきたけど、二段階目まではなかなか踏み込めてないという状況ですね。

テストの分割

給与計算のケーススタディを例にあげて、テストの分割について述べられています。詳細は本を見てもらうとして、簡単に要約すると、複数のオブジェクト同士が連動して動作する場合のユニットテストでは、オブジェクト間にInterfaceをかまして抽象化した上でモックオブジェクトを実装しましょうということ*4


このMock Objectパターンでテスト分割って、Interfaceの概念がない構造化プログラミングでは厳しいですよね。無理やりif文でやろうと思えばできるけど、保守性やら可読性やらが落ちそう。やっぱりOOPポリモーフィズムを利用した実装の切り替え、さらに推し進めると、設定を外出しにするAOPに行き着くのかな。



かなり長くなりましたが、読書自体はまだまだ続きます。この本から得ることはいろいろ多そう*5なので、内容を消化・定着させる意味でもできるだけブログにのっけていきたいですね♪

*1:PMがトップダウンで全て見積もり作業を立てるのは、そのPMの能力が素敵だったらうまくプロジェクトが回るけど、そうでない場合は見積もりがはずれてデスマーチに一直線…

*2:実際に持ってなくとも、取れるだけの知識があれば全然オッケー

*3:その講師がこの本を読んでいる可能性もあるけど、それはそれで独学で本を読む向上心があるということですし

*4:ここで取り上げられた給与計算のUMLはどこかで見た気が。多分原典はこの本でしょう

*5:っていうか、まだ40ページなのにこれだけ考えさせられることがいっぱい…