-1

以下の理由により、製品開発に携わるオフショア分散環境で働く従来の大規模なソフトウェア製品組織が、スクラムでのアジャイルの精神に従うことは容易ではありません。

  1. 彼らの製品開発は反復的ではありません。製品エンジニアリング チームは、反復的なシステム エンジニアリングを数回繰り返した後、特定のリリースの製品要件、製品アーキテクチャ、および設計を事前かつ正式に最終決定します。これに対する変更は発生する可能性がありますが、大規模ではありません。

  2. 製品エンジニアリング チームは、作成された仕様に基づいてオフショア チームがこの製品を構築するようになりました。これらの大規模なオフショア チームは、ここでは保証されていないため、反復的で経験的なモードで作業することはできません。

  3. ただし、製品マネージャーは、オフショア チームによる製品開発を定期的に確認するために、短いイテレーションで段階的な納品を要求する場合があります。

  4. これらのオフショア チームが、定義された正式なプロセス (経験的ではない)、管理者が管理する環境 (権限が与えられていない)、漸進的な開発アプローチ (反復的で適応的ではない) を使用してスクラムの変形に従うことができれば、彼らにとって非常に役立つでしょう。

  5. この状況で実装された真のスクラム アプローチは、非常に偽善的に見えるかもしれません。ただし、従来のウォーターフォールのようなシナリオ向けのスクラムの正式な変形を彼らに提供できれば、彼らはそれを全員の利益のために使用する可能性があります。

このコンテキストについては、 scrumtales.blogspot.comのブログで詳しく説明しようとしました。

これはできますか？

4

4 に答える 4

1

従来のウォーターフォール型のシナリオ用のスクラムの正式なバリアント

これを「スクラムフォール」と呼びます。以下に、組織にもたらす可能性のある問題を解決するためのリンクをいくつか紹介します。

http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.asp x http://blogs.msdn.com/nickmalik/archive/2007/06/04/waterscrum-vs-scrummerfall. aspx

于 2009-06-02T05:46:56.110 に答える
1

短い答えは、間違いなくYESです。

スクラムは特定の儀式とプロセスからなる方法論ですが、それらの一般的な実装は、まさにそれ、つまり 1 つの実装です。各プロセスについて、一歩下がって、主に距離の問題を抱えていない、より高いレベルの抽象化で解決策を探します。例 - コロケーション。一般的な解釈は、ユーザー ストーリーを「完成させる」ために協力している全員を 1 つの具体的な部屋に入れることですが、必ずしもそれが唯一の種類の部屋というわけではありません。チャットルームは仕事をしますか? バーチャル リアリティ ルームの方が適していますか? VOIP ソリューションも同様に機能します。

毎月 1 回か 2 回の会議 (スプリント計画とふりかえり) をこのような仮想環境で行うことができ、通常の勤務時間外に時折働く人々に負担をかけることはありません。

タイムゾーンとインターネット帯域幅が克服できない場合は、おそらく頻繁なオンライン会議をオフラインにすることができます. 毎日の会議は wiki を使用して行うことができます。または電子メール。

プランニング ポーカー ( PlanningPoker.com ) などのセレモニー用のオンライン ツールは無数にあり、一部は商用、一部は無料です: VersionOne、AxoSoft OnTimeなどがあります。

スクラムの残りの部分は、おそらく物理的な距離に関係なく実行できます。ユーザー ストーリーの作成、見積もり、ストーリー ポイントには、場所に基づく制約はありません。

これが役に立てば幸いです、アサフ。

于 2009-06-01T18:42:29.833 に答える
1

あなたの質問で読んだ内容に基づいて、私の短い答えはノーです。

分散型のオフショア チームがインクリメンタル開発を積極的に採用しない限り、これはまったく役に立たないでしょう。インクリメンタル デリバリがなければ、このリモート チームの残りのスクラム プロセスを嘲笑しているプロダクト マネージャーは、スプリント レビューで進捗状況を確認することになり、チームは、スプリント レビューの一部として完了したこと以上のものを示すことができなくなります。彼らの滝のプロセス。つまり、最初の部分ではその設計が完了し、後でその実装作業が行われ、最後にそのシステムと統合テストが機能しています。確かに、プロダクト マネージャーは、チームが対応し、推進している他のコミットメントやマイルストーンを達成できるプロセスの時点で、元の計画の変更を要求することはできません。なんで？プロジェクトの後半まで機能を提供しないためです。

漸進的な開発が重要です。彼らがそれを受け取り、プロダクト マネージャーが時間枠付きのレビュー セッションを受け取るようになったら、コミットメントを行うマネージャーから離れて、チーム メンバーにフィードバックを受け取り、直接コミットメントを行わせることができます。

インクリメンタル開発を行ったら、オフショア チーム マネージャーをプロダクト オーナー プロキシとして使用するというアイデアも試してみてください。これにより、プロダクト マネージャーはプロジェクトのすべてのチームと依存関係について交渉し、それらをプロキシに伝えることができます。その後、プロキシは信頼できる方法でローカル チームと対話し、プロダクト マネージャーの目標と優先事項を表すことができます。これは、分散したチームが製品所有者に直接アクセスできない場合に発生する問題に対処するのにも役立ちます。ローカル プロキシを使用すると、チームが機能について持っている可能性のある質問に対処するのに役立ちます。地球の反対側にいる誰かが 1 日後に応答するのを待つ必要はありません。

于 2009-06-05T20:44:27.417 に答える
0

アジャイルなオフショア開発を行うにあたって、ThoughtWorks (Martin Fowler) の経験を参照してください。アジャイルをオフショア開発に適応させる (またはオフショア開発をアジャイルに適応させる) ことは確かに可能だと思いますが、それは大きな変化になる可能性があります。新しいアイデアを組織に導入するパターンについては、 Fearless Changeも参照してください。あなたが直面している最大の問題は、アジャイルの実装に関する技術的な問題ではなく、変化への抵抗だと思われます。

于 2009-06-01T13:39:03.893 に答える