2011年12月11日

DevLOVE Hangar Flight - Snow Barrage - に参加しました

12月10日に日本オラクルさんで行われたDevLOVEの一大イベントに参加してきました。
Hangar Flight - Snow Barrage -、参加者150人超、4トラック並列4枠でおこなわれる、
「開発の現場を前進させる」ためのおはなしです。
http://kokucheese.com/event/index/21611/


賢くて熱意のある人々に囲まれて、久々に頭使って顎が痛くなりつつも、非常に楽しめました。
以下、メモ。


HF趣旨説明 from @papandaさん
DevLOVEの首謀者、papandaさんからハンガーフライトとは何かの説明がありました。

まだ人にとって空が未知の領域だった時代。
飛行機乗りが格納庫に集まって、お互いの体験を話しあうことによって、次の飛行に活かす。
それがハンガーフライトです。
それはSW開発でも同じ。
自分でできる開発は一生で300人月しかない。
これを拡張するためには、他人の知見から学ぶ必要がある。
学ぶだけでは足りない。
得られたプラクティスや知見を、自分のコンテキストに変換して、現場で活用しなければならない。
聞くだけじゃなくて、変換して活かさないといけない。



その後、4trackに分かれてのワークショップ・講演。
僕が最初に参加したのは
@agilekawabata 川端光義 さんの
「普通のプログラマチームによるアジャイル開発と少数精鋭によるアジャイル開発」
大人数のSI系プロジェクトをXPを用いて率いた経験、少人数の精鋭Rubiestとともに行ったXP経験を
対比しながらはなしていただきました。


■普通のプログラマチームによるアジャイル開発

川端さんにとってagileといえば、ケントベックが生んだXP。
XPではプラクティスを全部やれ、という。なかなか難しいことなんですが...
ベンダー3社、40人1年間、20イテレーションで、XPやってみた。
ほぼすべてのプラクティスを実施することができた。

プロジェクトは、COBOLからJavaへの置換プロジェクト。
現場の人Agileにできるポテンシャルがあったのだが、
マネージャがCOBOL時代の古い考え方の人で、うまくいかず。。。
しかし、顧客のトップがアジャイル開発に理解があった!
そこで、Agile開発がスタート!

メンバーにagileのすべてを伝える時間はなかった。
そこでリッツカールトンのクレドを真似た。
アジャイルソフトウエア開発宣言を毎日15分読み合わせて議論した。
教育するのではなく、自己組織化して、みんなで改善していった。
XPの手法は現場に応じて最適化した。
たとえば、ふりかえりをメールでリマインドする、ドキュメントをWiki化する、など。
週40時間を守ることを明示的に掲げた。守れた。
守ることによって見積精度と見える化も向上した。

うまくいかないこともあった。抵抗勢力の存在。
他の会社との協業。その頃、事件が起こった。
ある日、wikiがすべて消える→奴らの仕業に違いない
でも、ここでチーム全員が一致団結できた。バックアップから一日で再構築。泣ける。

■少数精鋭によるアジャイル開発
ルビーとアジャイルは、ビールとアジャイル開発くらい相性がいい。
Railsがビールなら、枝豆はケントベック。
Rubyでできるエンジニアとagile開発したときは、個性が強すぎてプラクティスが合わないところがあった。
しかしリファクタリングやテストは勝手に個人がやっていた。
少数精鋭の開発の際は、規約や開発手法や勤務時間は全部任せちゃった。
各自こだわりがあるから任せるしかない。しかし、個人が有能なので任せてうまくいく。
しかし、プランニングや仕様の確認は、全員で合わせないといけない。
出来る人達はオレオレ仕様で行っちゃうケースが多い。
Androidの開発も、JavaじゃなくてScalaでやっている。
開発者に刺激を与えてあげる。
「コミュニケーション能力が絶対いる!と宣伝されているが、プログラマにコミュニケーション能力は不要」


印象的だったのは、Cucumberのデモ。Acceptance Testの自動化ツールとして
Cucumberの使い方をデモされようとしたのだけど、なぜかサーバの状態がおかしくなっていました。
そこで、講演中にSkypeで青森で開発している担当者に連絡し、その場で修正してもらい、
復旧する、というライブ復旧を行われていました。 
http://yfrog.com/gzppysnlj
本当に優秀なチームだからこそ、こんなチャレンジングで自由なAgile開発ができるのだなぁ。
と感じました。

ただ、普通のチームでも、金融系のSIなど非常に堅い開発でも、
複数の会社が関係している受託開発でもAgile開発ができる、ということに感動しました。
やり方と、やる気次第やわ。ほんま。




二つ目は永和の@kenchan Kenichi TAKAHASHI さんによる「ビルドをだいじに」
Jenkinsの話です。


kenchan氏の開発現場では、Gentiを使ってサーバクラスタを作成し、その上でCI環境をJenkinsで作成している。
Ganetiとは分散仮想クラスタサーバのためのソフトウエア。
3つのノード上に複数の様々なOSのインスタンスを作成し、Jenkins用に使っている。
CIやることで、開発チームが開発に専念できるようになった。
最新のソフトはどれか、お客さんはJenkinsに聞けばいいので。
それによりお客さんに価値を伝えるのもはやくなる。
Jenkins使うことで「手元では通ってたパターン」が早めに検出できるようになった
テストの分類(コンポーネント外を叩くテストはCIでのみ実行する、など)をすることで、
スローテスト問題もある程度解決しつつある。

Jenkinsの対抗馬:Travis CI。Github上のプロジェクト専用のCIサーバ。
ホスティングサービスもあるので、オープンソースプロジェクトなら、環境を作る必要もない。
これはよさそう。

スローテスト対策:
CIマシンを買い換える。遅いテストはCIだけで実行(Rubyの場合はProfileで簡単に置き換えられる)。
遅い部分を切り離す。遅いテストを早くする(preconditionを早く作れるようにする)。
すべてのCIビルドで全部テストできない場合もあるので、デプロイ前だけやるテストなど、
分類することもできる。
銀の弾丸はない。




弊社でもJenkinsを使ったCIは行われているのだが、僕はユーザで中のことが理解出来ていなかったので、
CI環境構築の話が聞けて、非常に楽しかったです。おそらく弊社のCI環境は、かなり進んでいると思うだけれど、
僕は何も知らないなあ、ということを改めて感じました。もっとべんきょうしなくては。
僕の現場ではスローテスト問題が今問題になっているので、講演後に質問させていただき、
いろいろ教えていただきました。でも、いろいろ工夫しながら出来ることを
やって行くしかないんだなぁ、という印象を受けました。
まずはテストそのものの書き方を工夫するのと、サーバのクラスタ化を推進するのが急務ですな。。



三つ目はこれまた永和の@papanda 市谷聡啓 さんによる
「海岸沿いのSIerから海岸沿いのServicerに行って 帰ってきて、そこにあったもの」
この枠が、誰を聞くか一番迷いました。@kompiroさんの話も聞きたかった。
けど、@papandaさんの話を聞いて、すごく勇気をもらいました。


これまでの転職は、縦方向移動(規模の拡大)を目指していた人が多かった。
しかし最近は横方向(SI->Serviserなど)が増えてきた。ほか、選択肢も多くなってきてる。
ただ、別のことを始めることは怖い。今までの正道を外れ、けものみちを歩くようなイメージだから。

SIerについて。
稼働率勝負。人月単位。多くの人が食えなければならない。
ゲームのルールそのものを変えることができない。SIer的には稼働率が大事なので、稼働率を上げる。
そうするとスキマ時間がなく、他の新しいことが出来ない、という。SIerのジレンマ。
成果物ベースの契約、サービスベースの契約(初期投資にコストが掛からず、
運用時にサービスとしてコストをもらう)、というビジネスモデル。
Selesxxxxxxという黒船に敗れた。
「目の前の顧客の声がいつも正しいとは限らない。顧客に的をいた判断をできるように働きかける必要がある。」と思い知らされた
( そこでアジャイルサムライですよ!)

Serviserについて。
Serviserに移ると、壁にぶち当たった。求められるのは圧倒的な現状維持力。
魔法なんてない。
コンウェイの法則「システムを設計する組織は、その構造をそっくり真似構造を産み出してしまう」
苦しかった。


気づき。
「自分も、この憎むべき現場の一員だった」
気づいていないことに気づく。それは難しいが、いくつかきっかけはある。
例えばきっかけは事件。もしくはカンフーパンダ
「相手のメンタルモデルを迎え入れる。受け入れることはできないけど、理解する。」
情熱プログラマーに勇気をもらい、永和システムへの転職を決意。
そしてアジャイルサムライのことば。
「もうやり残したことはなし、なにもかもわかった」と思った瞬間、君はアジャイルではない。



もうね、泣ける。川端さんの話も泣けたけど、自分の経験や失敗に基づいた話というのは泣けますね。
僕はどこへ向かおうか。



次は@haradakiro Harada Kiroさんの実践DDDQuickReplay
プロジェクタを片付けて、机という障害を取り除いた上での模造紙を使ったインタラクティブな実践DDD。

ドメインを綺麗に設計して凝集度が高いシステムにすることでパフォーマンスは一桁変わる
モデルを作って実装する。incrementalに。
モデル設計は実装のちょっと先(2 iteration)前をつくる。造り過ぎないけど、ちょっと先を見る。
アジャイル開発でやってると「こんな小さなシステムで回ると思ってんのか?」
「いや、おもってません、すいません」 となる。
まあ、しょうがない。

みんなでやるのが大事。紙やホワイトボードでモデルを書いて、あとでastahでちょいちょい清書する。
現場でもこんな感じでやってるらしい http://yfrog.com/gzi8wsrj



僕に業務システム開発の経験がなさすぎて、付いていくので精一杯でした。
が、なんかリズムよく説明してくれて、面白かったし、雰囲気はわかったかなぁ。
とりあえずエリックエヴァンス読んでみようかと思いました。


ふりかえり
HangerFlightはふりかえりがあるのでいいですね。
ふりかえりで自分が何を思っていたのかを整理して人に話せるのもいいんですが、
もっといいのは他の人の話が聞けること。
同じ話を聞いていた人でも「ああ、そんなとらえ方があったんだ」
という気づきが得られて、勉強になります。


さいごに
前回のSpring Bombは、僕が参加したはじめてのアジャイル系の勉強会でした。
それから半年、DevLOVEにはなんどもおじゃまさせていただき、
会社でもアジャイル的な開発手法を推進させていただき、実際にScrumで開発させていただき。
この半年で非常に多くのことを学べました。
次の半年では何が出来るかなぁ。
posted by コパン at 20:28| Comment(0) | agile | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

×

この広告は1年以上新しい記事の投稿がないブログに表示されております。