バス ファクター スコア: チームが失敗する前に、何人のチーム メンバーがバスにひかれることができますか?

ちょっとした歴史

タイトルは非常に極端に聞こえるかもしれませんが、1994 年に Michael McLayによって同様の文が公に求められました。

グイドがバスにひかれた場合は？ (Guido van Rossum は Python 言語の作成者です)

その疑問は、バスの問題、トラックの要因、トラックの要因、または宝くじの要因としても知られるバスの要因の作成につながりました。

「バスファクター」とは？

ウェブ上には若干異なる定義がいくつかありますが、それらを次のように要約できます。

バス係数は、バスに轢かれて無力化される必要がある人々の総数であり、プロジェクトが失敗に終わる可能性があります。

これをよりわかりやすくするために、 Bus Factor スコアは、プロジェクトにとって非常に重要であり、それらがなければ失速する人々の推定値です。それらの人々が何らかの理由でプロジェクトから姿を消した場合 (「事故」や休暇、解雇、プロジェクトからの脱退など)、誰もプロジェクトを維持できなくなります。

バス ファクター スコアの最低値は 1 です。これは、1 人がプロジェクトを離れると、失速するか死亡することを意味します。より技術的な観点からは、これはプロジェクト内の単一障害点と見なすことができます。より大きなバス ファクター スコアが望ましいですが、常に簡単に達成できるとは限りません。

PHP コミュニティの問題

2021 年末、PHP コミュニティは、無数のバグ修正、機能の実装、および PHP のメンテナンスを 10 年間行った後、主な貢献者の 1 人であるNikita Popovが、まったく異なる言語とコミュニティ (Rust & LLVM)、彼はすでに数年間離れていました。

Python 言語の歴史と同様に、この決定は、PHP 言語が非常に低いバス ファクター スコアという非常に大きな問題を抱えていることを示しています。これは、Web の ~78% を強化する言語の将来を危険な立場に置きました。

現状を改善するために、PHP に取り組んでいる人々や企業が力を合わせて新しいイニシアチブを開始しました: PHP Foundation .

PHP Foundationは、PHP 言語の長寿と繁栄を保証することを使命とする非営利団体です。

財団が下した最初の決定は、PHP コア コンポーネントに取り組む新しい開発者を雇用/後援することでした。そうすれば、バス ファクター スコアをより安全なレベルまで上げ始めることができます。これは、PHP の将来を安全かつ安定させるためにコミュニティが実行する必要がある多くの手順の 1 つです。

会社の問題

スタートアップから大企業まで、私が働いていた多くの企業は、バスファクターによってしばしば大きな打撃を受けました.彼らのチームの多くは (ほとんどの場合意図的ではありませんが) NIH (Not Invented Here)に陥り、プロジェクトを離れる可能性のある人々によってますます多くのものが作成されたため、メンテナンスの問題が発生し、新規参入者のエントリーレベルが高くなりました。いつでも。これは多くの場合、高い技術的負債につながります (これについては、後の記事で説明します)。

低いバス ファクター スコアは、急速に成長する時期の一部であることが多く、数人の開発者だけが、後にますます複雑化するプロジェクトのベースとなる機能のほとんどを作成します。ほとんどの企業は、このような成長期に大規模な採用計画を開始しますが、それだけでバス ファクターを増加させることはできません。

低いバス ファクター スコアを上げる方法は?

コーチングセッション＆ペアプログラミング

各新メンバーは、参加するプロジェクトの上級者の 1 人と少なくとも 30 分間のペア プログラミング セッションを行う必要があります。このようなセッションでは、経験の浅い人がコーディングの大部分を行う必要がありますが、シニアメンターは例を挙げてリードし、タスクの目標を達成するのに役立つ可能性のある部分を提案します.

教師としてのバスファクターの人

Bus Factorのメンバーを特定するときは、プロジェクトの何年にもわたって収集した知識をどのように共有できるかに焦点を当てる必要があります。彼らの知識は、チームにとって最大の価値の 1 つです。ドキュメントの作成、チートシートの作成、社内プレゼンテーションの実施、チームメイトとの 1 対 1 のセッションでの知識の共有に集中してもらいます。彼らのプログラミングへの集中は減らされるべきです。

コードレビュー文化

コード レビュー文化の採用は、コードの品質とレビュー プロセスを改善するためにチームによって行われますが、プロジェクト内の人々の間で知識が直接共有されることはあまり明白ではありません。レビューは、承認のスタンプを与えるようなものであってはなりません。彼らは、何かが別の方法ではなくそのように行われた理由を指摘し、シニアの観点から、シニアと他のチームメイトの間で何が違うのかについて建設的な議論につながるようにする必要があります.レビューは議論につながる必要があります。

プロジェクトの複雑さの軽減

多くの場合、急成長中の企業の問題は急成長している技術的負債であり、バス ファクター スコアが低くなります。効果的な手法の 1 つは、プロジェクトをより小さく、より専用のプロジェクトに分割することで、プロジェクトの複雑さを軽減することです。これにより、エントリーレベルが低くなり、採用が早くなり、メンテナンスが容易になります。これらすべてのポイントにより、全体のバス係数を非常に効果的に増やすことができます。プロジェクトの複雑さを軽減する際に回避しなければならない最大の問題は、新しいサブプロジェクトでまったく同じ問題が発生しないように、リファクタリングに常にチーム (小さなチームでも) を関与させることです。

チームの「シャッフル」

これは、バス ファクター スコアを上げる最も効果的な方法ですが、最も困難で危険な方法でもあります。チームの士気を失わないように、あらゆる可能性を綿密に計画する必要があります。 「シャッフル」は強制されるべきではありませんが、次のように定期的にチーム メンバーに提案する必要があります。チームメイトは、新人のようにオンボーディングする必要があるため、頻繁にチームを変更することはできません。よく計画して実行すれば、チームはさまざまな分野でより幅広い経験を積むことができ、他のチームと協力しながら学んだ知識を共有できます。

研修予算

開発者のトレーニング予算を計画すると、人々がより幅広い経験を積むようになるため、バス ファクター スコアも向上し、チームを拡大して、会社の階層内の各年功序列により多くの人を配置できます。

概要

チームのバス ファクター スコアを上げるのは、それほど簡単でも、安くても、すぐでもありません。プロジェクトに機密データが含まれていて、新規採用者がその処理を開始することを信頼できない場合など、そのスコアを簡単に上げたくない (または上げられない) 場合があります。しかし、これで、「バス事故」による業務の停止を防ぐのに役立ついくつかの基本がわかりました。