Fator ônibus
O fator ônibus (também conhecido como fator loteria,[1][2] fator caminhão,[3] ou fator circo[4]) é uma medida do risco resultante da falta de compartilhamento de informações e capacidades entre os membros de uma equipe, derivado da frase "caso eles sejam atropelados por um ônibus".
O conceito é semelhante à ideia muito mais antiga de risco de pessoa-chave, mas considera as consequências da perda de especialistas técnicos essenciais, em vez de executivos financeiros ou gerentes (que são, em teoria, substituíveis mediante o custo de um seguro). Para que o fator ônibus seja eficaz, a pessoa deve ser essencial e insubstituível; a perda de uma pessoa substituível ou não essencial não resultaria em um efeito de fator ônibus.
O termo foi aplicado inicialmente ao desenvolvimento de software, onde um membro da equipe pode criar componentes críticos ao sistema escrevendo código que tenha bom desempenho, mas que não seja legível por outros membros da equipe, como trabalhos que não foram documentados, compartilhados, criptografados, ofuscados ou publicados. Dessa forma, um componente crítico seria efetivamente perdido como consequência direta da ausência desse membro da equipe, tornando-o, portanto, fundamental. Ou seja, se esse componente fosse essencial para o avanço do projeto, o projeto ficaria paralisado.
Definição
[editar | editar código]O "fator ônibus" é o número mínimo de membros da equipe que precisariam desaparecer repentinamente de um projeto para que ele fosse paralisado.[5]
A expressão "ser atropelado por um ônibus" descreve uma pessoa que morre ou, de outra forma, desaparece repentinamente do projeto. É usado para descrever hipotéticos desaparecimentos futuros se utilizando de humor mórbido. Os membros da equipe não precisam literalmente ser atropelados por um ônibus para que o fator ônibus se aplique: inúmeros eventos podem ocorrer em que um membro da equipe pode ser repentina e substancialmente impedido de trabalhar no projeto, incluindo, mas não se limitando a abandono de emprego, licenças médicas, licenças parentais e mudança de estilo de vida.
História
[editar | editar código]Uma das primeiras citações a esse tipo de risco foi feita por Michael McLay quando perguntou publicamente, em 1994, o que aconteceria com a linguagem Python se Guido van Rossum fosse atropelado por um ônibus.[6]
Estudos realizados em 2015 e 2016 calcularam o fator ônibus de 133 projetos populares do GitHub. Os resultados mostram que a maioria dos sistemas tem um fator ônibus pequeno (65% têm fator ônibus ≤ 2) e que o valor é maior que 10 para menos de 10% dos sistemas.[7][8][9]
Melhorando o fator ônibus
[editar | editar código]Em muitos projetos de desenvolvimento de software, um dos objetivos é compartilhar informações para melhorar o fator ônibus, idealmente aumentando para o tamanho de toda a equipe. Um bom fator ônibus significa que muitos indivíduos sabem o suficiente para continuar e o projeto ainda pode ter sucesso mesmo em eventos muito adversos.
Diversas maneiras de melhorar o fator ônibus foram propostas:
Ver também
[editar | editar código]Referências
- ↑ Adler, Adler (4 de abril de 2023). «Reducing the Lottery Factor, for Data Teams». Locally Optimistic. Consultado em 7 de setembro de 2026. Cópia arquivada em 4 de abril de 2023
- ↑ Marques, João (15 de julho de 2024). «How to Avoid the Lottery Factor». DEV Community. Consultado em 7 de setembro de 2026. Cópia arquivada em 10 de dezembro de 2024
- ↑ Bowler, Michael (15 de maio de 2005). «Truck Factor». Agile Advice. Consultado em 7 de setembro de 2026. Arquivado do original em 29 de abril de 2021
- ↑ Bernard, Mercedes. «RubyConf 2021 - Minimize Your Circus Factor: Building resilient teams by Mercedes Bernard». devconf.net (em inglês). Consultado em 7 de setembro de 2026. Arquivado do original em 8 de outubro de 2024
- ↑ Jabrayilzade, Elgun; et al. (21 de maio de 2022). «Bus factor in practice». ACM (em inglês): 97–106. ISBN 978-1-4503-9226-6. doi:10.1145/3510457.3513082
- ↑ McLay, Michael. «If Guido was hit by a bus?» (Lista de grupo de correio)
- ↑ Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (10 de setembro de 2015). «What is the Truck Factor of popular GitHub applications? A first assessment.». PeerJ Preprints. doi:10.7287/peerj.preprints.1233v3. Consultado em 7 de setembro de 2026. Cópia arquivada em 8 de dezembro de 2015
- ↑ Avelino, Guilherme; Passos, Leonardo; Hora, Andre; Valente, Marco Tulio (2016). «A novel approach for estimating Truck Factors». 2016 IEEE 24th International Conference on Program Comprehension (ICPC). [S.l.: s.n.] pp. 1–10. Bibcode:2016arXiv160406766A. ISBN 978-1-5090-1428-6. arXiv:1604.06766v1
. doi:10.1109/ICPC.2016.7503718 - ↑ Cosentino, Valerio; Izquierdo, Javier Luis Canovas; Cabot, Jordi (março de 2015). «Assessing the bus factor of Git repositories». IEEE: 499–503. ISBN 978-1-4799-8469-5. doi:10.1109/SANER.2015.7081864
- 1 2 3 «Increasing your team's bus factor». 3 de setembro de 2008. Consultado em 7 de setembro de 2026. Cópia arquivada em 16 de abril de 2016
Leitura complementar
[editar | editar código]- Marchesi, Michele; et al. (2003). Extreme Programming Perspectives. Boston: Addison-Wesley. ISBN 0-201-77005-9
- Williams, Laurie; Kessler, Robert (2002). Pair Programming Illuminated. Boston: Addison-Wesley. ISBN 0-201-74576-3
- Kent Beck (2000). Extreme Programming. Das Manifest (em alemão). [S.l.]: Addison-Wesley. ISBN 3-8273-2139-5