GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Vikas Hazrati , 翻訳者 沼田 暁子 投稿日 2009年1月5日
「ロケーション間でのスキルレベルの違いによるソフトウェアの品質の問題」は世論調査結果からわかった最も興味深いことの一つであるが、この調査は2008年9月のReg読者調査(リンク)で行われたものである。この調査の回答者は369人で、その内80%は分散ソフトウェア開発を直接経験していた。地理的には44%が英国、36%が米国、そして他の場所が20%に分かれていた。
コミュニケーションとコラボレーションは依然として分散開発の主要な課題であり回答者の85%以上が挙げていたが、驚いたことに2番目は、調査によると、サイト間でスキルセットに差異があり過ぎることに起因するソフトウェアの品質の問題であった。もう一つ密接に関係している問題は、プラクティスやプロセスの質における違いである。これらの課題は、組織の種類や以下のような管理手法にかかわらず、該当するものであった。分散開発において、回答者たちが利用している3つの主な手法には以下のものがある。
調査では、分散開発の課題はアドホックな手法をとると大きくなることが明らかになったが、しかし、課題の順番は手法を問わず同様であった。手法全体で報告された課題の上位5つは次のものである。
分散開発の背後にある一番の動機は、コストに照らしたリソースの柔軟性と戦略上の価値からきたものである。これは、コストだけに焦点を合わせることは役に立たないという意見に至るかもしれないが、それは安価なリモートのリソースが不十分な経験やスキルに結びつくかもしれないからである。
もう一つの興味深い意見は、どれが分散可能であるかというアクティビティに関する結果である。回答者たちの中でハブ・アンド・スポークの手法をとっている人たちは、仕様の定義や分析、設計のような、何らかの重大なアクティビティよりも、コーディングやテストのアクティビティを分散することを好んでいる。ピア・ツー・ピアの手法をとっている人たちは、これらの重大なアクティビティを分散することを、比較的に渋ってはいなかった。
同じような分析の中で(リンク)、Scott Ambler氏(リンク)はDr. Dobb'sが行った2008年のアジャイル採用に関する調査(参考記事)の結果をまとめたが、その中では、プロジェクトの成功率が地理的な距離に反比例することが明らかにされた。以下はアジャイルチームの成功率である。
Scott氏の意見では、コミュニケーションとスキルの発展を助ける分散開発成功への鍵(リンク)は、次のものである。
他に、Martin Fowler氏(リンク)のOffshore Development(リンク)(オフショア開発)や、Jeff Sutherland氏(リンク)が分散開発成功のための優れたプラクティスについて話したReaching Hyper-Productivity with Outsourced Development Teams(リンク)(アウトソースされた開発チーム群で高い生産性に到達する)などのサクセスストーリーがある。
分散開発は自らの課題を抱えているが、今日の世界における現実である。鍵は、効果的なツールを使用することと、より優れたコラボレーションのプラクティスにあり、それらはコミュニケーションの促進や地理的な配置を超えたスキルの構築を支援するだろう。
原文はこちらです:http://www.infoq.com/news/2008/12/distributed-development-quality
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
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
スレッド表示 返信