Na próxima terça (22/11/2011) palestrarei na III Semana de Tecnologia da Fatene sobre agilidade, farei um apanhado sobre tudo que passei, refleti, vi e ouvi em 2011, tanto sobre o trabalho quanto sobre os eventos que participei.

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.

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

Estamos trazendo novamente para Fortaleza o Maré de Agilidade, evento que ano passado balançou a cidade com excelentes cursos e palestras.

Esse ano teremos estrelas nacionais, Paulo Silveira, um dos líderes e popstars da Caelum, que inclusive mantém o patrocínio do evento. Rodrigo Yoshima, o samurai da agilidade brasileira. Willi e Pedroso, os mestres da SEA Tecnologia e inventores do Maré.  Maurício Linhares, palestrante do OxenteRails, um dos maiores do mundo em rails/java e além disso vai ministrar um curso de Objective-C no evento.  Alexandre Magno,  o nome do Scrum nessa galáxia. Serge Rehem, simplesmente o mantenedor do projeto nacional Demoiselle.  E na última hora o maior nome de Kanban na face da terra, Alisson Vale.

Infelizmente não contaremos com a presença do Manoel Pimentel e Alexandre Gomes, mas ano que vem não ficarão de fora.

Veja info na InfoQ.

Patrocinadores

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.

Duas horas produtivas para mim é uma licença poética para “códigos testáveis de forma automatizada, bem escritos, entregues por dia independente de tempo e que não trarão retrabalho”. Um par evita muito retrabalho, lembrando que retrabalho não é refactoring, é prejuízo.

Claro que não há método científico algum, apenas inferência por observação simples. Dia desses um funcionário de um cliente me disse:

“- Milfont, essa sua teoria é mais um dos seus exageros”.  Respondi:

“- Olha do lado, observe o que todos estão fazendo”.

Para espanto desse funcionário, ao olhar para o time mais caxias da empresa, aquele time considerado certinho, que ninguém conversa com ninguém, ele tomou um susto e detectou que todos, eu disse T-O-D-O-S, estavam com o cliente de email aberto. Ninguem estava com sua IDE em primeiro plano.

Coincidência?

Trabalho Energizado

Como consultor eu enfrento problemas de coaching e mentoring [adoro buzzwords] em relação a dificuldade da alta gestão não compreender os benefícios de programação em par para o trabalho energizado. Não que programação em par seja o único responsável por um trabalho focado, mas sem essa prática não dá nem para começar a mudar o cenário.

Todos meus clientes dizem em uníssono: “Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”. Investigaremos essa frase ao final.

Meu trabalho como consultor é transformar galinhas mortas em galos de briga, então não tenho pretensões nem esperança que em um mês meus clientes terão integração contínua, todos seguirão Test First como prática e serão felizes para sempre, no mundo real a coisa é só um pouquinho mais complicada. Enfrento muitos clientes saindo da década de 80 direto para o novo milenio, é uma leva de CVS, Delphi, até clipper, além de vícios provocados por essas plataformas/arquiteturas/whatever.

Agile Bibas

Hoje é muito comum meus clientes pedirem planilhas e técnicas para medir velocidade e desempenho de seus “recursos” porque leram sobre isso nas revistas da moda. Isso é perda de tempo, vou cair no clichê mas não posso deixar de falar, enquanto voce não tratar seu time como pessoas e que elas não são máquinas controladas, não espere retorno deles.

Leonardo Eloy cunhou o termo #Agilebibas para representar todos os defensores do PMBoK de Jeans que irão vender métricas e dirão que o time não produz conforme o esperado porque não se comprometem com as planilhas. Apenas comando-controle disfarçado de ágil.

Esqueça métrica de time, concentre-se na métrica do software. Não importa se o membro do time está nu, pulando corda, de cabeça para baixo, lendo emails ou enchendo a cara numa terça de manhã. O que importa é se as features foram entregues e com qualidade.

Parece simples mas não é, a soma “8 + 8 = 16″ é difícil de ser anulada [imaginar que 8 horas de dois funcionários representam 16 horas de trabalho produzido com qualidade]. Medir tempo por funcionário é um dos maiores erros para tentar aumentar a produtividade do time.

Vou dizer mais uma vez: “Não meça pessoas, meça e entregue software”. Então não importa se seu funcionário não trabalha as 6 ou 8 horas que você espera que ele trabalhe, o que importa é se as duas features planejadas para hoje foram entregues com a qualidade esperada.

Evitar o trabalho chato

Algumas empresas ainda sonham com a esperança que basta impedir o acesso a redes sociais ou serviços na web, então o funcionário vai parar o “Goofing Off“. Existem inúmeros motivos para uma pessoa não estar energizada em seu trabalho, considero o principal como sendo “fazer trabalho chato”.

Vamos agora analisar aquela frase do início:

“Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”

Observe que essa frase revela duas nuances onde o cliente acredita que trabalho em par não é importante, uma consequência da outra. Trabalho simples que provoca a necessidade de não trabalhar em par o tempo todo.

A primeira coisa como consultor quando sou contratado para mudar a cultura do time é tentar incluir programação em par como algo natural e prática necessária, para tanto preciso anular esse trabalho chato que considero ser basicamente trabalho repetitivo. Observe na frase anterior que meus clientes chamam esse trabalho de “simples”.

Não é simples, é chato.

Exemplo que me veio a cabeça agora mesmo, todos os cliente que não tem Test First como prática, então ficam testanto as coisas durante o desenvolvimento na mão, para tanto precisam gerar dados.  Para um desenvolvedor é frustrante ficar fazendo dump e passando para seus colegas de trabalho, porque não automatizar isso?

Todos meus clientes que não fazem Test First passam por isso. Ora, se mesmo os que tem essa prática nós enfrentamos desafios de um bom Setup para garantir a independência no INVEST, imagina os que não fazem.

Outro erro comum é achar que número de commits é sinal de proficiência ou estar trabalhando mais, em regra, para mim é sinal de muito trabalho repetitivo.

Não vou me prolongar, quero só concluir que evitar trabalho chato ajuda a demonstrar que Pair Programming é sim necessário o tempo todo e que se isso for alcançado a “morcegação” tende a diminuir e o reflexo na entrega de funcionalidades se torna positivo. Junte a isso o foco no software ao invés de medir pessoas e esqueça as toneladas de planilhas, na maioria das vezes nem um Burndown seja necessário, apenas trabalho energizado.

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