Palestra Agilidade no Mundo Real

{ July 11th, 2010 }

Autor: cmilfont

Ontem eu palestrei na faculdade IDEZ em João Pessoa – PB a convite do Dr. Rodrigo Rebouças – Coordenador e professor de pós graduação em dev de software -  sobre o tema “Agilidade no Mundo Real”, que consistiu basicamente em falar sobre minha experiência em implantação, mentoring e treinamento de agilidade em meus clientes nos últimos 2 anos.

Maurício Linhares também é professor da IDEZ, o que me deixa particularmente feliz em saber que tem gente capaz dentro da academia que pode fazer diferença. Esse contato entre mercado e academia é importante para todos e creio que os alunos ontem tiveram muito dever de casa para fazer.

Ontem anotei muitas dúvidas discutidas na mesa redonda que fizemos após as palestras e nos próximos dias eu postarei sobre as principais dificuldades em entender o que é agilidade, que TDD não evita equipe de Testes ou QA e nem sequer tem a ver com cobertura de código, que agilidade não é velocidade, inclusive pode ser mais lento em determinados períodos, confusão entre práticas, valores e princípios, entre outras coisas.

Sobre minha palestra eu falei sobre as dificuldades que encontro, como melhorar a adoção dos valores e princípios trabalhando a base. Vocês podem acompanhar nos slides e video abaixo:

Vídeo do Evento

Referências sobre os slides de minha palestra

O que é agilidade?
http://manifestoagil.com.br/
http://www.milfont.org/tech/extreme-programming-books/

Scripts do workflow GIT sobre os slides do “Merge From Hell”
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
http://reinh.com/blog/2008/08/27/hack-and-and-ship.html
http://gist.github.com/8511

Trabalho energizado
Pair Programming
http://www.milfont.org/tech/2010/06/17/trabalho-energizado-e-a-teoria-das-2-horas-produtivas/
http://www.milfont.org/tech/2009/02/03/pair-programming-vs-code-review/

Automação Total
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html
http://blog.caelum.com.br/2010/03/01/o-processo-de-deploy-continuo/
http://agilenomundoreal.com.br/2010/07/06/deploy-continuo-entrega-continua-de-valor/

http://railscasts.com/episodes/179-seed-data

Testes
http://www.milfont.org/tech/2009/06/01/recomendacao-sobre-tdd/
http://www.milfont.org/tech/2009/06/07/quanto-testar/

Sem tempo suficiente
http://www.milfont.org/tech/2010/06/29/sem-tempo-suficiente/

Dar caos a ordem

Destruir arquiteturas de referências

http://www.milfont.org/tech/2010/01/21/voce-esta-nivelando-por-baixo-eou-nao-conhece-seus-desenvolvedores/

http://www.milfont.org/tech/2008/01/20/frameworkstools-caseiros-ou-fechados/
http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/
http://www.milfont.org/tech/2008/01/21/nao-use-notacao-estranha/

Separar gerenciamento de projetos do processo de desenvolvimento
Pmbok de Jeans
http://www.milfont.org/tech/2009/03/14/pmbok-de-jeans/

Software Funcionando
http://www.milfont.org/tech/2009/09/17/qualidade-interna-vs-qualidade-externa/

Retrabalho e Prejuízo
http://www.milfont.org/tech/2009/01/08/retrabalho-e-prejuizo/

Workflow ágil e simples
http://www.pivotaltracker.com
http://github.com/tpope/pickler
http://github.com/trydionel/git-pivotal
http://www.pivotaltracker.com/help/api?version=v3#scm_post_commit

Jesus recomendando o trabalho em par
“E depois disto designou o Senhor ainda outros setenta, e mandou-os adiante da sua face, de dois em dois, a todas as cidades e lugares aonde ele havia de ir.”
Lucas 10:1

Posted in Engenharia de Software, Melhores práticas, Metodologia, Métodos Ágeis, Test Driven, XP, palestras ~ 2 Comments

Defesa Tardia do RUP

{ March 8th, 2010 }

Autor: cmilfont

Eu ia escrever um post gigantesco sobre o porquê do RUP ter morrido mas vou tentar ir direto pro cerne da questão. Ultimamente eu vejo muita gente dizer que RUP não deu certo por culpa humana e que só existem 3 caras no Brasil inteiro que entendem como a mágina do RUP funciona, entre outros argumentos desse estilo.

É muito fácil defender RUP hoje em dia depois de toda evolução do mercado [que diga-se de passagem o RUP só ajudou sendo a antítese do caminho correto], duvido que esses 3 únicos caras que supostamente conhecem a pedra filosofal do RUP fizessem o que fazem [ou devem fazer] hoje antes desses últimos 15 anos de discussão e experimento ágil.

É difícil imaginar que Kent Beck, Martin Fowler e tantos outros que começaram a propagar o agilismo após o manifesto ágil não conhececem RUP a ponto de,  como os defensores atuais do RUP afirmam: “renomearam práticas antigas com nomes novos”.

Meus caros, práticas não são o coração do agilismo, são os valores e princípios. RUP sempre valorizou os itens à direita em detrimento aos itens à esquerda no manifesto ágil, então não me venham com essa de que seguir o plano nunca foi prioritário do RUP. RUP é uma metodologia que não deu certo porque foi uma tentativa de taylorizar o desenvolvimento de software.

ps. Notaram que não linkei nada? Preguiça de responder esse tipo de coisa.

Posted in Engenharia de Software, Metodologia, Métodos Ágeis, Scrum, XP ~ 4 Comments

Quanto testar?

{ June 7th, 2009 }

Autor: cmilfont

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”.

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.

Posted in Engenharia de Software, Metodologia, Métodos Ágeis, Test Driven, mercado, teste, xpce ~ 7 Comments