Menu fechado

Só Agilidade funciona

Este conteúdo que postei só pra iniciar o blog faz críticas duras a maneira como projetos de software são construídos ou gerenciados. Muitas empresas utilizam essas má praticas e já esperava que a opinião de muitos leitores iriam divergir. Vou tentar explicar um pouco mais meu ponto de vista.

De qualquer forma, desculpem a sinceridade, desculpem se isso pode ofender alguém, desculpem falar “na lata”, mas AGILIDADE FUNCIONA.

Desde 2005, quando iniciei a área de treinamento da ASPERCOM ouço constantemente uma afirmativa. Seja em palestras, seja em fóruns de discussão, seja em treinamentos, seja em consultoria ou projetos que participo, sempre ouço participantes dizendo “Tudo o que você falou que é errado é o que praticamos na nossa empresa.”

É triste mas é verdade. Existe um gap muito grande entre a teoria e a prática na nossa área de desenvolvimento de software. Por exemplo, neste ano de 2008 já tive contato com aproximadamente 200 profissionais em treinamentos. Numa pesquisa rápida, TODOS disseram praticar o processo de desenvolvimento em cascata (waterfall), mesmo que este modelo seja comprovadamente ineficiente e seja refutado por TODOS os autores que escrevem sobre desenvolvimento de software. Até mesmo o autor que cunhou o termo “Waterfall” já reconhecia que era um modelo que não deveria ser utilizado, que é um anti-pattern. Teve um aluno de uma turma de UML que ainda foi mais enfático “- É lógico que todo mundo aqui faz software em cascata!”.

Antes de continuar, para tentar explicar porque só agilidade funciona, vamos ver uma “ilusão” que o mercado tem chamado de “Modelo Tradicional” (ou agora também temos o “Modelo Controlado”, mais um devaneio inconsequente escrito por um “especialista” sem noção).

Modelo Tradicional x Modelo Ágil

A pergunta que me levou a escrever é: O que é o Modelo Tradicional? Durante aproximadamente uns 2 meses perguntei em praticamente todos os fóruns de discussão que participo (veja links do Blog) o que seria o modelo tradicional. Essa pergunta foi provocativa, mas ao mesmo tempo elucidadora para muitos. O fato é que NINGUÉM soube responder o que é o Modelo Tradicional. Ninguém soube explicar, ou citar, que autor escreveu ou defendeu algo chamado “Método Tradicional de Desenvolvimento de Software”. Nenhum modelo de processo é Tradicional. O Modelo Tradicional não existe.

Alguns citaram que o modelo tradicional é o Waterfall. Bem, como expliquei aqui, o Waterfall não é defendido em nenhuma literatura. Ok… ele pode ser tomado como tradicional pois é o modelo mais utilizado, porém, o modelo waterfall não tem sustentação teórica. Nenhum autor sério defende waterfall. Como pode pois a nossa indústria estar usando um modelo que desde o nascimento foi taxado como anti-pattern? Se o Waterfall é o modelo tradicional, seguimos uma tradição bem burra.

Outros citaram que o modelo tradicional é o RUP. Mais uma discordância aqui. O RUP é um “agile process framework”. Jacobson, Larman, Booch, Ambler são Rupeiros de plantão como eu e praticam agilidade. O problema com o RUP é que poucos compreendem o RUP. Já ví muitos “especialistas” em RUP falando muita besteira no mercado. Aqui no Brasil conheço 5 a 10 pessoas que realmente conhecem o RUP. O mercado tem um poder enorme de deturpar coisas que ele não compreende (quantas vezes você não ouviu sarcasticamente que XP “é aquela metodologia que são dois programadores por micro”?). O RUP verdadeiro, o que consta na literatura, é ágil. Se o RUP verdadeiro fosse o adotado nas empresas todas seriam ágeis e este artigo não precisaria existir.

Outros citaram o SWEBOK como sendo o Modelo Tradicional. Bem, o SWEBOK é um body-of-knowlegde jogado as moscas. Ninguém tá procurando hoje SWEBOK. SWEBOK surgiu recentemente, assim, não poderia ser tomado como Tradicional. O RUP é um body-of-knowledge mais maduro e mais experimentado que o SWEBOK.

Se você nunca parou para pensar pergunte a sí próprio: Quem falou que desenvolvimento de software é sequencial como Caso de Uso – UML – Codificação e Teste? Quem disse que Gantt Chart é bom para desenvolvimento de software? Que pesquisa revelou que especialização e divisão do trabalho é uma boa idéia para software? Por que eu tenho que levantar todos os requisitos antes? E a principal: Se waterfall funciona por que meus clientes estão insatisfeitos?

Essas práticas não tem o mínimo fundamento teórico, nenhuma literatura prega que desenvolvimento de software é assim. Sim, você que é universitário pode questionar seu “mestre”, pois muitos não tem a mínima noção ou experiência no que estão ensinando. Essas práticas erradas são “idéias” que gerentes burros adotaram simplesmente fazendo um comparativo com linhas de produção da indústria. Eles se encheram de práticas sequenciais e colocaram uma placa na frente da empresa: “Fábrica de Software”. Eles simplesmente viraram as costas para os avanços da tecnologia e desenvolvem software como se estivessem furando cartões em 1960.

Com isso colocado, não vejo o mínimo sentido as pessoas afirmarem que são “tradicionalistas” no desenvolvimento de software e por isso não são ágeis. Não faz sentido pessoas dizerem “Eu desenvolvo software no modelo tradicional e estou estudando modelos ágeis”. Se você parar para pensar, essa pessoa começou agora a estudar desenvolvimento de software. Não confunda tradicionalismo com burrice.

Agilidade não é falta de controle

Como o já citado “devaneio inconsequente“, o mito mais comum é que modelos ágeis são descontrolados e que não dão informações para o gerenciamento. Quando falamos sobre controle temos que ter em mente o que realmente queremos com o projeto.

  • Como podemos planejar e ter precisão nas nossas estimativas?
  • Como devemos capturar os reais desejos do cliente?
  • Como incorporar as constantes mudanças no projeto?
  • Como fazer com que as mudanças não impactem aquilo que funciona?
  • Qual arquitetura é a certa para meu projeto?
  • Como garantir a manutenção futura do sistema?
  • Como saber o real andamento do projeto de uma maneira livre de riscos?
  • Como ter certeza que estamos satisfazendo a real necessidade do cliente?
  • Como fazer a equipe não se dispersar?
  • Como manter a documentação atualizada?
  • Como manter prazo e planejamento num projeto em constante mutação?
  • Como me antecipar aos riscos?
  • Quais são as ferramentas certas?
  • Como evitar correrias, horas extras e a explosão de custo no final do projeto?
  • E a melhor de todas: Como fazer o projeto ser entregue muito antes do prazo?
  • Creio que estas e muitas outras perguntas são dúvidas muito frequentes para qualquer equipe que desenvolve software. O mais interessante é que a resposta está na frente deles e se chama AGILIDADE.

    Os modelos ágeis são os modelos MAIS CONTROLADOS QUE EXISTEM. Se eu disser para você é possível fazer com que a equipe trabalhe motivada, focada em objetivos e que a assertividade das estimativas são muito próximas de 100% você acreditaria? Se eu disser para você que o simples fato de planejar baseado em objetivos e promover uma reunião diária de 15 minutos pode fazer com que a comunicação enriqueça e que o cliente sempre fique satisfeito mesmo com algumas falhas você acreditaria? As práticas do Scrum (que são baseadas no RUP) promovem esse tipo de controle.

    Outros pontos. Se eu falar para você que com seu código coberto de testes automatizados você poderá incorporar mudanças com uma segurança total você acreditaria? Se eu falar pra você que esses mesmos testes automatizados podem servir como documentação dos requisitos e do design de maneira executável, e que através de um relatório de cobertura e muitas outras ferramentas deterministas é possível saber se a “documentação” está atualizada de fato, você acreditaria? Essas são práticas do XP e da TDD.

    Se eu falar para você que aproximar o cliente da equipe de desenvolvedores, promover a colaboração e colocar “dois programadores para trabalhar numa mesma máquina” trocando pares é um excelente mecanismo para ganhar produtividade removendo atividades inúteis você acreditaria?

    A melhor resposta para o controle são práticas ágeis. Até o momento nenhum outro modelo provou ser eficaz. Nem Gantt, nem PMBOK, nem CMMI, nem MPS.BR são modelos completos que garantem respostas para as perguntas acima. Muito menos um mito, um dogma, um devaneio inconsequente que se criou nas mãos de pessoas que não sabem desenvolver software e chamaram isso de “tradicionalismo”.

    Práticas ágeis não competem com “alguma outra coisa” que funciona.

    Conclusão: (pela milésima vez)
    O modelo tradicional não existe.
    Só Agilidade funciona.

    30 Comentários

    1. Michel Vasconcelos

      Caro Rodrigo,

      Que tipo de processo você usaria para os seguintes casos:

      – Um sistema típico que já se conhece todos os requisitos previamente. Por exemplo: um compilador para uma linguagem de programação;

      – Um sistema onde o risco de se iniciar o desenvolvimento de alguma característica é maior do que esperar pela definição completa dos requisitos.

      Não que eu seja a favor do Cascata, mas acredito que ele se adequaria (e seria mais barato) nos casos acima.

    2. Luiz Augusto

      Excelente post!
      É impressionante como as pessoas fazem mesmas coisas e esperam resultados diferentes.

    3. Roberto Almeida

      Caro Rodrigo,

      Espetacular post, este é um assunto que deve ser a palta do dia de todas as empresas que trabalham com desenvolvimento de software, fui apresentado à metodologia ágil a cerca de três anos atrás numa empresa de software aquí de Fortaleza-CE (www.inteq.com.br), no início com uma certa desconfiança, mais logo que começaram as reuniões diárias, vimos que a sinergia dentro das equipes estava sendo consideravelmente incrementada e com isso passamos a ganhar mais agilidade e como consequência passamos a responder mais rapidamente a mudanças nos requisitos dos clientes. No início nossos controles eram feitos através de planilhas e documentação bastante precária o que levou a empresa a desenvolver sua própria ferramenta para gerenciamento de projetos com base nas premissas do Scrum. Apesar de ter saído desta empresa continuo utilizando, recomendando e implementando esta metodologia por todo lugar que eu vá, realmente antes da “AGILIDADE” vagávamos pela pré-historia do desenvolvimento de software.

      Grande abraço e mais uma vez, parabéns pelo post.

    4. Rodrigo Yoshima

      As linguagens de programação também seguem um desenvolvimento iterativo. Todas as linguagens. As JDKs do Java, Ruby, .NET, todas tem um “road-map” e estão evoluindo constantemente. Nesse tipo de cenário não trabalhar iterativamente é arriscadíssimo.

      Nosso amigo Rodrigo Kumpera tinha uma JVM como pet-project. Ele mesmo se preocupava em não ter um demo logo no início:

      http://www.kumpera.net/blog/index.php/2006/12/11/de-volta-das-ferias-retomando-meus-projetos/

      Lendo o Blog do AkitaOnRails, ví um problema parecido com o Ruby Core:

      http://www.akitaonrails.com/2008/4/22/a-t-vola-redonda-se-re-ne

      A construção de linguagens de programação também seguem desenvolvimento iterativo e ágil.

      Sobre o segundo cenário. Não consigo imaginar um software que é mais arriscado ter todos os requisitos do que começar a entregar resultado logo, principalmente nos projetos empresariais atuais. Projetos empíricos sempre seguem a máxima do Lean “entregue valor logo, demore para tomar decisões”.

    5. Pingback:Débito Técnico » Blog Archive » Síndrome da Gestão Covarde

    6. Michel Vasconcelos

      Olá Rodrigo,

      A resposta demorou. 🙂

      O fato de ser iterativo não indica ausência do modelo cascata. Na verdade, o cascata pode ser iterativo sim (principalmente quando pensamos na questão retrabalho – grande característica do desenvolvimento iterativo).

      Realmente você está correto quanto as VMs e outras linguagens de programação. Foquei em um pensamento mais acadêmico e esqueci das pressões do mercados por novas features nos compiladores e interpretadores.

      Quanto ao segundo cenário… nessa você me pegou. Eu quis “forçar” uma linha de raciocínio, mas não consigo formar um bom exemplo agora. Se eu fosse citar algum exemplo eu usaria um sistema de controle de tráfego aéreo ou um software que teria função piloto-automático para um avião. Nesses casos, você acha mais adequado usar um processo ágil? Ou talvez um cascata com algumas práticas de processo ágil? 🙂

      Talvez a minha discordância de alguns pontos que você postou baseie-se no que eu entendo por ser um Processo Ágil. O fato de um processo usar TDD ou desenvolvimento iterativo não o torna ágil. Concordas? 🙂

      De qualquer forma, diferenças de opiniões são totalmente salutares. Entendo o que você escreveu e concordo com muita coisa mesmo.

      Grande abraço!

    7. Michel Vasconcelos

      Só esclarecendo um comentário. Quando eu disse que o cascata também é iterativo, me referi ao fato de poder quebrar os estágios (Requisitos, Análise, Design, etc) em iterações. E não que ele se comporte como o desenvolvimento iterativo onde uso as várias disciplinas em cada iteração (estilo RUP).

    8. Rodrigo Yoshima

      Michel, de modo algum!!!!!!

      Cascata não é iterativo. Nunca foi, não é e nunca será iterativo. Seria legal você dar uma estudada melhor no modelo iterativo. Entrega de software constante é o cerne do modelo iterativo, por isso, cascata nunca é iterativo.

      Qualquer tipo de projeto de software que desenvolvo procuro ter um mecanismo de feedback constante. Um mecanismo que me fornecesse um andamento palpável do meu andamento. Só software funcionando e demonstrável é palpável. Isso independe da complexidade ou tolerância a falha que um software têm.

      Um processo ágil se fundamenta nos valores do Manifesto Ágil. Se o processo é iterativo e está sendo usado TDD pode ser que falte pouco para ser ágil. Se você me disser que além disso o cliente está presente e participando é bem capaz que eu julgue seu processo como ágil.

    9. Michel Vasconcelos

      Com certeza Rodrigo. Eu fiz uma grande confusão no meu último comentário . Realmente o cascata não é iterativo. Quis me referir ao fato de que o desenvolvimento iterativo pressupõe retrabalho, mas isso não quer dizer que o processo seja realmente iterativo.

      Quanto a questão de mecanismos de feedback, acompanhamento e prototipações, sugiro a leitura do artigo do Barry Bohem sobre o modelo espiral http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/spiral.pdf).

      Ele já citava que o cascata podia ter essas “novidades” àquela época (acho que 1988).

    10. Rodrigo Yoshima

      Michel… um erro comum é confundir retrabalho com novos requisitos descobertos com o modelo iterativo. A idéia do modelo iterativo é pegar um pequeno conjunto de requisitos, implementá-los e submetê-los ao crivo dos usuários. Se tiver novos requisitos no mesmo caso de uso, eles são NOVOS REQUISITOS. Isso não é retrabalho!

      O modelo iterativo é o único que não tem retrabalho nenhum. O cascata é que tem retrabalho. Você levanta um requisito e daqui a 4 meses quando for implementá-lo você vê que esse requisito não faz mais sentido e precisa revalidá-lo ou até refazê-lo. Isso sim é retrabalho!

    11. Michel Vasconcelos

      Oi Rodrigo,

      Nesse ponto eu discordo (Apesar da minha discordância ser motivada pelo conceito de retrabalho). Conceitualmente, o desenvolvimento iterativo baseia-se no retrabalho. Uma definição comum do modelo:

      “Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. It does not presuppose incremental development, but works very well with it. A typical difference is that the output from an increment is not necessarily subject to further refinement, and its’ testing or user feedback is not used as input for revising the plans or specifications of the successive increments. On the contrary, the output from an iteration is examined for modification, and especially for revising the targets of the successive iterations.”

      Maiores detalhes sobre a definição e relacionamento do modelo iterativo com o incremental (formando o chamado evolucionário) em

      http://en.wikipedia.org/wiki/Iterative_and_incremental_development
      http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development

    12. Pingback:Débito Técnico » Blog Archive » Product Owner: Um de$graçado ganancio$o

    13. Fernando Trapnell

      Rodrigo,
      Parabéns pelo post. Parece até que você previa o comentário que fiz hoje no GUJ…

      Uma das grandes discussões lá no GUJ realmente é esta separação entre RUP e CMMI e etc.. da modelagem Ágil, o que não tem nada a ver, uma vez que uma coisa complementa a outra e não são concorrentes.

      A minha opinião é que essa idéia de tradicionalismo é aquele monte de “artefatos” gerados em momentos de prazos escassos, e por isso, mesmo que numerosos NUNCA estão claros, completos e atualizados. Daí a grande diferença com a Modelagem ágil, que apesar de existir a um bom tempo, ainda se tem uma idéia de atitudes drásticas e mudanças radicais no processo de desenvolvimento, e tem muito esse medo do cliente querer mais coisa do que foi combinado.

      Minha discussão sempre foi, Pô já que tão fazendo todo este monte de documentos, porque não fazem documentos que prestem, que sirvam para o desenvolvimento e que sirvam para o futuro (manutenção)… Sempre criam um monte de planilhas, textos, e gantts que acabam não servindo pra muita coisa…

      Por isso pretendo me aprofundar mais na modelagem ágil e tentar convencer as pessoas a usá-la…

      Valeu Rodrigo.

    14. Pingback:Parem o mundo que eu quero descer ! « 1up4Developers

    15. Pingback:Débito Técnico » Blog Archive » O Mercado está mudando? (turmas de julho da Aspercom)

    16. Pingback:1up4Developers » Blog Archive » Parem o mundo que eu quero descer !

    17. Luiz Henrique

      Olá, excelente post.

      Acho que me enquadro na categoria dos que não conhecem o RUP, ou não entendem o RUP como ele realmente é. Por isso, algumas dúvidas surgiram ao ler esse ótimo post:

      O RUP é Ágil? Eu sempre acreditei que não, pois nele não consigo encontrar os valores ágeis, e quando comparamos o RUP com qualquer outra metodologia ágil aí sim é que fica ainda mais difícil de acreditar que o RUP é Ágil… acho que essa sua citação merece um post explicando realmente o que é o RUP 🙂

      As práticas do Scrum são baseadas no RUP?? Pensei que viessem do Lean.

      Fora isso, concordo plenamente com as suas opiniões.

      forte abraço,
      parabéns.

    18. LRenato

      Rodrigo,

      Acabei de ler o seu post, e posso de disser, que muito do que foi dito são verdades relativas. Concordo que os modelos Waterfall, Spiral entre tantos outros modelos podem não seguir ou estar baseados no manifesto ágil, mas apenas o manifesto, não movimento idéisa e pré-conceitos gerenciais, empresariais ou algo semelhante.

      Percebo na empresa em que trabalho atualmente (Waterfall), que todas as famosas resistências ao novo existem e e são latentes em todos os níveis hierárquicos da empresa. Porém, vou colocar algo que pode parecer estranho, mas acho que “cada cabeça de parafuso merece a chave de fenda correta”.

      Por que estou afirmando isso. numa empresa “enferrujada” por práticas não tão ágéis como as atualmente propostas, e cujo parque instalado remonta aos idos anos 70, sim, estamos falando de linguages velhas de guerra, como COBOL, CICS, DB2 entre outras ferramentas, como eu disso, não tão ágeis…..

      Num contexto em que essas linguagens e arquiteturas são ainda utilizadas, fica difícil, mas não impossível, aplicar os conceitos e valores ágeis, os quais respeito e utilizado no meu dia a dia e junto com a minha equipe, conquistando juntos vários desafios ….

      Falar ou mesmo garantir que nos primórdios, Análise Estruturada, Análise Essencial e tantos outros frameworks utilizados não é bom, ou mesmo taxá-las de velharias sem sentido me parece um nonsense …

      Me passa na cabeça agora a aseguinte dúvida, o que era a 7 maravilha do mundo em 60, 70, 80 hoje são relegadas a sua possível insignificancia histórica, assim, como poderá ocorrer com os métodos agéis … quando em 2050, alguém postar um blog dissendo frameworks ágeis nossa … era uma bagunça.

      Ao meu ver, cabe a nós a discussão dos usos e valores do ferramental que tem,os a nossa disposição HOJE e não, de certa forma, criticarmos ou mesmo levantarmos dúvida quando a utilização ou aplicabilidade desse ou daquele método, por isso, volto a afirmar … “cada cabeça de parafuso merece a chave de fenda correta” …

      Se hoje, podemos e temos o privilégio de estaremos participando ativamente ou indiretamente do Manifesto Ágil, levando suas idéais e valores para dentro de nossas empresas, devemos isso, justamente aos primordios, pois sem eles não teriamos parâmetros de comparação.

    19. Rodrigo Yoshima

      Renato, olhe creio que determinados ambientes não é possível a aplicação de métodos ágeis da maneira que os conhecemos. Ambientes e plataformas mais pesadas como Cobol, CICs e outras em plataforma mainframe pode ter certas dificuldades em aplicar iterações curtas, design emergente e etc… De qualquer forma, se pensar nos valores ágeis do manifesto e não nas suas práticas de mercado é possível ter uma postura centrada no usuário e mais humanizada.

      De fato, faz mais de 10 anos que não programo em COBOL e CICs, então, não posso opinar muito sobre as práticas de programação nesses ambientes. Porém, eu acho inadimissível pessoas trabalharem com tecnologia deste milênio com mentalidade dos anos 70.

      OK? Valeu pela participação aqui…

    20. Pingback:Um novo olhar! | Arquitetura da Informação

    21. Pingback:Só agilidade funciona | Arquitetura da Informação

    22. Paula

      Acho errado o uso do nome Àgil em maiusculo, tipo “Só Agilidade funciona” ou “Processo Agil”. Ele não dá uma característica pronta as coisas. Não é algo definido. Pelo que eu entendo, quando vc usa uma séria de práticas inventadas por vc ou por outro que seguem as premissas e objetos, vc tá seguindo um modelo agil de desenvolvimento.

      Não gosto da ideia de dar um novo nome as coisas existentes… Como vc disse RUP é “ágil” e Scrum é uma forma de gerência “ágil”, o PMBOK é cheio de processos que podem ser executados de forma ágil. O problema é o uso que as pessoas fazem das coisas.

      Com relação ao modelo cascata, criou-se nas empresas uma anomalia que foi a tentativa de trabalhar com iterações sem conseguir: cascata sobreposta hehehe. Que na verdade é o modelo espiral sem o controle de riscos provavelmente ou ainda um modelo de divisão por módulos onde cada módulo é uma iteração que pode ou não ser entregue ao cliente. Enquanto vc está projetando esse modulo, a equipe de requisitos vai levantando o próximo, tendo uma sobreposição de etapas. Mas seriam mini cascatas.

    23. Rafael Cotta

      Olá, Rodrigo. Belo post.

      Do alto do meu parco conhecimento sobre processos de desenvolvimento de software, eu sou a favor de modelos ágeis, acho que é um ótimo caminho a se tomar.

      Porém, sou contra essa visão de que “Só Agilidade funciona”. Isso me cheira a bem x mal, preto x branco, Vasco x Flamengo.

      A citação de que ninguém consegue definir o modelo tradicional me cheira a uma tentativa de desqualificar o “inimigo”. A falta de uma definição de “modelo tradicional” não invalida em nada o que é feito no waterfall.

      Finalmente, você cita testes automatizados como se fosse um benefício exclusivo dos modelos ágeis. Ora, se eu uso waterfall estou proibido de utilizar e me aproveitar dos benefícios dos testes automatizados?

      Não ter citações a testes automatizados na literatura a respeito de waterfall, não quer dizer que essa é uma prática proibida.

      E parabéns pelo post e por trazer essa discussão para cá.

    24. Roberto

      Ora, considerando cada sprint uma iteração e que cada iteração / sprint passa por uma sequência de processos, requisitos, análise, condificação, testes, homologação e disponibilização, isso não é uma cascata? Métodos ágeis usam cascatas menores com cascatas sobrepostas. Quando um sprinte está sendo codificado outro já está sendo analizado, etc. A diferença é que as iterações são menores, ou melhor as cascatas são menores. Não estou defendendo a cascata como o melhor método. Cada projeto é um projeto, cada empresa tem sua cultura e que se ache o método para o projeto que melhor se enquadre no universo em que está situado. Concordo com Renado, daqui a alguns anos, alguém vai dizer que o método ágil era a tentativa de organizar o caos, ou qualquer outra coisa.
      A máxima é “cada projeto é um projeto” e deve ser tratado como tal.

    Deixe um comentário

    O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *