技術的な債務管理の問題は、文化の問題または洞察の問題のどちらですか
免責事項：私はハイテク債務をゼロにすることを期待していません。この投稿では、技術的債務問題とは、生産性など、マイナスの影響を引き起こしている深刻さを指します。
最近、Issue Trackerから技術負債レポートを自動的に生成するツールを作成することを考えていました-導入率とクリーンアップ率の経時変化合計とは別に、プロジェクトチームとマネージャーごとに分類された数値も表示されるため、マネージャーは、課題追跡と詳細を掘り下げることなく、現在の技術負債レベルを簡単に把握できます（このようなツールはすでに存在している可能性があります。ホイールの再発明を避けるための研究）。
モチベーションに関して、テクノロジーの負債は何年もの間急上昇しています。開発者がプロジェクトの見積もりを増やして技術負債のクリーンアップを含めると、より多くの場合、それらの数字を見積もりから削除するよう求められるため、リファクタリング/クリーンアップ作業は通常、無期限に延期されます。定期的なレポートが技術債務管理問題の改善に役立つことを願っています。
しかし、2番目の考えでは、テクノロジーの負債レベルの可視性を高めることが優先順位を上げるのに本当に役立つのではないでしょうか。一般的に、技術債務は組織文化の問題ですか、それともツールや洞察力の欠如ですか？普遍的な答えはないと思いましたが、どちらがより一般的な原因なのでしょうか。 あなたの経験は何ですか？
---更新2/28
説明：特にチームメイトがプロジェクトの生産性の観点から痛みを報告した後は、ほとんどの経営陣は影響があることを理解するのに十分インテリジェントであると思います。私の直感は、彼らがどれほど深刻な問題であるかについての具体的な写真を持っていないということです。私の考えは、次の2つのステップで経営陣がより明確な状況を把握できるようにすることです。
- Techdebtsをログに記録し、その影響を追跡します。 （課題はありますが、この質問の範囲を超えています）
- 導入率とクリーンアップ率のレポートを作成します（影響が大きい/小さい場合はさらに分類される可能性があります）。
私の好奇心は、これらの取り組みが役立つのか、それとも単なる時間の浪費なのか一般的に言えば（私の組織内では特定されません）-したがって、質問あなたの経験は何ですかです。それが組織文化の問題である場合、おそらくこれらの努力はあまり役に立たないでしょう。
逸話的に
私はコンサルタントの開発者です。 「開発の問題を修正する」ために、私は何度か雇われました。開発プロセスの問題を認識している顧客もいれば、バグの原因（つまり、不適切なコーディング方法）を見ずに修正する必要のある一連のバグとしてそれを見る顧客もいます。
私の経験では、開発プロセスを修正するための支援を求めたある企業は、実際には開発プロセスを改善するための措置を講じることに興味を持っていました。他の会社では、彼らの関心は、彼らの側からのアクションが必要になるまで存在していました（たとえば、リファクタリングや改善を積極的にロールバックする開発者を叱責したり、CI/CDパイプラインをセットアップするために必要なツールへのアクセスを実際に私に与えたりします）。
私の経験に基づくと、悪い習慣は開発者の欠陥として始まります。意図的なものではなく、未経験または一般的なコーナーカットの態度の問題です。原因が何であれ、これらの開発者は、テスト、レビュー、リファクタリングなどのデューデリジェンスに時間をかけないため、迅速な結果を示します。
経営陣はこれらの迅速な結果に気づき、やがてこの効率を期待するようになります。彼らは悪い習慣（バグなど）からの影響を直接処理しませんが、開発時間の短縮から利益を得ます。
この時点で、フィードバックループになります。経営陣は予想される（迅速な）期限を通知します。開発者はそれを達成するために手抜きを強いられます。コードベースが劣化します。最初のクイックリリースは、不明確で不安定なバグ、リグレッション、および一般的な読みやすさの欠如のメンテナンスサイクルに変わります。対処するために、迅速な結果に対する継続的な需要に対応しながら、開発者はバグ修正で手を抜かざるを得ません。
このサイクルは継続しますが、コードベースの品質とパフォーマンスは低下します。また、開発者の優れた実践スキルは侵食され、「不必要に」時間がかかると見なされ始めます。一部の開発者が良い習慣に固執し、他の開発者はそうしない場合、管理者は、バグやバグの原因を観察することなく、提供する速さに基づいてそれらを判断します。
グッドプラクティスの開発者は非インセンティブであり、悪いプラクティスの開発者はインセンティブです。時間が経つにつれて、経営陣からの肯定的または否定的なフィードバックにより、悪い習慣の開発者は良い習慣の開発者よりも主導的な役割を果たすことになり、悪い習慣は土地の法則になります。
社外コンサルタントを主な従業員とする会社の経験から言えば、優良事例の開発者は単に去るか、権利を剥奪された不良事例の開発者になります。 （初期の）悪い慣行の開発者が固執しています。これは、優良事例開発者よりも年功序列を持つ不良事例開発者の不均衡を永続させます。
この時点で、悪い習慣は風土病の企業文化になっています。それはすべての側面（開発会社の場合は営業部門を含む）から補強されており、ポップアップが表示されるというグッドプラクティスの提案は、多くの場合、悪いプラクティスに対する人気の高いサポートと、より長い期限に対する経営者の不寛容と相まって、見過ごされがちです。
このデボルブは、少なくとも3つの異なる会社で見たものです。同じイベントと一般的な労働環境が3社すべてに浸透しました。
サルとはしご
「これが私たちのいつものやり方です」という態度として現れる有害な企業文化について話すときはいつでも、サルとはしごのたとえを思い出します。
写真4の頃にシャワーをオフにしていたとしましょう。サルは波及することなくそのはしごを登っていたかもしれませんが、彼らの「社風」が今の時代遅れの考えに基づいてそれを防ぐことができました（シャワーがあるため）アクティブではなくなりました）。
このたとえ話は、行われる良い習慣の侵食に正確に触れています。人気がありますが見当違い悪い習慣のサポートは、良い習慣を導入することでより良い方向への変更を試みる人を阻止します。
問題は、社会的なチェックとバランスではありません。他の企業でも同じ原則を使用して、良い習慣を維持し、悪い習慣の提案をつぶします。
問題は、blind再評価することができずに「物事はこのように行われる」ことの受け入れにあります。その段階に達したときの行動は、企業文化です。
あなたの質問に答える
一般的に、技術債務は組織文化の問題ですか、それともツールや洞察力の欠如ですか？
プロセスのどの段階にいるかによって異なります。最初は、洞察やツールの欠如です。しかし、結果だけを見て進行中の問題を見ていないため、誤って（おそらく無意識のうちに）悪い習慣を刺激する管理と組み合わせると、フィードバックループになり、時間の経過とともに企業文化に変わります。
通常はどちらでもありません。通常、それは主にコミュニケーションの問題です。
多くの人が気付いていないのは、技術的借金は会社にとって大きな問題ではないということです。
一方、興味はそうです。金利が非常に低いかゼロのローンに不必要な分割払いをするのは無責任です。
技術的負債の削減について話すとき、あなたが実際に求めているのは、その負債の分割払いです。経営陣はその負債の利息（つまり、コスト）を認識していないため、これは重要とは見なされていません。
あなたがすべきことは、技術的負債を減らすために必要な作業ではなく、この負債のために新機能を提供するために必要な追加の作業（またはバグの修正）を強調することです。
だから（いくつかの簡単な例をとるために）：
しないでください CI/CRパイプラインをセットアップする許可を求めます。 Doすべてのリリースで環境ごとに30分余分にかかることを指定します。 しないでください自動テストを要求します。 Do自動化された可能性のあるものに対して2日間の手動テストを使用することを指定します。 しないでくださいリファクタリングする時間を求めます。 Do不完全に構造化されたコードの検索に費やした時間を指定します。
このようにして、実際に管理者にとって重要な問題を提起します。また、経営陣が賢明であれば、問題を修正する価値があるかどうかを判断することもできます。 （来年サポートされない製品の技術負債を修正する理由）
このようなレポートは、既に課題追跡（Jira）で入手できました。導入とクリーンアップのグラフが手に負えなくなったとき、経営陣は実際にそれを修正するためにより多くのリソースを投入しました。可視性は間違いなく優先順位を変えると思います。
主な問題は、可視性はすべて、欠陥が記録されてから修正されるまでの時間についてです。これにより、記録バグの修正に多くの時間が費やされました。これにより、新しい機能を作成するために利用できる人が少なくなりました。開発者は緊張して急いでいるので、リファクタリングや自動テストなど、レポートに直接表示されないものをスキップしています。
私たちは今、借金の返済を早くするだけでなく、それをより早く生み出すという奇妙な状況にいます。それはあなたの文化の問題になります。非常に目に見えるバグを修正することを優先することは、最初から品質を構築する文化を持つこととは大きく異なります。後者は、muchを測定するのがより困難であり、より前の努力のように感じるため、栽培するのがより困難です。
SCRUMの正解は、チームが技術負債を所有しているということです。チームはスプリントバックログを作成します。したがって、チームは技術債務が削減される率を制御します。
実際には、これを実際に行って建物の外にエスコートすると、怒っているマネージャーが現れます:)
さらに真剣に、どの技術負債が本番環境で問題を引き起こしているか、どの技術負債が現在の機能の実装を遅くしているのかについて、POと良好なコミュニケーションをとることが重要です。これにより、POを疎外することなく、重要な技術負債の解決を推進し、成果物に対する1つの戦略を立てることができます。
開発者がプロジェクトの見積もりを増やして技術負債のクリーンアップを含めると、より多くの場合、見積もりからそれらの数値を削除するよう求められるため、リファクタリング/クリーンアップ作業は通常、無期限に延期されます
なぜこれが起こるのですか？
あなたの経営者に聞いてください。彼らがこの現象を認識していることを確認し、その正当化を得る。
技術的負債に取り組むことは、機能として「販売」される必要があります。あなたの経営陣は、負債/負債を解決することの価値を解決するために必要な努力にコスト/利益分析を適用できる必要があります。
言われたこと-
開発チームがコードを所有しています。 X機能を導入する前にリファクタリングする必要がある場合、チームは全体として、その手足をさらに遠ざけることがプロジェクトの将来を危うくすることを理解しているので、それを見積もりに含め、何が起こる必要があるかを伝えます。
彼らは機能を実装するために何が必要かをあなたに伝えることはできません-彼らはできません。それは彼らの仕事やスキルセットではなく、彼らはとにかく判断を下すのに十分な知識を持っていません、そして彼らはそれを知っています。 Xストーリーポイントを取ることを伝え、チームがその数値についてコンセンサスを持っている場合、彼らは法定でそれを受け入れます。
標準を持ち、それらの標準に固執し、独自の標準の重要性を信じます。これはあなたの仕事の一部です。なぜなら、あなたに機能を提供している人々はあなたのためにそれらの基準を設定する文脈を持っていないからです。
特定の機能（つまり、前述の標準に準拠しているかどうか）に対してどのリファクタリング作業を行う必要があるかについてチームの合意が得られない場合、それは内部で対処できる文化的な問題か、またはこのテクノロジーの負債は、実際にはあなたの視点から見た場合のように重要な領域で発生しているわけではありません-そして、あなたはチームとその会話を徹底的に追求して、それが実際にどれであるかを見つけ、それを理解しようとする必要がありますそれはおそらく両方の少なくとも少しです。
[〜＃〜] xp [〜＃〜] 数十年前にこの問題を非常に簡単な方法で解決しました。
顧客、または製品の所有者、またはあなたが彼らと呼んでも構わないものは、ストーリーの所要時間を宣言することはできません。ストーリーは、希望する順序でのみ配置でき、特定の見積もりが気に入らない場合は、開発者と交渉してストーリーをより安く変更するように交渉します。
開発チーム（ストーリーの優先順位を変更できない、ever）は、適切なレベルの技術的負債を維持し、ビジネス目的でいつ増やすことができるかを決定する責任があります。そして、どのようなスケジュールの下でそれが返済されなければならない、など。特定の時点でこれを処理するために必要な時間と労力は、顧客には決して示されず、ストーリーの現在の見積もりに組み込まれるだけです。
特に、お客様は決して技術的負債などのリファクタリングまたは削減についてのストーリーを持っているため、お客様はストーリーのスケジュールを完全に制御できます。 「それは絶対にしてはいけない」と言う能力を含みます。技術的負債について決定を下すように顧客に伝えている場合、プロジェクトが予測可能な速度で前進できるようにするために、開発者としての責任を放棄していることになります。 （顧客は、コードベースの技術的負債の将来の影響を理解するのと同じくらい、またはそれ以上に良いと真剣に考えていますか？）
したがって、プロジェクトの管理を技術的な管理（ストーリーの優先順位を設定できない「開発者チーム」）と製品の管理（XP lingo）の製品の所有者または「顧客」）に分割して、技術的なことはできない技術的負債をどれだけ確保すべきか、または現時点で既存の技術的負債を返済するためにどれだけの時間と労力を費やすべきかなどの決定を含む決定。
文化的またはその他の理由で、これらの両方について誰かが決定を下す必要がある場合は、少なくともこれらの2つの役割を区別し、それらを独立させてください。つまり、「開発者の帽子」または「製品所有者の帽子」を着用します、」しかし同時に両方になることはありません。 （これは、自分の会社を経営しているときはうまくいきました。）
私は、問題追跡ツールで技術的な負債を追跡し、適切にタグ付けする傾向があります。 Jiraインスタンスでは、これは多くの場合、問題の種類を意味します。 Githubでは、ラベル。他のツールには他の方法があります。ただし、そのためには、まず技術的な負債を認識する必要があります。私はどのような報告も製品の技術的負債の状態の正確な画像を提供しないが、むしろ製品内の既知の技術的負債の状態を提供することを心配します。問題追跡で技術的負債を評価および追跡するように人々を奨励することは、組織にとってプロセスであり、おそらく文化的な変化です。
それは、組織が技術的負債をどのように見ているかに依存します。特定のモジュールまたはコンポーネントに取り組む前に、開発者は既知の技術的負債について課題追跡に問い合わせることができ、これは推定のガイドに役立ちます。テストカバレッジやタイトカップリングなどの既知の欠陥を知ることで、設計の意思決定が不十分であると見なされ、推定と計画のアクティビティをガイドするために必要な洞察が得られます。ただし、製品とプロジェクトの管理者は、いつでも締め切りとコミットされた日付でこれらの見積もりを押し戻すことができます。それはバランスをとる行為です。
文化の問題のようです
開発者がプロジェクトの見積もりを増やして技術負債のクリーンアップを含めると、より多くの場合、見積もりからそれらの数値を削除するように求められますなので、リファクタリング/クリーンアップ作業は通常、無期限に延期されます。
私にとって、これは文化の問題を悲鳴させます。経営陣は問題を認識しているようで（たぶん完全ではないかもしれませんが、少なくともある程度）、それを聞きたくありません。今のところ、コードの品質よりも何かが彼らにとってより重要です。管理はどのように奨励されますか？彼らにとって何が成功とみなされますか？安定した保守可能なコード？または派手な新機能、市場投入までの時間など？後者のようですね。どちらの場合も、品質が成功を定義する方法ではないため、コードの悪臭を言っても何の助けにもなりません。彼らにとって、それは悪臭を放ちません。したがって、最終的には、まず企業の開発文化を理解する必要があります。その前に、この問題にどのように取り組むかを判断できます。