データアクセス層のボガーティング
状況：dbaは、DALコード全体をTFSでチェックアウトし続けるオフサイトの請負業者です。フロントエンド開発者として、この人物が電子メールに応答して作業を行うのを待つことなく、列を追加したり、プロシージャなどを微調整したりできると便利です。
質問：データの整合性とチーム間の平和への愛と幸福を維持しながら、より迅速で機敏な開発を可能にする推奨されるソリューション/プロセスは何でしょうか？
MartinFowlerとPramodSadalageは、このテーマについて 優れた記事 を書いています。
すべての開発者は、変更を加えることができる独自のデータベースを持っています。これらの変更は、マスターデータベースに実装するDBAに（チェンジセットとして）返送されるため、彼はまだプロセスに関与しています。彼はおそらく、データベースの構造とニーズについて最もよく知っています。プロセスに関与するすべての人にとって満足のいくものであり、非常に機敏であるため、これが最善のアプローチだと思います。
同様の方法でDALを変更できます。変更を加えて、完了したと思ったらDBAに変更セットを提供するだけで、DBAはそれを確認して、マスターにマージできます。
ウェルル、私がDBAのことをしているとき、私はすべてをロックして、ひどい汚いプログラマーがそれにミットを付けられないようにすることで知られています。誰もがそれをより良くする方法を知っていると思います、そして彼らは彼ら自身のためにそれらをより簡単にするために物事を「微調整」します、そしてそれは不潔な混乱を引き起こします。
もう1つの方法は、それを大きく開いて、プログラマーにしばらく近接させてから、ジャンプして、物事が終わりに近づき始めたら順序を課すことです...これは確かにより「アジャイル」ですが、何を切り取ったり変更したりする必要があるかによって、実際の悪夢が発生します... DBAはプロジェクト全体をよりよく理解していることが多く、無害に見える変更によっては問題が発生する可能性があります。
彼が唯一のゲートキーパーになる場合は、仕様を固定するか、ビジョンを残りの開発者に「販売」できる必要があります。
他の問題に優先する大きな問題があります。
- 請負業者が常にコードをチェックアウトしているのはなぜですか？
なぜ彼はこれをすることが許されているのですか？積極的に編集していない限り、ファイルをチェックアウトしてはいけません。チェックアウトに関するチームポリシーが必要です。
請負業者は（好むと好まざるとにかかわらず）チームの一員として働き、チームの他のメンバーが変更を加える必要がある場合があります。これは通信の問題です。残念ながら、この通信の問題を自動化して修正する方法はありません。
水平レイヤーではなく、レイヤーをまたがるサイロで作業することを好みます。
そうすれば、1人/チームがこの方法でブロックすることはできません。
また、開発者はマルチスキルであり、機能をはるかに簡単に移動できることも意味します。
もちろん、より専門的な作業が必要なセクション（UIデザインとDBデザイン）もありますが、あなたはその考えを理解しています。
シンプル、まだ行っていない場合は、3つの環境が必要です。
- 開発環境
- QA環境
- 本番環境
開発環境は、開発者が管理する必要があります。
RC環境を追加することもできます。
別の答えは、複数の環境が不可能な場合は、モックされたリポジトリに対して開発することができます...この方法でモデルを構築し、請負業者がモデルをDBに一致させる責任があります。ある意味で、これは開発者がデータベースについて心配する必要がないため、より優れています。
あなたの問題は私には人的資源の1つであるように思われます。すべての潜在的なdaatbaseの変更がデータベースの専門家によって承認されることは適切であり、必要です。現在の人がタイムリーに仕事に追いつくことができない場合は、より多くのデータベーススペシャリストが必要です。
これは技術的な問題と同じくらい管理上の問題です。
DBAには（オンサイトかオフか、請負業者か従業員かに関係なく）開発者がデータベースを変更しないようにする正当な理由が確かにあります。
ただし、定義した主な問題は可用性の1つです。あなたのマネージャーは、この人を待つのに時間/お金が無駄になっていることを知っていますか？そうでない場合は、みんながどのように座っているかを取り上げたいと思うかもしれません。