「プロセス債務」は人々が一緒に働く用語ですか
ふりかえりの結果として、私たちはソフトウェアを開発するより悪い方法を発見していました。素晴らしいと思い、試してみました。 3か月かかったメジャーアップデートの開発中、私たちはそれにとどまりました。メンテナンスエンジニアとの回顧展の後、私たちのアイデアは彼らにとってうまくいかないことがわかりました（アイデアを試す前に彼らと話し合い、またそれは素晴らしいアイデアだと思いました）。私たちは、以前の状況に戻るほうがよいという合意に達しました。更新のためのチームは解体され、メンテナンスエンジニアはそうする時間がありません（プロジェクトマネージャーは時間を投資することに同意していますが）。
現在、マイナーリリースが必要になるたびにメンテナンスエンジニアが利息を支払う状況にあります。これは 技術的負債 と非常によく似ていますが、製品自体とは何の関係もありません。これはプロセス債務と呼ばれますか、それとも技術的債務という用語の下に置かれますか？そして、それに対処するための良い方法は何でしょうか？ （製品マネージャーに見えるようにするための他のまたは具体的なアイデアはありますか？）
PSアイデアは、4製品のVSSデータベースをSVNに移行することでした。データベースは共有ファイルに大きく依存しており、使用可能なSVN構造を解きほぐして注ぎ込むのは面倒です。非常に直感的ではありませんが、VSSに保存したほうがよいものもあるようです。
私は物事を正しく解釈したことを望みます、私はこれを技術的負債と呼びます。ソフトウェアは単なるソースコード以上のもので構成されています。ソースはおそらくSDLCの取り組みの10％未満で20％以下です（少なくとも商用レベルでは）。ソースコードを確実かつ簡単にビルドしてデプロイできず、問題が発生し、コストがかかる場合は、保守が難しく、バグが多く、速度が遅いソースコードと同じです。
あなたが何か違うことを試みたという事実は、あなたが残したものほど良くなかったという事実も、物事を変えません。選択されたテクノロジー（VSSとSVN）（技術的負債）のために、ソフトウェアは以前よりも保守性の低い状態になっています。
あなたが参照しているプロセス債務は間違いなく存在しますが、それはあなたにもはや必要とされていないことをさせるプロセスによるものです。たとえば、リリースごとに印刷されたテストブックの手動実行とマークアップを必要とするプロセスがあり、自動テストを実装した場合、それはプロセスの負債になります。これは、方法の変更により関連性がなくなったためです。完了しました。
プロセスの「借金」は存在できず、確かに発生することはありません。
チームAが「少ない」作業を行っているため、チームBが「多い」作業を行っているプロセスに「ギャップ」があります。
これは発生しません。それは単にワークロードのシフトです。
何かが発生している場合、1年後、チームBにはやるべきことの膨大なバックログがあります。待つ。それは技術的な仕事のバックログです。それが技術的負債です。
「プロセス債務」は、実行する必要のあるプロセスステップのバックログになります。チェックインチェックアウト？何かが変更されようとしている更新を電子メールで送信しますか？それはばかげています。また、アジャイルでもありません。
muda、 リーンソフトウェアエンジニアリングからの廃棄物 を説明しているようです。明らかに、あなたは可能な限り無駄を減らしたいです...
直接の質問に対する答えではありませんが、VSSの問題を解決するためのものです。
数年前にVSSDBをSVNに移行しましたが、共有ファイルはかなり少なくなりました。ひどいものでした。そこで、これらのファイルを特定し、すべてを「共通」ディレクトリに移動しました（ありがたいことに、任意のプロジェクト間で共有されるファイルはありませんでした。多くはありませんでした）。
プロジェクトから離れた共通フォルダーに配置されると、SVNの外部機能を使用してフェッチおよび更新でき、プロジェクトワークスペースを更新して、共有ファイルフォルダー内の共有ファイルを参照できます。その時点から、コードが大幅に改善され、無関係のプロジェクトに影響を与える1つのファイルが変更されたときの破損が大幅に減少しました。