Category Archives: Scrum

Extreme Programming no Ceará

Em virtude da crescente adoção de metodologias ágeis no Ceará e a carência de informações sobre a situação real nas empresas assim como o mau conhecimento de profissionais sobre métodos e práticas, criei uma lista sobre XP, específica para o Ceará, afim de sanar essas principais dificuldades.

A lista tem menos de um mês e já conta com cerca de 120 membros e uma boa movimentação, por volta de 500 emails, se mantivermos essa média seremos uma das mais movimentadas do Brasil.

A idéia é fortalecer o XP, mas não em detrimento de outras metodologias ágeis, pelo contrário, teremos sempre o prazer em discutir e divulgar outras iniciativas.

Mas XP?

Sim, XP porque tenho um carinho especial e por considerar que é a metodologia mais madura no Ceará.

Segundo dados do artigo do João Barros [membro do grupo], XP aparece empatado com Scrum com 30% de adoção, mas as experiências públicas mais conhecidas e profissionais mais experientes são com XP. Destaque para a Fortes Informática e o Clavius Tales – confiram esse Podcast com ele.

Nada impede discussões sobre outra metodologias, lembrando somente que o foco é XP. Se criqrem outros grupos eu terei o prazer de participar também, só não tenho tempo para administrar e focar várias iniciativas e pessoalmente prefiro XP por motivos que ficarão para um post futuro.

É interessante observar no artigo do João que já há uma crescente adoção por parte das principais empresas do Ceará – ele listou 24 das mais conhecidas e importantes do estado. Todo trabalho de pesquisa é uma fotografia de um momento e nos fornecem estatísticas de avaliação, pode parecer alguns dados muito otimistas, mas precisamos ter uma base para trabalhar as ações e direcionar os esforços.

É impressionante como o XP sem divulgação e apelo de marketing conseguiu empatar com Scrum e com modelos mistos cada qual com 30%. Outro fato interessante é a baixa representação de outros modelos fora Scrum e XP.

Porque do Ceará?

O Anderson Fabiano fez uma pergunta pertinente no twitter:

@cmilfont me juntei ao grupo. perguntinha basica: qual o ponto de limitar o grupo geograficamente (ce) na era da internet?

E ele mesmo deu uma boa definição:

@cmilfont saquei. +- o principio do craigslist (de 4 anos atras)… limitar para conquistar 🙂

Tenho notado que grupos menores e com pessoas que se conhecem tem melhores discussões porque inibe mais flamewars e ataques pessoais devido ao conhecimento do “humor” nos emails de caras conhecidas.

Criar uma lista exclusiva e focada no estado ajuda a direcionar esforços, não só discussões. Um dos grandes objetivos da lista – grupo- é fortalecer a adoção de XP e para tanto organizaremos eventos e pesquisas nesse intuito.

Já dei início ao censo ágil de 2009 com um questionário para colher informações macros sobre adoção de metodologias ágeis, após essa primeira pesquisa entrerei mais a fundo em questões específicas. A idéia é realizar um censo a cada semestre.

Enfim, vale a pena a participação mesmo de quem não é do estado, as discussões estão “quentes” e boas.

Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a highly complicated problem. Matters, like “coupons for viagra“, are coupled numerous types of heartiness problems. If you need to take prescription medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

Pair Programming vs. Code Review

Uma das grandes brigas do momento entre FDD e XP seria sobre qual a melhor maneira de trabalhar em conjunto, os XPers sempre fizeram Pair Programming [PP daqui pra frente] e alegam que o processo de Code Review [CR daqui pra frente] já é algo intrínsico ao processo, já coberto pelas práticas como TDD e pelo próprio PP.

Existe uma diferença básica entre as duas formas, enquanto o PP trabalha com código em edição, a CR trabalha com código já pronto. Um é durante, o outro depois.

Como eu sou XPer, você deve pensar que vou escolher PP em detrimento a CR. Você está certo e errado.

PP é muito importante em um processo de desenvolvimento mas não é perfeito – como tudo nessa vida, existem sim GAPs encontrados em códigos, até porque não existiria Refactoring se não houvesse, isso é natural e esperado.

Uma prática bacana em um dos meus clientes [adoro escrever assim, parece que tenho vários clientes] foi a adoção de revisão de código entre a “troca de pares” [Moving People Around, uma prática do XP]. Isso já era natural mas na forma de uma espécie de Standup Meeting [prática do XP] com Brainstorm e dificilmente descia até o código, fizemos algo melhor:

Durante a troca dos pares, fizemos com que o navegador fosse trocado pelo condutor do mesmo par onde ele iria e revisariam o código do período anterior como prática institucionalizada. Os caras trocados revisariam o código anterior e discutiam entre os 4.

Dessa forma a oxigenação com uma nova mente [a terceira nesse caso] no mesmo código gerado consegue um ganho excepcional na cobertura dos testes, já pegamos várias coisas que passariam [principalmente em testes de integração] e evitamos voltar tarefa já concluída para refactoring.

Enfim, são eXperiências e nada de eXcepcional. Eu não tenho compromisso em agradar um ou outro, apenas a meu cliente e a única coisa que ele quer é software funcionando e saudável, para isso precisamos sempre evoluir as práticas adotadas.

Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a extremely complicated question. Matters, like “coupons for viagra“, are coupled numerous types of heartiness problems. If you need to take prescription medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

Retrabalho e prejuízo

Em todos os projetos que trabalhei até hoje no mercado local [Ceará] existem profissionais mais ou menos qualificados a partir de uma base mínima de qualidade que um profissional tem que possuir dentro do modelo “Enterprisey” – que estamos acostumados e que responde pela quase totalidade dos projetos de software.

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 itensDevolucao = 
		new ArrayList();
	
}

@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 itensDevolvidos = 
				new ArrayList();
	
}

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.