技術的負債の文書化と計画？
私は同じソフトウェア会社で14年近く働いています。その間、多くの技術的負債が発生するのを見てきました。これは、長年のソフトウェア会社にとって避けられないことだと思います。
ただし、これに対処するための戦略はありませんでした。私たちは技術的負債を認識しており、人々は技術的負債について不平を言っていますが、それを処理する方法を計画に組み込むことはほとんどありません。私はこれが人々が私たちの会社を去った理由の一部であることを知っています。
私は調査を行いましたが、技術的負債を処理するための実証済みの方法を見つけることができませんでしたか？
私が個人的に行っているのは、TechnicalDebt.mdと呼ばれるファイルを私のリポジトリに追加することです。変更が必要だと思うものとその理由の説明と、時間の見積もりを記載しています。
上記は私の第一の質問ですが、特に「技術的負債は決してあるべきではない」と主張する人々からは、これについて議論があると思います。したがって、技術的負債へのアプローチを持つことの根拠となる、あなたが提供できるものは何でもありがたいです。
あなたの質問は、あまりにも広範すぎて閉ざされてしまうのではないかと思います。これは、何度かトラックを回った開発者がこれに何度も遭遇するためです。
しかし、私の経験を共有するために-これにはいくつかの側面があります：
単体テスト
借金の返済には、レガシーコードのリファクタリングが含まれます。これはすべて非常にうまくいきますが、物事を壊し始めるとすぐに歓迎されない注目の焦点になります。いずれにせよ、適切な単体テストスイートを用意する必要がありますが、そうでない場合は、リファクタリングがうまくいかないという早期の警告を与える可能性があるので、始めましょう。
レガシーコードへのアプローチ
これは人々が文字通りに本を書くトピックです-最も有名なものは要約されています ここ 。
借金の性質
すべての負債が同じというわけではありません。どのように取り組むかは、負債の性質によって異なります。それが単に時代遅れのテクノロジーである場合、リファクタリングするのではなく単に置き換えることができます。詳細を知らずにもっとアドバイスをするのは難しい...
バイインの取得
私は管理がすべて機能とバグについてであり、単に「研磨」に専念する時間を楽しまない場所で働いてきました。もちろんこれは非常に近視眼的です。問題を修正するための賛同を得られない場合は、他のことをしているコードの実行中に問題に参加する必要があります。
また、それは単なる管理の賛同ではないことも理解してください。同業者の賛同も必要です。彼らはさまざまな問題をどのように解決すべきかについて異なる考えを持つでしょう。全員を巻き込むと、プロセス全体がはるかに簡単になることがわかります。
あなたの儀式は何ですか？
技術的な借金があってはならないという人もいます。私がそう言っても、これはかなり素朴なスタンスです。おそらくそれらが意味することは、あなたの負債は可能な限り低くあるべきだということです（家計の負債のように）。
そうは言っても、あなたが持っている借金の額は、それをまとめて見る方法の関数です。どこにいても借金を返済することが常に頭の中である場合、それは非常に急に下がるのがわかります。あなたが自由時間にそれを修正しようとしている場合（それがいつでも）、それは長く困難な道です。
最初にそれを追跡することに関しては、それはあなたの通常の仕事追跡ツールに記録されるべきです。これを残りの作業から分離する方法は、ツールによって異なります。
技術的負債を追跡するために私が見つけた最良の方法は、新機能/開発およびバグとともに、問題追跡で追跡することです。使用しているツールに応じて、問題のタイプからタグやラベルの種類まで、技術的負債を特定するためのさまざまなオプションが存在する場合があります。
全体として、技術的負債を返済する方法は2つあります。
まず、開発中のアプリケーションの同じ領域に技術的負債がある場合、それは作業の見積もりに反映されます。技術的な負債が多い場合、特定の機能を同じレベルの品質で開発するのに時間がかかります。最低でも、見積もりは技術的負債を処理する必要性を説明し、見積もりには技術的負債を返済するための努力を含めることができます。
第二に、技術的負債を追跡し、それを支払うための個々の作業項目は、新しい開発以外の作業を計画および追跡するのに役立ちます。これは、技術的負債のある機能が現在または近い将来に活発に開発されていない可能性がある場合に特に役立ちます。システム変更のどの領域に加えられているのかを追跡して、追跡可能性をテストし、どこにテストの焦点を当てるべきかを知ることができます。
損失の確認とグラフ化
ここで例を使用してみましょう。地元のスーパーマーケットで1年間の会員証を購入すると、購入金額が5％割引になります。しかし、このメンバーシップにかかる75ドルを本当に投資したいですか？
とりあえず、会社が技術的な負債に時間を費やしたくないのと同じように、メンバーシップカードを購入しないことにしました。結局のところ、私は食料品に自分のお金を使う必要があります。
- 12月30日-NYEパーティーのために200ドル相当の食料品を購入した。私はそのメンバーシップを持っていた場合よりも10ドルを支払いました。
- 1月3日-毎週の食料品$ 60。 $ 3をメンバーとして保存できました。
- 1月10日-毎週の食料品$ 60。 $ 3をメンバーとして保存できました。
- 1月17日-毎週の食料品$ 60。 $ 3をメンバーとして保存できました。
- 1月24日-毎週の食料品$ 60。 $ 3をメンバーとして保存できました。
- 1月31日-毎週の食料品$ 60。 $ 3をメンバーとして保存できました。
- ...
これは単純な例ですが、1か月後には、メンバーになることで25ドル節約できたことにすぐに気づきます。会員になることでより良くなることを知るために、次の11か月を登録する必要さえありません。
毎週の食料品だけを数えると、年間$ 180節約できます（メンバーシップのコストを差し引いた場合、合計で$ 105）、そしてそれは時々の余分な費用も数えていません。
ここで取り上げるべき重要なことは、合計時間（1か月）の一部を記録すると、合計時間枠（つまり、1年のメンバーシップ、またはプロジェクトの存続期間）の合理的な期待がすぐに明らかになったということです。
リファクタリングのコストとリファクタリングしないことのコストを比較検討する
純粋に技術的な負債によって引き起こされたものに費やされた時間の損失と余分な労力を文書化すると、どれだけの時間を無駄にしているかがすぐにわかります。これは、修正に「無駄」に費やす時間と対照的です。技術的負債。
数学を見てください。チーム全体を組み合わせた場合が平均して1日30分を技術的に失う借金（これは合理的です）、それからあなたは合理的に200工数（5週間）リファクタリング以外の何もしないことに費やすことができ、それでもあなたは破るでしょう5年以上（これもプロジェクトにとって妥当な時間枠です）。
この計算では、将来追加される機能についても考慮されていません。これは、技術的負債に対応しなければ時間の無駄を増やすだけです。
技術的な負債が食料品の請求書ほど明確に描かれておらず、バグ（またはその修正）に貢献したかどうかを判断する必要があることは承知しています。これは客観的に測定可能ではありません。これは推定値であり、推定値は不正確ですが、妥当な推定値は長期間にわたって平均化される傾向があります。チームが妥当な見積もりを立てられない場合は、大きな魚を揚げる必要があります。
技術的負債によって合理的に影響を受けたすべてのチケットを文書化し、それで失われた時間を見積もる場合（一部のバグは100％とカウントされ、他のバグは部分的にしかカウントされない、新機能により、不必要に複雑なコードベースにより％時間コストが発生します...） 、それからすぐに、この負債がどれだけの時間を費やしているのかがわかります。
特定の技術的負債を分類し、個別に追跡することをお勧めします。 特定の負債があなたにどのように影響しているかを知ることはより意味があります。それで会社は彼らのボトムラインのためにアクティブな問題を作成している負債だけを修正することができます。
これは、長年のソフトウェア会社にとって避けられないことだと思います。
建物の腐敗は避けられないと言っているようなものです。建物が維持または修理されない場合、腐敗は確かに避けられません。しかし、適切なメンテナンスに時間をかけると、建物は事実上永遠に良好な状態を維持できます。
同様に、技術部門を減らすために時間がかかる場合、コードベースは製品の全寿命にわたって良好な状態のままになる可能性があります。
私は調査を行いましたが、技術的負債を処理するための実証済みの方法を見つけることができませんでしたか？
多くのソフトウェア会社が良い例を提供しています。
あなたはそれらの会社をどのように見つけるのですか？非常に長い間存在している成功した製品を見ることによって。一部（Windowsなど）は最初から書き直されましたが、多くは書き直されませんでした。最初から書き直すことは コストがかかり、リスクのあるビジネス です。 時の試練に耐える有名な製品の1つはLinuxです。オープンソースであることは良いことです。それは時間をかけて開発され、開発者が技術的負債をどのように管理したかです。
私はこれについて、特に「技術的負債は決してあるべきではない」と主張する人々からの議論があると期待しています。
技術部門がないことは非常にコストがかかり、常に役立つとは限りません。リファクタリングなどの一部のプラクティスは一定のアクティビティである必要がありますが、コードが十分に安定するまで延期されるものもあります。
技術的な負債のタスクを課題追跡に入れることは明らかです。しかし、それが問題になることはめったにありません。
私が技術的負債との取引で経験する主な問題は、それがビジネスとエンジニアリングの間の対立を引き起こすことです。技術的債務問題のビジネス価値を定量化することは非常に困難です。特に、利益が数か月または数年の範囲で非常に長期的である場合。したがって、ビジネスに「重要な」新機能に関する技術的な債務問題を計画させることは、不可能な作業になります。
最も単純なソリューションは、エンジニアリングのために一定のメンテナンス時間を確保することです。私の経験によると、技術的な負債が少ない場合は、エンジニアリング時間の10〜30％が最適です。しかし、実際には長期的に合理的な利益を達成する方法で巨額の技術的負債を返済する場合、価値は最大70％に達する可能性があります。多くの場合、代わりに機能に費やす時間を要求するため、この時間はビジネスが知らないはずのことになります。
技術的負債は、次のようないくつかの要因により忍び寄ります。
- 厳しい納期-製品を出荷するために手抜きをします。
- 要件の変化-製品は何かを実行する必要があり、そのために設計されていません。
どのくらいの技術的負債が許容できるかはビジネス上の決定です。たとえば、出荷しないと、もう1度も獲得できないVCラウンドすると、できる限り隅を切りたいと思うでしょう。したがって、借金が発生したり返済したりした場合の影響をビジネスに伝え、そこから計画を立てます。
借金の返済
議論するいくつかのオプションがあります：
- 債務返済のために各反復の一部を割り当てました。
- クリーンアップのために四半期ごとに1反復を割り当てます。
- 特定のモジュールを書き直すプロジェクト全体。
- 各ストーリーに追加の時間を割り当てる-より良い仕事をするための時間を開発者に与えるため。
ビジネスは何を「得る」のか
それはあなたがおそらくビジネスから1つの難しい質問に直面するつもりであると言いました：
「クリーンアップに時間を割り当てるために私は何を得ますか」
回答するには、次のように言う必要があります。
- 今日、どんな技術的負債がありますか。
- それを修正するのにどれくらい（時間）かかりますか？.
- 借金の費用は何ですか。
ポイント＃3はここで本当に最も重要です。コードが正常に実行され、サポートインシデントが発生せず、近い将来変更する予定はありません。ビジネスの観点からは、これは「無利子ローン」です-それを支払う理由はありません。
企画
おそらく追跡するためにプロセスを配置したいでしょう：
- 各技術的負債項目の結果として発生する追加の開発費の額。
- 給与および/または収益に関して、サポートインシデントにかかる費用。
このプロセスでは、現在持っている技術的負債項目を記録し、将来の開発上の問題や生産上の問題をそれらに結び付ける必要があります。これにより、ビジネスにとって最もコストのかかる技術的負債に優先順位を付けることができます。
最も高価なアイテムについては、それぞれを修正するのにかかるコストの大まかな見積もりを生成する必要があります。これを行った後は、ビジネスに対する投資利益率の議論になります。そのため、良い事例を作った場合は、前述の方法のいずれかを使用して、時間を割り当てるように説得できます。