BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース アジャイルとオフショア: トラブルを求めているのか?

アジャイルとオフショア: トラブルを求めているのか?

Kevin Coleman(リンク)氏が、先月のAgile Journalの記事で、「アジャイル」であると主張するオフショアチームと仕事をした話と、その経験からくる問題と心配について話した。何人かの読者は、自分自身の経験と照らし合わせて、彼の経験が正しいと言った。実際に、今日のビジネスの現実を考えて、アジャイル手法をオフショアチームでうまく使えるだろうか?

Kevin氏の主な仮説は以下の通りである。

大抵のオフショア開発組織は、彼らの方法論として伝統的なウォーターフォール型の開発を標準にしてきました。これらのさらに伝統的な手法は、大規模で古典的に組織化されたプロジェクトでしなければならないタスクを決めるものです。これらの伝統的な開発技術は、アジャイルの基本的な概念に反して実行されがちです。

これを心にとめて、Kevin氏はまさに共通の(そして費用のかかる)問題をまとめて紹介する。

.オフショア開発チームは、バックログの在庫リストを見て、要望、サイズ、複雑さ、そして、在庫の各コンポーネントに必要な労力を評価します。これらの見積もりと開発チームのサイズに基づき、オンショアとオフショアチームを決めて、それから、そのスプリントでどの機能を納品するかをよく検討します。何を納品するかが明確になって、それに同意すると、開発プロセスを開始します。これが問題の始まりになります....アジャイル手法が、デモをしたり、コンセプトを証明したりして、反復する発見のプロセスと呼ばれているものを通して進むにつれて、新しい要望が明らかになります。これによって非常にコストがかかるようになります。支払請求可能な時間は、コードを再び書き、新たに発見された要望を見積もり、スケジュールを変更することに費やされます。

そして、

しかし、それはだんだんと良くなります。多くのハイブリッド(アジャイル/伝統的)なプロジェクトは、タイムボックスマネジメントの技術を使って、それをアジャイルと呼びます。タイムボックスは、与えられたタスクやタスクのまとまりに費やす時間を決める技術です。タイムボックスが確立すると、開発スタッフは、そのタイムフレームに留まることができるように全力を尽くします。だから、典型的なウォーターフォール開発のように、完成するまで何かに取り組む代わりに、オフショアチームは、言ってみれば五日間だけ働きます。この五日間の後で、作業は完成しているか、後日取り組むバックログの在庫に置かれます。または、もともとそのスプリントンでスケジュールされている他の機能に置き換えます。こうする理由は、たった今、この機能の一部を実装するコストが変わり、オンショアチームに再評価される必要があるからです。

また、

他のハイブリッドの技術は、伝統的なレビューを機能的なデモンストレーションに置き換えることです。作業が進むにつれ、オンショアチーム、ビジネスユーザ/SME(中小企業)と主なステークホルダからのフィードバックを受けて、フィードバックを統合します。大幅にさらなる努力が要求される場合は、フィードバックの統合を延期して機能バックログの在庫に入れ、後のスプリントで扱うことにします。フィードバックを受けた機能が指定された時間に必要な場合、ご推察の通り、スプリントのタスクリストに追加し、作業を見積り、変更の命令を出します。そして、キャッシュレジスタが再び鳴るのです。

つまり、Kelvin氏の経験によると、アジャイルチームがアジャイルでないオフショアチームと仕事をする時、全てに費用がかかるのだ。根本的原因は、Kelvin氏の経験では、多くのオフショアチームが実際にはアジャイルではないことのようである。この記事にコメントを残すことを選んだ読者たちも、同様の経験を持つようである。

2つの方法論を1つにすることは危険であるというのはとてもよい指摘です。しかしながら、両方の会社が1つか2つのプロジェクトで一緒に働き、彼らの間である程度の信頼を確立するまで、私は、伝統的なウォーターフォールの組織がアジャイルプロジェクトをスムーズに完了するのを決して見たことがありません。通常、それぞれの会社がどのプラクティスをしっかりと保つかを決めて、そこからハイブリッド/共同のプロセスを独創的に構築しなければなりません。

また、次のような意見があります。

オフショア開発者によってアジャイル開発を使っている人たちに一言警告することがあります。開発者によって使われているのが、あなたのビジネスであり、お金であり、時間であることを、彼らが確実に理解するようにしなければなりません。開発者が仕事に立ち向かっている一方で、広範囲の計画が進んでいます。あなたが仲間に入っているのではなく、絶えずコミュニケーションしているのではない場合、トラブルに巻き込まれるでしょう。

そして、

私は、ちょうどいまこの問題を経験しています。一人でなくてよかった。古いことわざで、同病相哀れむとでもいうのでしょうか?

これは、InfoQの読者が見つけた同じ経験ではないだろうか?もしそうならば、この人がアジャイルオフショアについて読んだ記事の大部分は、肯定的なものであったということだ。これは、間違った情報の例だということだろうか?それとも、Kevin氏はただ不運な少数派なのだろうか?

 

原文はこちらです:http://www.infoq.com/news/2008/10/agile-offshore

この記事に星をつける

おすすめ度
スタイル

BT