Abr 23rd, 2008
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 SÓ 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.
Enviar por e-mail | Hits para esta publicação: 2253
Olá Rodrigo, trabalho na W7 Solutions, empresa de desenvolvimento de software em Teresina - Piauí.
Gostei muito do teu artigo, e compartilhei em nosso blog, http://blog.w7solutions.com.br/2008/04/23/so-agilidade-funciona/
Abraços
Só tenho uma palavra Rodrigo: PERFEITO!
Parabéns pelo post amigo!
Parabéns pelo post Rodrigo, foi excelente em sua abordagem…
ps: pq demorou tanto pra criar um blog hein!?
Excelente post!
É impressionante como as pessoas fazem mesmas coisas e esperam resultados diferentes.
Isso aí Rodrigão!!! Grande Post Cara. Parabéns!
Teu feed já está no Reader… Abraço.
“…quantas vezes você não ouviu sarcasticamente que XP “é aquela metodologia que são dois programadores por micro”) ” - Pelo menos umas 10 vezes.
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.
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.
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”.
[…] Por mais incrível que possa aparecer, o empresariado (os caras que estão pagando a cara conta do desenvolvimento de software “Tradicional”), aceita Agilidade. É isso mesmo! Se você conversar com qualquer empresário você terá o seguinte padrão de diálogo: […]
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!
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).
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.
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).
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!
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
[…] É muito impressionante ver a falta de compromisso que os projetos em geral tem com o ROI. Ora, ninguém investe dinheiro para perder dinheiro. É estranho ver que o empresariado não enxergou que fábricas de software e consultorias montam contratos que estão se lixando para o ROI e para o sucesso do cliente. Quando um empresário faz um investimento qualquer, como um dono de uma gráfica que compra uma impressora off-set ou um fazendeiro que compra uma ceifadeira, ele sabe que aquele investimento terá um retorno. Isso significa mais páginas impressas ou mais sacas colhidas. Infelizmente muitos empresários estão bem insatisfeitos com o retorno oferecido por soluções de software. Isso se deve a maneira que o software é contratado. Fábricas de Software e Consultorias em Geral não dão a mínima importância se o projeto vai ou não colocar dinheiro no bolso do cliente. O escopo de um projeto para esses fornecedores é implementar requisitos e não dar soluções para problemas de negócio. Geralmente um requisito levantado e implementado não necessariamente resolve um problema de negócio. Requisitos são abstrações. Essa é a maior razão de trabalharmos de maneira iterativa seguindo princípios ágeis. Quem desenvolve um projeto de maneira iterativa quer solucionar os reais problemas de negócio do cliente e não simplesmente implementar requisitos. O mercado em geral adota um processo cascata e não iterativo. Eles caem no conto que requisitos traduzem as necessidades de negócio. […]
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.
[…] Obs: Sei que o RUP é mal usado, pois uma brecha dele é ser muito genérico, e isto cada vez se confirma mais, que o modelo atual “tradicional” está falido. […]
[…] Uma das grandes “novidades” é que dessa vez mais pessoas levantaram a mão quando perguntei se elas estão aplicando desenvolvimento iterativo. De acordo com a pesquisa rápida, creio que 60% dos alunos disseram estar aplicando desenvolvimento iterativo. 40% ainda era cascateiro. Bem, creio que isso é uma grande vitória, pois é muito comum 100% da turma ser cascateira. Será que as empresas estão caindo na real? […]
[…] Obs: Sei que o RUP é mal usado, pois uma brecha dele é ser muito genérico, e isto cada vez se confirma mais, que o modelo atual “tradicional” está falido. […]
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.
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.
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…