Ano passado eu escrevi sobre minha teoria de produtividade nas empresas de software e a incluí em algumas palestras, inclusive é também um tópico da minha palestra recém aprovada no AgileBrazil 2011: Dar Caos à Ordem.

Essa minha teoria é puramente empírica, não fiz nenhum estudo com rigor acadêmico sobre isso. Eis que vejo uma pesquisa na Época Negócios dando razão a minha teoria. Só que a matéria fala em meio expediente, eu sustento que por volta de 60 a 70% do tempo é desperdiçado com trabalho repetitivo e desnecessário que pode/deve ser automatizado.

Algumas empresas sentem essa má produtividade, mas culpam o cafezinho, quando na realidade a hora do cafezinho responde por grandes momentos de discussões necessárias.

O objetivo dessa palestra foi desmistificar um pouco o entendimento sobre Domain Driven Design. O foco foi demonstrar que essa abordagem não é sobre padrões, como bem me aconselhou o Rodrigo Yoshima. Enfatizei a comunicação como fator importante e comparei arquiteturas existentes por má compreensão não só da “Orientação a Objetos”, mas por dogmatismo e ignorância.

Como eu conheço bem o mercado local, enfatizei algumas más práticas que considero o empecilho aos projetos, principalmente as “arquiteturas de referências” que se proliferam aqui e impactam na modelagem.

Fizemos um “Hands On” rapidinho e não tem como não falar sobre TDD, afinal, modelagem ágil passa invariavelmente pelo Test First. “Fizemos”, porque tive a ajuda do @rponte.

Descobri só ontem que existe tradução do livro Domain Driven Design do Eric Evans, eu recomendo comprarem o original na Amazon, mas se forem comprar em português que seja pelo meu link.

A InfoQ publicou um minibook sobre o tema.

Vou subir a aplicação que codificamos ontem para o github e atualizo essa página quando estiver disponível. Algumas fotos que foram tirados voces conferem aqui.

Algumas referências importantes sobre o que falei ontem:

http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/

http://fragmental.tw/2010/02/24/everyday-tales-anatomy-of-a-refactoring/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%E2%80%93-part-2/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%e2%80%93-part-3/

http://fragmental.tw/2010/03/22/nevermind-domain-driven-design/

Esse foi um bom ano, iniciei 2009 abrindo outra empresa e saindo da Triadworks que continua Triad (com o Carlos Átila, além do Handerson Frota e o Rafael Ponte) e agora parceira e amiga.

Minha empresa, a Milfont Consulting foi o profissionalismo de algo que eu já vinha fazendo há algum tempo: Mentoring, treinamento e coaching em desenvolvimento de software, só que agora focado em XP e um nicho específico de linguagem, Ruby. Sobre Rails eu vou fazer um post a parte, sobre o mercado local e meus projetos.

Dois clientes em especial marcaram o ano da Milfont Consulting, o Grupo Tubform que vem montando um dos maiores projetos em Rails no Brasil que tenho notícia e o Grupo Fortes que lançou recentemente o F2RH, um portal gratuito para empresas e profissionais que desejam contratar e serem contratados respectivamente. Claro que meus antigos clientes continuam com atenção especial, mas já estão bem maduros em seus sistemas e processos o que me alegra enormemente e me dão aquela satisfação profissional que é motivo para continuar o trabalho que estamos fazendo.

Em relação à comunidade de desenvolvimento de software começamos (eu e Igo Coelho) o ano criando um grupo de discussões sobre XP exclusivamente do Ceará, o XPCE, do qual explico os motivos nesse post. Depois convidamos o Henrique Landim e por último o Francisco Barroso para se tornarem coordenadores.

Em agosto realizamos o Maré de Agilidade Fortaleza, que nos deu uma boa perspectiva de como fazer um evento, aprendemos muito com os erros cometidos e vamos para 2010 agora com profissionalismo. Nesse mesmo evento nós formamos a primeiro turma da Caelum em Fortaleza, aos trancos e barrancos conseguimos trazer o Fábio Kung para nos ensinar um Rails de qualidade. Agradeço a Caelum e principalmente ao Paulo Silveira por nos ter presenteado com a vinda do Fábio Kung, que é um dos melhores profissionais do mundo e conseguiu impressionar profissionais com anos de mercado e alguns com mais de um ano em Rails mesmo sendo um curso básico. Em 2010 vamos tentar trazer a Caelum mais vezes.

Não daria para citar todos os amigos e profissionais envolvidos nesses eventos da XPCE, mas agradeço o desprendimento de todos vocês, quem nos acompanha sabe o esforço e dedicação que todos fizeram.

Esse ano li cerca de 20 livros para um projeto de pesquisa que estou escrevendo, além de alguns livros técnicos. Fui muito ao cinema para assistir desenhos e filmes de ação com meu filho mas tive pouco tempo para escrever como eu gostaria. Ouvi pouco rock esse ano, já que passo o tempo quase todo em clientes e não dá para voce botar fones de ouvidos quando trabalhamos com consultoria.

Tempo de correr

Em Setembro eu comecei um desafio do jornal OPOVO a convite do jornalista Hamilton Nogueira para sair do sedentarismo e fazer uma corrida de 5 km. Como não nego uma boa briga, além de topar eu aumentei para 10 km, se vamos morrer pelo menos vamos com classe. O resultado foi que fiz a prova da Unifor, 10 km, em 1:16 aproximadamente.

Essa saída do sedentarismo foi graças ao acompanhamento do preparador físico Pedro Sena (Quality Assessoria) que teve muita paciência e profissionalismo para suportar minha agenda um pouco fora do convencional. Essa saga vou publicar com mais calma em outro post.

Com um bom preparo físico o rendimento é outro, você consegue trabalhar e se divertir melhor. Até dores nas costas devido à obesidade eu já tinha, cheguei a pesar 110 kg.

Meus objetivos para o próximo ano com essa reviravolta  como atleta é correr uma meia maratona (que pretendo ser a do RJ no meio do ano) e voltar ao Jiujitsu que é meu esporte favorito. Até dei um treino em uma academia lá em Iguatu onde meu irmão treina. Em termos de esporte esse ano marcou meu renascimento.

Em termos familiar nunca estivemos tão bem, esposa amada (Renata Milfont) e filho saudável que #asgatapira. Feliz ano-novo para todos vocês e que 2010 seja melhor do que foi esse ano.

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

Palestra: BDD prático com Cucumber, Selenium e RSpec

Resumo: Palestra na forma de “hands on” com a construção de uma aplicação utilizando conceitos de BDD. Outside in development visto na prática através da construção e automação de user stories com Cucumber + Selenium e descrição de comportamento com RSpec e Remarkable

Palestrante: Jefferson Jean Martins Girão
Desenvolvedor no Grupo Tubform (http://www.grupotubform.com.br) atualmente trabalhando na migração de um ERP industrial de MS FoxPro para Ruby on Rails e Javascript com EXTjs. Tem 4 anos de experiência em desenvolvimento de software já tendo passado por áreas como automação comercial, terceiro setor e gestão pública municipal.

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 – BDD prático com Cucumber, Selenium e RSpec – Jefferson Girã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

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

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.

“Já tentei algumas vezes escrever os testes unitários no começo, mas simplesmente prefiro a abordagem de escrever os testes posteriormente, preferencialmente acompanhando o desenvolvimento das funcionalidades de negócio.”

Notei em diversas consultorias que isso é muito comum por diversos motivos, o principal a meu ver é justamente entender como começa o código do teste, em dois extremos: se depois que definiu o fluxo de processo de negócio de alguma forma [como UML, CRC ou mesmo apenas com UC] ou se já começa algum esboço em código sem ter discutido bem como funciona totalmente o negócio.

A primeira abordagem, definir todo o processo primeiro, deixa a grande maioria dos desenvolvedores confortáveis já que é algo tradicional que vinhamos fazendo, mas o problema é que invariavelmente descamba para BDUF.

A segunda abordagem, que está ligada ao desenvolvimento iterativo e incremental, já deixa um sentimento de que “algo está faltando” em grande parte dos times que tenho trabalhado. A resistência maior é deixar um sentimento de que não preparamos a arquitetura adequadamente e essa pode sofrer um revés num futuro próximo, claro que isso é uma bobagem para quem conhece como TDD funciona, mas é algo comum que tenho notado e precisa ser desmistificado.

Note que não estou falando aqui do sistema inteiro, apenas uma funcionalidade, mesmo assim a mudança cultural de quebrar uma funcionalidade em tarefas e ir desenvolvendo com “passos de bebê” é algo que dificulta a adoção.

Como sanar essas deficiências?

Precisamos de uma forma que conversassemos sobre a funcionalidade inteira mas que me permita ir avançando e atualizando conforme eu vá entendendo melhor como funciona.

Tenho trabalhado essas deficiências nos últimos times que peguei com BDD [Behaviour Driven Development] , iniciando a escrita das histórias [descrição daquela funcionalidade na visão de uma pessoa] seguindo o modelo de template que o Dan North sugeriu. O resultado é que os times avançaram porque eles notaram como iniciar satisfatoriamente com testes sem comprometer a velocidade do desenvolvimento.

O BDD nos trouxe os testes para o inicio de qualquer código, praticamente sem distinguir que se está testando antes e associado com outras práticas como “Programação em Par” facilitou a linguagem ubíqua do time.

Independente se é ágil ou tradicional eu tenho notado uma deficiência na coleta de informações, seja como User Stories ou Use Cases, onde os analistas de negócio, ou seja lá como são chamados nos times, não sabem pensar em negócio. Uma das coisas mais ridículas que vejo é o sujeito explicar para seu time uma funcionalidade com base em um DER ou outra estrutura técnica, dizendo coisas como: “a tabela tal, associada a entidade x”.

Tenho tentado corrigir isso nos times que enfrento como princípio básico, antes de qualquer coisa eu tento disciplinar a pensarem em negócio. Faço exercícios simples como questioná-los com “esqueçam de qualquer termo técnico” e “como essa funcionalidade é no papel?” ou “se não tivesse computador, como fariam isso?”, perguntas simples para instigar o raciocínio sobre a funcionalidade. Após esse exercício, escrevemos essa história em um arquivo e partimos para sua implementação.

Em março desse ano eu palestrei no primeiro encontro da XPCE sobre BDD, vejam os slides. Em termos de ferramentas você pode conferir como temos trabalhado em um projeto recente seguindo os posts do Jefferson Girão:

Parte 1 http://jefferson.eti.br/?p=96
Parte 2 http://jefferson.eti.br/?p=105
Parte 3 http://jefferson.eti.br/?p=139

Enfim, acredito que BDD seja um caminho natural para adoção de TDD por seu time já que eles terão código de teste, antes de qualquer coisa, na forma de negócio e o TDD já florescerá quando forem testar o modelo criado ou sugerido pelo código BDD. Ainda tem uma vantagem adicional, terão a documentação do sistema executável e comprovável.