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.
