Para quem gosta de etimologia, a palavra “metodologia” vem da junção de duas palavras gregas: methodos, que significa "modo para se chegar a um determinado fim ou objetivo" e logia, que significa estudo. Logo, no sentido mais lato, metodologia pode ser definida como o estudo dos métodos para se atingir um objetivo.
Especificamente no desenvolvimento de software, a seguinte citação ajuda a explicar:
“Metodologias impõem um processo disciplinado no desenvolvimento de software, com o objetivo de torná-lo mais previsível e eficiente. Elas fazem isso desenvolvendo um processo detalhado com uma forte ênfase em planejamento” (Martin Fowler)
Sem dúvida, a proposta das metodologias é muito boa. E, de fato, as metodologias que se tornaram populares são realmente boas, tendo sido concebidas por respeitáveis profissionais de desenvolvimento de software. A questão não é se as metodologias são boas, mas se a ênfase dada a elas é adequada.
Para entender melhor, pense em alguma atividade manual que você realize com alguma frequência. Pode ser montar um computador, lavar o carro, aparar a grama etc. Se você listar os procedimentos envolvidos nessa atividade, identificar padrões de ação que se repetem e encontrar os meios mais eficientes e seguros para realizar essas ações, você terá o suficiente para criar uma metodologia que otimize essa atividade. Parece fácil criar uma metodologia para esse tipo de atividade, certo?
Agora, suponha que você queira criar uma metodologia para uma atividade intelectual tal como criar músicas, pinturas ou esculturas*. Concorda que nenhuma metodologia garantiria a produção de belas músicas, pinturas ou esculturas? Você provavelmente concorda porque sabe que quando se trata de um trabalho intelectual, o resultado final não depende da forma como o trabalho foi estruturado, planejado ou conduzido, mas do talento de quem o executa.
Ora, o que é o desenvolvimento de software – um atividade manual ou intelectual? Sendo uma atividade intelectual, há uma barreira que as metodologias não conseguem transpor: a necessidade de pessoas talentosas para executar o trabalho.
“O problema, na maioria das vezes, é que metodologia se opôs à noção que as pessoas são fatores de primeira ordem no sucesso de um projeto.” (Martin Fowler)
Não compreender que desenvolver software é um trabalho predominantemente intelectual é a causa de sérios equívocos na indústria de software, entre eles, tratar software como algo determinístico, que pode ser produzido em série, como numa fábrica. Sob esse olhar equivocado, basta uma boa metodologia e uma equipe obediente disciplinada que o resultado final será maravilhoso. "As pessoas não são importantes, mas sim as suas funções. Mais importante ainda é o processo. Se alguém deixa a equipe, basta substituí-lo por outra pessoa que exerça a mesma função e a engrenagem da fábrica continuará funcionando, afinal, ninguém é insubstituível."
Isso pode soar correto na teoria, mas na prática, resulta em softwares que até atendem aos requisitos funcionais, mas falham em atender aos requisitos não funcionais como facilidade de uso, rapidez e manutenibilidade.
“Não há pesquisas e estudos suficientes sobre como se organiza o trabalho intelectual ou criativo. Na falta desse conhecimento, a empresa aplica para intelectuais as mesmas regras criadas para os trabalhadores manuais [...] A conseqüência é que a criatividade fica reprimida e diminuída.” (Domenico de Masi)
Se você quer fazer bom software, tenha uma equipe talentosa e dê a ela boas condições de trabalho. Metodologias serão de ajuda, desde que sirvam como um plano geral, constantemente adaptado ao tipo e às circunstâncias de cada projeto.
Gostou desse artigo? Ficarei feliz ao ler seu comentário.
—
* ^ Para efeito de desambiguação, estou usando a seguinte definição para atividade/trabalho intelectual: "Trabalho intelectual é o que envolve a manifestação do intelecto, em todos ou qualquer dos seus sentidos: intuitivo, operativo ou compreendente, ou seja, a ação criativa ou recriativa, de ordem física e/ou mental, concebida a partir da compreensão abstrata do objeto." (LIMA, Francisco Meton Marques de - Âmbito Jurídico)
Crédito da foto: National Geographic (elefante pintor do Thailand Elephant Conservation Center)
Referências:
- Martin Fowler. “The new methodology”.
- Tom DeMarco & Timothy Lister. "Peopleware"
- Alexandre Gomes. "Manifesto 2.0"
- Domenico de Masi. "Organizações Criativas"
22 comentários:
Muito bom!
Você descreveu, na minha opinião, um cenário triste que existe hoje na indústria por aqui.
A indústria está querendo apenas absorver engrenagens para suas máquinas e não busca polir, principalmente os recém-chegados das instituições de ensino, inibindo o potencial de muitos e até mesmo descartando possíveis profissionais excelentes.
Concordo com você, Leandro. Não é muito comum ver as empresas proporcionarem um ambiente fértil para o desenvolvimento profissional. E isso vale tanto para recém formados como para profissionais experientes. Nem me refiro com isso a patrocinar cursos, me refiro a proporcionar um ambiente criativo onde os talentos possam aparecer e se desenvolver. Acredito que esse cenário predominante só vai mudar quando tivermos mais gerentes e gestores que entendam o que é fazer software.
Impressionante como vc pensa exatamente como eu.
Infelizmente, muita gente, mas muita gente mesmo da indústria de software, acredita que software é de fato produzido em série.
Pior ainda, programadores são comparados com pedreiros, por pessoas que se dizem analistas. Eu fico loucoooo quando me dizem que programador não tem que pensar.
"Programador tem que fazer, não tem que pensar";
"Meu professor disse que...";
"EU ACHO que...";
Senhor, perdoai-vos, eles não sabem o que dizem.
Conheço analistas que dizem para Deus e o mundo: "Não gosto de informática, não gosto de computador".
E lá vai eu explicar tudo isto que vc escreveu para um...analista de sistemas???
Veja uma empresa de porte médio, com inúmeros clientes no Brasil inteiro:
1) Tem pessoas que querem corrigir todos os problemas dentro de uma versão só;
2) Tem pessoas que não sabem ou não querem priorizar, e preferem se apegar a detalhes( o ícone está grande demais ) quando o circo está pegando fogo;
3) Muita gente ACHA muita coisa, e eu sou obrigado a escutar cada um em prol da democracia.
Então as pessoas que não sabem fazer SELECT, ACHAM inteiro melhor que booleano, pois o professor dela disse que Oracle não tem booleano;
Gerentes e gestores que não entendem de software também são um problema.
Pessoas talentosas e que realmente tem conhecimento são mais caras, então eles contratam pessoal ruim por um custo menor, sem perceber que a longo prazo o custo dele é 5 vezes maior, e a qualidade do produto vai lá em baixo.
Eu nunca peguei um bisturi e sai por ai dizendo que sou médico;
Eu nunca peguei um compasso, um lápis e sai por ai dizendo que sou engenheiro civil;
Porque alguém que vendia sistema, ou dava suporte de um sistema sai por ai dizendo ser analista? Sem o mínimo de conhecimento.
Um analista que não consegue projetar uma tela quer dar sugestões em algorítimos críticos.
Realmente algumas coisas não valem a pena na vida.
Eu ainda estou tentando aprender a abstrair, prometi a mim mesmo que não vou tentar ensinar um pato a ser um ganso.
Minha saúde agradece.
Foi um baita desabafo, Vinicius. Há certas mudanças que gostaríamos de fazer, mas simplesmente não valem o esforço. É sensato da sua parte, nesses casos, não "tentar ensinar um pato a ser ganso". Não é satisfatório trabalhar assim, mas podemos tirar proveito dessa insatisfação. É ela que nos tira da zona de conforto e nos move para frente.
Obrigado por acompanhar o blog! Um abraço.
Opa,
Muito bem colocado no último parágrafo em negrito!
Acredito que ter uma equipe talentosa produzindo software é essencial.
Na verdade, entendo que uma equipe talentosa E uma metodologia bem utilizada leva à produção de um produto com qualidade.
Assim, acredito que um puxa o outro, ou seja, com uma equipe talentosa, a metodologia pode se adaptar e tornar-se boa, e uma metodologia boa é útil para atrair novos talentos para a equipe! Um ciclo!?!
Até!
Concordo que a diferença esta no foco da equipe :
Usuario X tempo
Olá Sergio,
Muito bom seu comentário! Concordo contigo que o conjunto formado por uma equipe talentosa + uma metodologia bem utilizada tende a produzir software de qualidade. "Utilizar bem" é muito diferente de simplesmente "utilizar".
De alguma maneira, uma metodologia sempre é utilizada, ainda que a equipe não se dê conta disso. Todo trabalho segue processo mais ou menos planejado; não dá pra começar um projeto sem isso.
Mas, certamente, as Metodologias ficam mais evidentes quando elas têm um nome e seguem uma "cartilha", tal como RUP, XP, Scrum etc.
Seja qual for o caso, utilizar bem uma metodologia (com "M" ou com "m") significa aplicá-las nos projetos adequados e adaptá-las às circunstâncias do projeto ao longo do tempo. Não dá pra utilizar a mesma metodologia em todos os casos. E pode ser que as circunstâncias do projeto mudem ao longo do tempo, fazendo com que o processo que era uma ajuda no início do projeto se torne um obstáculo ao longo dele. Isso se aplica a qualquer Metodologia, incluindo as Ágeis, que são as que mais gosto.
Uma equipe que percebe seu talento como mais importante que metodologias e processos, certamente tem sua autoestima elevada, o que gera comprometimento e contribui para a fluidez dos processos. Numa equipe assim, quem não gostaria de trabalhar?
Olá Edg. Não entendi sua colocação.
Muito bom o tópico, estamos passando por um processo de padronização de código na empresa, vou repassar para minha equipe.
Olá Dirlei!
Qto tempo ñ deixo um comentário aqui. Meu trabalho é metodologia, vc sabe, né? Manualidade, de vez em quando, até em produção!...rs...Mas acho incrível a capacidade que vcs têm criar sistemas que facilitam algo que, pra um inexperiente, já era fácil. Vcs fazem o fácil tornar-se prático e rápido!
Agora, aqueles que insistem em reprimir esse talento por que se apegam a metodologias (como disse um dos comentaristas aqui em cima "meu professor disse", "fulano sempre fez assim...")acho que na verdade ficam um pouco...como posso dizer...intimidados (ñ sei se seria a palavra certa)com novidades. Com gente nova, com cabeça fresca(diria minha mãe) que possa superar expectativas. Infelizmente só ñ admitem o processo de especialização e criação numa única pessoa! rsrssss...Gente, pelo amor de Deus, o que não existe é coelho que bota ovo de chocolate! kkkk
Parabéns a vc e a seus seguidores com esse talento!
Legal, Rodrigo! Depois, gostaria de saber qual foi o feedback da sua equipe. []'s
Olá, Regina! Fazia tempo que você não me fazia uma visita : ) Você pegou bem o espírito da coisa, há sim um pouco de resistência a mudanças, principalmente quando elas vêm de baixo para cima.
Sobre o seu trabalho (artesanato para os que não sabem), acho que você não usa uma metodologia durante todo o tempo. Durante a fase de criação (antes da execução), seu trabalho é puramente intelectual. Nesse momento, creio que o resultado depende do seu talento, não do método. Você não é como o elefante da foto, que apenas executa o desenho que foi ensinado a pintar. Você inventa, cria e isso nenhuma metodologia pode padronizar.
Obrigado pela visita! []'s
Pensando bem, vc está certo. Obrigado por notar essa parte do meu trabalho. Por falar nisso, minha sobrinha recebeu um trabalho de escola. Todos foram incentivados a criarem suas próprias versões em desenhos ou pinturas sobre uma historinha que ouviram lá. Adryanne ñ quis ficar só nisso! Correu pra me contar e, pra surpresa da professora, da 'tia' da sala de leitura e o diretor, ela informou que me pediria ajuda pra reproduzir a historinha de outro jeito: Em linhas e lãs!
Imagina só: Vamos criar os personagens da história! Vamos fazer bichinhos de crochê, com roupinhas e tudo mais que tem na historia!
Falamos com o diretor sobre isso e ele pediu que tirássemos fotos do processo todo que vamos utilizar. E, pra completar, ele convidou a autora do livro pra ir lá na escola da Adryanne ver isso de perto. Ela aceitou! Quando estiver quase tudo pronto eles marcam a data com ela.
Legal, né?
Sem métodos! Pura criação!
P.S.: Sempre visito seu blog. Mas às vezes ñ sei o que comentar. Tento encontrar conselhos para o meu tipo de trabalho, daí faço um comentário paralelo. Mas ñ quer dizer que ñ visito.rsrssss...Estou sempre por aqui!
Tchau! Até o próximo post!
Muito legal, Regina! Se a professora da Adryanne tivesse tentado "ajudar" os alunos com algum tipo de Metodologia, essa criatividade dela talvez não tivesse emergido. Depois quero ver as fotos : ) [ ]'s
Olá, Dirlei!
Concordo com tudo o que foi escrito.
Penso que, talvez, esse ponto de vista só se manifeste em pessoas que já passaram pelo problema de não serem completamente aproveitadas em suas produções.
Enquanto lia, eu dividia, internamente, metodologias para análise e metodologias focadas em programação. Acho que a última fica bem mais em evidência com as suas palavras. Como há muitos algoritmos prontos para determinados casos, na maioria das vezes, os programadores seguem logo a ideia do reuso. Embora seja realmente proveitoso utilizar algo que é comprovadamente bom e que evita a perda de tempo de se reescrever o código, acho que perde-se o foco de ultrapassar os limites. Se uma coisa é boa pode ficar excelente, até que o excelente seja intransponível.
Parabéns pelo blog! Admiro muito essa organização.
Opa, Felipe,
O que você citou se aplica bem à metáfora "reinventar a roda". Muitas vezes vale a pena usar algo que já existe, está testado e pronto para o uso. Mas é importante não fechar os olhos para as oportunidades de criar algo melhor, novo e diferente. Para isso é preciso ter mente aberta, bom senso e não ter medo de mudar de opinião.
Obrigado pelos seus comentários positivos! Grande abraço!
Grande Dirlei,
Como sempre trazendo assuntos super interessantes e polêmicos na mesma medida.
O tema metologia possui diversas (e controversas) definições. Tenho outra definição: metodologia é a superclasse abstrata da classe processo. Processo sim, conseguimos definir de forma mais concreta.
Pelo que pude perceber o artigo promove uma reflexão sobre o peso de uma metodologia no desenvolvimento de software e a capacidade criativa dos desenvolvedores. Realmente, concordo com você que precisamos de grandes talentos para criar software. E mesmo os grandes talentos precisam de inspiração (como você citou, "boas condições de trabalho" ajudam e muito).
Agora, se nos afastarmos um pouquinho e olharmos todo o processo (juro que não queria utilizar a palavra "processo"), que vai desde o levantamento de inicial das necessidades do cliente, a parte comercial, o detalhamento dos requisitos sistema, a validação dos requisitos junto ao cliente, o plano de testes (até aí não entramos em criação e sim em comunicação), a arquitetura, o desenvolvimento (sim, criação!), a homologação, os ajustes, ..., a comunicação entre toda a equipe e a gerência de tudo isso.
Ufa... seria interessante se para organizar todas essas atividades tivéssemos algo que nos ajudasse... processo??? Caso seja, este processo deve ser leve e flexível o suficiente para aderir aos variados tipos de cenário que encontramos na prática, funcionando como um alicerce para a criação de software de qualidade.
Um forte abraço!
Grande Guterres!
É uma satisfação receber sua visita e ver seu comentário no meu blog! Você pegou bem a idéia das reflexões que quis provocar com esse artigo e seu comentário foi bastante pertinente.
Fazer software realmente envolve uma série de atividades que, na maioria das vezes, começam muito antes de qualquer linha de código ter sido escrita. Para fazer um bom software é importante conhecer essas atividades e saber conduzi-las.
Você tem razão, seria interessante termos algo para nos ajudar a organizar todas essas atividades. Penso que esse "algo" não seja "um processo", mas "o conhecimento sobre processos" (de desenvolvimento de software, especificamente). Esse conhecimento ajuda a criar um "plano geral" flexível, mas não no sentido de que todos os cenários estejam previstos e tenham um "roteiro" de como agir, mas no sentido de que, dado o tipo de projeto e as circunstâncias (a equipe, o gerente, o cliente, o prazo, o orçamento etc), haja a liberdade para que o gerente e a equipe planejem (o plano geral) como esse projeto será conduzido e ajustem esse planejamento ao longo de todo o projeto.
Não sei se esse "plano geral" pode ser chamado de "processo". Se for, a concepção desse processo, sua execução e seu ajustes serão úteis para outros projetos, mas não o processo em si e sim o conhecimento adquirido com ele. Acredito que nenhum projeto (tipo+circunstâncias) seja igual a outro, logo, mesmo um excelente processo usado num projeto pode oferecer ajuda limitada quando aplicado a outros projetos.
No final das contas, o resultado final dependerá na sua maior parte, do talento da equipe e das boas condições de trabalho. Parte desse talento envolve a capacidade de descobrir qual o melhor processo para cada caso e o bom senso para mudar o processo quando for apropriado.
Gostei muito do seu comentário e da troca de idéias que ele nos proporcionou.
Sinta-se a vontade para escrever mais sempre que desejar.
Grande abraço!
Nossa como seu blog está movimentado! prometo que no dia que eu parar de odiar meu trabalho eu comento direito.
Puxa, se você chegou nesse ponto, é melhor acelerar a sua mudança de ramo. Como diz Steve Jobs, "a única maneira de fazer um bom trabalho é amar o que você faz".
De qualquer forma, fiquei feliz com a sua visita! : )
Dirnei,
Conheci hoje o seu blog e achei bem interessante os temas.
Concordo com você!
Sempre encontrei uma relação entre a qualidade da equipe versus ortodoxia das metodologias. Quanto mais fraca a equipe, mais o projeto se beneficia das metodologias menos flexíveis.
Em particular, bons profissionais costumam ter um certo desprezo pela metodologia, no máximo aceitando-a como uma base flexível de trabalho, porque elas associam métodos a arreios que freiam a criatividade e ainda geram trabalhos inúteis e chatos.
O perigo das metodologias praticadas em excesso é gerar muito metatrabalho, que pode terminar atrasando significativamente o cronograma de um projeto de desenvolvimento. Além disso, trabalhos chatos costumam ser "matados" e feitos de forma semi-automática e com baixa qualidade.
No meu modo de pensar, isso vale tanto para TI, quanto para gestão de projetos e processos em geral.
Oi Paulo, concordo plenamente com o que você disse. Quando estava lendo, imaginei como seria se alguém hoje pudesse contratar Picasso para pintar um quadro. Só um louco o tentaria convence-lo a usar uma determinada metodologia ao invés de deixá-lo organizar seu próprio trabalho. Mas é isso o que muitas empresas tentam fazer. Querem os melhores profissionais, mas os restringem com metodologias e processos burocráticos.
Obrigado pela visita e pelo comentário.
Grande abraço!
Postar um comentário