読者です 読者をやめる 読者になる 読者になる

めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

アジャイルサムライ

読むきかっけ

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

アジャイルサムライ

読んでみて

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

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


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

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

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

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

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

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

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

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

おすすめ

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