技術的負債：誰もがそれを持っており、彼らの称号に値するすべての開発者はそれを完済したいと思っていますが、このプロセスをどのように整理しますか？

輪作を実施

私には 以前の記事、私は農業における輪作の重要性への技術的な債務返済を比較しました。大規模な収穫（プロジェクトの完了、機能の追加など）を得るために、フィールド（コードベース）をシーズンごとに処理し続け、このフィールドに回復するシーズン（技術的負債の支払い）を与えない場合は、徐々にその品質と生産性を失い始めます。



この比喩は、ソフトウェア開発に適しています。さらに、技術的負債を返済するために使用できる可能な戦略のヒントが含まれています。



借金を返済する方法は驚くほど広範囲に渡ります。そして、これは私たちに多くの計画オプションを提供するので非常に便利です。



この記事では、アジャイル開発の方法論で作業していることを前提としていますが、創造的に洗練されている場合、原則の多くは他の方法論にも当てはまります。

技術的負債を完済するための専用スプリント

輪作と完全に類似して、4スプリントごとに機能の作業を停止し、技術的負債を返済するためだけにそれを割り当てることができます。



長所：

• 開発者は、技術的負債の返済のみに集中するという共通の意欲を共有しています
• 開発者は、連携して作業することにより、技術的負債のより大きなチャンクを完済するように調整できます
• 企業は、仕事の重要性と残りの量を示す技術的負債の結果を研究するように動機付けられています。

マイナス：

• 従業員が大量のアーキテクチャ変更を行うと、マージの競合が発生し始めます。
• この混乱と不安定さにより、適切なテストカバレッジがない場合、何かが壊れているかどうかを判断するのが難しい場合があります。
• 技術的負債に取り組んでいるからといって、サポートインシデントがなくなることはありません。サポートリクエストのエスカレーションを支援するスタッフがいなければ、技術的負債はサポートによって妨げられることが保証されます。

技術的負債返済のための専用能力

このモデルでは、アジャイルチームは、継続的に技術的負債を支払うために、特定のポイント数または総スプリント容量のパーセンテージを予約します。たとえば、各スプリントで、チームはさまざまな債務返済の仕事の5つのストーリーポインを取ることができます。



長所：

• これにより、技術的負債の返済が組織の継続的な文化の一部となることが保証されます。
• 進行中の技術的負債の仕事は、将来のさらなる仕事の必要性を妨げるかもしれません。

マイナス：

• スプリントに変更を加える必要がある場合、技術的負債に取り組むことがスプリントから削除される可能性が最も高い候補になります。
• 技術的負債に関する作業を少量に制限することにより、技術的負債の大きな塊を排除することが難しくなります。

技術的負債の返済に従業員を捧げる

これは、最後の2つのオプションのハイブリッドです。各スプリントは、技術的負債に取り組む1人の開発者を選択し、他の全員は通常の作業を続けます。



長所：

• , , .
• , ,

:

• ,
• , , capacity

このモデルでは、開発者が作業を計画するときに、隣接するコードのクリーンアップと、すでに作業領域にある検出可能な技術的負債の支払いを計画に追加します。これはボーイスカウトの原則に沿ったもの です。駐車場（コードベース）は常に以前よりも清潔に保ってください。



言い換えれば、これは、コードに触れると、コードが改善されるはずであることを意味します。最も頻繁に触れられるコードでは、技術的負債の最も高い割合を支払う必要があるため、 作業中のコードの領域で負債を返済することは理にかなっています。



同様の概念は、マルコム・グラッドウェルの著書「ティッピングポイント」にも見られ ます。ニューヨークの地下鉄の例です。市交通局は、地下鉄の車を切り離し、落書きを取り除き、常に落書きがないようにすることで、車の状態が気にならないという人々が信じている壊れた窓の影響を節約できることを発見しました。 誰でも犯罪率が上がる可能性があります。ウサギと落書きの数を減らすことによって、機関はまた、地下鉄での暴力犯罪の数を減らすことができます。



同じ原則をコードベースに転送する場合は、コードの領域に触れたときにそれらがクリーンアップされ、技術的負債が支払われるようにする必要があります。



あなたはおそらくあなたが上で読んだことから私がこのアプローチのファンであると推測しました、しかしそれでもその賛否両論を考えましょう。



長所：

• 技術的負債は、開発者が自然に触れることが多い分野で報われます
• 技術的負債を支払うために「スペースを割り当てる」必要はもうありません。これはワークフローの一部にすぎません。
• 変更は孤立した領域でのみ行われるため、マージの競合は最小限に抑えられます。

マイナス：

• システム全体に影響を与える大きな変更を加える特別な機会はありません
• チケットごとに追加の作業を行う必要があるため、ストーリーポイントの「インフレ」が発生します。これにより、各スプリントで実行できる作業量が削減されます。

主要なコード改訂

上記では、テセウスの船での思考実験のように、システムの一部を徐々に交換して技術的負債を返済する戦略についてお話しました が、それだけでは不十分な場合はどうでしょうか。すべてのソフトウェアを1つずつ交換する時間がなく、より根本的な変更を加える必要がある場合はどうなりますか？



ここにあなたを助けるためのいくつかのアイデアがあります：

アプリケーションをより小さなアプリケーションに分割する

この方法論では、モノリシックアプリケーションをより小さなアプリケーションに分割します。多くの場合、このアプローチはドメイン駆動設計やマイクロサービスによって補完されますが、その主なポイントは、アプリケーションが大きすぎて置き換えることができない場合、アプリケーションを小さな部分に分割できることです。その置き換えは現実的であり、その後、それぞれを置き換えることができます。次々とパート。 MartinFowlerのStranglerApplicationパターン



を使用してこのスキームを実装することもできます。この パターンは、古いアプリケーションと同じリクエストを受信し、各システムの最新の交換の準備ができるまでレガシーシステムを呼び出す新しいアプリケーションを作成します。



長所：

:

• ,

capacity

このモデルでは、開発者はスラック時間または技術的負債に割り当てられた時間を使用して、アプリケーションの一部または全部の交換などの長期プロジェクトに取り組むことができます。十分な進展が見られ、本格的に作業を開始できるようになると、これらのタスクは、正式な実装と配信のためにスプリントまたはスプリントシリーズに実装され始めます。



このパターンに従って、 JavaScriptアプリケーションをTypeScriptに移植することに非常に成功しました。これには、仕事以外の時間を費やしたり（必ずしもそうする必要はありませんが、そうすることにしました）、回帰テスト環境がオンラインになるのを待つことも含まれます。



長所：

• 正式なQA /供給サイクルに結び付けられていない潜在的に欠陥のあるプロトタイプを特定して対処することができます
• 作品をスプリントに含める準備ができたら、それはすでに非常に集中した作品であり、未知の変数のほとんどが解決されます。

マイナス：

• 組織が他のプロジェクトへのリソース割り当てを減らしたい場合を除いて、スケジュール外のプロトタイピング時間を大幅に見つけるのは難しい場合があります。

新しいアプリケーションへの完全な移行

このモデルでは、重大なバグの修正を除いて、古いアプリケーションでのすべての作業が停止し、アプリケーションでの作業が開始されます。これが完全な代替となります。これは、アプリケーションの書き換えについて話すときに人々が通常意味することです。



長所：

• 従業員は、既存のシステムを実際に考慮することなく、新しいシステムに集中できます。
• 合計実行時間は短くなる可能性があります

マイナス：

• 納期が非常に短いため、ビジネスはプロジェクトにお金を浪費しているように感じるかもしれません。
• 締め切りの遅れは、必要な作業の提供を妨げる可能性があります
• 実際、このアプローチは全か無かの法則になります。
• 新しいプラットフォームプロジェクトに投資する前に、すべてのリスクを十分に考慮していない可能性があります

調査結果

アプリケーションを継続的に更新するためのこれらのオプションと、より根本的なオプションを検討してください。私の意見では、最善の選択肢は1つではありません 。チーム、製品、組織に最適な選択肢を探す必要があります。これらのアプローチを評価し、コードベースを長期にわたって健全に保つための「輪作」を準備するときに、どのオプションが最適かを判断します。