BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 散らかった製品チームを構造化する

散らかった製品チームを構造化する

原文(投稿日:2009/5/7)へのリンク

多くのコンサルタントや管理者と同じく、アジャイルコンサルタントCory Foy氏は、買収やちょっとした怪物への進化によって成長した既存の組織に取り組んでいる。チームは以下のようだった。

元からの開発者だった一人がトップのVPとなるチーム構成です。その後、品質保証(QA)、開発者、ビジネスアナリスト(BA)とサポートができます。基本的にサポートは独立した構成要素です。私たちは彼らと密接に働いて、彼らからのインプットを得ます。でも彼らは自立しています。

私たちには米国に18人、そして(同じタイムゾーン内の)オフショアチームに別の30人がいます。米国チームは、2人のBA(まもなく4人に増えます)、3人のQA、残りは開発者です。オフショアチームには、およそ20人の開発者と10人のQAがいます - 彼らの役割はもっと流動的ですが。2人の米国を拠点とする契約開発者もいます。

このままでは、主に時間不足のために、チームは自身のプロジェクトの外でほとんど作業をできなかった。さらに、リリースサイクルはとてもウォータフォール的であり12~18ヶ月だった。良い面としては、QAと開発者はすでに一緒に良く働いており、“壁を越えるまで何も投げ出さない精神”があった。彼は、中間管理職に – 製品開発の一部では使われない – いくつかの挑戦があったことにも言及した。

Innovel社でパートナー管理をしているRobin Dymond氏は、(Larman氏とVodde氏共著の)“Scaling Lean & Agile Development(原文はScaling Agile and Lean Development)”を、中でも特に機能チームとプロダクトオーナへの提案を彼らに薦めた。彼はリリースサイクルを最大の明らかな問題とも見なした。

リリースサイクルを短くするための課題は、製品を翻訳しなければならない言語の数であるとCory氏は説明した。フランス語、スペイン語、ドイツ語だけでなくロシア語、ヘブライ語、その他の言語にも翻訳する必要がある。

Mayford Technologies社でアジャイルコンサルタントをしているDave Rooney氏は、3ヶ月ごとの内部リリースとビジネス要求の頻度でのパブリックリリースを推奨した。

Hillel Glazer氏は、Cory氏が上級管理者によって迎え入れられたことと、リスクと留まっている障害の現在の状況のハイライトを彼が報告できることが、ここでの潜在的な管理上の問題であることを取り上げた。Hillel氏は、これらの注意をできる限り非個人的にすることの重要性を強調した。“中間管理職を"非難"するな。君は"優先度の衝突"や"一貫性のない情報"やそのような何かを追求することができたかもしれない。”

現在のリリースサイクルが終了した後の8月に、組織はこれらの変更のいくつかを実行に移し始めるだろうとCory氏は言っている。

この記事に星をつける

おすすめ度
スタイル

BT