クライアントが進行中の開発でソースコードに変更を追加することを受け入れる必要がありますか？
私は現在、クライアントが自分でソースコードを変更した状況にあり（私はテクニカルリードです）、変更を受け入れてそのバージョンで作業を続けるように指示されます。技術的には彼がコードを所有していますが、彼は変更を行うことを決定し、私にそれを知らせませんでした。
彼の変更は、どの慣例にも従わず、実際にはレポート要件があるため、データ構造に変更を加えました。
上司はそれを受け入れて対処するように私に言った。私がクライアントに維持するために多大な労力を費やしてきたもの、つまりコードの品質を台無しにしてしまうのであれば、なぜ標準をチームに課す必要があるのかと尋ねて、彼に返信しました。
クライアントは、変更を元に戻すことを受け入れることを認識しましたが、この変更でデータがすでに作成されており、変更を元に戻すと、変更が失われます。
詳細に関係なく、私の質問は残っています。クライアントがソースコードを変更したという事実を受け入れ、それを続行する必要があるか、またはチームの基準に忠実であり続けて続行を拒否する必要があるか。
編集：問題について調査しましたが、ソースコードの所有権に関するトピックしか見つかりませんでした。
編集：コードをリファクタリングして改善するようクライアントに提案するべきだと示唆しているように、現状では、クライアントがデータベースとコードの両方でデータ構造に変更を加えたことを明確にする必要があります（動的リストタイプを変更）構造が固定列の1つになり、5つの固定アイテムが生成されます）。理由は、SQLから直接レポートを作成する必要があったからです。これが本番環境で公開され、約1500のレコードが作成された後で、このことを知りました。コードのクリーンアップを提案するずっと前に、そうすることは互換性がないために作成されたデータを失うことになるか、またはデータを新しい構造に移行する必要があることに気づきました。クライアントは、急いで脱出し、私たちへのリクエストをスキップするためにそれを行ったことを認めました。
どうしたの ？
これは非常に煩わしいことであることを理解しています。しかし、これはゲームのルールが明確に説明されていない場合に起こります。
契約事項によっては、顧客がコードに介入することを許可される場合と許可されない場合があります。たとえ顧客が干渉しなくても、上司は商業上の理由でそれを受け入れることがあります（たとえば、会社が非常に小さく、顧客が非常に大きいなど）。ですから、上司から言われたら、それに対処する必要があります。
それをどう扱うか？
このようなサプライズのプロジェクト管理キーワードは変更管理です。変更は自然であり、プロジェクトでは避けられません。古典的なプロジェクト管理であろうと アジャイル であろうと、抵抗せずに変化に対応してください。
しかし、あなた自身の費用ではなく、あなたの信頼性を犠牲にしてではありません。顧客が開始したこの変更は、開発チームの作業に影響を与えます。それを明確にする必要があります。
続行する一般的な方法は、予期しない変更を評価することです。
- あなたの仕事への影響は何ですか？
- それをリエンジニアリングし、リファクタリングし、開発標準に準拠させるには、どのようなワークロードが必要ですか？
- 設計が無効になっているため、ジョブの一部で追加の作業が必要ですか？またはデータベースを修正するには？そしておそらく追加のドキュメントのために？
通常、上記のすべてに必要な労力を推定します。また、スケジュールへの影響も見積もる必要があります（結局、間に合わなかったはずのストーリーを次のリリースにシフトする必要があるかもしれません）。
上司に影響評価を報告してください。彼が顧客に同意するまで：商業的/金融的な問題はあなたのビジネスではありません。しかし、少なくとも責任は明確であり、すべての関係者は何を期待すべきかを知っています。この変更は、要件の変更を受け入れるのと同じくらい専門的に処理してください。
損傷の封じ込めとプロセスの改善
また、それが将来再び発生するリスクを減らすように努めるべきです。
顧客が変更を撤回することに既に同意している場合、彼/彼女は問題を理解しており、再度それを実行したくはないでしょう。ただし、トピックについては明確に伝え、顧客に他のチームがある場合は通知するよう依頼してください。
もう1つの方法は、配信と展開のプロセスを強化することです。あなたがそれを持っていない場合は設定するのがより困難ですが、間違いなく投資する価値があるもの：
- 権限のないユーザーが必要に応じてコードを変更するのを防ぐために、少なくとも適切なソースコード管理と適切なワークフローを使用してください。 （これは、一般的なITセキュリティを改善するための良い動きになるでしょう-インサイダーによる悪意のあるソフトウェアの変更は本当の脅威です）。
- ビルドおよびテストプロセスを自動化するには、 [〜＃〜] ci [〜＃〜] を使用します。
- [〜＃〜] cd [〜＃〜] を使用して、不要な干渉なしに展開を自動化する
永続的なデータベースを維持するアプリケーションは、随時アップグレードする必要があります。
データのバージョン管理（別名 スキーマの移行 ）は非常に重要であり、y'allには何らかの本当の戦略が必要です。
後者は開発の内部であり、前者はより直接的に顧客に行くため、スキーマ移行の戦略を持つことは、間違いなく統一コーディング標準の実施よりもはるかに重要です。誤った結果や顧客データの損失などの経験。
スキーマ移行の戦略には、次のものがあります。
- ワイルドにリリースされたすべてのスキーマバージョンを追跡します（つまり、クライアントによって使用されている可能性があります）。
- スキーマのバージョン番号付け。野生で見つかったデータベースを直接認識できます。
- スキーマ定義は、バージョン管理されたソース管理下で維持する必要があります
- 違いを特定するためのツールによってそれらを比較できるようにするため
- 高度なケースでは、移行スクリプトを自動生成します。
- インストールとアップグレードは、移行スクリプトを統合する必要があります。アップグレードが必要になる可能性のあるすべてのスキーマについて
- アップグレードでは、アプローチの自動化と包括的な方法に応じて、スキーマの移行中に追加のダウンタイムが発生する場合があります。
- インストールされているアプリケーションは、（バージョン番号をチェックすることによって）処理できないスキーマに対して誰かが実行しようとした場合、失敗するはずです。
これらの考えは、唯一のクライアントが製品を所有している場合よりも、製品を所有していて複数の消費者がいる場合に関係しているため、上記の一部のみが該当する場合があります。それでも、スキーマのバージョン管理に関するいくつかの規律が整っています。クライアントが複数の個別のインストール（実験的、運用中、その他？）を単独で持っている可能性があります。