Débito Técnico

Este post é sobre a comunidade Java que está enferrujando (eu me incluo na comunidade Java). Não sei se é porque a comunidade cresceu. Não sei se é porque temos muitas JSRs. Não sei se é porque a linguagem popularizou. E nem sei porque ainda achamos que daqui a 10 anos ainda estaremos programando em Java.

Vou listar aqui algumas coisas da nossa comunidade que me irritam profundamente:

1. Engolimos a J2EE

Todos nós fizemos BMPs, Service Locators, DTOs desnecessários. Empilhamos várias classes para ter um Session Bean. Implementamos várias javax.ejb.EJBObject, lançamos várias RemoteExceptions. Nós realmente pensamos que nossas aplicações teriam trilhares de usuários.

Não só isso. Nós olhamos para o Spring no início e não achávamos que isso iria dar em alguma coisa. Não demos crédito para o Hibernate no momento certo. Os POJOS poderiam ter tomado a cena muito antes. Nós demoramos para compreender que a Sun não era detentora da sabedoria suprema. Até na comunidade .Net essa ficha caiu mais rápido.

2. Nós pervertemos os POJOS

Livres do modismo J2EE e EJB 2.1 pra baixo, estávamos livres para melhorar nossos modelos, aplicar nossa teoria OO, parar de fingir que distribuimos objetos e ter uma visão mais enxuja. Infelizmente muitos de nós caíram na cilada do modelo anêmico. Ainda com sangue “Core J2EE Patterns” na veia, implementamos factories, DAOs e por influência de Struts 1, DTOs (com nome de VOs) emergiram como rãs nas pragas do Egito.

Fizemos o Martin Fowler perder seu precioso tempo escrevendo sobre Anemic Domain Model.

Pojos não são DTOs, pelo amor de Deus!

3. Nós cultuamos os XMLs

struts-config.xml, web.xml, hibernate.cfg.xml, persistence.xml, context.xml, ejb-jar.xml…

Sim, desenvolvedores foram para a plataforma .Net por nossa exclusiva culpa.

4. Torcemos o nariz para novidades

Quem não reclamou de Generics? Quem não reclamou de Annotations? Que atire a primeira pedra! Somos eternos insatisfeitos só para não sair da zona de conforto. Há quem diga que não gosta de tipagem dinâmica, Jboss Seam, Groovy, JDK com várias linguagens, scripting. Sim, ainda tem muita gente usando Struts 1, implementando DAOs na mão (afinal, hibernate é complicado….), implementando milhares de Factories, controlando transações na mão e estacionados na JDK 1.4.

5. Rigidez conceitual burra

Sinto muito, mas aqui eu não vou usar “nós”. Vocês são os primeiros a sacar os padrões. Vocês ainda estão discutindo framework MVC web. Vocês empilham classes, se enchem de interfaces. Vocês preferem fazer algo complicado por medo das críticas. Não estou suportando mais as discussões sobre DDD, repository, JPA e Hibernate. Por favor compreendam o que o Evans quis dizer com “Don’t Fight your Framework”. Não aguento mais ver trocentas camadas e DTOs. Não apliquem otimização prematura. Sejam pragmáticos. Respirem YAGNI. Abusem das Spike Solutions. Façam a coisa mais simples possível que funcione.

Enquanto vocês estão discutindo os padrões, todas as outras comunidades estão correndo por fora. Desculpem o desabafo. Teve um determinado momento onde gostava dessa rigorosidade da comunidade Java, porém, hoje vocês estão me fazendo flertar com a comunidade PHP.

Sequência de cor…. faz tempo que queria fazer uma dessas!!!! (e logicamente puxar mais de 1.000 fichas com isso)

Há 32 chances em 2.598.960 de você fazer um Straight Flush. O Royal Straight Flush (sequência de cor para ÁS) são somente 4 em 2.598.960.

No TDC 2008 tive a oportunidade de conversar um pouco com o André Piza do UOL. Sua palestra no evento tratava sobre a adoção do Scrum em todo o desenvolvimento de produtos da empresa.

Essa notícia foi muito especial para nós da Aspercom pois em julho do ano passado, exatamente 1 ano atrás, ministramos uma série de treinamentos para mais de 40 pessoas do UOL, entre eles o nosso curso Scrum. Pelo que me lembro foi uma das primeiras turmas corporativas deste treinamento.

Ficamos bem contentes em receber a notícia do sucesso na adoção do Scrum. E desejamos grandes sucessos a todos os envolvidos.

No sábado passado estive na TDC 2008. Um evento da Globalcode em parceria com várias empresas como UOL, Locaweb, Teamware e outras.

O evento foi excelente e agradeço o convite do Jorge Diz! A organização foi espetacular, o local, a grade, os palestrantes, tudo feito com muito cuidado. O evento foi muito legal pois pude conhecer o Vinicius Teles pessoalmente e rever amigos e alunos.

Coisas que aprendí no evento:

1. Na palestra do Manoel Pimentel: Devo aprender mais e tentar usar Mind Map Modeling.

2. Assistir palestra ao lado do Papo é praticamente uma viagem no tempo. Até Harlan Mills foi citado. Fazendo um trocadilho, é um papo cabeça… (essa foi péssima).

3. Você cascateiro de plantão será insultado caso assistir uma palestra sobre XP do Vinicius da Improve It. Excelente palestra por sinal!

4. A macarronada ágil se transformou em feijoada ágil, por conta do custo e prazo. Nós agilistas não conseguimos desligar!!! Porém, as mulheres preferem os “não ágeis” por razões óbvias!

5. Não chame o Vinicius (já citado) para jogar Tenis no Wii. Perdí: 45 x 0 e 45 x 15! Vergonhoso!

6. Fui entrevistado pelo Vinicius. Segue o link para o blog dele:

http://blog.improveit.com.br/articles/2008/07/29/entrevista-com-rodrigo-yoshima-da-aspercom


(eh… estou ficando careca)

7. Juntando vários agilistas numa sala ocorre o “Mesa Redonda Agile Debate”. Participantes: Eu, Manoel, Vinicius, Juan, Ricardo e Jorge. Logo logo o Vinicius coloca este vídeo no blog dele. Um super bate papo (apesar que o Papo não participou, essa foi pior ainda, vou parar com as piadinhas). Algo completamente informal, sem planejamento, sem tema, nos revezamos nas filmagens. Até roubamos o suco do Ed Burns!

8. Tive um sentimento do tipo “não se mistura trevas com luz” no painel sobre metodologias. Como meu amigo Luca falou, o Marcos Dorça estava na berlinda ao querer falar sobre CMMi na mesma mesa com Manoel Pimentel, José Paulo Papo, Juan Bernabó, Vinicius Teles, André Piza entre outros… Aliás, este foi o único momento do evento que sentí uma invasão publicitária. Neste caso por parte da Borland.

Minha opinião sobre CMMi (pela milésima vez): Nada adianta você ser maduro num processo que é ruim.

Ficamos com um compromisso de fazer uma conferência Agile maior ainda neste ano. É esperar pra ver…

Iniciando a série perguntas e respostas, dúvida na lista scrum-brasil:

2008/7/29 Alguém wrote:
Olá pessoal,

Gostaria de tirar algumas dúvidas:

Imaginem que existe um sprint definido e iniciado, que possui 10 tarefas. Depois de passados alguns dias, o Product Owner quer trocar um item do Sprint por outro de mesmo peso, que ainda não foi iniciado. Isso poderia ser feito? Ou em Sprint iniciado não se mexe?

Essa é uma pergunta muito comum nos cursos que ministro. Na maioria das vezes não é simplesmente trocar um pelo outro. Muitas vezes o planning é um momento onde aprofundamos em requisitos, fazemos alguns modelos rascunhando, levantamos tarefas, preparamos o que for necessário e isso sempre é sobre as Stories que selecionamos para o Sprint.

Durante o Sprint é o único momento onde o escopo está fixo (escopo do Sprint). Isso faz parte do contrato Scrum. Isso garante o mínimo de segurança para a equipe trabalhar num terreno um pouco mais firme mesmo que por um curto prazo. Sou partidário do “sprint iniciado não se mexe”. Já tive cliente que o Product Owner queria toda hora mudar o Sprint Backlog. Isso gerava um estresse grande na equipe. A equipe não sabia o dia de amanhã. É muito ruim.

Um artifício que o Product Owner pode usar é cancelar o Sprint, mas isso significa parar o Sprint atual e voltar para o Planning. Não é uma coisa muito comum e nem muito agradável. O Product Owner tem que se organizar!

Segunda pergunta: se o Product Owner quiser tocar um item do sprint que ainda não foi iniciado, por outro de peso maior, o que consequentemente iria aumentar o tamanho do sprint, isso poderia ser feito? Estou considerando que o Product Owner tem consciência que essa alteração irá aumentar o tamanho do sprint e ele não se importa se o sprint tiver 1 semana a mais, se for necessário.

Antes de mais nada, leia isso aqui:

http://gc.blog.br/2008/05/05/nao-da-pra-fazer-so-mais-uma-coisinha/

O Product Owner está no comando do barco num processo Scrum. Ele está guiando o desenvolvimento. Ele tem muito controle sobre a equipe, mas esse controle é ordenado e as regras do contrato Scrum devem prevalecer sempre. O ScrumMaster não pode deixar o Product Owner fazer o que quiser.

Já disse que não é uma boa idéia mexer no escopo do Sprint corrente. E para todos os efeitos, vocês da scrum-brasil vão ficar de castigo. Escrevam 100 vezes na lousa:

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

O timebox é um conceito sagrado. Iterações tem tamanho fixo e todas são do mesmo tamanho. Costumo dizer para as equipes: “- Este Sprint termina na data 01/04/20XX. Quer vocês queiram, quer vocês não queiram, ele vai terminar nessa data.”

Essa regra não é uma rigidez conceitual qualquer. É só para deixar as coisas mais simples. Desenvolvimento iterativo possui um conjunto mínimo de regras que faz o processo funcionar. Abrir mão de algumas delas gera muita confusão.

Este texto foi publicado no blog do Carlos Vilella, achei tão bom que decidi traduzir.

Uma fábrica de pastas de dente tinha um problema: as vezes eles entregavam caixas vazias, sem o tubo dentro. Isso ocorria por causa da maneira que a linha de produção foi montada, e pessoas com experiência em design de linhas de produção podem confirmar como é difícil ter tudo ocorrendo no tempo certo para que cada unidade fabricada seja 100% perfeita. Pequenas variações no ambiente (que por conta do custo não podem ser controladas) obrigam que você tenha alguns pontos de checagem da qualidade inteligentemente distribuídos ao longo da linha de produção, para que os consumidores que vão até o supermercado não fiquem fulos com seu produto e comprem do concorrente.

Compreendendo que isso era importante o CEO da fábrica de pasta de dente pegou as pessoas mais importantes da companhia e eles decidiram iniciar um novo projeto. Eles contratariam uma empresa de engenharia externa para solucionar o problema “das caixas vazias”, já que o departamento de engenharia já estava abarrotado de trabalho.

O projeto iniciou como sempre: orçamento, financiamento, propostas, fornecedores selecionados e depois de 6 meses (e $8 milhões) eles tiveram uma solução fantástica - dentro do prazo, do orçamento, alta qualidade e todo mundo no projeto estava feliz. Eles resolveram o problema usando algumas balanças de alta precisão que soava uma sirene com luzes toda vez que uma caixa de pasta de dente pesasse menos do que deveria. A linha de produção pararia e alguém teria que andar até lá, retirar a caixa com defeito e pressionar um botão para a produção continuar.

(neste momento, pense com seus botões se esta solução é plausível - grifo meu)

Momentos depois o CEO decide ver o ROI do projeto: resultados incríveis! Nenhuma outra caixa vazia saiu da fábrica depois que as balanças foram colocadas. As reclamações reduziram e eles estavam ganhando mercado. “Isso sim é um dinheiro bem gasto!” - ele falou, isso antes de olhar mais de perto outras estatísticas do relatório.

(mais uma vez, neste momento avalie o resultado do projeto - é uma solução de sucesso? - grifo meu)

Ao virar a página ele vê que o número de defeitos capturados pelas balanças foi ZERO depois de 3 semanas de uso. Poxa! Elas deveriam estar capturando pelo menos uma dúzia por dia, então, deve ter algum problema com o relatório. Ele apontou um bug nesta funcionalidade. Depois de alguma análise os engenheiros voltaram dizendo que o relatório estava correto. As balanças de fato não estavam mais captando nenhuma caixa vazia. Todas as caixas que estavam chegando no ponto onde as balanças estavam na esteira tinham o tubo dentro.

Confuso o CEO vai até a fábrica e chega até o lugar aonde as balanças de precisão foram instaladas. Alguns passos antes das balanças tinha um ventilador de $20 assoprando pra fora da linha as caixas vazias para dentro de uma lixeira.

“Ah… esse ventilador? Um dos nossos colocou ele aí, pois estava com o saco cheio de andar até aqui quando a sirene tocava” - disse um dos trabalhadores.

Nesta semana ministrei nosso curso Scrum para a animada equipe da agência VM2. A VM2 é uma empresa especializada em projetos de design e mídia on-line em geral. Possui uma vasta carteira de produtos e já entregou mais de 750 projetos.

É interessante ver como uma empresa que veio do mundo da publicidade é bem diferente de empresas que simplesmente são produtoras de software. No trabalho da VM2 existe o trabalho artístico de design e também o dia a dia do desenvolvedor de software, lidando com integrações, frameworks, patterns, modelagem, testes e etc… A empresa deseja utilizar o Scrum para ter uma visão única do projeto, adotando a característica multi-disciplinar da metodologia.

Uma das coisas legais do nosso workshop é o exercício de levantar as User Stories de um projeto de rede social empresarial. Nós fazemos o planejamento de um projeto partindo do zero: eu faço o papel de cliente e os alunos fazem parte do corpo técnico.

Nesta atividade os alunos devem achar as User Stories conforme a conversa com o cliente se desenvolve. Não é a primeira vez que ví um aluno fazendo isso, mas dessa vez conseguí pegar um deles no flagra.

Nós também temos atividades de modelagem ágil na concepção deste projeto, porém, intuitivamente este aluno (ele se chama Everton) estava modelando um mapa de navegação do sistema só para compreender melhor o problema, na melhor forma do “modelar com um propósito” da Agile Modeling. Ninguém tinha pedido pra ele fazer modelo algum, mas ele o fez por necessitar dele. Ele fez para o propósito de ter uma melhor visão sobre as Stories.

Creio que este é um bom exemplo dos benefícios de modelar. Um modelo não é uma especificação. Modelar deve ser uma atividade intuitiva e não uma obrigação. A formalidade do modelo costuma variar conforme a necessidade.

O que está na cartolina azul é um mistério…

Muitos outros alunos fazem outros tipos de diagramas. Alguns deles são completamente indecifráveis para quem não participou da sua elaboração. Nenhum deles são “UML compliant”. Muitos fluxogramas simples costumam aparecer. Outros (como eu) simplesmente precisam de um papel para rabiscar coisas enquanto falam.

É só afastar as cadeiras!

Parabéns e obrigado a todos da VM2 pela hospitalidade e pela troca de informações sobre PHP, Web Design, LAMP e etc… Até o próximo treinamento!

Amigos(as) líderes,

No dia 21 de julho, segunda, o Rick Warren estará no Credicard Hall em São Paulo. A obra do Warren é uma das que mais me influenciaram sobre liderança e de fato é um dos maiores nomes sobre o assunto no mundo hoje. Para quem não conhece, o Dr. Rick Warren é um pastor. Isso mesmo! Ele é o pastor sênior da igreja Saddleback na Califórnia (não se engane, a liderança da igreja é uma das coisas mais complexas que existe).

Warren foi nomeado um dos 25 líderes americanos de maior destaque em outubro de 2005 num artigo da U.S. News and World Report. Warren foi eleito pela Revista TIME um dos “15 líderes mais influentes dos Estados Unidos” em 2004 e uma das “100 Mais Influentes Pessoas no Mundo em 2005”. A Revista Newsweek declarou que ele é uma das “15 Pessoas que Fazem a América ser Excelente”. Este é um prêmio dado a pessoas que através da bravura ou generosidade, genialidade ou paixão, dão-se a si mesmos para ajudar outros.

O primeiro best-seller do Pr. Rick “Uma Igreja com Propósitos”, está na lista dos “100 livros cristãos que mais mudaram o século XX” e foi considerado pela Forbes “O melhor livro sobre empreendimento, gerenciamento e liderança já escrito”. Warren também é autor de vários livros pela Editora Vida.

Maiores informações:

http://www.rickwarrennobrasil.com.br

(infelizmente não poderei comparecer pois tenho uma turma de UML iniciando neste dia)

Sabe o que eu gosto no poker? Seu oponente bota fichas na mesa sem a mínima noção da besteira que ele tá fazendo…

Creio que a Cemig dispensa apresentações. É uma empresa pública brasileira com 56 anos e uma das maiores geradoras e distribuidoras de energia aqui no Brasil. Ela tem uma receita operacional de 15 bilhões de reais anuais.

A equipe de desenvolvimento de aproximadamente 40 pessoas foi treinada na metodologia Scrum, onde pudemos desmistificar muito sobre as melhores práticas de gerenciamento e principalmente auxiliá-los na melhoria contínua dos processos que o Scrum proporciona através da constante inspeção e adaptação.

Em tecnologia se aprende na prática!!!

Exercício de Concepção Ágil. Como descobrir e dar peso funcional para as User Stories ?

Parabéns a todos da equipe de desenvolvimento da Cemig e espero que a ASPERCOM tenha ajudado nos importantes projetos que vocês estão desenvolvendo.