Category Archives: mercado

Quanto testar?

Uma métrica que sempre tenho dificuldade de aferir é o retorno sobre o investimento no aumento da quantidade de testes do sistema.

Quando falo em testes aqui eu falo no conjunto de todos os tipos de testes, como: unitários, aceitação, integração, carga e demais necessários. A cobertura de testes é um investimento para redução de bugs na fórmula de ROI. Bugs são como “Back Order” na indústria e comércio, além de lucro perdido pela não-venda da mercadoria, ainda fragiliza a marca.

Um ponto crucial: EU ACREDITO EM COBERTURA DE 100%, mas não existe cobertura de 100%, então como podemos conviver com esse paradoxo?

Cobertura de 100% é uma meta ambiciosa de um mundo feliz onde não nos preocupamos com custos e escassez, ou seja, uma utopia. Utopia na vida real não é vendável, precisamos [mesmo a contragosto] medir os dados reais e encontrarmos um padrão aceitável.

Sabemos por consequência que testes aumentam a qualidade do software, eu não tenho tanto problema quanto antes em vender testes de software, mesmo a empresa que não tem testes automáticos, sabem da importância de se testar o software [mesmo que manual].

Meu problema atual é como conseguir vender o aumento da cobertura, mas antes disso eu mesmo preciso entender até quanto testar é suficiente para se pagar.

Power Law

Conversando dia desses na Fortes com o Clavius Tales sobre o seu post de mesmo preocupação, ele me explicava porque encontrou uma função logarítmica e eu tive o mesmo sentimento em dois pontos: que o aumento de testes por mais insignificativo que seja já provoca uma redução drástica de bugs e que ao passar do tempo você tem a impressão de que os testes já não trazem mais retorno, como vocês podem ver no grafico abaixo. Vou chamar esse ponto de “Ponto de Acomodação”.

Funcionalidades x Testes x Defeitos

Fonte da imagem: Blog do Clavius Tales.

Comentei com o Tales que concordo que a função seja mesmo logarítmica, mas que tenho a impressão que a curva é um pouco mais acentuada e o “Ponto de Acomodação Ideal” que deveria ser o “Ponto G” no mundo real é algo entre ele e o “Ponto B” e que devemos ir mais além. No gráfico do Tales ele mostra dois pontos de acomodação, o real no Ponto B [que é um engano e as empresas devem buscar sair dessa área] e o “ideal” no ponto G, aqui tratado.

Então temos dois fatores novos, a curva mais acentuada e o ponto de acomodação, que é o ponto onde as pessoas sentem que não adianta mais testar porque o inicio de testes já reduzem significativamente o número de bugs. Esse ponto de acomodação pode ser explicado por Pareto que é algo que funciona aproximado em quase tudo na vida, dizendo que 20% de alguma coisa geralmente representa 80% do todo.

Tenho ainda um terceiro sentimento provocado pela minha experiẽncia com testes, quanto mais testes nós fazemos, mais cedo detectamos bugs e sempre há pelo menos uma inconsistência que não tinhamos “pensado” antes. Pode até ser que seja finito a quantidade de testes necessários no sistema, mas esse número é muito grande e nunca consegui alcançar na prática, sempre há bugs.

Considerando esses fatores somados, podemos usar os cálculos do Power Law ou cauda longa para melhorarmos o gráfico original do Tales de forma mais aproximado da redução de bugs com o aumento constante de testes no sistema.

Fonte da imagem: Wikipedia

Considero que a meta de cobertura de 100%, mesmo sendo irreal, é algo a ser buscado sempre, forçando o time a se policiar e aumentar o número de testes constantemente mesmo após a acentuada queda de bugs [que chamei de “Ponto de Acomodação”] e que 100% de cobertura não quer dizer livre de bugs porque a cauda sempre vai ser um número aproximado mas nunca toca o zero na prática. Esse caso se aproxima da regra de 98%.

Considero também que dependendo da necessidade de software em produção um número aceitável de bugs a partir do “Ponto de Acomodação” não trás tanto retorno de investimento a curto prazo.

Vou começar a coletar informações de dois projetos atuais para verificar se a tendência desse gráfico satisfaz a realidade. Por enquanto preciso de mais informações para chegar a conclusões melhores.

Extreme Programming no Ceará

Em virtude da crescente adoção de metodologias ágeis no Ceará e a carência de informações sobre a situação real nas empresas assim como o mau conhecimento de profissionais sobre métodos e práticas, criei uma lista sobre XP, específica para o Ceará, afim de sanar essas principais dificuldades.

A lista tem menos de um mês e já conta com cerca de 120 membros e uma boa movimentação, por volta de 500 emails, se mantivermos essa média seremos uma das mais movimentadas do Brasil.

A idéia é fortalecer o XP, mas não em detrimento de outras metodologias ágeis, pelo contrário, teremos sempre o prazer em discutir e divulgar outras iniciativas.

Mas XP?

Sim, XP porque tenho um carinho especial e por considerar que é a metodologia mais madura no Ceará.

Segundo dados do artigo do João Barros [membro do grupo], XP aparece empatado com Scrum com 30% de adoção, mas as experiências públicas mais conhecidas e profissionais mais experientes são com XP. Destaque para a Fortes Informática e o Clavius Tales – confiram esse Podcast com ele.

Nada impede discussões sobre outra metodologias, lembrando somente que o foco é XP. Se criqrem outros grupos eu terei o prazer de participar também, só não tenho tempo para administrar e focar várias iniciativas e pessoalmente prefiro XP por motivos que ficarão para um post futuro.

É interessante observar no artigo do João que já há uma crescente adoção por parte das principais empresas do Ceará – ele listou 24 das mais conhecidas e importantes do estado. Todo trabalho de pesquisa é uma fotografia de um momento e nos fornecem estatísticas de avaliação, pode parecer alguns dados muito otimistas, mas precisamos ter uma base para trabalhar as ações e direcionar os esforços.

É impressionante como o XP sem divulgação e apelo de marketing conseguiu empatar com Scrum e com modelos mistos cada qual com 30%. Outro fato interessante é a baixa representação de outros modelos fora Scrum e XP.

Porque do Ceará?

O Anderson Fabiano fez uma pergunta pertinente no twitter:

@cmilfont me juntei ao grupo. perguntinha basica: qual o ponto de limitar o grupo geograficamente (ce) na era da internet?12:42 PM Feb 16th from web in reply to cmilfont

E ele mesmo deu uma boa definição:

@cmilfont saquei. +- o principio do craigslist (de 4 anos atras)… limitar para conquistar 🙂12:48 PM Feb 16th from web in reply to cmilfont

Tenho notado que grupos menores e com pessoas que se conhecem tem melhores discussões porque inibe mais flamewars e ataques pessoais devido ao conhecimento do “humor” nos emails de caras conhecidas.

Criar uma lista exclusiva e focada no estado ajuda a direcionar esforços, não só discussões. Um dos grandes objetivos da lista – grupo- é fortalecer a adoção de XP e para tanto organizaremos eventos e pesquisas nesse intuito.

Já dei início ao censo ágil de 2009 com um questionário para colher informações macros sobre adoção de metodologias ágeis, após essa primeira pesquisa entrerei mais a fundo em questões específicas. A idéia é realizar um censo a cada semestre.

Enfim, vale a pena a participação mesmo de quem não é do estado, as discussões estão “quentes” e boas.

Gerentes de projetos não são técnicos

Há uma grande confusão sobre o papel correto de um gerente de projetos, eu mesmo até pouco tempo exigia dos gerentes um papel diferente da sua real função dentro de uma empresa de desenvolvimento de softwares.

Teoricamente o PMI não criou uma metodologia para gerência de projetos de desenvolvimento de softwares, criou algo mais abstrato, que teoricamente deveria ser apropriado para quaisquer projetos. A cultura PMBOK aliado a cultura CMMi pode produzir algo profundamente pior se exigida como “metodologia para gerencia de projetos de software”.

Em discussão recente nas listas de discussões eu respondi o seguinte:

from CMilfont
to pbjug@googlegroups.com
date Wed, Sep 24, 2008 at 3:49 PM
subject Re: [PBJUG] Re: [MEIO-OT] – Referencia de leitura do mês sobre nossa realidade no NE
mailed-by gmail.com

hide details 3:49 PM (20 hours ago)

Reply

Um gerente de projeto não tem nada a ver com desenvolvimento de software. O papel dele no time é de observador. lado a lado com o cliente.
O papel de um gerente em um processo de desenvolvimento cabe a grosso modo acompanhar e providenciar ações para minimizar os riscos passados pelo líder técnico da equipe.
Como: providenciar mais recursos financeiros, contratar mais pessoas, gerenciar tempo do projeto, e principalmente cuidar para que o café não esteja mais ou menos frio, que é o que mais impacta no bom desenvolvimento de software.
Se é para ter um script, uma boa empresa deveria distribuir seus cargos onde o lider e os desenvolvedores devem ser os mais bem pagos, seguidos do gerente e do sobrinho do dono, acabar com cargos de programador e analista.
Em primeiro lugar na folha de pagamento a copeira que faz o capuccino perfeito e o boy que compra aquela coxinha + coca de 600 do outro lado da rua.

Sobre a brincadeira da coxinha, o que quero dizer é que dinheiro e evolução na carreira não passa em se tornar um gerente de projetos, papéis em uma equipe tem a ver com “skills” diferentes, não com salário ou evolução. Um líder técnico pode ganhar mais que um gerente de projetos.

Limitando-me apenas ao contexto desse post, o papel do gerente tem que ser o mais abstrato possível, sei que a realidade é diferente no nosso mercado, mas essa história de que o caminho natural de um bom desenvolvedor é evoluir para um gerente é errado.

Não necessariamente o gerente é o técnico mais experiente, são papéis distintos na equipe, ele não vai se preocupar com aspectos técnicos. Até a métrica não é feita por ele, a equipe que especifica, mas controlada e acompanhada. Com base nisso um gerente pode ser tranquilamente um não-técnico naquilo que gerencia desde que não assuma responsabilidades que interfiram no processo de desenvolvimento do software.

Claro que em ambientes burrocráticos onde o gerente não lide com auto-gerenciamento ou não saiba como trabalhar adequadamente, acaba involuntariamente em um processo monolítico e prolixo que por mais que se tenha boa vontade, nada de substancial consiga ser produzido.

Tive uma experiência traumática quando fui coordenador de projetos de uma “fábrica de software”, assumi o papel de coordenador/gerente quando na verdade era um líder técnico, todos os projetos evidentemente fracassaram, porque os projetos que conseguimos entregar foram projetos fora do prazo.

Riscos como falta de pessoal, recursos financeiros e de equipamentos foram orçados e medidos de forma errada porque estava assumindo skills técnicos como programar e arquiteturar em todos os projetos envolvidos, acabei não realizando uma coisa nem outra. Cheguei ao ponto de me auto-alocar no cliente desenvolvendo porque assumi os riscos de forma inapropriada.

Não assumo todos os deméritos pelo fracasso, mas com a experiência que tenho hoje eu deveria saber que ser gerente assumindo funções técnicas é prejudicial para a equipe.

Hoje não quero ser gerente de projetos, sou programador, gosto de ser técnico, sou mais feliz assim. Poderia ser um gerente de projetos hoje? Poderia e tenho mais experiência de quando eu fui, mas não quero.

Cada um tem que assumir os papéis dos quais tem melhor aptidão. Não necessariamente ganhar melhor.

Fazer o que sabe melhor e o que gosta é o caminho mais natural para ser feliz ou no mínimo não ferrar com a vida dos outros.