Ao elaborar um projeto, tem-se um dilema: qual metodologia seguir? São tantas que temos de analisar qual irá atender melhor ao projeto. Por que resolvi criar um post com esse assunto? Tem certeza que você não sabe? Ora, atualmente está na moda dizer por aí que você faz parte de um projeto que utiliza uma metodologia ágil, seja qualquer uma delas, essa é a verdade. A maioria das empresas que não adotaram esse tipo de abordagem de gerência de projeto estão incluindo-a em seus escopos.
Segundo o pai dos burros (o dicionário), metodologia significa: subdivisão da lógica que estuda os métodos técnicos e científicos; ou ainda melhor: conjunto de regras para o ensino de uma ciência ou arte;
Eu acredito que focar na mão-de-obra, tornando-a capacitada e produtiva, ainda é melhor do que fazer com que passem por um conjunto de regras para poderem fazer algo. Então vamos consultar no dicionário o significado de outra palavra muito utilizada junto com metodologia: ágil. Segundo ele (o dicionário), a palavra ágil significa: leve, ligeiro. Logo, o termo metodologia ágil não seria para tornar o desenvolvimento mais rápido, mais produtivo? O Scrum está com esse pensamento, você pode ver nesse artigo da Caelum, nesse livro gratuito e também nessa palestra.
Não sou contra metodologias ágeis e nem estou fazendo propaganda para não utilizá-las em projetos, apenas quis enfatizar no parágrafo acima que é importante pensar muito antes de querer incluir alguma metodologia em um projeto. Claro que é bom para a empresa, colocar uma metodologia em seus projetos, estampar no peito e mostrar para os clientes que utiliza uma metodologia X, Y ou Z. Mas o importante mesmo é: entregar o projeto do jeito que o cliente pediu e no tempo que ele pediu.
Na minha pouca experiência profissional já vi casos de empresas que utilizam essas metodologias concluirem bem um projeto, mas em outros casos vi projetos atrasados e com clientes insatisfeitos. Mas será que a culpa é da metodologia ou será que a forma como foi aplicada não foi correta? Estou participando de um projeto que não utiliza nenhuma dessas metodologias citadas e ele está indo muito bem.
Não vou ser o primeiro, nem o segundo e muito menos o terceiro a falar sobre esse assunto. O grande lance é: fique atento ao mercado. Se o mercado exige que você conheça pelo menos uma dessas metodologias, então aprenda, o que importa é isso. Ou, se você for um daqueles que gosta de ler sempre, compre alguns livros e se atualize antes mesmo do mercado exigir.
Assinar:
Postar comentários (Atom)
3 comentários:
Sabe o que é pior?
Eu achava que o errado era a metodologia, mas hoje eu vejo que são as pessoas...
Nesses próximos 12 meses veremos aquelas empresas que hoje são criticadas por usarem o RUP sem ser o RUP, usarem métodos ágeis sem serem ágeis...
Tá uma onda crescente de entusiastas de Scrum, mas são os mesmos que hoje criticam os métodos ágeis. Só que, quando comecarem os grandes CMMIs a usarem, eles todos correrão atrás e o ciclo recomeça...
Os valores e princípios são mais importantes que a prática, enquanto não entenderem isso, não adianta nada trocarem de metodologia, qualquer dia escrevo sobre isso. :)
Excelente post Rafael, parabéns :))
Meus dois cent's..
Em todos os projetos que participei nunca foi adotado uma metodologia como RUP, Xp ou Scrum, sempre se utilizou uma metodologia que se adequou ao projeto, ao cliente e principalmente a equipe. E olha que participei de projetos críticos com prazos demasiadamente curtos onde conseguimos termina-los com êxito.
Acredito que são as pessoas envolvidas no projeto que fazem a diferença, sendo na minha opinião a melhor metodologia/processo é aquela que se adeque principalmente a equipe de desenvolvedores, analistas, projetistas e gerentes, não importa se é Xp ou RUP ou mesmo uma mistura das duas e de mais algumas, o importante é que a equipe esteja sincronizada, organizada e principalmente satisfeita com a metodologia escolhida :)) Assim teremos no final um produto de qualidade, no prazo estipulado e um sorriso maroto do cliente de satisfação.
Novamente parabéns pelo post Rafael.
Rafael,
Você colocou como meta:
"Mas o importante mesmo é: entregar o projeto do jeito que o cliente pediu e no tempo que ele pediu."
Porem sabemos que o cliente nunca sabe o que quer e pede o que acha que precisa... seria como o medico tratar o paciente segundo o diagnostico que o paciente da e depois culpar o paciente porque não sabe fazer o seu proprio diagnostico, o paciente sabe da "dor" não do tratamento a ser dado, isto quem sabe é o medico.
Por isso acho que cada vez mais em software a nossa meta tem que ser:
"Solucionar o problema do cliente o mais rapido possivel ou seja agregar mais valor, no menor tempo possivel"
Abraços,
Juan.
Postar um comentário