エンジニアが突然利用できなくなった場合のソフトウェア災害復旧

私の会社では最近、締め切りが非常に厳しいプロジェクトがあり、極端な個人的な問題のために私が不在になるまで、すべてが計画どおりに進んでいました。

結局、4〜5日で締め切りに間に合いませんでした。

これらの状態の通常の回復計画は何ですか？私の会社は私の仕事を完了するために開発者を外部委託しようとする必要がありますか？それを見つけるのに数日かかるかも？

それは、利用不可の予測可能な期間、プロジェクトの残りの期間、タスクが分散される方法、および期限を逃した結果に依存します。

ソフトウェア開発者は自由に入れ替えることはできません。開発者はシステムの成長に応じてシステムに関する知識を構築します。新しいリソースを追加するには、新しいリソースの不足しているコンテキスト知識に対処する必要があります。

いくつかの優れたプラクティスは、突然の利用不能に関連するリスクを軽減します。

• ピアレビューにより、開発に関する知識が複数の開発者間で共有されます。利用できない場合は、チームの残りのメンバーが再編成して引き継ぐか、最悪の場合は新しいコーダーを招いて知識の伝達を整理します。
• 設計の決定を行うために緊密に連携する統合された同じ場所に配置されたチームは、同じように可用性を緩和できます。全体的な設計に関する共有された知識は、仕事の再配布と新規参入者への説明を容易にします。
• 正式なドキュメントが最終的に役立つ可能性があります。ただし、実際にこれがうまく機能するのは、ある開発者が作成したドキュメントが別の開発者（またはコード生成ツールで使用されるモデル）によって使用される場合のみです。自分で読むだけのドキュメントは、多くの場合あいまいであるように見えます。新しい開発者がそのような作業を引き継ぐ必要がある場合は、自己文書化によって、答えるほど多くの質問が生じる可能性があります。

締め切りが迫っているときに新しい開発者を取り込むことは非常に困難です。これは、余暇がない時間に、新参者にチームの説明に時間をかけるためです。1週間病気の場合は意味がありません。新規参入者へのブリーフィングのコストが新しいリソースのメリットによって補われる場合、通常は遅れるコストが高い場合、延期できない場合、または利用できない状態が長期間続く場合が想定されます。

これの通常の計画は、期限に不測の事態を組み込むことです。事態が発生し、納期に間に合わないことがよくあります。あなたが利用できなくなっているのは、計画どおりに進むことのない、慎重に計画された計画の別の問題でした！

これは「バス係数」と呼ばれます。基本的に、開発者がバスにぶつかった場合にプロジェクトにもたらされるリスク。開発者を1週間利用できなくすることは、開発者を永久に失うことと比較して、小さな問題です。それは事故や突然の病気の可能性がありますが、それほど劇的ではありませんが、コアデベロッパーが急に仕事を切り替えたり、解雇されたりする可能性があります。または、コア開発者が別の部門の別の優先度の高いタスクに転送されます。

つまり、バス係数を下げることを計画するか、またはバッファーを期限内に置くか、または期限を延ばすことができるように十分に柔軟であるなど、それを軽減する準備をする必要があります。通常、実行できないことは、複雑なタスクをすぐにアウトソーシングするか、新しい開発者を雇うことです。ほとんどの場合、コア開発者が戻るのに1週間待つよりも、既存のシステムに新しい開発者を紹介するのに時間がかかります。小規模なチームがメンバーを失うと、もちろん遅くなりますが、新しいメンバーを紹介する必要がある場合は、さらに遅くなります。

チームが継続的に知識を共有し、ピアレビュー（またはペアプログラミング）を行うことで、バス係数を下げることができます。しかしもちろん、これはバスがヒットする前に行わなければならないことです。

従業員は、いつでも通知なしに、1週間、1か月、または永久に利用できなくなる可能性があります。事故、病気、この仕事を十分にしたこと、他の多くの理由。そのような機会が厄介で、おそらく高価であるが災害ではないことを確認することは、管理者次第です。

10人のチームがある場合、チームの10％を失う可能性があります。会社は、チームの他のメンバーがやる気を起こさせられた場合、それを処理できるはずです（残業代の支払いは非常にやる気を起こさせます）。あなたが1つのチームである場合、作業は完了しません。介入できる他の従業員がいる場合、遅延は最小限に抑えられます。外から誰かを雇うのは難しいでしょうが、おそらく非常に高い時間単価で数週間前から数日前に開始できる請負業者を見つけるでしょう。

契約などを整えておくことが最善であり、製品の完成が遅れても経済的な被害にはなりません。そして、締め切りを前倒しして計画的かつ達成可能な終了日を設定すること。互いに介入できる従業員がいることは役立ちます（ただし、達成するのに問題が生じる可能性があります）。

また、達成する必要がある期限がある場合は、作業の範囲がより柔軟になります。つまり、期限に合わせて機能をドロップします。

@JacquesBが前述した「バス係数」を減らすための重要な方法の1つは、コアテクニックとしてのペアプログラミングです。（私自身の習慣は、「宝くじ因子」という用語を使用することです。これは病的状態が少ないためですが、効果は同じです。）

多くの開発者はペアプログラミングを嫌います。多くのマネージャーもまったく異なる理由でそれを嫌っています（一部の開発者は、長期間他の人間と通信することを強いられます。一部のマネージャーは、1つの出力に対して2倍のお金を払っているように感じることがよくあります）。

ただし、ペアプログラミングでは、少なくとも2人の開発者が特定の開発タスクを確実に実行し、理解できるようにすることで、単一の人間の障害点のリスクを完全に排除します。

この種の処理を私が見た方法はいくつかあります。

ワークアウトを共有する

最も明白なことは、既存のリソース間で作業を共有することです（これが可能な場合）。開発者が確実に着手する方法はそれ自体でほぼ答えですが、結局のところ、要件、設計、および進捗を適切に記録することになります。ペアプログラミングのようなものもここで大いに役立ちます。

期限を遅らせるか、時間を取り戻そうとする

期限を延長できるかどうかをお客様に確認します。あるいは、夕方、週末、休日に勤務することで、追加の開発時間を獲得できる可能性があります。

他のタスクを削除する

スペースを空けるために一時的に削除できる他の重要でないタスクはありますか？

先を行く

ドキュメント、テストスクリプト、構成など、開発後に進めることができる作業は計画されていますか？

遅れる可能性があることを認める

早めにお客様にご相談ください。一部を提供することは可能かもしれません-または、少なくとも、他のものの相対的な優先順位についてまともな操縦を得ることができます。

追加リソース

可能性-しかし、これ自体がリスクを伴います。彼らが速度を上げるまでには時間がかかり、それらは一時的であるため、彼らはあなたをさらに悪化させたままにしておくことができます。

クリティカルパスを確認する

他の関係者が関与している場合-それらがまだ目標に達していることを確認してください。テストチームが物事をテストするのに1か月遅れている場合、天と地を動かして何かを完成させる意味はほとんどありません。

リスクの現実を受け入れる

法律の専門家には、難しい問題は貧弱な解決策を生み出すという一般的な言い回しがあります。すべての不測の事態をカバーするために、すべての人にすべてを理解させようとするのは魅力的です。しかし、これは愚か者の用事です。

開発者は自分の開発に質の高い時間を費やす必要があります。他の開発でau faitになるまでに増え続ける時間を消費することは非常に疑わしい活動です。妥当な中立的な根拠は、主題の専門家と代理人を置くことかもしれません。