Rodrigo Allemand

Muitas coisas fazem um projeto passar de sucesso a um completo fracasso, dentre eles uma equipe mau escolhida, um escopo não casado com os prazos, uma arquitetura ruim, etc. Mas um dos maiores problemas que eu vejo que pode transformar um “felizes para sempre” em um “problema para sempre” é o levantamento das necessidades e requisitos.

Mais uma vez, muitos podem ser os fatores que atrapalham um bom levantamento. Analistas inexperientes, hierarquias mau definidas, credibilidade da equipe, clima hostil com o cliente, falha de detalhamento – muito ou pouco, dependendo do caso, usuários indecisos, usar “o que já existe” como exemplo e o pior de todos: usuários “acostumados” com o erro.

Recentemente, estou trabalhando como bombeiro em um projeto que espelha muito do dito acima.

A proposta era redesenhar um sistema originalmente feito em Delphi, que já funcionava a alguns anos para uma estrutura web em Java que temos. Este sistema já tinha passado por diverss atualizações, transformando o código em uma bela macarronada

Por uma briga que se arrasta a gerações (rs), há um clima hostil entre o gerente de projetos e o cliente final (que não cabe a mim questionar, muito menos entender). Isso gerava muitas discursões (infinitas até) quando se queria definir algum ponto.

Dica 1:Quando o manifesto ágil diz para ter o cliente como parte da equipe não é so ter o cliente por perto, mas sim jogando no mesmo time.

Quando se senta para definir alguma coisa, quanto mais gente entendendo, melhor! Entendendo não significa estar falando ou questionando. Mas todas pessoas precisam ter o mesmo entendimento. Por muitas vezes na reunião, surgia uma pergunta que não tinha fundamento algum, como se a pessoa estivesse voando ou não entendendo nada do que estava acontecendo.

Dica 2: Nunca deixe uma duvida no ar. A reunião é justamente para atender as necessidades dos analistas. Preste atenção quando alguem fala para poder perguntar alguma coisa válida. E questione se não entender! Sempre!

Para piorar, o gerente teve uma das piores atitudes que se pode tomar em uma reunião de levantamento: proibir os analistas de perguntarem, fazendo ele um funil com o cliente. Esta atitude fez com que conceitos fossem perdidos e o pior, conceitos errados surgiram.

Dica 3: Para um projeto, hierarquias não devem existir. Claro que algumas vozes pesam mais do que outras mas no momento de levantamento, todos devem ser ouvidos.

Então começa a definição dos casos de uso. Envolvidos em conceitos errados, climinhas e muita briga, os analistas ‘copiaram’ as funcionalidades do sistema antigo sem propor nenhuma alteração. Na aprovação do documento de requisito (aqui nós temos esse passo, por enquanto, rs) o usuário reclamou de muita coisa que estava definida ali, dizendo que se fosse par ter a mesma coisa, que continuasse com o antigo.

Dica 4: O legado pode ser usado como exemplo, mas tente sempre surpreenda o cliente com alguma novidade. Pense no que pode melhorar o trabalho dele e proponha modificações, sempre embasadas em alguma teoria, por mais simples que seja.

Troca-se a equipe para dar mais força ao projeto. Com isso, o usuário já não acreditava na equipe anterior, achando que eles poderiam novamente fazer as besteiras feitas anteriormente.

Dica 5: Por mais que fosse necessária a colocação de mais recursos, nunca deixe a credibilidade da equipe em risco. Se você não acredita no vendedor, como vai comprar o produto?

A nova equipe começou a detalhar – novamente – as funcionalidades e as mesmas tiveram variações, fazendo com que coisas com pouco detalhe tivessem uma pontuação de ‘codificação’ errada diante de tantos detalhes e outras que realmente tinham um alto grau de dificuldade, com pontuações baixas diante da falta de detalhamento.

Dica 6: Detalhe somente o necessário. Incremento é justamente isso! Se Quando chegar o momento você aumentará o nivel de detalhe.

Dá pra sentir como foi a fase de desenvolvimento deste projeto, né?!

Fazendo uma analogia com a construção de uma casa, a reunião de apresentação dos requisitos e das datas de entrega foi mais ou menos assim.

Analista: (…) Então aqui nós teremos os 3 quartos necessários.
Usuário: Mas eu não preciso de 3 quartos. Eu preciso de 3 camas!
Analista: Sim mas nós colocamos 3 quartos distintos para uma melhor modularização. Sem contar que esse quarto maior aqui é uma suite.
Usuário: Mas nesse quarto aqui, alem de ser suite, ele precisa de uma cozinha.
Analista: Como assim uma cozinha? Já existe uma cozinha aqui, veja!
Usuário: Mas eu preciso de uma cozinha aqui porque na antiga casa eu tinha uma cozinha perto da cama.
Analista: Sim, mas agora nós temos quartose a cozinha em ambientes separados.
Usuário: (…) E onde está a minha janela dos fundos para eu entrar?
Analista: Agora nós temos uma porta aqui nos fundos.
Usuário: Está errado. Funcionava assim: eu entrava na casa, abria a janela, saia da casa, dava a volta na casa, entrava pela janela e acessava a parte dos fundos da casa.
Analista: Agora você não vai precisar fazer isso. Nós temos uma porta para que você entre diretamente por ela, já que o proposito é apenas entrar na casa.
Usuário: Não o proposito é entrar na casa pela janela. E janela não é porta. A porta é pra entrar pela frente, a janela é para entrar pelos fundos.

Dica 6: Para o usuário que está acostumado com o erro do software antigo (que para ele já é trivial “entrar por uma janela”), você precisa mostrar e provar para o usuário que se é para entrar, precisa ser por uma porta.

Como dizia meu avô…

Burro não aprende, burro acostuma.
Não faça do seu usuário um burro.

Comente e Recomende!

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é!

A primeira vez que eu (quase todos) ouvi falar em testes automatizados, pensei comigo:

Capitão, isso vai dar merda!

Como qualquer pessoa eu cometi/pensei algumas das 5 maiores desculpas para não desenvolver testes!

• O prazo vai aumentar, com certeza!
• O sistema é pequeno. Seria um canhão numa formiga!
• Sou bom e o sistema é simples. Pra que testes?
• E as funcionalidades complexas, que são “intestaveis”!?
• E a galera de teste? O que fará?

Fala sério?! Você tambem pensou nisso tudo a primeira vez (que pode até ser agora)!

Como falei, isso foi a muito tempo atrás, posso falar que a uns 4 anos.
Com o tempo eu fui tentando, testando e hoje, quase tudo o que faço tem algum tipo de teste!

Teste é um dos pilares de um desenvolvedor ágil! Há xiitas quem diga que, sem testes, o seu código não existe!

Mas como testar?

Bem, mais uma vez, pretendo criar uma série de posts pra tentar passar a técnica e a arte de criar testes.

Inicialmente, vamos entender o que é testar!

Testar é simplesmente verificar se o seu código está de acordo com uma determinada regra.

E o que é teste automatizado?

É fazer com que o seu teste seja executado automaticamente e te dê um relatório final, sem necessidade de intervenção sua para isso, ou que esta esteja ligado a alguma ação que você efetue com frequência.

Bem, a tendência é que você teste a cada alteração no código, correto? Nada melhor do que colocar os testes ligados ao momento do deploy, ou seja, antes de gerar o deploy, mande executar os testes. Com isso vc vai garantir que os seus códigos estão sempre testados, e irá executar os testes diversas vezes ao dia…

Basicamente existemdois tipos de metodologias para testes, o TDD (Test Driven Development ou Desenvolvimento Orientado a Testes) e BDD (Behavior Driven Development ou Desenvolvimento Orientado a Comportamento). Vocês vão perceber que ambos se assemelham, afinal, o propósito básico é testar! Mas inicialmente vamos focar em TDD.

O script básico de um cíclo de testes é o seguinte:

• Desenhe o que você quer que seu código faç
• Escreva o teste
• Rode o teste, provocando a falha
• Refatore o código para passar no teste
• Reinicie o cíclo

Essa adoção foi chamado por James Shore de Red-Green-Refactor. Explicando melhor:

• Red: Seu código não passou no teste. Refatore seu código!
• Green: Seu código passou no teste. Refatore o teste!

Claro que isso tem que ser bastante controlado! Você não pode escrever muita coisa em cada cíclo. Você deve caminhar devagar, em poucas linhas de código, em poucos cenários de teste. Senão você vai entrar em um looping infinito e jamais sairá do outro lado! A unica parte que vc deve perder um tempo consideravel é a parte onde vc desenha o que o seu código deve fazer, ao final de tudo. Mas tambem nada muito exosbitante não senão o conceito de ágil vai pro buraco!

Outra coisa: não se preocupe com design e padrões nesse primeiro momento. Apenas desenvolva! Isso! Código “tosco” jogado na IDE mesmo (com moderação, claro)! Você verá que, ao final, quando for ajustar esse código “tosco” levando-se em consideração um melhor design e uma padronização de mais alto nivel, os testes que vc construiu irão te guiar para o sucesso.

Viu?! Simples como a definição de teste! Agora, deixa de ser frouxo e comece a desenvolver testes automatizados para as suas aplicações! Não sabe como? Bem, aguarde o próximo post então!

Até!

Comente e Recomende!