良いアジャイル　悪いアジャイル

概要

• いいアジャイルと悪いアジャイルを読んだ感想。

引用

高いレベルでは、Googleのプロセスは、もっと伝統的なソフトウェア開発会社の人から見ると、たぶんカオスのように見えるだろう。新しく入ってきた人には、次のようなことが目に付く。

• 一種のマネージャはいるが、彼らのほとんどは少なくとも時間の半分はコードを書くのに使っており、テクニカルリードに近い。
• 開発者は、自分のチームやプロジェクトを、いつでも好きなときに、何も聞かれることなく変えることができる。ただそうすると言えば、運送屋がやってきて翌日には新しいオフィスで新しいチームと働くことになる。
• Googleには開発者に何をやれと言わない哲学があり、開発者たちはそのことをとても重く受け止めている。
• 開発者は20%の時間(これは週末や個人の時間にということではなく、月-金、8-5時の間でということだ)を、自分のメインのプロジェクト以外でやりたいことに使うよう強く促されている。
• ミーティングがあまりない。平均的な開発者はたぶん週に3回くらいのミーティングに参加し、これには自分のチームのリーダーとの1対1のものも含まれる。
• 静かである。エンジニアは1人で、あるいは2-5人の小さなグループで、静かに自分の仕事に集中している。
• ガントチャートや、日/タスク/担当者が書かれたスプレッドシートや、そのほか何であれ、目に見えるプロジェクト管理を示すものは見たことがない。
• 比較的まれなクランチ期間においてさえ、みんなランチとディナーは食べにいき、それは(良く知られている通り)いつも無料で美味だ。そして自分でそうしたいというのでない限り、ばかげたくらい長時間働くようなことはない。

Googleは、ソフトウェアエンジニアの視点から見たとき、際立って統制のとれた会社だ。彼らはユニットテストや設計ドキュメントやコードレビューといったことを、私が聞いたことのあるどの会社よりも真剣にやっている。彼らは自分たちの環境が常に整理されているよう熱心に働いており、どこかのエンジニアやチームが自分勝手な方法でやら

ないようにする厳格なルールやガイドラインが実施されている。結果として、コードベース全体が同じように書かれ、チームを変えたりコードを共有したりすることが、他の会社でよりもずっと簡単なことになっている。

そして(小文字の)アジャイルとなることに集中する。

引用元：http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm

要点

• アジャイルやスクラムといった開発手法がもてはやされていたが、実際使えない。
• 使えないのは、アジャイルを誤解した使い方がされている。
• 開発は、開発者へのインセンティブなどで開発者のモチベーションをベースに実装すべき。
• 時間やスケジュールといった縛りは無くす。

チームまたは自分の中にあるソフトウェアを構築することにより達成できる目的のある仕事であれば、アジャイルは機能すると思う。