InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

開発の分散は品質の問題が生じるだろう

作者 Vikas Hazrati , 翻訳者 沼田 暁子 投稿日 2009年1月5日

セクション
プロセス/プラクティス
トピック
Agile in the Enterprise ,
Agile
タグ
Surveys

「ロケーション間でのスキルレベルの違いによるソフトウェアの品質の問題」は世論調査結果からわかった最も興味深いことの一つであるが、この調査は2008年9月のReg読者調査(リンク)で行われたものである。この調査の回答者は369人で、その内80%は分散ソフトウェア開発を直接経験していた。地理的には44%が英国、36%が米国、そして他の場所が20%に分かれていた。

コミュニケーションとコラボレーションは依然として分散開発の主要な課題であり回答者の85%以上が挙げていたが、驚いたことに2番目は、調査によると、サイト間でスキルセットに差異があり過ぎることに起因するソフトウェアの品質の問題であった。もう一つ密接に関係している問題は、プラクティスやプロセスの質における違いである。これらの課題は、組織の種類や以下のような管理手法にかかわらず、該当するものであった。分散開発において、回答者たちが利用している3つの主な手法には以下のものがある。

  • ハブ・アンド・スポーク – 中心となる開発機能を地理的に分散されたチームが囲む
  • ピア・ツー・ピア – 全てのアクティビティを対等な立場のチームで分担する
  • アドホック – 一貫した方針は無く様々な手法を組み合わせる

調査では、分散開発の課題はアドホックな手法をとると大きくなることが明らかになったが、しかし、課題の順番は手法を問わず同様であった。手法全体で報告された課題の上位5つは次のものである

  1. 全般的なコミュニケーションやコラボレーションの課題
  2. ロケーション間でのスキルレベルの違いによるソフトウェアの品質の問題
  3. 組織を構築する方法に関する政治的な課題
  4. プロセス/プラクティスの違いによる品質に関する懸念
  5. 分散開発の複雑さに起因するプロジェクト管理の問題

分散開発の背後にある一番の動機は、コストに照らしたリソースの柔軟性と戦略上の価値からきたものである。これは、コストだけに焦点を合わせることは役に立たないという意見に至るかもしれないが、それは安価なリモートのリソースが不十分な経験やスキルに結びつくかもしれないからである。

もう一つの興味深い意見は、どれが分散可能であるかというアクティビティに関する結果である。回答者たちの中でハブ・アンド・スポークの手法をとっている人たちは、仕様の定義や分析、設計のような、何らかの重大なアクティビティよりも、コーディングやテストのアクティビティを分散することを好んでいる。ピア・ツー・ピアの手法をとっている人たちは、これらの重大なアクティビティを分散することを、比較的に渋ってはいなかった。

同じような分析の中で(リンク)、Scott Ambler氏(リンク)はDr. Dobb'sが行った2008年のアジャイル採用に関する調査(参考記事)の結果をまとめたが、その中では、プロジェクトの成功率が地理的な距離に反比例することが明らかにされた。以下はアジャイルチームの成功率である。

  • 一緒にいたチーム – 83%
  • 近くにいたチーム – 72%
  • 遠く離れていたチーム – 60%

Scott氏の意見では、コミュニケーションとスキルの発展を助ける分散開発成功への鍵(リンク)は、次のものである。

  • プロジェクトの開始時に全てのチームが集まる。
  • 比較可能なスキルを確立するため、いくつかの最初のモデリングを前もって行う。
  • ハイレベルな計画を立て、主要な依存関係とマイルストンの日付を確認する。
  • アーキテクチャを中心としてチーム構造を組織化し、いくつかのサブチーム間で必要となるコミュニケーションを減らすようにする。
  • チームが同じ場所で作業する場合よりも優れたツールを使う。なぜなら離れたところでは、インデックスカードやコルクボードやホワイトボードはうまくいかないからである。
  • 使節の役割をする人や境界をまたぐ人を作ること。

他に、Martin Fowler氏(リンク)のOffshore Development(リンク)(オフショア開発)や、Jeff Sutherland氏(リンク)が分散開発成功のための優れたプラクティスについて話したReaching Hyper-Productivity with Outsourced Development Teams(リンク)(アウトソースされた開発チーム群で高い生産性に到達する)などのサクセスストーリーがある。

分散開発は自らの課題を抱えているが、今日の世界における現実である。鍵は、効果的なツールを使用することと、より優れたコラボレーションのプラクティスにあり、それらはコミュニケーションの促進や地理的な配置を超えたスキルの構築を支援するだろう。

 

原文はこちらです:http://www.infoq.com/news/2008/12/distributed-development-quality

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。