エンジニアが突然利用できなくなった場合のソフトウェア災害復旧
私の会社では最近、締め切りが非常に厳しいプロジェクトがあり、極端な個人的な問題のために私が不在になるまで、すべてが計画どおりに進んでいました。
結局、4〜5日で締め切りに間に合いませんでした。
これらの状態の通常の回復計画は何ですか？私の会社は、私の仕事を完了するために開発者を外部委託しようとする必要がありますか？それを見つけるのに数日かかるかも？
それは、利用不可の予測可能な期間、プロジェクトの残りの期間、タスクの分散方法、および期限を逃した結果に依存します。
ソフトウェア開発者は自由に入れ替えることはできません。開発者はシステムの成長に応じてシステムに関する知識を構築します。新しいリソースを追加するには、新しいリソースの不足しているコンテキスト知識に対処する必要があります。
いくつかの優れたプラクティスは、突然の利用不能に関連するリスクを軽減します。
- ピアレビューにより、開発に関する知識が複数の開発者間で共有されることが保証されます。利用できない場合は、チームの残りのメンバーが再編成して引き継ぐか、最悪の場合は新しいコーダーを招いて知識の伝達を整理します。
- 設計の決定を行うために緊密に連携する統合された同じ場所に配置されたチームは、同じ方法で可用性を緩和できます。全体的な設計に関する共有された知識は、仕事の再配布と新規参入者への説明会を容易にします。
- 正式なドキュメントが最終的に役立つ可能性があります。ただし実際には、これは、ある開発者が作成したドキュメントが別の開発者（またはコード生成ツールで使用されるモデル）によって使用される場合にのみ機能します。自分だけで読むドキュメントは、多くの場合あいまいなように見えます。新しい開発者がそのような作業を引き継ぐ必要がある場合、自己文書化は、答える質問と同じくらい多くを提起するかもしれません。
締め切りが迫っているときに新しい開発者を取り込むことは非常に困難です。これは、空き時間がない期間に、新人の説明にチームの時間がかかるためです。 1週間病気の場合は意味がありません。新規参入者へのブリーフィングのコストが新しいリソースの利点によって補われる場合、通常は遅れるコストが高い場合、延期することが不可能である場合、または利用できない状態が長期間にわたる場合に想定されます。
これは「バス係数」と呼ばれます。基本的に、開発者がバスにぶつかった場合にプロジェクトにもたらされるリスク。開発者を1週間利用できなくすることは、開発者を永久に失うことと比較して、小さな問題です。それは事故や突然の病気かもしれませんが、それほど劇的ではありませんが、コアデベロッパーが急に仕事を切り替えたり、解雇されたりする可能性があります。または、コア開発者が別の部門の別の優先度の高いタスクに転送されます。
つまり、バス係数を下げることを計画するか、それを緩和する準備をする必要があります。期限内にバッファを用意するか、期限をプッシュできるように十分に柔軟にする。通常、あなたができないすることは、複雑なタスクをすぐにアウトソーシングするか、新しい開発者を雇うことです-ほとんどの場合、既存のシステムに新しい開発者を紹介するには、1週間待つよりも時間がかかります戻るコア開発者。小さなチームがメンバーを失った場合、もちろん彼らは遅くなりますが、新しいメンバーを紹介する必要がある場合、彼らはさらに遅いになります。
チームが継続的に知識を共有し、ピアレビュー（またはペアプログラミング）を行うことで、バス係数を下げることができます。しかしもちろん、これはバスがヒットする前に行わなければならないことです。
これの通常の計画は、期限に不測の事態を組み込むことです。事態が発生し、締め切りに間に合わないことがよくあります。あなたが利用できなくなっているのは、計画どおりに進むことができない、慎重に計画された計画の別の問題でした！
従業員はいつでも、通知なしに、1週間、1か月、または永久に利用できなくなる可能性があります。事故、病気、この仕事を十分にしたこと、他の多くの理由。そのような機会が厄介で、多分高価であるが災害ではないことを確認することは、管理次第です。
10人のチームがある場合、チームの10％を失う可能性があります。会社は、チームの他のメンバーがやる気を起こした場合（時間外労働に対する支払いが非常にやる気を起こさせる場合）に対処できるはずです。あなたが1つのチームである場合、作業は完了しません。介入できる他の従業員がいる場合、遅延は最小限に抑えられます。外から誰かを雇うことは難しいでしょうが、おそらく数週間前にvery高い時間単価で数日前に通知を開始できる請負業者を見つけるでしょう。
契約を結ぶなどして、製品の完成が遅れることで経済的に困らないようにするのが一番です。そして、締め切り前に計画的かつ達成可能な終了日を設定すること。お互いに介入できる従業員がいることは役立ちます（ただし、達成するのに問題がある場合があります）。
そして、もしあなたがmustが達成される期限があるなら、多分仕事の範囲はより柔軟です。つまり、期限に合わせて機能をドロップします。
@JacquesBが前述した「バス係数」を削減する1つの重要な方法は、コアテクニックとしてペアプログラミングです。 （私自身の習慣は、「宝くじ因子」という用語を使用することです。というのは、病的状態は少ないですが、効果は同じです。）
多くの開発者はペアプログラミングを嫌います。多くのマネージャーもまったく異なる理由でそれを嫌っています（一部の開発者は長期間他の人間と通信することを余儀なくされます。一部のマネージャーは、1つの出力に対して2倍のお金を払っているように誤って感じることがよくあります）。
ただし、ペアプログラミングでは、少なくとも2人の開発者が特定の開発タスクを確実に実行および理解できるようにすることで、単一の人的障害点のリスクを完全に排除します。
この種の処理を私が見てきた方法はいくつかあります。
ワークアウトを共有する
最も明白なことは、既存のリソース間で作業を共有することです（これが可能な場合）。開発者が確実に着手する方法はそれ自体でほぼ答えですが、結局のところ、要件、設計、および進捗を適切に記録することになります。 ペアプログラミング のようなものも、ここで大いに役立ちます。
締め切りを遅らせるか、時間を取り戻そうとします
期限を延長できるかどうかをお客様に確認します。あるいは、夕方、週末、休日に勤務することで、追加の開発時間を獲得できる可能性があります。
他のタスクをドロップする
スペースを空けるために一時的に削除できる他の重要でないタスクはありますか？
先に進んでください
ドキュメント、テストスクリプト、構成など、開発後に進めることができる作業は計画されていますか？
遅れる可能性があることを認めてください
早めにお客様にご相談ください。一部を提供することは可能かもしれません-または、少なくとも、他のものの相対的な優先順位についてまともな操縦を得ることができます。
追加リソース
可能性-しかし、これ自体がリスクを伴います。彼らが速度を上げるまでには時間がかかり、一時的なものであるため、彼らはあなたをさらに悪い状態にしてしまう可能性があります。
クリティカルパスを確認してください
他の関係者が関与している場合-それらがまだターゲットになっていることを確認します。言うなら、天と地を動かして何かを完成させる意味はほとんどありません。テストチームは物事のテストに1か月遅れています。
リスクの現実を受け入れる
困難な問題は貧弱な解決策を生み出すと述べている 一般的なフレーズ が専門職にあります。すべての不測の事態をカバーするためにすべての人にすべてを理解させようとすることは魅力的です。しかし、これは愚か者の用事です。
開発者は自分の開発に質の高い時間を費やす必要があります。他の開発でau faitになるまでに増え続ける時間を消費することは非常に疑わしい活動です。妥当な中立的な根拠は、主題の専門家と代理を置くことかもしれません。