2011年12月17日

Googleのバグ予測アルゴリズムのスコアをgitのファイル毎に得る

先日、以下のような記事をみつけました。

グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
http://www.publickey1.jp/blog/11/post_193.html

これの値をgitのファイル毎に取得するスクリプトを書きました。
以下においてあります。
https://github.com/kopanitsa/Google-Bug-Prediction-Score

gitのコミットログを取得して、そのタイムスタンプを抜き出し、スコアを計算する
簡単なスクリプトです。

以下の方法で使用できます。実行するとファイルごとのスコアを示す
csvファイルが生成されます。

$ cp <this script> <root of your project>
$ cd <root of your project>
$ python bugfix_score.py --target=<target path>


--package=Trueとすると、ファイルごとではなく、パッケージに対する数字を計算します。
--extension=javaとすると、.javaファイルのみを対象とします(--package=Trueとしたときは、ここはうまく働きません、いまのとこ)

自分のプロジェクトにも適用してみたのですが、だいたい直感と同じ結果が得られました。
すなわち、
 枯れているな、と思っているコンポーネントの値は小さく、
 炎上しているな、と思っているコンポーネントの値は大きく、
計算されました。

直感と同じ値なので、計らなくていいじゃんwという気もしないでもないですが、
問題点を数値で示されると、「やっぱりまずいんだな、直さないとな」という気になりますね。

posted by コパン at 12:17| Comment(0) | agile | このブログの読者になる | 更新情報をチェックする

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 | このブログの読者になる | 更新情報をチェックする

2011年07月31日

Devlove0729に参加してきました

Devlove0729に参加してきました。
タイトルは
 DevLOVE PF「あなたのチームは、もえているか?」

PF / agileを実践している方の実際の事例をたくさん聞けて非常に刺激を受けました。
ただ、特に印象に残ったのは、あまのりょーさんの
「講演ではPFの上澄みしか伝えられず、本当に面白い大変なところは現場でしか得られない」
という趣旨の発言。
思考方法やツールは同じでも、その適用方法は実際に現場で実践していくしかない、
近道はない、と改めて感じました。

以下、メモ。

■My job went to vitnam?(あまのりょーさん)
 my job went to India
  改訂版は、「情熱プログラマー」というタイトルになっている
 今回の話は事例紹介
  泥臭い話はできないので、今日は上澄みだけ。
  ベトナムハノイのチームとオフショア開発
 英語について
  一夜漬けのビジネス英会話 岸良裕司
  勇気づけるための本
 タックマンモデル
  forming:形成
  storming:混乱
  norming:統一
  performing:機能
  adjourining:散会
   →なんか新しいことをやろうとすると、stormingの時期は発生する。
 顔が見えるコミュニケーションは非常に重要
  Swedenとのやりとりも同様
  偏愛マップを書いて一時間くらいかけて自己紹介
  Daily short meeting via chat
   stand up meetingの代わり
  信頼関係が超大事(聞けばすぐ答えてくれる。正確さや厳密さはそのつぎ)
 課題が残ったところ
  バージョン管理システムへの意識のずれ
  品質感への意識のずれ
  セキュリティ意識のずれ
 「経験が重要な部分はサポートしつつ、あふれるようなモチベーションを逆に補完してもらえれば勝てる」
 ”Probrem vs us", not "You vs us"
 ふりかえり最優先条項
  ふりかえりをする際の心構え
  全員がベストを尽くしたことは疑わない、事を確認する。
 私にとってのPF
  メンバーが互いに
  「信頼貯金」を貯めるための
  仕組みと実践


■PFの組織導入(天野勝さん)
 トップダウンでのPFツールの使用が増えてきている
 PFとは
  目的:
   個々人の能力をうまく発揮させることでプロジェクトを成功させる
   エンジニアとしてのQuality of Engineering Life (QoEL)を向上させる
  PFとPMは両輪。PFは協調の場づくり
  5つの価値
   対話、行動、気づき、信頼関係、笑顔
  5つの行動原則
   見える化、なまえづけ、リズム、問題vs私達、カイゼン
  スクラムとかアジャイルとかいう言葉は使わずに導入している。
  チームファシリテーション
   タスクボード、ふりかえり、朝会だけを使用する
 PFを組織導入すること
  トップダウンでカイゼン活動、見える化をやる事例が増えている。
  ミドル層が困る
   トップがカイゼンしろ、とか言っても、中間層がリソースを取られるのを嫌がって止まることがある。
  経験として、やっぱりアナログのほうがデジタルよりもうまくいく。
   デジタルだと誰も見ない。アクセスしに行かないといけないから。
  プロジェクトごとに大きく特性が異なるので、一概に言えない。
   チューニングする必要がある。
  アジャイル開発
   二つに分けられる
    開発プロセス・開発手法の視点
     Lean、顧客巻き込み
   チーム運営の視点
     Scrum
 トップダウンPF導入の計画
  事務局を置いて、3ヶ月程度企画をする
   会社に応じた戦略をとる
   パイロットプロジェクトを選定する
  立ち上げに3−6ヶ月
   パイロットプロジェクトを一周回す
   ここは意外に簡単。やりたい人がやってくるから
  展開に6ヶ月以上
   やりたくない人にも展開する。
   立ち上げ時のプロジェクト数より大幅に多い場合は破綻する。
   社外コンサルが直接チームに教えるのではなく、社内コンサル・推進チームがプロジェクトチームに教える。
 トップダウンで導入するときの注意事項
  経営層について
   経営層に人気があるか、任期が長いか、信頼されているか
   ビジョンが明確か
   経営層がビジョンに対してコミットしているか
  事務局について
   専任でなければならない
   TFに関する知識を有しているか
   事務局内での合意形成は行われているか
   事務局からの発信文書は受け取られるか
  社内コンサルについて
   教え方を教えられる人か
  推進者について
   人材育成のミッションを持っているか

posted by コパン at 22:57| Comment(0) | agile | このブログの読者になる | 更新情報をチェックする
×

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