Amanhã, 11/04/2011, palestrarei no evento “8.ª Jornada CETI – Cursos de Extensão em Tecnologia da Informação” na FA7, sede do BrazilJS.

Titulo: Test Driven Development com Javascript
Resumo Original:  Entenderemos que só TDD é o caminho e a luz da escrita de um bom software, será demonstrado como até em plataformas difíceis se pode praticar essa metodologia, admitir que testes em TDD é apenas um benefício e não a causa, além de códigos e mais códigos.

Ah, será duas vezes:

Manhã

Data: 11/04/2010, segunda-feira
Horário: 07h30
Local: Auditório do Curso de Direito

Noite

Data: 11/04/2010, segunda-feira
Horário: 19h
Local: Auditório do Curso de Direito

Palestra sobre TDD na comunidade Dotnet amanhã, qual linguagem eu devo demonstrar TDD?

Vamos lá, inscreva-se:

Maré de Agilidade em Salvador desse ano está imperdível, grandes nomes da agilidade braziliana estarão lá em 3 dias de eventos com cursos e palestras. Não perca tempo, inscreva-se já.

Milfont Consulting estará presente apoiando o evento com a palestra “Oxente, os cabras rão entender BDD e rebolar no mato código réi” e o curso “Desenvolvimento/Web Standards com Sencha Javascript Frameworks“.

O curso será basicamente um subset do mesmo curso que já ministro pela Milfont Consulting só que reformulado para o novo empreendimento, a Milfont Universitas, ainda a ser lançado.

A palestra será um esforço para resumir em uma hora o que se precisa entender sobre Test First e sua prática moderna como BDD, entender que BDD é uma evolução de TDD e não o sinonimo de ATDD, entre outras coisas.

Abaixo a programação chupada do site do maré:

Patrocínio Ouro

Organização

Apoio

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

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.

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

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.

Estamos preparando o 3º encontro da comunidade e já confirmamos a primeira palestra com um dos maiores especialistas em testes do Ceará, confiram abaixo:

Palestra: Automação de Testes Funcionais de Software com Selenium

Resumo: Serão discutidos conceitos e fundamentos de automação de testes funcionais e depois será apresentada a ferramenta multiplataforma para automação de testes de sistemas web Selenium. Serão mostradas as características da ferramenta e o passo a passo para sua instalação, gravação e execução de suites de testes. Por fim serão discutidas boas práticas de automação de testes de software e de uso da ferramenta.

Palestrante: Fabrício Dias Alves Lemos

Bacharel em Ciência da Computação pela Universidade Federal do Ceará possui seis anos de experiência em desenvolvimento de software, cinco dos quais aplicando técnicas de automação de testes para sistemas do governo federal e estadual. Atualmente atua como analista de tecnologia da Secretaria da Fazenda do Ceará e mantem o blog http://www.fabriciolemos.org/blog/

Informações sobre o evento:

Título: 3º Encontro XPCE – Comunidade eXtreme Programming do Ceará

Local: Faculdade FA7

Data: 24 de Outubro

Agenda

1. 08:30 as 09:30 – Palestra em processo de definição
2. 09:30 as 10:00 – Intervalo
3. 10:00 as 11:00 – Automação de Testes Funcionais de Software com Selenium – Fabrício Lemos

Fonte: XPCE.org ]]> http://www.milfont.org/tech/2009/09/13/3-encontro-xpce-1-palestra-confirmada/feed/ 2 http://www.milfont.org/tech/2009/08/12/cobertura-do-mare-de-agilidade/ http://www.milfont.org/tech/2009/08/12/cobertura-do-mare-de-agilidade/#comments Thu, 13 Aug 2009 01:27:01 +0000 cmilfont http://www.milfont.org/tech/?p=737 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