大規模アジャイル開発の実態～ セールスフォース・ドットコムの作り方（前編）
クラウド上に構築したアプリケーションをサービスとして提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、開発を行っています。 アプリケーションのメジャーアップデートは年3回。クラウドで提供しているサービスという性格上、もしもアップデートにバグがあればそれは全ユーザーに対して大きな影響を与える可能性があります。バグがないこと、性能低下を起こさないこと、品質管理はパッケージソフトウェア以上に重要です。 同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか」で詳しく紹介されていました。 同社の開発手
「アジャイルな見積りと計画づくり」書評 -- 顧客を黙らせる為の見積りではなく喋らせる為の見積り - アンカテ
翻訳者の角谷さんより献本をいただきました。ありがとうございます。 アマゾンに以下のレビューを投稿したのですが、なぜか1ヶ月以上待っても表に出てこないので、こちらに出します。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ この本が問いかけているのは「開発者にとって客は敵なのか味方なのか」という問いだと思う。 私がソフトウエアの見積りの本を読む時に、漠然と期待してしまうのは、「これで客の口を塞ぐことができるか」ということだ。つまり、自分が「これは1000万円かかりますね」と言って顧客がそれを値切ろうとした時に、「いやこの見積りは正確です。なぜなら....」と言うような、建築における構造計算のような理論武装が欲しいと思ってしまう。 こういう思考の暗黙の前提は、「開発者と顧客は敵同士である」ということだろう。 見積りも仕様も開発者と顧客の間で交わす契約である。契約とは
アジャイル開発と反復開発の落とし穴
前回「『現状のソフトウェア開発は間違っていないか？』（プロセス編）」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は本来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発（*1）やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。 ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。 （*1）反復開発とは例えばRUP（Rational Unified Process）やUP（Unified Process）のこと。 反復開発とアジャイル開発の違い 反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる
エンタープライズにおけるRailsの価値とは - kuranukiの日記
Ruby on Railsが、エンタープライズの中でどのように広まっていくのか。スーツの奴らが金のために煽ってるだとか、エンタープライズRailsってどうよとか、バブルだとか、バブルは弾けたとか、色々な意見があるようです。 言語やフレームワークの考え方の好き嫌いといった哲学的な観点で色々な意見が出たり、テクノロジの観点で様々な意見が出るのは、むしろ良いことだなぁと思うわけですが、どうも違うなぁという考え方が１つあります。 それは「価格競争になったときの選択肢」のためにRailsに取り組もうとすること。それがエンタープライズにおけるRailsの価値なのでしょうか。私は違うと考えています。 単純に、金額のためだけにRailsを選ぶくらいならば、Javaでオフショアを選んだ方がよほど低リスク・低価格だと思いますし、せっかくの生産性の高さを安売りしている風に聞こえます。（それはSIの人月ビジネスの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
