ちょっとした歴史 タイトルは非常に極端に聞こえるかもしれませんが によって同様の文が公に求められました。 、1994 年に Michael McLay グイドがバスにひかれた場合は？ (Guido van Rossum は Python 言語の作成者です) その疑問は、 、 、または としても知られる の作成につながりました。 バスの問題、 トラックの要因 トラックの要因 宝くじの要因 バスの要因  「バスファクター」とは？ ウェブ上には若干異なる定義がいくつかありますが、それらを次のように要約できます。 バス係数は、バスに轢かれて無力化される必要がある人々の総数であり、プロジェクトが失敗に終わる可能性があります。 これをよりわかりやすくするために、  は、プロジェクトにとって非常に重要であり、それらがなければ失速する人々の推定値です。それらの人々が何らかの理由でプロジェクトから姿を消した場合 (「事故」や休暇、解雇、プロジェクトからの脱退など)、誰もプロジェクトを維持できなくなります。 Bus Factor スコア バス ファクター スコアの最低値は 1 です。これは、1 人がプロジェクトを離れると、失速するか死亡することを意味します。より技術的な観点からは、これはプロジェクト内の と見なすことができます。より大きなバス ファクター スコアが望ましいですが、常に簡単に達成できるとは限りません。  単一障害点  PHP コミュニティの問題 2021 年末、PHP コミュニティは、無数のバグ修正、機能の実装、および PHP のメンテナンスを 10 年間行った後、主な貢献者の 1 人である が、まったく異なる言語とコミュニティ (Rust & LLVM)、彼はすでに数年間離れていました。 Nikita Popov  Python 言語の歴史と同様に、この決定は、PHP 言語が非常に低いバス ファクター スコアという非常に大きな問題を抱えていることを示しています。これは、Web の ~78% を強化する言語の将来を危険な立場に置きました。 現状を改善するために、PHP に取り組んでいる人々や企業が力を合わせて新しいイニシアチブを開始しました:   . PHP Foundation   は、PHP 言語の長寿と繁栄を保証することを使命とする非営利団体です。 PHP Foundation 財団が下した最初の決定は、PHP コア コンポーネントに取り組む新しい開発者を雇用/後援することでした。そうすれば、バス ファクター スコアをより安全なレベルまで上げ始めることができます。これは、PHP の将来を安全かつ安定させるためにコミュニティが実行する必要がある多くの手順の 1 つです。 会社の問題 スタートアップから大企業まで、私が働いていた多くの企業は、バスファクターによってしばしば大きな打撃を受けました.彼らのチームの多くは (ほとんどの場合意図的ではありませんが)  に陥り、プロジェクトを離れる可能性のある人々によってますます多くのものが作成されたため、メンテナンスの問題が発生し、新規参入者のエントリーレベルが高くなりました。いつでも。これは多くの場合、高い技術的負債につながります (これについては、後の記事で説明します)。 NIH (Not Invented Here) は、急速に成長する時期の一部であることが多く、数人の開発者だけが、後にますます複雑化するプロジェクトのベースとなる機能のほとんどを作成します。ほとんどの企業は、このような成長期に大規模な採用計画を開始しますが、それだけでバス ファクターを増加させることはできません。 低いバス ファクター スコア 低いバス ファクター スコアを上げる方法は? コーチングセッション＆ペアプログラミング 各新メンバーは、参加するプロジェクトの 者の 1 人と少なくとも 30 分間のペア プログラミング セッションを行う必要があります。このようなセッションでは、経験の浅い人がコーディングの大部分を行う必要がありますが、シニアメンターは例を挙げてリードし、タスクの目標を達成するのに役立つ可能性のある部分を提案します. 上級 教師としてのバスファクターの人 のメンバーを特定するときは、プロジェクトの何年にもわたって収集した知識をどのように共有できるかに焦点を当てる必要があります。彼らの知識は、チームにとって最大の価値の 1 つです。ドキュメントの作成、チートシートの作成、社内プレゼンテーションの実施、チームメイトとの 1 対 1 のセッションでの知識の共有に集中してもらいます。彼らのプログラミングへの集中は れるべきです。 Bus Factor 減らさ コードレビュー文化 コード レビュー文化の採用は、コードの品質とレビュー プロセスを改善するためにチームによって行われますが、プロジェクト内の人々の間で知識が直接共有されることはあまり明白ではありません。レビューは、承認のスタンプを与えるようなものであってはなりません。彼らは、何かが別の方法ではなくそのように行われた理由を指摘し、シニアの観点から、シニアと他のチームメイトの間で何が違うのかについて建設的な議論につながるようにする必要があります.レビューは議論につながる必要があります。 プロジェクトの複雑さの軽減 多くの場合、急成長中の企業の問題は急成長している技術的負債であり、バス ファクター スコアが低くなります。効果的な手法の 1 つは、プロジェクトをより小さく、より専用のプロジェクトに分割することで、プロジェクトの複雑さを軽減することです。これにより、エントリーレベルが低くなり、採用が早くなり、メンテナンスが容易になります。これらすべてのポイントにより、全体のバス係数を非常に効果的に増やすことができます。プロジェクトの複雑さを軽減する際に回避しなければならない最大の問題は、新しい でまったく同じ問題が発生しないように、リファクタリングに常にチーム (小さなチームでも) を関与させることです。 サブプロジェクト チームの「シャッフル」 これは、バス ファクター スコアを上げる最も効果的な方法ですが、最も困難で危険な方法でもあります。チームの士気を失わないように、あらゆる可能性を綿密に計画する必要があります。 「シャッフル」は強制されるべきではありませんが、次のように定期的にチーム メンバーに提案する必要があります。チームメイトは、新人のようにオンボーディングする必要があるため、頻繁にチームを変更することはできません。よく計画して実行すれば、チームはさまざまな分野でより幅広い経験を積むことができ、他のチームと協力しながら学んだ知識を共有できます。 研修予算 開発者のトレーニング予算を計画すると、人々がより幅広い経験を積むようになるため、バス ファクター スコアも向上し、チームを拡大して、会社の階層内の各年功序列により多くの人を配置できます。 概要 チームのバス ファクター スコアを上げるのは、それほど簡単でも、安くても、すぐでもありません。プロジェクトに機密データが含まれていて、新規採用者がその処理を開始することを信頼できない場合など、そのスコアを簡単に上げたくない (または上げられない) 場合があります。しかし、これで、「バス事故」による業務の停止を防ぐのに役立ついくつかの基本がわかりました。

Different

2022 - All About Teamwork

2022 - HackerNoon Contributor of the Year - Management

Official Technical blog

Nominated for 2022 - All About Teamwork

Nominated for 2022 - HackerNoon Contributor of the Year - Management

Staff Software Engineer at TUI Musement

このオーディオは、ストーリーの元の言語で制作されています。

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

About Author

コメント

ラベル

この記事は

Related Stories

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

AI の力を解き放つ。最先端技術の体系的レビュー: 概要と序論

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

AI の力を解き放つ。最先端技術の体系的レビュー: 概要と序論

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps

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

About Author

コメント

ラベル

この記事は

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps

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