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

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.

Ontem começou o Maré de Agilidade com o curso RR11 de Ruby on Rails da Caelum com o Fábio Kung, que não precisa de apresentações [se você não sabe quem é Fábio Kung então mude de profissão].

Como o Kung está indo integrar o time da Locaweb, [apesar de continuar como instrutor na Caelum] essa é a última oportunidade de tê-lo conosco para ministrar esse curso, a turma foi agraciada com a sorte.

Na quinta e na sexta acontecerão os minicursos oficiais do Maré de Agilidade com o Manoel Pimentel da Visão Ágil e a turma da empresa SEA Tecnologia [ Renato Willi, Bruno Pedroso e Alexandre Gomes], ambos organizadores do evento.

No sábado acontecerão as palestras com todos que ministraram/rão cursos além de Clavius Tales, Fabiano Milani da Adaptworks e um tal de Christiano Milfont.

Todos os minicursos estão com vagas esgotadas, se você quiser ainda participar do Maré de Agilidade, corra para a inscrição das palestras enquanto há tempo.

Para finalizar o Maré, a Adaptworks promove o curso “Planejamento e estimativas em projetos ágeis”, através do telefone (11)5585-7738 ou pelo e-mail contato@adaptworks.com.br na sede do CGDT.

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.

“Vejo que estou fazendo a coisa certa quando vejo meu saldo bancário!”

Frase dita por um palestrante em um evento recente no ano de 2009.

Palestra realizada no evento do grupo XPCE em 28/03/2009.

Palestra realizada no evento do grupo XPCE em 28/03/2009.

Devido a problemas de saúde do palestrante Igo Coelho, sua palestra foi cancelada e vai ser realizar no próximo evento provavelmente. A programação continua apenas com uma palestra:

09:00 – 10:20

Palestra: Começando a usar BDD e TDD
Resumo: Se você nunca entendeu como é que se escreve testes antes do código ou ainda não conseguiu uma forma satisfatória de seguir essa prática, aproveite essa oportunidade onde dissecaremos Test Driven Development até convencê-lo de que essa é a abordagem profissional adequada, além disso facilitaremos a compreensão em um nível mais abstrato com Behaviour Driven Development agilizando o mergulho de cabeça nessa forma de modelar código saudável e eficiente.
Palestrante: Christiano Milfont, coordenador do grupo XPCE e um cara que gosta de programar.

Local: Fortes Informática.

Endereço: Rua Antônio Fortes, 330, Bairro Edson Queiroz, próximo ao antigo Hiper Mercantil da Washington Soares. Localização com o Google Maps.

Data: Dia 28/03/2009 [sábado] das 09:00h as 12:00h na sala de treinamentos 1.

XPCE - Grupo de Extreme Programming do Ceará.

[http://groups.google.com.br/group/xpce]

Primeiro encontro XPCE

XPCE - Grupo de Extreme Programming do Ceará.

[http://groups.google.com.br/group/xpce]

Local: Fortes Informática.

Endereço: Rua Antônio Fortes, 330, Bairro Edson Queiroz, próximo ao antigo Hiper Mercantil da Washington Soares. Localização com o Google Maps.

Data: Dia 28/03/2009 [sábado] das 09:00h as 12:00h na sala de treinamentos 1.

Palestras

09:00 – 10:20

Palestra: Começando a usar BDD e TDD
Resumo: Se você nunca entendeu como é que se escreve testes antes do código ou ainda não conseguiu uma forma satisfatória de seguir essa prática, aproveite essa oportunidade onde dissecaremos Test Driven Development até convencê-lo de que essa é a abordagem profissional adequada, além disso facilitaremos a compreensão em um nível mais abstrato com Behaviour Driven Development agilizando o mergulho de cabeça nessa forma de modelar código saudável e eficiente.
Palestrante: Christiano Milfont, coordenador do grupo XPCE e um cara que gosta de programar.

10:40 – 12:00

Palestra: Integração Contínua
Resumo: Descubra o que projetos ágeis fazem para possibilitar que diversos desenvolvedores trabalhem juntos em um mesmo projeto, integrando suas contribuições de forma harmônica e segura.
Palestrante: Igo Coelho, fanático por desenvolvimento de software, novas tecnologias, internet, eletrônicos e tudo mais que um geek pode gostar. Com mais de 9 anos de experiência em desenvolvimento de Software trabalha atualmente na Fortes Informática como arquiteto de software com XP e Java. Casado, pai de dois filhos e mantem um blog em www.igocoelho.com.br.

Sorteio de livros e revistas.

Quando cunhei esse termo por volta de 2 anos atrás, o fiz pelo fato de ter observado a migração serelepe dos defensores do modelo “PMBOK de ser” para Scrum.

Um grande problema na compreensão sobre Scrum é justamente achar que ele serve para gerenciar projetos, dessa forma para ser confundido com um PMBOK ágil é um passo. Gerência de projetos é um campo distinto da direção do desenvolvimento de software e não vou tratar ou especificar nesse artigo porque já rascunhei em artigo passado.

Scrum é um modelo de desenvolvimento de software. A Scrum Alliance que é uma espécie de “organismo” que rege a maturação do Scrum, não o definiu como Project Management, mas como:

“Scrum is an agile software development framework.“

Scrum é similar ao XP ou FDD, guia a equipe com um modelo baseado em práticas para um melhor desenvolvimento de software. Como esse pessoal – que muitas vezes nunca foram técnicos – encontra em Scrum práticas fortemente ligadas ao controle das iterações, transmuta toda a cultura burocrática adquirida em metodologias de gerência de projetos e confunde atividades – como avaliação de riscos e aquisição e controle de recursos – com as necessidades do time jogando fora o que os incomoda – como práticas necessárias ao desenvolvimento – e ficando apenas com o que sentem confortáveis.

Quando James Shore escreveu seu famoso artigo “The Decline and Fall of Agile” ele definiu isso muito bem fazendo analogia que estavam correndo para a sobremesa mas jogando fora os vegetais. Martin Fowler em seu artigo Flaccid Scrum [Akita traduziu e comentou], escreveu ter notado que o problema técnico acontece mais com Scrum devido a não prescrição [omite] de práticas técnicas e ser centrado em técnicas de “gerenciamento de projetos”, ou seja, o problema é de qualidade técnica interna.

Hoje todo mundo se diz Scrum Master, todos entendem e usam Scrum e mesmo assim já estamos vendo projetos com Scrum caírem no mesmo erro e problema de modelos anteriores. Como disse o Martin Fowler em seu artigo: “Esses projetos de Scrum flácido em andamento prejudicarão a reputação não somente do Scrum mas de todo Agile”.

Scrum é uma metodologia maravilhosa que tem muito a engrandecer o XP e as outras metodologias, mas usando um Scrum transviado de PMBOK é um caminho natural ao fracasso retumbante.

Solução?

Eu poderia escrever dezenas de linhas aqui com conselhos e bla-bla-blas mas vou ser direto e lacônico: XP.