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

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

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.

09:00 – 10:20

Palestra: Começando a usar BDD e TDD
Resumo: Se você nunca entendeu como é que se escreve testes antes do código ou ainda não conseguiu uma forma satisfatória de seguir essa prática, aproveite essa oportunidade onde dissecaremos Test Driven Development até convencê-lo de que essa é a abordagem profissional adequada, além disso facilitaremos a compreensão em um nível mais abstrato com Behaviour Driven Development agilizando o mergulho de cabeça nessa forma de modelar código saudável e eficiente.
Palestrante: Christiano Milfont, coordenador do grupo XPCE e um cara que gosta de programar.

Local: Fortes Informática.

Endereço: Rua Antônio Fortes, 330, Bairro Edson Queiroz, próximo ao antigo Hiper Mercantil da Washington Soares. Localização com o Google Maps.

Data: Dia 28/03/2009 [sábado] das 09:00h as 12:00h na sala de treinamentos 1.

XPCE - Grupo de Extreme Programming do Ceará.

[http://groups.google.com.br/group/xpce]

XPCE - Grupo de Extreme Programming do Ceará.

[http://groups.google.com.br/group/xpce]

Local: Fortes Informática.

Endereço: Rua Antônio Fortes, 330, Bairro Edson Queiroz, próximo ao antigo Hiper Mercantil da Washington Soares. Localização com o Google Maps.

Data: Dia 28/03/2009 [sábado] das 09:00h as 12:00h na sala de treinamentos 1.

Palestras

09:00 – 10:20

Palestra: Começando a usar BDD e TDD
Resumo: Se você nunca entendeu como é que se escreve testes antes do código ou ainda não conseguiu uma forma satisfatória de seguir essa prática, aproveite essa oportunidade onde dissecaremos Test Driven Development até convencê-lo de que essa é a abordagem profissional adequada, além disso facilitaremos a compreensão em um nível mais abstrato com Behaviour Driven Development agilizando o mergulho de cabeça nessa forma de modelar código saudável e eficiente.
Palestrante: Christiano Milfont, coordenador do grupo XPCE e um cara que gosta de programar.

10:40 – 12:00

Palestra: Integração Contínua
Resumo: Descubra o que projetos ágeis fazem para possibilitar que diversos desenvolvedores trabalhem juntos em um mesmo projeto, integrando suas contribuições de forma harmônica e segura.
Palestrante: Igo Coelho, fanático por desenvolvimento de software, novas tecnologias, internet, eletrônicos e tudo mais que um geek pode gostar. Com mais de 9 anos de experiência em desenvolvimento de Software trabalha atualmente na Fortes Informática como arquiteto de software com XP e Java. Casado, pai de dois filhos e mantem um blog em www.igocoelho.com.br.

Sorteio de livros e revistas.

Essa base mínima eu proponho que seja – dentro do modelo exposto -  raciocínio lógico. O resto ele pode aprender.

Raciocínio lógico está ligado diretamente a noção de avaliar a situação, encontrar um padrão, investigar soluções existentes e implementar a solução, além claro de bom senso.

Não adianta pregarmos que os profissionais deveriam ser melhor escolhidos assim ou assado porque a realidade é que as empresas não tem como medir satisfatoriamente quem é ou não competente e mais cedo ou mais tarde você se deparará com indivíduos em sua equipe vindos por diversas nuances administrativas, seja aquele superqualificado cheio de títulos ou o primo do diretor da empresa.

Aonde quero chegar com essa história?

Precisamos avaliar os riscos necessários com bastante antecedência para que toda a equipe e consequentemente o projeto não sejam lesados e paguem o preço da incompetência às vezes de um único elemento. Parece óbvio? Acredite, não é!

Temos um projeto em um cliente – uma Alfândega – que precisamos refatorar todo o código criado por um determinado profissional com apenas dois ou três meses pronto. O projeto ainda está no início e já temos que refazer código.

Convenhamos, tudo bem que o código de meia hora atrás já é legado, mas código tão recente não deveria já ser refatorado sem mudança na lógica de negócio ou arquitetural. Algo muito errado aconteceu.

Mudanças não funcionais acontecem, surge um novo paradigma ou framework que reduz o tempo de desenvolvimento e convenientemente é adequado sua mudança, isso é comum durante a manutenção de um software já em produção com um meio século de uso – que em informática dura cerca de 4 ou 5 anos.

O nosso em questão não há motivos. Projeto novo, sem restrição ou adequação à “Arquitetura de Referência”, Frameworks de última milha na plataforma Java como JSF, Spring e Hibernate. Testes unitários – mas não TDD.

Como dito, separei um exemplo em código para demonstrar aonde quero chegar. Tem uma lógica bastante simples, existe um processo de apreensão de mercadorias na alfândega e liberação dessa mercadoria.

Há 3 tabelas que representam isso no modelo E/R: TB_DEVOLUCAO, TB_ITEM_APREENSAO, TB_ITEM_DEVOLUCAO. Segundo a lógica relacional, a TB_ITEM_DEVOLUCAO é uma tabela de junção entre a devolução e os itens apreendidos para indicar que item será devolvido.

Seguindo minha definição, um profissional com raciocínio lógico encontraria fácil a solução do mapeamento entre essas entidades apenas lendo a documentação, ele saberia que o Hibernate tem um mapeamento de OneToMany com Join Table Uni ou Bidirecional.

Mas não, ele criou essa bizarrice:

@Entity
@Table(name="TB_DEVOLUCAO")
public class Devolucao {
 
	@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.ALL)
	@JoinColumn(name="SEQ_ITEM_DEVOLUCAO")
	@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
	private List<ItemDevolucao> itensDevolucao = 
		new ArrayList<ItemDevolucao>();
 
}
 
@Entity
@Table(name="TB_ITEM_DEVOLUCAO")
public class ItemDevolucao { //Para que essa entidade?
 
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	@Column(name="SEQ_ITEM_DEVOLUCAO", columnDefinition="NUMERIC")
	private Integer codigo;
 
	@OneToOne
	@JoinColumn(name="SEQ_ITEM_APREENSAO")
	private ItemApreensao itemApreensao;
 
}

Esse profissional em questão é graduado em computação, tem mestrado em uma federal, certificação como arquiteto Java e diversas outras certificações e pasme, anos de experiência em projetos. Mas não tem o básico, raciocínio lógico. Não investiga e não sabe desenvolver software de qualidade.

O código em questão pode parecer bobagem até mas isso se repete em todo o código criado por esse profissional.

Um profissional responsável em refatorar o código com apenas curso técnico e uma mísera certificação de programador java refatorou assim [como deve ser]:

@Entity
@Table(name="TB_DEVOLUCAO")
public class Devolucao {
 
	@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.ALL)
	@JoinTable(name="TB_ITEM_DEVOLUCAO",
		joinColumns = @JoinColumn(name="SEQ_ITEM_DEVOLUCAO"),
		inverseJoinColumns = 
				@JoinColumn(name="SEQ_ITEM_APREENSAO")
	)
	@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
	private List<ItemApreensao> itensDevolvidos = 
				new ArrayList<ItemApreensao>();
 
}

Ad Hominem da minha parte? Tomar uma exceção pela regra? nada disso, eles são legião! Isso é meu cotidiano.

O prejuízo que esse profissional acarreta a todos os envolvidos é enorme e até difícil de ser mensurado porque envolve custos e humor da equipe que impacta em outros custos imperceptíveis na conta final que é a “fodisse” dos caras que tiveram que refatorar, ou seja, fizeram o seu e o trabalho alheio.

Ah, mas XP não prega o código coletivo? ir lá e consertar? Mas quebra o principal valor que é “Respeito”. Além do mais o projeto em questão seque o velho Cascata – mas culpa do cliente que exigiu ser assim, exigiu não, obriga.

Pela minha experiência de nada adianta você jogar um Clean Code nas mãos dele e pedir para estudar, ele vai continuar escrevendo nmDesc em uma propriedade ou IRepository em uma Interface. Ele foi treinado assim e sem raciocínio lógico no máximo que voce vão conseguir é retreiná-lo para conseguir comer a banana por outro túnel.

Um projeto sem um líder técnico responsável com aptidão e experiência necessária aliado a método baseado em BDUF sem um processo restritivo [como TDD] com modelagem ultrapassada com papéis de analista de sistemas “UMLizados” deixa esse tipo de profissional cometer esses pecados e prejudicar a todos os envolvidos retrabalho desnecessário.

É fácil resolver isso? É! O problema maior é que não podemos simplesmente aceitar que “o cliente quer assim”, temos um dever ético com nossa profissão de não permitir que o paciente escolha como ele quer ser operado e ceder médicos que não tenham capacidade de operá-lo.

Existe um tipo de falácia bem comum que está crescendo ultimamente se aproveitando da célebre frase: Não existe bala de prata!

Quando invocamos a necessidade de não considerar todos os problemas como um prego e a única arma um martelo, não estamos fornecendo a chave da irrestrita flexibilidade irresponsável.

Quando assumimos que em tudo depende, não estamos dizendo que não há uma fronteira. O avanço significativo do cálculo só foi possível com o advento do limite matemático.

Fazer ciência é investigar e fazer a pergunta certa ao contrário da resposta certa. Para isso identificamos padrões e formulamos teorias.

Antes de abandonar uma teoria devemos substituí-la por outra mais apropriada. Isso soa conservador mas é preciso para se fazer ciência, propor o abandono de uma determinada teoria sem a substituição por outra mais adequada é leviano.

Para entender como algo funciona não podemos simplesmente achar que qualquer solução é válida e sim descobrir qual a solução adequada.

Entender que existem soluções mais apropriadas – e que sim, existe um jeito certo ou um modo melhor de se fazer algo – não quer dizer que outras abordagens simplesmente estão erradas,  podem ser apenas incompletas e/ou inviáveis.

Em muitas discussões que tenho travado ultimamente sempre quando tento argumentar que uma solução específica é melhor do que determinada outra, ouço:

“Não existem balas de prata”. Bingo!

Essa pessoa não entende ou não quer aceitar por motivo qualquer que a solução dela está errada ou não satisfaz.

Aqui a proposta é pontual, para determinado conjunto de fatores existe uma solução mais adequada, isso é fato.

Existem Balas de prata!

Mas como somos fans de Supernatural, sabemos que o que mata é acertar no coração. O trabalho deve ser direcionado a combater a complexidade no coração do problema e não simplesmente num jogo de escolher a ferramenta certa.

Na área de desenvolvimento de software a maioria dos desenvolvedores se apegam a uma metodologia/ferramenta/arquitetura e tentam encaixá-la para a construção de qualquer sistema. Não entendem que aquela solução não vai resolver todos os problemas.

Até aqui tudo bem, o problema é aproveitar a defesa de que não existe uma ferramenta para todos os propósitos e considerar que “não existe o melhor” ou a “forma apropriada”, quando justamente por não existir ferramenta universal é que devemos usar algo por sua especialidade.

O manifesto ágil tem um trecho que diz:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.”

Observe que ele diz “melhores” e não “diferente” ou “de outra forma“.

No final diz:

“Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Aqui reconhece que os itens à direita não estão errados, apenas que os da esquerda levam a uma melhor forma de tratar o campo específico que é desenvolver software.

Tentar levar o manifesto ágil para gestão de projetos, construção civil ou limpeza da sua casa o faz ser uma bala de prata e que não vai matar nada porque você não está atigindo o coração, apenas tentando criar um martelo genérico para um uso universal.

Todo o “KnowHow” associado ao manifesto ágil se refere única e exclusivamente ao processo de desenvolver software da melhor forma, atinge o pontual.

Agiletards sabem ser chatos também quando seguem metodologias de caixinhas e querem criar um novo dogma de desenvolvimento de software.

Existe o melhor e a forma mais adequada, procurar é nosso dever!

Riscando os cavalos!
Tinindo as esporas!
Través das coxilhas!
Sai de meus pagos em louca arrancada!
— Pra quê?
— Pra nada!

Poema Gaúcho do poeta pernambucano Ascenso Ferreira.

O SEI publicou uma nota sobre CMMi e Agile e causou um certo frisson em membros de “listas de discussões agiles”.

O que muda? nada, absolutamente nada. Pelo menos para o mundo agile continua a mesma coisa, não só temos de lutar contra o mundo de terno como o pessoal do Jeans já está lutando entre si.

O SEI está vendo que perdeu a batalha e agora quer liderar essa nova “era agile”.

Agile é possivel com CMMi?

Nunca, porque a cultura deles valoriza mais os itens a direita do manifesto ágil, é da essência.

Mas vão tentar especificar um “burro”, podem ter certeza.

A mistura de um jumento[jumenta] com cavalo[égua] nasce um burro[mula], ser híbrido mas ESTÉRIL. Muito bom para trabalhos pesados [já que o jumento tem resistencia] e com mais velocidade [que o cavalo possui] mas que não pode gerar filhos. A mesma analogia pode ser aplicada a mistura de duas culturas antagônicas.

Quem promove essas bobagens são charlatões que saíram do mundo do terno e caíram no mundo do Jeans por pressão e querem se sentir com capacidade de liderar novamente, para isso precisam controlar e guiar a cultura do Jeans já que é contra sua essência assumir que um “Recurso Humano” [que para nós se chama gente ou pessoa] tem mais valor do que um processo por exemplo.

Essa turma não consegue entender a cultura que propiciou o manifesto ágil e abraçou – desvirtuando – alguns métodos, entre eles o Scrum, que apelidei desde o ano passado de “RUP de Jeans”.

Observe que o software funcionando foi abandonado em prol do discurso de “gestão”, “venda da imagem”, “governabilidade” e todas as Buzzwords importadas – [trazidas?] – do mundo de terno.

XP é radical

Noto que o pessoal FuDiDo está em luta aberta contra o XP, tudo bem que FDD sempre esteve à sombra até do Scrum, mas esse tipo de abordagem é idiota e irracional, com argumentos do tipo: “XP é um nome agressivo”, “Práticas de engenharia do XP são restritivas e difíceis de adotar”, “XP não tem governança de projeto”, “XP não tem controle de riscos, prazos”, “Whatever”.

Idiotice tem limites e todos os limites já estão estourados. Esse tipo de argumentação é somada com os preconceitos clássicos de que: “agile não dá certo em projetos grandes”, “equipes remotas perdem toda a comunicação”, “não tem documentação”, “é anarquia”, … e se confundem.

Essa nota do SEI me lembrou da Questão Christie, o que eles querem? Um pedido de desculpas por terem enterrado sua cultura na lata do lixo da história? Vão impor sua força para controlar o mundico agile?

Ágil não dava errado em projetos grandes? As falácias estão perdendo força?

Vamos esperar qual o próximo capítulo.