タグ付けされた質問 「distributed-development」

私は、すべてのソフトウェア設計がローカルチームによって行われ、これらの設計がコーディングのためにオフショアチームに送られるプロジェクトに関与します。 この特徴を持つプロジェクトに直面するのはこれが初めてであり、私にとってはちょっと奇妙に感じます。マネージャーは、私たちが非常に詳細な設計文書を作成することを期待しています。私の観点からは、IDEで行うことはできますが、彼らは紙でコーディングすることになります。 だから、私の質問はこのアプローチが良いですか、それとも正しいですか？ソフトウェアプロセスがプロジェクトで成功するために必要な主な考慮事項は何ですか？

28 design  development-methodologies  distributed-development  offshore 

クライアント用のCRMを構築しています。最初の主要なフェーズが終了し、2番目のフェーズが合意されたので、クライアントは作業の一部をピックアップし、2番目のフェーズを構築する間にデータベーススキーマとビジネスプロセスを若干修正します。 これが実用的かどうかは定かではありませんが、そうであると仮定すると、これを実行可能にするための対策を講じることができる指針が欲しいのです。ここに私がこれまでに得たものがあります： これまで、クライアントは主にユーザーの視点からプロジェクトを見てきました。明らかに、2部構成のセミナーを開催し、内部の仕組みを紹介します。 最初に、既存のデータベーススキーマを表示し、例としてそれを拡張します。 次に、サンプルコードをいくつか表示し、スキーマ拡張のための新しいビジネスプロセスを記述します。 コードは現在、内部Subversionリポジトリにあります。私たちは彼のネットワーク（VPNに接続できる）にパブリックなものをセットアップできましたが、分散システムの方がうまくいくと思います。しかし、そのように感じるのは私だけだと思われるので、説得力のあるいくつかの議論を使用できます。 本番環境で実行されるコードがコミットされることを義務付け/保証する方法がわかりません。「xは休暇に入る直前に重大な、文書化されていない変更を加えたようだ。今ではyはそれ以来ずっと発生しているこのバグを見つけようとしている」災害は避けられない。理想的には、すべての変更は、展開前に次のことを行います。 問題追跡システムに文書化される、 最初に別のテスト環境で発生し、 自動テストに合格する必要があります。 悲しいかな、私はそれらのいずれかの規律が勝つことを疑います。 1）前者は存在せず、2）後者はクライアントが既存のコードを見て、場合によっては変更することを禁止するため、プラグインアーキテクチャまたは個別のプロジェクトは実行可能なオプションではないと想定します。主張する。

12 version-control  distributed-development 

すべてのチームメンバーに共通の言語が1つもないチームがあります。チームは2つの場所に分かれています（ただし、地理的な問題は主要な問題ではありません）。各場所のすべてのチームメンバーは同じ言語を話し、両方の場所で両方を話すことができるメンバーがいます。スクラムを紹介したいのですが、言語の問題に対処するためのロジスティックスに苦労しています。 これはオフショアチームではありません。すべてのチームメンバーは会社の従業員ですが、異なる国の2つの異なるオフィスにいます。幸いなことに、タイムゾーンに関する問題はありません。言語が第一の障壁です。各場所の人々の規模とスキルセット、およびその他の外部要因を考慮して、チームを2つのチームに分割することもできますが、単一のチームとして統合することがより望ましいです。 コミュニケーションを豊かにし、チームが団結してお互いを見て真のスタンドアップアプローチを行えるようにするには、ビデオ会議を使用することが望ましいと思います。しかし、これは言語間でのコミュニケーションが困難になると思います。チームのバイリンガルメンバーは口頭で翻訳する必要がありますか？代わりに、分散スクラムの言語の問題に関する唯一のリファレンスで推奨されているインスタントメッセージを使用することもできます。私は「貧しい」コミュニケーションを心配しており、おそらくそれはスクラムの概念への不十分な紹介です。 チーム内で言語の違いに対処した経験のある人から、問題にどのように対処し、どの程度うまく機能しましたか？

11 agile  scrum  team  spoken-languages  distributed-development 

C＃の分散システム用のカスタム再帰オブジェクトロックメカニズム\パターンを考え出す必要があります。基本的に、私はマルチノードシステムを使用しています。各ノードは、n個の状態に対して排他的な書き込み権限を持っています。同じ状態が、少なくとも1つの他のノードで読み取り専用形式でも利用できます。一部の書き込み/更新はすべてのノードでアトミックである必要がありますが、他の更新はバックグラウンドのレプリケーションプロセスやキューなどを通じて最終的に整合性が取れます... アトミック更新では、オブジェクトを書き込み用にロックされているものとして効率的にマークして、配布、コミット、ロールバックなどを実行できるパターンまたはサンプルを探しています。システムには高レベルの同時実行性があるため、ロックが解除されるとタイムアウトになるか、アンロールされるロックをスタックできるようにする必要があると思います。 トランザクションまたはメッセージングの部分はこの質問の焦点では​​ありませんが、いくつかの追加のコンテキストのためにそれらを提供しました。とはいえ、必要に応じてどのようなメッセージが必要だと思うかを自由に説明してください。 これは、私が想像していたものの漠然としたサンプルですが、まったく新しい製品を実装することを除いて、新しいアイデアを受け入れることができます。 thing.AquireLock(LockLevel.Write); //Do work thing.ReleaseLock(); 次のような拡張メソッドの使用を考えていました public static void AquireLock(this IThing instance, TupleLockLevel lockLevel) { //TODO: Add aquisition wait, retry, recursion count, timeout support, etc... //TODO: Disallow read lock requests if the 'thing' is already write locked //TODO: Throw exception when aquisition fails instance.Lock = lockLevel; } …

10 c#  multithreading  concurrency  distributed-development 

私の会社では、PerforceからDVCSへの移行を模索しています。現在、ソフトウェア開発チームはドイツ、中国、米国、メキシコに分散しており、ある場所から別の場所への帯域幅がそれほど大きくない場合があるため、現在、多くのPerforceプロキシを使用しています。 ITと話して、地理的に分散された観点から物事をスムーズに実行する方法を探し始めました。これにより、どのリポジトリサーバーが真のソースであるかを決定せずに（つまり、透過的に複製することなく）すべての人が最新かつ最高の状態を得ることができます。 おそらくpre-pushおよびpre-pullフックを介してDNSメカニズムをエミュレートできると思いました。たとえば、国A、B、Cについて考えてみます。祝福されたAからプルすると、A自体がBからの変更をプルし、次にBからCへの変更をプルします。BとCに新しい変更がある場合、Aに落ちます。逆に、プッシュがある場合、それはすべての祝福されたリポジトリに伝播される可能性があります。 私がいることを承知している、一般的に一つだけ恵まれレポを持っているが、これは世界的に拡大しないことがあり、それぞれの祝福されたリポジトリがただ一つの国からのチームに適用可能です。 私の質問は、DVCSレポレプリケーションの概念は実際に使用されているものですか？それを成功させた人はいますか？その場合、正しい方法は何ですか？

9 dvcs  distributed-development  data-replication