Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Economizando com Programação em Par
Postado por Mike Bria , traduzido por Hildebrando Furlan Neto em 02 Jul 2009
"Porque alguém utilizaria duas pessoas para fazer o trabalho de uma? " Esta é uma reação comum quando as pessoas são apresentadas a ideia da programação em par. Na essência, eles concluem programação em par como duplicar o custo de escrever um segmento de código. Dave Nicollete demonstra algumas ideias quantitativas para ajudar a mostrar como a programação em par pode salvar dinheiro, ao invés de desperdiça-lo.
A questão econômica da programação em par é confundida como um resultado de uma percepção equivocada de que programação é, em sua maioria, digitação. Na realidade, na sua maioria, é sobre pensar e, como resultado, provê infinitas oportunidades para tomar decisões erradas e criar erros - erros que irão no fim custar aos desenvolvedores (e no caso a organização) tempo no futuro.
É aqui aonde a proposta econômica da programação em par esta fundamentada, e também porque é tão difícil de quantificar. Como Dave Nicolette resumiu em um artigo recente:
Primeiramente, o valor dos pares vêm na forma de pequenas correções de curso que previnem a ocorrência de erros. Estas correções têm um escopo tão pequeno e ocorrem tão naturalmente dentro do fluxo de trabalho do par que elas não chegam nem a serem notadas. O valor acaba passando despercebido por que o efeito do par é o de justamente prever situações que podem causar trabalho extra em algum trabalho futuro. Não é muito fácil observar ou quantificar estes efeitos depois do fato, por que os erros não acontecerão mais.
Assim, o valor dos pares vem na forma de economia de tempo que seria despendido no futuro e, como todos sabem, "Tempo é dinheiro". Mas, quanto de dinheiro? Neste mesmo artigo, Dave apresenta de forma resumida algumas ideias para responder esta pergunta.
Durante uma recente sessão de programação em par, Dave foi registrando a frequência que um par ajudava o outro indicando enganos, bem como as discussões sobre assuntos relacionados com design que foram ocorrendo. Em seguida eles decidiram o quanto de tempo futuro cada uma dessas coisas economizou, assim com essa informação foram fazer mais alguns cálculos.
Em um de seus mais recentes livros, Alistar Cockburn computou que o custo de um profissional de TI gira em torno de US$2.10 por minuto... Na nossa sessão de programação em par, nós tivemos duas mini-discussões sobre design que levaram a pequenos refatoramentos. De acordo com nosso calculo, foram economizadas quatro horas de esforço de manutenção futuro. Isto vale algo como 2.1 x 120 = $252.00. Tivemos 12 momentos em que um de nós notou um pequeno equivoco. Se estas ocorrências economizaram uma média de 30 segundos de esforço de depuração, então custou 0.5 x 2.1 x 12 = $12.60. No Total, nós economizamos para a companhia $274.60 em 90 minutos ou, dividindo em horas, em torno de $180.00 por hora.
A empresa tem um pequeno departamento de TI com um total de aproximadamente 40 desenvolvedores trabalhando em diversos times XP. Se nós assumimos que as sessões de par ocorrem 5 horas por dia, então serão 20 pares x 5 horas x 5 dias por semana = 500 horas de programação em par por semana. Assumindo que foram economizados $180.00 por hora por par, isso faz com a média de economia seja de $90.000,00 por semana. Se esta taxa de trabalho for mais ou menos constante durante o ano, e os times trabalharem 50 semana por ano (este exemplo é de uma fabrica americana, em que as férias são curtas), a empresa vai desfrutar de uma economia de $4.5milhoes por ano, especificamente porque a prática da programação em par é a padrão dos times de desenvolvimento.
$4.5 milhões para esta empresa de apenas 40 desenvolvedores. Mas Dave admite, que estes são apenas cálculos não precisos derivados de uma simples sessão de programação em par, assim não tem nada de científico, no entanto não tem porque não ser levado em consideração.
O que você acha?
Nenhum comentário
Acompanhar Discussão Responder