Smarana

Discussões sobre Memória Organizacional em ambientes de desenvolvimento de Software

A falta de confiança na execução de projetos

Hoje participei do meu primeiro coding-dojo. Não por falta de vontade, mas por impossibilidade de aceitar os convites anteriores. Marlon fez uma rápida apresentação sobre o que seria abordado – BDD, Ruby e Cucumber. Não tinha dúvidas sobre o aproveitamento e esperava até mesmo o acanhamento usual de não conhecer nada que estava sendo exercitado. Após uma rápida demonstração de Serge, aprendi como de fato a coisa acontece.

No decorrer do dojo, observei algo que já percebia no uso de processos tradicionais e ditos super-onerosos. A falta de confiança no trabalho (próprio ou da equipe) é fator preponderante no aumento da carga de trabalho. Quem acompanha meus comentários, sabe que sou combativo a assunções que denigrem métodos e processos sem uma fundamentação forte. Primeiro porque as pessoas que desenvolvem esses trabalhos o fazem com grande esforço, estudo e experiência – e denegrir é uma extrema falta de respeito com essas pessoas. Também aprecio o rito científico de evolução e revolução de teses (a ciência é uma comunidade colaborativa e não uma guerra de feudos).

Voltando ao dojo, percebi que não foi dada especial atenção à tradução da especificação nas features. Uma atenção que deveria ser dada num caso de projeto real, mas para fins do dojo é perfeitamente aceitável o nível de tolerância aplicado. Durante a implementação em Ruby, observei com bastante atenção comportamentos que oneraram bastante o desenvolvimento – e que nada tem a ver com o nível de expertise da linguagem.

O conjunto de features era lido como uma única coisa, como se estivessem implementando um Caso de Uso – que jamais fora especificado. O pensamento era sempre “o cliente pede, aí o sistema valida, aí faz tal coisa, aí acontece isso”… coisas que estavam em steps distintas. Obviamente o Cucumber acusava que os comportamentos não estavam sendo respeitados. Tendo que manipular mentalmente todas as variáveis envolvidas (e Baby-steps? Cadê?), MAIS a obrigação de atender às exigências do Cucumber deixavam as pessoas meio perdidas. Resultado: mais tempo para fazer menos.

Outro problema era que as pessoas comparavam as features com a especificação – e aqui reside minha maior preocupação. Conhecendo processos de tradução dentro e fora do universo a informática, posso dizer que isso é o maior crime contra a produtividade. A rigor, features deveriam ser a tradução da especificação declarativa (em qualquer meio… escrito, por oralidade etc), tornando-se única fonte para a implementação dos steps, pois devem conter todos os comportamentos esperados (daí BDD). Seguindo o fluxo, features são traduzidas em steps – que, da mesma forma, devem ser totalizantes – e finalmente traduzidos no código que implementa o comportamento esperado.

Entendam bem… revisar é ótimo para ter um produto de qualidade – contestar isso é idiotice. O viés aqui é outro. Se a tradução não for feita corretamente, pode e deve ser corrigida o quanto antes. Mas além de tudo ter seu tempo, é fundamental que a tradução seja feita com segurança, para que a corrente da transferência de informação não seja quebrada. Revisão de tradução deve ser feita tão logo o produto tenha sido criado (e, se possível, fazer revisão por sub-produto ou capítulo) para evitar corrupção do sujeito pela associação de outros fatores como tempo e informações contraditórias às fontes originais de informação ou ainda, o que é pior, ideias mirabolantes.

O pior de tudo, a confiança, destrói por completo a produtividade. Isso ocorre quando assumimos que a tradução não foi feita corretamente. Como consequência temos:

1. O programador se preocupa em programar E revisar as fontes de informação – desnecessário dizer que isso causa sobrecarga, levando a atrasos;

2. A fonte intermediária de informação perde sua função – se vou usar a especificação, o trabalho e o produto da tradução não serviram de nada. Além do aspecto gerencial do esforço e custo crescentes no projeto, há pelo lado humano uma falta de respeito com o tradutor;

3. A falta de confiança permeia a equipe, gerando incertezas sobre o projeto. Assumir que coisas erradas acontecem significa estar pronto para corrigir quando elas forem percebidas e não revisar repetidamente artefatos (que é uma das maiores reclamações sobre processo tradicionais e que, pelo visto, vem se repetindo)

O que mais escuto é que estou pensando em um mundo perfeito… mas minhas observações estão muito longe disso – elas falam de um mundo onde a pessoa é valorizada, em que haja reconhecimento e confiança em seu trabalho. E se uma pessoa não tiver as competências necessárias para fazer a tradução, que ela seja aproveitada melhor onde ela trará resultados mais significativos.

Anúncios

Um comentário em “A falta de confiança na execução de projetos

  1. Marlon
    sexta-feira, outubro 29, 2010

    Muito bom. Fez uma ótima observação sobre o Dojo. E as seções de Coding Dojo em muito enriquecem neste aspecto. Observamos como as pessoas não estão acostumadas a este novo paradigma. Por mais que eu tenha pedido para que usassem Baby Steps, algumas pessoas sequer olhavam para mim enquanto eu falava isso.

    Todo mundo está acostumado mesmo é a programar direto e pensam que teste é bobagem. Mas é tudo perdoável, uma vez que as pessoas estão aprendendo esta nova ideia. É normal encontrar alguns que sentem dificuldades em largar os velhos costumes.

    As vezes eu tenho excesso de confiança também (não sei se este é o termo). Como sou uma pessoa muito aberta (lá ele) a novas ideias e a participar de atividades deste tipo, acabo sendo levado a acreditar que todo mundo é assim também. É só observar que eu não expliquei muita coisa no início e quis entrar de vez na prática. As pessoas ficam assustadas. Parece que estão com medo e que acham que vão passar vergonha se chegar lá na frente e simplesmente perguntar como faz! Já eu, acho natural. Sempre fui acostumado a fuçar por conta própria e a perguntar quando não sei ou não encontro a resposta no google 🙂

    Outra coisa que sempre percebemos em Dojos é que as pessoas se preocupam com a solução. Algumas saem frustradas porque acham que foram péssimos porque só conseguiram programar 1 linha. Ou porque não conseguiram fechar mais do que uma feature. O objetivo do Dojo não é a solução!!!!! O desafio é só um argumento para juntar as pessoas para aprender. Mas, pra muitos, todo o aprendizado do dia é jogado no lixo por causa desta frustração. E já percebi que aprendemos muito mais quando a seção de Dojo é como a de hoje. Cheia de discussões, ideias e etc.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado em sexta-feira, outubro 29, 2010 por em Processos e Metodologias.

O Autor

Twitter

Goodreads

Oath of non-allegiance

Oath of non-allegiance

Oath of non-allegiance

%d blogueiros gostam disto: