GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Chris Sims , 翻訳者 渡嘉敷 満理子 投稿日 2009年5月26日
アジャイル・マニフェストには「契約交渉における顧客との協力」と記述されているが、多くの開発者や企業にとって契約とは現実味を帯びるものである。Peter Stevens氏は、10種類の開発契約について分析し、それぞれの形態がどの程度アジャイル・プロジェクトに適合するか明らかにした。また、氏は、固定価格やタイム・アンド・マテリアルよりもはるかにふさわしい組合せを見出した。
Peter氏は、10種類の各契約を調査し、それぞれ以下の点について述べた。
最も基本的な開発の契約種別は、タイム・アンド・マテリアル方式である。この方式では、金銭面のリスクの大部分を顧客が負うことになる。開発者には早期終了やコスト削減へのインセンティブはない。
タイム・アンド・マテリアルに代わる最も一般的な契約は固定価格契約である。この方式は、大部分のリスクを開発者が負うため、顧客に支持されている。プロジェクトが長引いた場合は、開発者がコストを負担することになる。この種の契約は、スコープの変更には都合が悪い。それは、スコープの対象内か否かに関する意見の相違が生じる可能性があるからだ。
Stevens氏は、この2つの契約はもちろんのこと、固定利益方式など興味深い種別も調査している。関係者は開発者に支払われる固定利益(たとえば100,000ドルなど)にあらかじめ合意している。プロジェクトにかかる時間はどうであれ、開発会社は利益に加え実際にかかったコストを受け取る。プロジェクトが早期に終了すれば、それは顧客と開発者双方の利益となる。
Llewellyn Falco氏は、Bob Martin氏による複合型の契約を使用してきた。この契約には定額および時間給の両方が盛り込まれている。開発者は作業にかかる時間(たとえば80時間など)を見積もる。続いて開発者は、この時間に「通常」の時間給をかけ合わせ、作業に対する期待原価を(仮に時給200ドルとして)導き出す。この場合、期待原価は16,000ドルということになる。この総額を定額やより低い時間給へと分ける。たとえば、固定部分を8,000ドルとし、時間給は時給100ドルまで下げるとする。プロジェクトにかかる期間が予想どおりであれば、代価は、8,000ドル + 80 * 100ドル = 16,000ドルということになるだろう。プロジェクトが予定より遅れた場合は、開発者は追加の作業に対し時間当たり100ドルを稼いでいるに過ぎない。この方式では、開発者と顧客の間でより平等にリスクを共有しようという試みがなされている。
Peter Stevens氏は、フェーズ開発契約や「money for nothing, changes for free(早期解約と無料変更)」契約を推奨している。氏はフェーズ開発による自らの成功を報告し、次のように述べている。
「money for nothing, changes for free」契約は、スクラムやアジャイル開発プロセスのメリットを競争上の優位性へと変えます。
- 業務価値を優先し付加的に実現することにより、完全に失敗する可能性は劇減する。また、このメリットは顧客に引き継がれる。
- さらに、これは協力型モデルであるため、コスト削減維持へのインセンティブを双方に与える。
- 早期解約条項により、スクラム・チームはより高い生産性を達成できる。マイナス面を言えば、この条項は、現在の経済情勢では政治的に容認しがたい「ゴールデン・パラシュート」のようにも思われる点である。
最後に、Peter氏は再びアジャイル・マニフェストに戻り、適切な契約を結ぶことは重要であるが、良好な協力関係を築くことはさらに重要であると繰返し述べた。
これまでどのようなタイプの契約に関わり、その契約は関係の構築にどの程度貢献したのか?これについてコメントし自らの経験を共有していただきたい。
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信