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!

Em um ciclo de desenvolvimento em cascata, existe um processo chamado Revisão de Código (Code Review), onde uma pessoa avalia o trabalho de outra pessoa em busca de qualidade, etc. Nas metodologias ageis, esse processo foi substituito por uma ação mais inteligente, que é a Programação em par.

Revisão de código

Sempre me perguntei:

“Como vou deixar claro pra uma pessoa no futuro que o que eu pensei foi asssim, e não assado sem usar somente a documentação?”.

Normalmente, em equipes heterogêneas no carater de senioridade, as solições podem pensar bastante diferente, fazendo com que só a documentação não seja suficiente. E esse cenário de equipes heterogêneas é o mais comum em ambientes de fabricas, onde se misturam plenos – chamados de seniors – com estagiários – chamados de juniors. Então, por ser um processo requerido – por exemplo no CMMi – um pleno desenvolve e um estagiário revisa.

Caso Veridico

Esse lance de revisão me lembra um caso acontecido com um grande amigo meu.

Lá no inicio de vida, a ‘tia’ avisa que fará o ditado do emprego de L e do U, mas que haverá uma surpresa na correção, que será feita pelo coleguinha ao lado. Pois bem, começou o ditado e André foi escrevendo:

1. Salto
2. Alto
3. Saudade
4. …

Ao fim, a professora pede pra trocar com o coleguinha ao lado e André troca com o seu amiguinho Filipe (nome fictício). Ao começar a ver o ditado, André percebe que Filipe inverteu todos os empregos de U x L, colocando Sauto, Auto, Saldade, etc. Com isso, André começou a dar errado em cada item do ditado, fazendo com que Filipe ficasse com zero. André entrega a prova a Filipe e recebe a sua. Ao ver o seu ditado, André fica indignado! Filipe corrigiu tudo como escreveu (Sauto, Auto, Saldade) dando zero para André tambem! (É mais engraçado ele contando…)

Conclusão: Pessoas de niveis diferentes não conseguem estabelecer um nivel de revisão satisfatório.

Programação em Par

Já na programação em par (Pair Programming) as duas pessoas estão no mesmo momento desenvolvendo o código, fazendo com que a conversa, as duvidas e as soluções faça o código sair da melhor maneira possivel para as duas pessoas, evitando retrabalho.

Moral da História: se fosse um ditado em par, de repente, Filipe aprenderia mais rapido e as notas seriam melhores na turma toda.

Obs.: Um ótimo post da InfoQ-Br.

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