問題タブ [technical-debt]

ソフトウェア開発プロジェクトで技術的負債を積極的に管理していますか? もしそうなら、どのように管理していますか?

Martin Fowler による技術的負債、Steve McConnellによる

YAGNI (You Ain't Gonna Need It)ウィキペディアより

ウィキペディアによるBDUF (Big Design Up Front)

更新：質問を明確にするために、このように述べて、私の意味を維持することもできると思います：

「あなたは、アジャイルの実践者として、各イテレーション内で、「クイック アンド ダーティ」(YAGNI に準拠しようとして意図せずに技術的負債を負う危険を冒すこと) とオーバーエンジニアリング (BDUF) の間の適切なバランスをどのように見つけますか?

実務において、技術的負債を効果的に追跡および管理するにはどうすればよいですか?

SLOCなど、使用している特定の指標はありますか?

結果を利害関係者や経営陣にどのように視覚的に表示しますか?

その過程でどのようなメリットがありましたか?

技術的負債がプロジェクトに組み込まれる方法は (少なくとも) 2 つあります。1つ目は、意識的な決定によるものです。一部の問題は、事前に取り組む価値がないため、意識的に技術的負債として蓄積することが許可されています。2つ目は、無知によるものです。プロジェクトに取り組んでいる人々は、技術的負債を負っていることを知らないか、認識していません。この質問は2番目を扱います。プロジェクトに取り入れた技術的負債は、無視するのは些細なことですが (「知っていれば...」)、プロジェクトに組み込まれると、劇的にコストが高くなりますか?

私は ruby​​ on rails の大ファンで、web アプリケーション プログラミング手法の「最大のヒット」の多くが組み込まれているようです。特に構成よりも慣習は、私の心にとって大きな勝利です。

しかし、私が得ている便利さの一部は、将来的に返済する必要がある技術的負債を犠牲にしてもたらされていると感じています. 多くの場合、ROR には多くのベスト プラクティスと適切なデフォルト オプションが組み込まれていると思うので、ROR が迅速で汚いと思っているわけではありません。ただし、まだいくつかのことをカバーしていないように思えます (特に、フレームワーク内のセキュリティに対する直接的なサポートはほとんどなく、私が見たプラグインの品質はさまざまです)。

ここで宗教的な意見や論争を求めているわけではありませんが、Rails を改善する必要がある分野や、Rails のユーザーが自分で注意する必要があることについて、コミュニティの意見を知りたいと思っています。フレームワークは彼らの手を握って正しいことをするように導くことはありません.

最新のCodingHorrorブログエントリは、このコンセプトを聞いたのは初めてではありませんが、それを読んでいたので、自分のプロジェクトにそれを適用せざるを得ませんでした。

私が取り組んでいるコードベースは、現在約3年の時点で進行中のプロジェクトであり、プロジェクトの初期段階のコードの大部分は、ほとんど監視されていない開発者によって作成されたため、多くのコードの重複、パフォーマンスの低下など。経営陣との話し合いで、リファクタリングを望んでいるいくつかの主要なコンポーネントがあることを主張しようとしました。そうすることで、新しい機能を追加するときに、将来の反復で多くの時間と頭痛の種を節約できます。これらの重要な領域のバグを修正します。彼らはこれらのコンポーネントのリファクタリングがいいと私を信頼しているように見えますが、彼らは私にそれをする余裕を与えたくありません。コードベース全体の書き直しや劇的なことについて話しているのではなく、2〜3週間程度かかるいくつかのコア領域の書き直しについて話しているだけであることに注意してください。

では、問題は、開発者として、これらの領域に対処する必要があることをマネージャーに売り込み、あちこちで段階的に改善するのではなく、今すぐ対処する時間を確保するためのビジネスケースを作成する方法です。

フレームワークまたは言語の新しいバージョン (.NET 3.5、SQL2008 など) が登場した場合、人々はいつ採用/アップグレードするためにどのようなアプローチをとりますか?

一般的に、開発者はできるだけ早く言うでしょう (彼らは履歴書でそれを望んでおり、管理の観点から、彼らが望むものを提供することでモチベーションが向上します)、商業的にはほとんどインセンティブがなく (最新バージョンを要求するクライアントはほとんどいません)、コストの観点からも(再テスト、トレーニング) しばしば意欲をそぐものがあります。

私が特に考えているのは、「進行中の」システムとプロジェクト (ソフトウェアハウスなど) が存在し、何年にもわたって進化し、「新しいプロジェクトで新しいテクノロジーを使用する」アプローチがうまくいかない場合です。

人々は特定の要件 (新しい機能を使用する必要性、潜在的または既存のクライアントがそれに対するサポートを要求すること) によって動かされていますか、それを正式に評価しますか (この場合の基準は何ですか)、または定期的にアップグレードしますか (どの場合に - リーディング エッジとブリーディング エッジ)?

何かの最新バージョンを使用していないことを技術的負債と見なし、そのように管理する必要があると人々は考えていますか?

または、「壊れていない場合は修正しないでください」という有効なアプローチはありますか?

私が日常的に使用しているサイトにはいくつかの欠点があり、後で修正することを意図して「今すぐやり遂げる」という設計上の決定を下すことがよくあります。

実際に戻ってそれらを修正する時間を作ることは言うまでもなく、To Do 項目の完全なリストが何であるかを思い出すことは、せいぜい困難なことです。

技術的負債を効果的に管理するのに役立つツール、リソース、またはトリックをお勧めできますか?

2010年には多くの機能的な成果物が計画されていますが、テクノロジーのアジェンダ（アーキテクチャのリファクタリング、統合、プラットフォームのアップグレード）もあります。これらをロードマップに含めて、ビジネスがそれらが重要である理由を理解するのに役立つ最善の方法に関する提案。

1つの選択肢は、すべてを健康に保つためにこれが正しいことであるため、私たちを信頼すると言っているだけですが、可能であれば、より良い視覚化を望んでいます

私は現在、かなり古い製品に取り組んでいます。この製品は、過去の貧弱なプログラマーや貧弱な開発慣行から多くの技術的負債を抱えていました。私たちは改善し始めており、技術的負債の発生はかなり鈍化しています。

状態の悪いアプリケーションの領域を特定し、それらの領域を修正するためのコストを見積もることができますが、投資収益率 (ROI) を見積もるのに苦労しています。

コードは保守しやすく、将来的に拡張しやすくなりますが、これらにドルの数字を付けるにはどうすればよいでしょうか?

開始するのに適した場所は、バグ追跡システムに戻り、これらの「悪い」領域に関連するバグと機能に基づいてコストを見積もることです。しかし、それには時間がかかり、価値の最良の予測因子ではないかもしれません。

過去にそのような分析を行った人がいて、何かアドバイスはありますか?