InfoQ

News

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

作者 Vikas Hazrati , 翻訳者 沼田 暁子 投稿日 2009年1月5日 午後12時45分

コミュニティ
Agile
トピック
Agile in the Enterprise
タグ
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

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
slashdot+
Hatena

特集コンテンツ一覧

Flex 4の新機能トップ10

今週(2009年6月1日)AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumbo(オクラ)というコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。

Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。

JavaプログラマがFlexとBlazeDSを学んだ方がいい13の理由

この記事ではJavaプログラマがなぜFlexとBlazeDSを学ぶべきなのかについて13の理由を述べています。なぜ高度にインタラクティブなWeb サイトからJavaで開発されたバックエンドをもつエンタープライズ・アプリケーションまでを含む、リッチ・インターネット・アプリケーション(RIA)の開発にFlexとBlazeDSの組み合わせが最適な選択肢となるのかについて述べています。

仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?

Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。

Perf4Jを使ったパフォーマンス解析とモニタリング

この記事ではAlex Devine氏が、Java開発者がPerf4Jをどのように利用できるかと、タイミングステートメントにコードを追加し、ロギング、結果の解析とモニタリングを行うオープンソースツールセットの説明をします。

複雑な外部DSLを開発する

本稿では、Vaughn Vernon氏が内部DSLと外部DSLの違いを説明し、複雑な外部DSLを開発する際のステップを示します。

J2EEアプリケーションにおけるAOPを使ったフェッチ戦略の実装

この記事では低レベルのサービス・レイヤやリポジトリ・レイヤを肥大化させることなく、フェッチング・ストラテジによってモジュール化された方法でバックエンドにあるシステムからデータを取得する処理を最適化する方法について説明します。

実証済みのアイデアの融合: S#arp Architectureの裏側

この記事では、Web開発における多数の成熟傾向と、クライアントに価値を提供することに対するそれらのメリット、およびS#arp Architecture(最善の手法と技術を活用しようとするASP.NET MVCをベースとしたフレームワーク)内でのそれらの使用について取り上げます。