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

Recentemente, em um determinado projeto, tínhamos uma semana para disponibilizar uma versão e uma timeline definida por motivos externos que não poderíamos furar. O problema era que toda modificação gerava ainda mais medo por conta da baixa cobertura de testes, praticamente estavam codificando e corrigindo nessa altura do campeonato.

Eu radicalmente sugeri um grande refactoring para corrigir nossa bateria de testes, uma parada faltando apenas uma semana para entrega, mas só assim voltaríamos a trabalhar na entrega das features.

Nesse momento, o clássico “Não temos tempo para isso” surgiu das profundezas do inferno.

Fiquei sozinho nessa decisão, o time inteiro foi contra. Na defesa da solução apresentada eu falei: “Vocês podem se enganar imaginando que podem entregar essa release em uma semana com a qualidade do código existente que vocês sabem que vai de mal a pior ou podem trabalhar para corrigir esses problemas e entregar o possível, mas funcionando”.

Sabemos da importância de testes, todas as metodologias os cobra obrigatoriamente, então se você não testa, você está errado em todas as metodologias. O problema sempre é a desculpa da timeline e quanto mais vai se aproximando mais desculpas procuramos encontrar para esconder as deficiências. Como nesse caso não tínhamos Test First, os problemas vão se empilhando no final e se tornam mais difíceis de serem detectados.

Por sorte, minha sugestão acabou sendo acatada, apesar de ser apenas um consultor no projeto, portanto uma galinha e não porco.

De onde nascem essas desculpas?

Coragem é um dos valores do XP, é importante enfrentarmos esse tipo de situação que descrevi, na vida real isso quase nunca é possível porque essas arquiteturas flácidas ou códigos mal cheirosos não nascem do dia para o outro e vão se acumulando.

O projeto que descrevi era um projeto novo, tecnologias fresquinhas e um time modernoso. Imagina agora se você está em uma corporação que usa um processo cascata, todo amarrado, criando documentos UML desnecessários no EA, struts 1 como framework, CVS como controle de versão do código [quando há! Sim, em pleno 2010 ainda há quem não use nenhum], o código de banco de dados cheio de procedures e tantas modernidades da década de 80.

Então, acha que só coragem basta?

Em muitas oportunidades o custo de mudanças ou simplesmente “fazer o que se tem que fazer” não se pagará nem a médio prazo, nessas horas convencer já não basta. É muito difícil você convencer a alta direção que deve jogar fora um determinado projeto e começar do zero, ou modificar toda a infraestrutura existente.

A degradação de um software nasce de pequenos problemas que se acumulam, no final há tanto para se fazer que ninguém mais tem coragem para isso.

Socorro, Milfont!

Recebo constantemente pedido de socorro de pessoas que me conhecem das comunidades que participo como XPCE, GURU-CE, JAVA-CE, entre outras. Geralmente são funcionários que se encontram nessa situação que citei anteriormente, com projetos muito defasados e problemáticos.  O pedido é sempre o mesmo, querem que eu vá lá dizer para a alta direção o que eles [funcionários] já sabem. Só que isso não basta, o movimento tem que começar por lá.

Em reunião com a turma da TriadWorks, temos discutido isso já há muito tempo e acabamos preparando um serviço de resgate aos clientes para contornar esse problema. A proposta é envolver as pessoas desses clientes, dar coragem e ânimo nelas para começarem a resolver o problema.

Resolvemos começar com nossos próprios clientes, sim, dá preferência a quem tem contrato conosco e depois verificar como abrir para a comunidade.

Então, esse envolvimento nós demos o codinome de “AvoidNotEnoughTime” e consiste basicamente em um conjunto de ações/eventos  com os funcionários dessas empresas para dar essa força necessária para anular o NotEnoughTime na base. É um movimento de baixo pra cima, roots, serão desde Coding Dojos, Code Retreat, Code Jam, Hack Days, Lightning Talks, Open Space ou um formato adequado a um determinado problema que identificarmos.

Nós não vamos cobrar a mais dos clientes por isso, aliás, eles nem foram avisados e não terão controle sobre o projeto, nós que decidimos quando, como e com quem faremos justamente para evitar sabotagem ou direcionamento.

Sem planejamento nem nada, resolvemos iniciar mesmo assim, domingo passado [27/06/2010] realizamos um Git Session onde eu [@cmilfont], @triadworks representada por @handersonbf, @rponte e @carlosatilabreu, recebemos funcionários de clientes nossos. @jeffersongirao da TubForm, @rodrigogalba da Casa Magalhães e @rodrigodealer da Fortes Informática.

O que vocês ganham com isso?

Resolvemos fazer um Git Hack Session devido alguns de nossos clientes usarem CVS e SVN. O tempo perdido resolvendo problemas de repositório como merges e bobagens simples causam um prejuízo enorme, as desculpas para mudarem cai sempre no “não temos suficiente” ou “depois fazemos quando terminar esse projeto”.

Então cada ponto de dificuldade que um time enfrenta e observarmos que se repete nos demais clientes, vamos organizar ações para envolver essa turma afim de anular essas desculpas. Treinar multiplicadores em todos os princípios.

No caso do Jefferson Girão, que trabalha também para a Hoodiny, veio mais para nos auxiliar, já que está mestre no uso do git no meu cliente Tubform [uma das maiores indústrias do Nordeste].

Dessa forma nosso trabalho de consultoria será facilitado e no mínimo já faríamos esses eventos internamente, então unimos o útil ao agradável.

Se você gostaria de participar de algum desses eventos mesmo não sendo funcionário de cliente nosso, mande um email para mim [cmilfont@gmail.com] e tentaremos incluir sempre quando puder. Domingo agora surgiu um desfalque, até twittei convocando alguém que estivesse disponível, mas foi em cima da hora.

É com satisfação que vejo o trabalho da Milfont Consulting participando diretamente na transparência da saúde pública no estado do Ceará.

O governo do estado inaugurou essa semana “A Conta do Paciente“, um projeto inédito no Brasil que vai informar ao paciente quanto foi sua despesa desde a entrada no hospital até sua alta. Esse tipo de atuação aproxima o governo da agilidade que a sociedade cobra em relação à transparência nas contas públicas, antes era quase impossível saber o custo real por paciente. Fora que a secretaria vai saber precisamente e em tempo real os custos por unidade, além de facilitar a tomada de decisões que podem salvar vidas.

Esse formulário detalhado com a conta do paciente é possível graças ao ERP especialista em gestão hospitalar pública da empresa Insystem, nosso cliente e parceiro. A Insytem acreditou em nosso trabalho e é um dos maiores Cases, senão o melhor.

O ERP foi construído 100% com base em TDD em Java usando DWR, Hibernate e  Spring basicamente. Alguns requisitos necessários de usabilidade utilizam Reverse Ajax com DWR. O sistema é totalmente ajax e utiliza o Extjs seguindo a filosofia model 3. Fizemos algumas customizações no Extjs para se integrar ao DWR de forma transparente.

Fomos ágeis desde o primeiro momento, mas nunca nos preocupamos em implantação de processo, metodologia ou qualquer coisa que o foco não fosse software saudável. XP foi algo natural, valores e princípios foram assimilados desde o primeiro dia, mas foi e é o software funcionando e livre de erros [o mais livre possível] que nos moveu.

Destaque para o Felipe Andrade, funcionário da Insystem que se tornou especialista em Extjs com DWR e hoje domina e é talvez o maior conhecedor da união desses Frameworks no estado.

Agradecimentos especiais aos diretores Evando Chaves e Marcelo Meirelles que investiram nessa solução e tiveram a sagacidade de sair na frente da concorrência entendendo que software funcionando é mais importante do que processos bonitos e pomposos, afinal o barco não chega na frente por causa do tambor e sim dos remadores. A Insystem está de parabéns por ter enfrentado todas as correntes contrárias e ter chegado a essa vitória investindo e apostando no fator humano como responsável para a vitória.

Esse é um Case que entrou para a história, estamos procurando outra solução semelhante na saúde pública do Brasil e até agora não encontramos nada.

Orgulhoso por participar dessa conquista.

Projeto de exemplo com Cucumber, Selenium e Rails http://github.com/cmilfont/bddonrails

Para executar o exemplo deve se lembrar de ter o java instalado [de preferência o da SUN] por dependência do Selenium. Execute os comandos abaixo para baixar e rodar a aplicação:

git clone git@github.com:cmilfont/bddonrails.git
cd bddonrails/
sudo rake gems:install RAILS_ENV=test
#lembre de trocar a senha do root no mysql ou mudar o banco
rake db:create:all
rake db:migrate
rake cucumber:ok

Processos de desenvolvimento de software são quase todos iguais em termos de práticas e todos podem assumir práticas novas de outros processos, até cascata pode aplicar qualquer prática de XP e Scrum em seu modelo naturalmente.

O que diferencia esses processos não são as práticas, são os valores. O problema é que entender, compreender e adotar valores é algo subjetivo que varia de pessoa para pessoa por mais que se tenha princípios bem definidos que conectem as práticas a esses valores.

Diante disso, nenhum processo garante que seu projeto será um sucesso por estar o seguindo, mesmo que seja “By The Book”.

Há uma preocupação com o chamado Scrumbut, mas eu já vejo e vi projetos Scrum que não são Scrumbut e mesmo assim o software produzido, por mais ágil que seja, não tem qualidade e no primeiro refactoring você já entra no prejuízo similar a um software desenvolvido em Cascata.

Fato é que esses valores e princípios não garantem software com código coeso, desacoplado, limpo, claro e facilmente lido, ou seja, com qualidade interna.

Hoje minha preocupação em todos os projetos é a qualidade interna do software, não importa que metodologia seja adotada. Qualidade interna garante que o software tem boa saúde e é fácil de ser medida.

Saúde do software é o quão rápido e efetivo ele se recupera de mudanças e o quão limpo ele está de defeitos. Para se recuperar de mudanças o software precisa ser limpo e claro, ser facilmente entendível e lido.

Livre de defeitos é ter uma cobertura de testes que explorem e machuquem o código até descobrir falhas que passam despercebidas.

A grande maioria dos processos se preocupa mais com a qualidade externa do que a interna. Não importa se você faz reuniões em pé, tenha o cliente presente ou faça Scrumban ou até mesmo que você esteja entregando software rápido, nada disso vai garantir qualidade e que não vá ter prejuízo no futuro.

Vender qualidade externa tem um apelo comercial fácil porque você não precisa comprovar a qualidade do software e sim do processo, o discurso é sempre mais elegante do que falar em código, principalmente para alta gerência e burocratas, tanto é que todos os modelos de qualidade reconhecidos avaliam o processo e não o produto.

CMMi, ISO ou seja lá que for, não garantem que o produto será de qualidade e sim que o processo seja e se pararmos para pensar um momento, o processo realmente é de qualidade, temos um conjunto de métodos eficazes para produzir… processo e não produto.

Um exemplo de qualidade interna de um software são os testes automáticos em suas diversas nuances como unitários, aceitação, integração e funcional, mas não apenas isso, métricas de coesão, cobertura, LOC, complexidade e tantas outras.

No Maré de Agilidade eu fiz questão de enfatizar:

“Não importa que processo você siga, se é ágil ou não, se você não faz testes de Software vocês está errado em todos.”

Não existe um software sem bateria de testes automáticos com qualidade, isso é lenda. Em mais de 10 anos de profissão o que tenho notado é que a grande maioria, senão todos, são fortemente acoplados e de baixa coesão como consequência da falta de testes. Aplicar testes nesses softwares é uma tarefa quase impossível e proibitiva em relação a custos, sai mais barato fazer um software novo.

Outra coisa que falei no Maré de Agilidade foi:

“Não seja ágil, seja o melhor possível, porque ao procurar ser o melhor você invariavelmente vai se deparar com práticas que o tornam melhor e aí você se tornará ágil”.

Assim como o lema da Rossi: “Armas não matam pessoas, pessoas matam pessoas” podemos induzir que: Processos não desenvolvem software, pessoas desenvolvem software!

Ao trabalhar com pessoas, precisamos entender que modelos de negócios como software são de terceira onda [Alvin Toffler aqui] e não da segunda onda [industrialismo]. Qualquer analogia com modelos de segunda onda provocará insuficiência no trabalho dessas pessoas [por isso Lean faz tanto sucesso hoje] e elas precisam estarem motivadas para produzir qualidade interna, coisa que o trabalho sobre qualidade externa não produz.

Esse tema sobre pessoas e processos [como homem/hora] será escrito em outro artigo.

Resumo desse artigo é: Pessoas são responsáveis por produzirem qualidade interna ao produto e não processo, invista nelas.

Ainda na ressaca do Maré de Agilidade – Fortaleza, vou indexar toda a cobertura nesse post, se você conhece mais conteúdo sobre o evento, por favor me avise.

Fotos

http://picasaweb.google.com.br/lucianobeserra/CursoCaelum
http://picasaweb.google.com.br/cmilfont/CursoCaelumRR11
http://picasaweb.google.com.br/handersonbf/MareDeAgilidade
http://picasaweb.google.com/maredeagilidade/SwellFortalezaMinicursos
http://picasaweb.google.com/maredeagilidade/SwellFortalezaPalestras
http://picasaweb.google.com/maredeagilidade/SwellFortalezaConfraternizacoes
http://www.manoelpimentel.com/fotos_eventos/72157622015680086/1

Twitter

http://twitter.com/#search?q=maredeagilidade

Posts

http://agiletips.blogspot.com/2009/09/big-agile-wave-in-brazil.html
http://pauloigor.blogspot.com/2009/08/mare-de-agilidade-em-fortaleza.html
http://www.natanaelpantoja.com/tech/?p=299
http://felipebviana.wordpress.com/2009/08/10/mare-de-agilidade-fortaleza/
http://ialis.wordpress.com/2009/08/09/mais-agilidade-por-aqui/
http://www.handersonfrota.com.br/triadworks-no-mare-de-agilidade/
http://www.milfont.org/tech/2009/08/05/mare-de-agilidade/
http://henriquegogo.wordpress.com/2009/08/04/mare-de-agilidade-em-fortaleza/
http://www.cearaonrails.org/2009/07/29/esta-querendo-ir-ao-mare-de-agilidade-que-tal-concorrer-a-algumas-cortesias/
http://blog.seatecnologia.com.br/2009/07/20/mare-de-agilidade-e-oxente-rails
http://iviablog.blogspot.com/2009/07/fortaleza-e-palco-para-o-evento-mare-de.html
http://www.igocoelho.com.br/2009/07/14/promocao-para-o-mare-de-agilidade/
http://www.fa7.edu.br/ypiranga/noticia/noticia.php?id=848
http://www.fernandoquadro.com.br/html/2009/07/13/evento-mare-de-agilidade-2009/
http://www.eventosdeti.com.br/2009/07/mare-de-agilidade-fortaleza/
http://www.cejug.org/pages/viewpage.action?pageId=40632324
http://leonardoeloy.com/2009/05/13/mare-de-agilidade-fortaleza/

Slides

http://www.slideshare.net/seatecnologia/manifesto-20
http://www.slideshare.net/seatecnologia/minicurso-ruby-e-rails
http://www.slideshare.net/seatecnologia/minicurso-de-testesonrails
http://www.slideshare.net/fabiokung/onde-mora-a-produtividade-do-ruby-on-rails
http://www.slideshare.net/manoelp/gesto-lean-para-o-desenvolvimento-de-softwaremanoel-pimentel-verso-30
http://www.slideshare.net/cmilfont/mare-de-agilidade-bdd-e-tdd
http://www.slideshare.net/brunopedroso/curso-xp

Videos

http://www.youtube.com/watch?v=IG7QzUjl5TM

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.