Embora o título possa parecer bastante extremo, uma frase semelhante foi feita publicamente por Michael McLay em 1994 :
Se Guido fosse atropelado por um ônibus? (Guido van Rossum é o criador da linguagem Python)
Essa pergunta levou à criação do Fator Ônibus , também conhecido como problema do ônibus, fator caminhão , fator caminhão ou ainda fator loteria .
Embora existam várias definições ligeiramente diferentes na Web, podemos resumi-las como:
O Fator Ônibus é o número total de pessoas que precisariam ser incapacitadas, como atropelamento para que o projeto fosse dado como morto.
Para tornar isso mais descritivo, a pontuação do Fator de Ônibus é uma estimativa das pessoas que são tão vitais para o seu projeto que, sem elas, ele parará. Se essas pessoas desaparecessem do projeto por qualquer motivo (como um "acidente" ou mesmo férias, fossem demitidas ou deixassem o projeto), ninguém seria capaz de manter o projeto.
A pontuação mais baixa possível do fator de barramento é apenas 1, o que significa que, se uma pessoa deixar o projeto, ele irá parar ou morrer. De um ponto de vista mais técnico, isso poderia ser considerado um único ponto de falha dentro do projeto. Uma pontuação de fator de barramento muito maior é preferível, mas nem sempre é fácil de alcançar.
No final de 2021, a comunidade PHP recebeu a triste informação de que, após 10 anos implementando inúmeras correções de bugs, recursos e manutenção do PHP, um dos principais contribuidores: Nikita Popov , decidiu se concentrar em trabalhar em uma linguagem e comunidade completamente diferentes (Rust & LLVM), da qual já se encontrava separado há alguns anos.
Semelhante à história da linguagem Python, essa decisão mostrou que a linguagem PHP tem um grande problema com uma pontuação de fator de barramento tão baixa. Isso colocou o futuro da linguagem que alimenta cerca de 78% da Web em uma posição perigosa.
Para melhorar o estado atual, pessoas e empresas que trabalham com PHP uniram forças e iniciaram uma nova iniciativa: PHP Foundation .
A PHP Foundation é uma organização sem fins lucrativos cuja missão é garantir a vida longa e a prosperidade da linguagem PHP.
A primeira decisão tomada pela fundação foi contratar/patrocinar novos desenvolvedores para trabalhar nos componentes principais do PHP. Dessa forma, eles poderiam começar a aumentar a pontuação do Fator de Ônibus para um nível mais seguro. Este é um dos muitos passos que precisam ser dados pela comunidade para tornar o futuro do PHP seguro e estável.
Muitas empresas para as quais trabalhei, de startups a corporações, muitas vezes foram duramente atingidas pelo Bus Factor. Muitas de suas equipes (na maioria das vezes não intencionalmente) caíram no NIH (Not Invented Here) , o que levou a problemas com manutenção e nível de entrada mais alto para os recém-chegados, pois mais e mais coisas foram criadas por pessoas que poderiam deixar o projeto a qualquer momento. Isso geralmente leva a uma alta Dívida Técnica (que tentarei explicar em um post posterior).
Uma pontuação baixa do fator de barramento geralmente faz parte do período de rápido crescimento, quando apenas alguns desenvolvedores criam a maior parte da funcionalidade que mais tarde se torna a base para um projeto cada vez mais complexo. A maioria das empresas inicia grandes planos de contratação durante esse crescimento, mas isso não é algo que pode aumentar o Fator Ônibus sozinho.
Cada novo membro deve ter pelo menos 30 minutos de uma sessão de programação em pares com uma das pessoas mais velhas do projeto ao qual está participando. Durante essas sessões, uma pessoa menos experiente deve fazer a maior parte da codificação, enquanto os mentores seniores lideram pelo exemplo e sugerem partes que podem ajudar a atingir o objetivo da tarefa.
Ao identificar as pessoas da Bus Factor , você deve se concentrar em como elas podem compartilhar o conhecimento que agregaram durante todos esses anos em seu projeto. Seu conhecimento é um dos maiores valores para sua equipe. Faça com que eles se concentrem mais em escrever documentação, criar dicas, fazer apresentações internas e compartilhar conhecimento em sessões individuais com colegas de equipe. Seu foco na programação deve ser reduzido .
Embora a adoção da cultura de revisão de código seja feita por equipes para melhorar a qualidade do código e o processo de revisão, o resultado menos óbvio é o compartilhamento direto de conhecimento entre as pessoas no projeto. Avaliações não devem ser apenas como dar um selo de aprovação. Eles devem apontar por que algo foi feito dessa maneira, e não de outra, levando a discussões construtivas entre os seniores e outros colegas de equipe sobre o que poderia ser feito de maneira diferente, na perspectiva dos seniores. As revisões devem levar à discussão.
Frequentemente, o problema das empresas de crescimento rápido é a Dívida Técnica de crescimento rápido, o que leva a uma pontuação baixa do Fator de Barramento. Uma das técnicas eficazes é reduzir a complexidade dos projetos, dividindo-os em projetos menores e mais dedicados. Isso leva a um nível de entrada mais baixo, adoção mais rápida e manutenção mais fácil. Todos esses pontos permitem aumentar o Fator de Barramento geral de forma bastante eficaz. O maior problema que você deve evitar durante a redução da complexidade dos projetos é sempre envolver equipes (mesmo as pequenas) na refatoração para evitar criar o mesmo problema no(s) novo (s) subprojeto(s) .
Esta pode ser a maneira mais eficaz de aumentar a pontuação do Bus Factor, mas também é a mais difícil e perigosa. Você precisa planejar profundamente todas as possibilidades para evitar a perda do moral da equipe. O "embaralhamento" não deve ser forçado, mas proposto aos membros da equipe de forma regular, como: uma vez a cada dois trimestres; os colegas de equipe não podem mudar de equipe com muita frequência, pois precisarão ser integrados como um novato. Se bem planejado e executado, suas equipes obterão uma experiência muito mais ampla em diferentes domínios, compartilhando o conhecimento aprendido enquanto trabalham com outras equipes.
O planejamento de orçamentos de treinamento para seus desenvolvedores também pode aumentar a pontuação do Bus Factor, pois as pessoas terão uma gama mais ampla de experiência e expandirão sua equipe para ter mais pessoas em cada nível de senioridade na hierarquia de sua empresa.
Não é tão fácil, barato ou rápido aumentar a pontuação do Bus Factor da sua equipe. Há casos em que você não quer (ou até não pode) aumentar facilmente essa pontuação, por exemplo, quando o projeto contém dados confidenciais e você não pode confiar em seus novos contratados para começar a lidar com isso. Mas agora você conhece alguns dos princípios básicos que podem ajudá-lo a evitar que suas operações sejam interrompidas devido a um "acidente de ônibus".