Agile Japan 2009
2009年4月22日、東京千代田区にある放送会館で「アジャイルジャパン2009」が開催されました。本イベントは「ソフトウェア開発の次世代リーダーをつくる」ことを合い言葉に、200人以上の参加者を集めてスタートしました。
作者 Mike Bria , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2009年7月1日 午後3時4分
"なぜこの世界では1つの仕事を2人でするのか?" 初めてペアプログラミングの考え方を紹介されたとき、多くの人は最初にこのように反応する。本質的に、彼らは、ペアプログラミングとはある部分のコードを書くコストが2倍になることだと考える。Dave Nicollete氏が、ある計量的な考え方を示し、ペアプログラミングはお金を無駄にするのではなく、節約することを示している。
ペアプログラミングの経済的価値に関する提案は、誤解されることが非常に多い。プログラミングはタイプすることだと誤って考えられるからだ。現実に、もちろんプログラミングの大部分は、実際に考えることで、その結果として間違った決定をしたり、エラーを作り出したりする機会を延々ともたらすことになる。このように作り出したエラーは、最終的には、将来開発者の時間を費やすことになる。(つまり、それは会社の時間だ。)
これが、ペアプログラミングの経済的価値に関する提案がなされるところであり、また定量化が難しい理由でもある。Dave Nicolette氏は最近の記事において以下のようにまとめている。
ペアプログラミングをする価値は、最初の場所でエラーが起きるのを防ぐとても小さな軌道修正という形でやってきます。軌道修正は小さな範囲で行われ、ペアで行う作業の流れの中で境目なく起こるので、通常まったく気付かれません...その価値は簡単に見過ごされます。なぜなら、ペアプログラミングの効果は、いつか将来、余分な作業が起こる状況を防ぐものだからです...後になってこれらの効果を観察して、定量化するのは簡単ではありません。そのような悪いことは決して起こらないのですから。
つまり、ペアプログラミングの価値は、将来の時間が省かれた形でやってくる。結局は、"時は金なり"だ。では、一体、いくらになるのか? 同じ記事の中で、Dave氏はこの質問に答える考え方を示しながら推測した。
最近のペアプログラミングのセッションにおいて、Dave氏はどれだけペアの1人が他のペアを助けたかを記録した。これには、間違いを見つけたり、設計に関する議論が起きたりしたことが含まれていた。その後、これらのことがそれぞれどれだけ将来の時間を節約したかを決めた。そして、この情報はさらに他の計算に使われた。
Alistair Cockburn氏が以前に書いたある本の中で、ITプロフェッショナルのコストは1分間2.10ドルだと計算しました...ペアプログラミングのセッションにおいて、設計に関するちょっとした議論を2回行い、少しリファクタリングしました。計算によると、これによって将来コードメンテナンスを行う4時間を節約しました。これは、2.1 x 120 = 252.00ドルの価値があります。私たちのうちの1人が小さな間違いに気付いた瞬間が12回ありました。これらの出来事によって、平均30秒のデバックのための努力が省かれた場合、0.5 x 2.1 x 12 = 12.60ドルの価値があります。合計して、90分で会社のお金を264.60ドル節約しました。これは、1時間に約180.00ドルを節約したことになります。
...
会社には、複数のXPチームがあって、合計約40人の開発者が働いている小さなIT部門があります。開発者が1日5時間ペアプログラミングを行うと仮定する場合、20ペア x 5時間 x 1週間5日 = ペアプログラミングの時間が1週間500時間です。1組のペアで1時間180ドルを節約すると仮定すると、ペアプログラミングによって確かに節約できるのは1週間で平均9万ドルです。この作業の割合が1年を通じておおよそ一定で、チームが1年間に50週作業をするとすれば(アメリカ合衆国の場合であり、休暇は短い)、会社は、具体的に言って年間450万ドルを節約できます。ソフトウェア開発チームが、標準のプラクティスとしてペアプログラミングを行うことによってです。
たった40人の開発者がいるこの会社で、450万ドル だ。Dave氏は次のように認めている。これらは、1つのペアプログラミングのセッションから出した大雑把な計算でしかなく、決して科学的なものではない。しかし、それにもかかわらず考慮すべきものだ。
あなたはどう考えるだろうか?
2009年4月22日、東京千代田区にある放送会館で「アジャイルジャパン2009」が開催されました。本イベントは「ソフトウェア開発の次世代リーダーをつくる」ことを合い言葉に、200人以上の参加者を集めてスタートしました。
今週(2009年6月1日)AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumboというコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。
ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。
この記事ではJavaプログラマがなぜFlexとBlazeDSを学ぶべきなのかについて13の理由を述べています。なぜ高度にインタラクティブなWeb サイトからJavaで開発されたバックエンドをもつエンタープライズ・アプリケーションまでを含む、リッチ・インターネット・アプリケーション(RIA)の開発にFlexとBlazeDSの組み合わせが最適な選択肢となるのかについて述べています。
Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。
この記事ではAlex Devine氏が、Java開発者がPerf4Jをどのように利用できるかと、タイミングステートメントにコードを追加し、ロギング、結果の解析とモニタリングを行うオープンソースツールセットの説明をします。
この記事では低レベルのサービス・レイヤやリポジトリ・レイヤを肥大化させることなく、フェッチング・ストラテジによってモジュール化された方法でバックエンドにあるシステムからデータを取得する処理を最適化する方法について説明します。
No comments
スレッド表示 返信