いいアジャイルと悪いアジャイル
を読んだ。
グーグルーすげーよ。わーわー。っていう話。
俺はこういう話に乗っかりたくなっちゃう(こうあるべきだーーみたいな)タイプなんだけど、
多分大勢の人はそんなこといっても現実はー、とか、こんなの絵空事だよー、とかっていう反応だと思う。
以下、引用を伴っての感想
- 一種のマネージャはいるが、彼らのほとんどは少なくとも時間の半分はコードを書くのに使っており、テクニカルリードに近い。
- 開発者は、自分のチームやプロジェクトを、いつでも好きなときに、何も聞かれることなく変えることができる。ただそうすると言えば、運送屋がやってきて翌日には新しいオフィスで新しいチームと働くことになる。
- Googleには開発者に何をやれと言わない哲学があり、開発者たちはそのことをとても重く受け止めている。
- 開発者は20%の時間(これは週末や個人の時間にということではなく、月-金、8-5時の間でということだ)を、自分のメインのプロジェクト以外でやりたいことに使うよう強く促されている。
- ミーティングがあまりない。平均的な開発者はたぶん週に3回くらいのミーティングに参加し、これには自分のチームのリーダーとの1対1のものも含まれる。
- 静かである。エンジニアは1人で、あるいは2-5人の小さなグループで、静かに自分の仕事に集中している。
- 比較的まれなクランチ期間においてさえ、みんなランチとディナーは食べにいき、それは(良く知られている通り)いつも無料で美味だ。そして自分でそうしたいというのでない限り、ばかげたくらい長時間働くようなことはない。
で、なんでそういうことが可能かっていうのがなんとなく書いてあるんだけど、多分みんな同じようなタイプの人間が集まってくるからじゃないかな。
職業プログラマ(別にやりたくてやってるわけじゃないし、プログラミングも好きじゃないし)みたいな人がいないっぽいのがいいよね。
こいつすげーあいつもすげーみたいな連鎖反応が起きてサボる人なんて出ないようにうまいことなってんじゃないかな。あとインセンティブ制度もそうか。
んでじゃあ別に好き勝手やっているのかというとそうではなくて
Googleは、ソフトウェアエンジニアの視点から見たとき、際立って統制のとれた会社だ。彼らはユニットテストや設計ドキュメントやコードレビューといったことを、私が聞いたことのあるどの会社よりも真剣にやっている。彼らは自分たちの環境が常に整理されているよう熱心に働いており、どこかのエンジニアやチームが自分勝手な方法でやらないようにする厳格なルールやガイドラインが実施されている。結果として、コードベース全体が同じように書かれ、チームを変えたりコードを共有したりすることが、他の会社でよりもずっと簡単なことになっている。
エンジニアはもちろん優れたツールを必要とするので、Googleは自分で使うツールを作るために優れた人々を雇っている。彼らはエンジニアたちに、その方面への興味があればツール作りに協力するように(インセンティブを使って)奨めている。結果として、Googleは世界でもトップクラスの優れたツールを手にしており、それは改善されつづけている。
とまじめにソフトウェアについて考えていると。
あとこういう決め事が技術のよくわかんない人やたいした技術の無い人が適当に決めたとしか思われないまったく時代錯誤なものだと納得できないんだけど、リーダーがテクニカルリードしてるわけだからそういうことも基本的には起こりえないと。
あとこれは単純なやつなんだけど、
作業キュー(もちろん優先度つきだ)さえあれば、アジャイル方法論の魔法の利点だとされていることの多くは即座に達成できる。そして間違わないで欲しいのは、それはインデックスカードの山ではなく、ソフトウェアに入れた方がいいということだ。納得できないというなら、あなたのインデックスカードを取ってしまうから。
優先度つきキューは、プロジェクトが進むにつれて人々から出てくるあらゆるアイデア(それにバグ)を投げ込むゴミ捨て場のような場所だ。このキューが空(これは定義により、プロジェクトが完了されたことを意味する)にならない限り、どのエンジニアもアイドル状態になることはない。タスクを保留したり再開したりするには、単に適当なメモやドキュメントをつけてキューに戻すだけだ。どれだけの作業が残っているのかいつでも分かり、望むなら残っているタスクに基づいて時間を見積ることもできる。クローズされた作業アイテムを調べてバグの回帰率から(望むなら)個々人の生産性まで、様々なことを推定できる。何のタスクがよく見送られるかわかり、これは組織における苦痛の原因を見つける役に立つ。作業キューは完全に透明なものであり、作業がだぶって行われるリスクはほとんどない。
これは欲しい。自分があとどれくらいタスクがあるのかとか、色々忘れちゃうし。
他人もどのくらいタスクがあるのか目で確認したいし、
そうすれば誰に何を振ればいいのかも管理できるし、
技術の事がまったくわからない上の人でも「ああ、こんなに作業が残ってるのね」みたいに感じて自分の仕事が終わったからリリースが出来るみたいな勘違いされなくて良いし。
で、これってtracのチケット機能が使えるんじゃないかなと思ってるんだけどどうだろう。
個別のチケット一覧とか、未解決済み一覧とか、あとカスタムクエリも書けるみたいだし。
あー最後に、この著者がねぼすけだと言うことにも共感を覚えておく。と。
それと今うちの会社は全くこの方向とは逆行している気がする。
管理、管理、管理。
どっちが良いか悪いかなんてわからないし。よいって誰にとってのよいなの?(技術者?上司?株主?)とかそんな定義まで持ち出したらキリがないのでそれはそれで良いんだけれども。
少なくとも根っからのエンジニア気質の人に好かれる環境ではなくなっていっていることは確かだと思う。