Rodrigo Allemand

Uma das grandes barreiras para a adoção de uma metodologia ágil de uma equipe pode ser aquela antiga mania de isolar o cliente das adoções tomadas no decorrer do desenvolvimento. Não adianta! Sem o cliente por perto, não temos metodologia ágil que funcione simplesmente porque sem o cliente por perto, a chance de errarmos aumenta demais! Isso normalmente acontece quando temos aquele otimo tecnico que virou gestor e parou no tempo onde existia as fases de um produto, e não um produto em fases!

Muitas vezes, por mais que um ‘analista’ entenda 100% do que o cliente solicitou, ele não sabe o que o software tem que fazer quando for dado por completo. Nem o cliente saberá isso em um Brainstorm, ainda mais se vc colocar aquela bendita fase de levantamento no seu cornograma cronograma.

Dividir o produto em UserStories é dar certeza ao cliente e ao desenvolvedor que, apenas aquele pequeno escopo está sendo desenvolvido neste momento (iteração). Ele não precisa se preocupar no momento que lá na frente o produto tem que se comunicar com 50 pontos diferentes. Isso não está no mini-escopo da UserStory a qual o desenvolvedor está focado!

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

Para quem não sabe, eu trabalho no Instituto Nacional do Cancer, com uma equipe de 12 pessoas que desenvolve Java (Web e Mobile) para alguns clientes/institutos satélites do governo. Porem, quando eu cheguei aqui, minha tarefa era “organizar a casa para que os sistemas que estavam em fase final de levantamento tivessem uma melhor performance de entrega”.

Pois bem, fiz a minha parte! Os softwares estão sendo entregues quase como eles descreveram, mesmo com todos os problemas encontrados no meio do caminho! Digo isso porque não sei se enquanto eu escrevi esse post, as novas funcionalidades foram aceitas. Mas ainda me sinto muito insatisfeito com o meu próprio serviço, conforme enumero abaixo:

1. Não há testes por parte da equipe, nem falo de unitários ou integrados. Não há teste automatizado de maneira alguma!;
2. Não há a presença do cliente. Estamos desenvolvendo no escuro, levando em consideração o que o gerente do projeto acha, o que não será (quse com certeza) o que o cliente final deseja;
3. Não há uma definição fechada do que fazer e como fazer. Até mesmo coisas básicas como layout são alterados dias antes da entrega final de um módulo, mesmo sem o concentimento do cliente;
4. Não há gerencia de configuração alguma. Os ambientes de desenvolvimento, homologação e produção são diferentes a ponto de serem utilizadas versões de softwares e bibliotecas comuns diferentes entre esses ambientes;
5. Há sempre o “faz como esse aqui”. Sistemas arcaicos com soluções precárias como exemplo… nesse eu nem preciso me aprofundar muito!
6. Minha-Própria-Metodologia-Ágil não funciona se todos não tiverem completa noção de como funciona. Para qualquer metodologia funcionar, tudo deve estar entendido e todos devem estar de acordo.

Para se ter noção melhor sobre o que eu passo, na proxima terça feira (03/03/2009) deveriamos fazer um deploy contendo 80% do projeto para o cliente. Mas quem vai testar é o gerente do projeto, já que o cliente só vai ver quando o produto estiver 100% pronto. Mas amanhã teremos uma reunião para definir um escopo de versionamento de informações, que é vital para um processo de certificação (escopo do sistema). MAs calmae, amanhã para entregar numa terça?! Sugeri então envolver o cliente, mesmo que por audio conferência, para ter uma solução aprovada por ele, porque a alteração iria ser muito grande. Resposta: Vamos definir entre nós, o cliente será avisado sobre a nossa decisão!!

Um outro exemplo aqui tambem: o sistema ainda não tem usuário final e está em fase de homologação?!? Como assim?!? Quem definiu isso?!?

Enfim, estou muito insatisfeito e tenho plena noção de que não conseguirei alterar isso a curto prazo, ou seja, até a entrega desses produtos aos seus clientes com a etiqueta “SURPRESA!” Gosto muito do local, da empresa, da causa (principalmente) e das pessoas. Mas as metodologias e os modelos estão me esgotando!

Mas a minha saga em busca do projeto-agil-piloto-que-transformará-toda-a-empresa continua!

“Não é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças” – Charles Darwin

Até!

Depois de um tempo colocando outras coisas no lugar e bastante focado na entrega de um produto aqui no trabalho, o blog vai voltar à ativa!!

Sei que muita coisa ficou de ser falada, muitos comments ficaram bloqueados, mas agora tudo voltou ao normal! Bem, quase tudo!

Vou começar uma série de palestras (aqui no trabalho e em uma outra empresa) sobre DDD e Padrões de Arquitetura. Garanto que todos os tópicos e materiais usados nessa apresentação estarão aqui!

Aguardem!

Comente e Recomende!