ソフトウェア開発プロジェクトで技術的負債を積極的に管理していますか? もしそうなら、どのように管理していますか?
10 に答える
技術的負債を管理する 1 つの側面は、リファクタリングとバグ修正に時間を割く必要があることを非技術系のマネージャーに納得させることです。
私たちのチームでは、技術的負債を積極的に管理しています。私たちはスクラムを行っているため、見積もりと残りのスプリント キャパシティに応じて、現在のイテレーションまたは次のイテレーションの技術的負債カードを作成し、機能やバグ カードと同様に優先順位を付けます。また、スプリント計画中に各スクラム チームに優先順位を付けて注入する技術的負債のチーム間バックログを用意することで、より大きなチーム間の負債項目を管理します。
古い罪を埋め合わせようとするなら、技術的負債を処理する時間をスケジュールすることが重要だと思いますが、これを習慣にするべきではないと思います。混乱を一掃したら、正当な理由がない限り、プロジェクトに借金を負わせることは避けてください。
マイクが提案するように積極的に管理することは最も合理的なアプローチのように思えますが、長期的には時間のスケジュールやリファクタリングの計画を立てるべきではないことを(チームに)明確にすることが非常に重要だと思います。
リファクタリングはコード作成の自然な部分である必要があるため、他の見積もりや計画に含める必要があります。「歴史的な」理由で、または意識的に何かを実装することを決定した場合を除いて、個別のアクティビティとして扱われるべきではありません。与えられた方法で、後でそれを再実装します。
あなたがしていることは、極端な場合を除いて技術的負債が受け入れられない文化を作り出すことです. 現金のみを支払い、絶対的な最後の手段としてクレジットを使用する人々と同じように.
何かを今すぐリリースする必要があるために本当に技術的負債を積み上げる必要がある場合は、それに関する重大なバグを報告して、最も優先度の高いものにします。ただし、これは極端な状況 (クライアントが飛び跳ねている、妻が絵文字を探しているなど) に限られます。
私はアンダースに同意します。技術的負債を管理するためのシステムをセットアップする必要がある場合、それはまだ追加していることを意味します。「完了」の定義をアップグレードすることで、そもそも借金をするのをやめましょう。
これは、「お世話になっている」モジュールを処理するのが難しくなることを意味します。開発者はこれを認識し、より多くのストーリー ポイントを割り当てて、物事を「完了」したままにしておく必要があります。
リリース サイクルに遅れている場合は、コード ベースをあまり変更したくありません。これは、常に何らかの技術的負債が存在することを意味します。私は通常、最適ではない変更に対して FIXME:s を作成し、次のリリースの機能の実装を開始する前にそれらを処理します。
私がこれまで関わってきたプロジェクトでは、プロジェクトの新しいフェーズの開始時、つまり「大きなリリース」またはマイルストーンの後にのみ、一部の技術的負債が「支払われ」(管理され)ました。
技術的負債の非常に重要な側面は、開発者だけでなく管理も関与するということです。その意味で、これに対処する最善の方法は、技術的負債の影響を理解したら、技術的負債を管理するために時間とリソースを割り当てる可能性のある「技術的でないプロジェクトの利害関係者」に見えるようにすることだと認識しています。
この記事では、健全な技術的負債のいくつかのタイプと、特に技術的負債の負荷を管理および追跡する方法について説明します。
Java Posse は最近、技術的負債の管理について取り上げましたが、これは非常に包括的です。
製品によって大きく異なります。コードが外部監査されなければならない分野で働いていたとき、それは私たちのスプリントの計画的な部分でした. PM は、リファクタリングが必要な領域を開発者に尋ねただけで、それが計画に組み込まれました。作業している領域のコードを修正しないと言っているわけではありませんが、機能するコードの壊れたチャンクを書き直すことに 1 日を費やすことはありません。現在、私はスクラムで作業しており、開発者は作業中にスクラムを実行しています。私の印象では、どちらの方法でも、リファクタリング作業に費やされる時間はほぼ同じです。