「アジャイルサムライ」を（とりあえず）読了した

アジャイルサムライ−達人開発者への道−

アジャイルプロジェクトというのに昔から興味があって、「アジャイルサムライ」というのを読み始めていた。

アジャイルサムライについては前に少しブログで触れたけれども、この度やっと一通り読み終えたので、全体を通して思ったことをまとめておきたい。

msyksphinz.hatenablog.com

お客との対話が常に重要

アジャイルサムライでは、要求や締め切りをミートさせるために、お客と常に話し合うことが大事だとまず説いていた。 プロジェクトにお客を巻き込むのだと。 そして、短いスパンでリリースを繰り返して行き、顧客の思うものと、最終成果物との差分をなくしていくことが重要だ。 また、常にプロジェクトのありのままをお客に見てもらうことにより、プロジェクトに問題が発生しても正しい解決策を導き出すことが出来るようになる。

これ、ハードウェアや半導体開発でも同じことが言えるだろう。ハードウェア開発者にとって、お客というのは実際にチップを使うメーカーであったり、 同じプロジェクト内にいるソフトウェア技術者だったりする。

ソフトウェア技術者に対して、細かくFPGAで最新ハードウェアをリリースしチェックしてもらうことは、常にゴールをぶれさせないようにするためであったり、 後に述べる「継続的インテグレーション」のために必要なことだと思う。

面白いツールの紹介「インセプションデッキ」

よくプロジェクトの途中に、自分の役割が良く分からなくなったり、目標がぼやけてしまうことがある。

そのためにまずはアジャイルプロジェクトでは「このプロジェクトの視界を遮る難しい問題」についてあえて取り上げ、プロジェクトをスムーズに進めるための 手助けとする。これはエンジニアにとって、「今自分の仕事は何のためにあるのか」という重要なモチベーションを維持するのに役に立つ。

面白いツールの紹介「バーンダウンチャート」

プロジェクトの進捗度合い、ベロシティが今どの程度なのか？それを見積もるためのツールとしてバーンダウンチャートが紹介されていた。

どの程度タスクをこなしたかにより、現在のベロシティと完了見積もりをたてることが出来る。

タスクが増えたことにより、見積もりが変わった場合にはベロシティを考え直し、プロジェクトの終了見積もりを立て直す。

おまけ：第V部の個人メモ

第５部については、読みながらRedmineにメモを取っていったので、それを貼っておこうと思う。

第12章 ユニットテスト：動くことが分かる

• バグを修正する前に、失敗するテストを書く。

テストコードをたくさん書くことの利点

• すばやいフィードバックが得られる
• きわめて低コストにリグレッションテストを実行できる
• デバッグ時間を大幅に削減できる
• 自信を持ってデプロイできる

一見ユニットテストを書くのが難しそうな項目(ランダムテストであることを確認するテストなど)でも、アサーションなどを適用することにより、ある程度チェックすることが出来る。

第13章 リファクタリング：技術的負債の返済

• 新機能の追加はしないし、バグの修正もしない。もっと分かりやすくする。
• コードの意図をつかみやすくしたり、変更がしやすくなるように設計を改善する→リファクタリング

第14章 テスト駆動開発

ごく短いサイクルを繰り返しながら少しずつソフトウェアを設計していく。

1. まずは失敗するユニットテストを書く
2. テストに成功するコードを書く
3. リファクタリングする

以上を繰り返す。

• ルールその1。失敗するテストをひとつ書くまでは、新しいコードを一切書かない。
• ルールその2。｢危なっかしいところ」をすべてテストする。

第15章 継続的インテグレーション：リリースに備える

• 常にリリースできるような状態を維持する。
• チェックイン手順を習慣付ける
• ビルドの作業単位を短くし、短いスパンで継続的インテグレーションできるように心がける。