アジャイルサムライ

読むきかっけ

各所で話題になっていたのが気になりつつ、手を伸ばしていませんでした。前職では、上司の机に置いてあったりしたので、身の回りでも呼んでいそうな気配を感じていたことがあります。
また、開発手法について学んでおくと、自分が働くとき、誰かと働くときに、ゴールに達するまでの流れや方法を共有できそうだからです。

読んでみて

アジャイル開発というと、自分の中にある知識は、

• ドキュメントが無い、もしくは、いらない
• 常に開発してリリース
• ペアプロ
• スクラム

などなど、断片的な知識ばかりです。
日々の仕事でも、うっすらと「アジャイルとは？」だとか、開発手法については、きちんと知っておきたいと思いながら、目先の技術について追いかけるばかりで、学んでいませんでした。

読んでみて改めて大切であると感じたことは、

• チームで成功を手にしようとすること
  • 自分が得意なことを担当するのはもちろん、誰が担当？ということではなく、チームでカバーする
  • 誰がやる？じゃなく、チームで行う
• 継続的に時間（期間）、予算（とか経費）、品質、スコープ（機能とか実装要件）を見直す
• 可視化
• 方向転換のための技術的な継続。リファクタリング、ユニットテスト、テスト駆動
• 考える。これがアジャイル、ということは無い。案件、チームに合わせて手法を見直す。ライトスタッフであること

プロジェクトに影響する力として、紹介されているのが、下の4つ（ちなみに、四天王として紹介されていました。カンフーパンダが元ネタらしいですが）。

• 時間
• 予算
• 品質
• スコープ、やるべきこと

社内開発と、受託開発でことなるとは、思いますが、スコープは、動かしやすいのは納得（四天王としては最弱、ということですね）。
動かすべきではないのは、品質。

技術的なこととして気になったのは、下記のもの

• テスト（と、テスト駆動開発）
• CI
• デモ

テスト駆動開発については、大絶賛されてます。恥ずかしいことに、きちんとユニットテストもしていないので、まずは、テストから。最近、自分が書いたコードをリファクタリングする事が増えたのですが、テストしてる、してないは、リファクタリング時に効いてきます。もちろん、ふだんの開発でも、テストされていたら、なおさら安心。
CIは、デモに繋がる技術。これまたきちんと試したことがありません。試したいところ。
デモは、ウェブ開発みたいな場所だと（もちろん、プロダクトによって違うとは思いますが）、いつでも、誰でも、開発中のプロダクトに触れていいと思うのです。発注側は、もちろん、自分達でも何を開発してるかわからない時があるんですから。もちろん、そのためには、今まで紹介されている技術を利用した方が良いし、利用しなくても、デモは、出来る（デモ環境が、いつでも作りやすい、とはいかない場合は、デプロイなどを見直すとか）。

読んでいて、アジャイル開発に感じたのは、何かが新しいわけじゃなく、プロジェクトを進めるために、してきた、している工夫を、集めて、体系化されたような印象です。

おすすめ

開発者、開発マネージャーは必須。もし、1人で発注、開発、利用しているのでなければ。
でも、発注側も読んで欲しい一冊。というのも、プログラムソースがでてこないわけじゃないけれど、本質に関わることじゃないので。むしろ、なにかを生み出す、プロセスを踏む、ということについて学べる一冊だと思います。

【送料無料】アジャイルサムライ [ ジョナサン・ラスマセン ]