Ao realizar uma pesquisa na web sobre as empresas ágeis no Brasil, os mecanismos de buscas apontaram a TeamWare como uma das empresas que nasceram ágeis e que mais se destacam no ramo. Logo, o próximo passo foi a tentativa de conseguir algum contato interno que pudesse expressar os motivos de utilização e a visão profissional em relação ao Desenvolvimento Ágil.
Uma semana após o contato, o fundador da TeamWare gentilmente retornou o e-mail agendando uma audioconferência via Skype para explicar o que fosse necessário para o trabalho. Em uma hora e meia de conversa, Juan Bernabó mencionou o seu ponto de vista profissional, a história da TeamWare e destacou os pontos principais do Desenvolvimento Ágil no cenário atual.
A ideia de ser ágil ou não ser ágil está especificamente na cabeça das pessoas. Quando eu trabalhava com desenvolvimento, enxerguei a oportunidade de montar uma empresa não voltada para a venda de produtos, mas uma empresa de serviços. Nunca tinha feito consultoria e nem treinamentos, mas o propósito era simplesmente tentar resolver o paradigma do desenvolvimento de sistemas. Minha ideia então foi desenvolver uma metodologia que ajudasse as pessoas a enxergarem o próprio conflito que elas tinham. E foi assim que comecei a apresentar duas palestras que se chamavam “Manifesto Ágil e Declaração de Interdependência – O que eles significam para nós” e “Desmistificando Scrum – Agile & Lean” durante três anos, totalizando aproximadamente 130 palestras.
Em proporção às constantes mudanças no cenário de desenvolvimento de softwares, os gestores de projeto passaram a pensar da seguinte forma: Primeiro eu preciso entender o que tenho que desenvolver, depois analisar, projetar, construir e então avaliar se desenvolvi corretamente. Faz todo o sentido, mas o fato é que infelizmente não funciona, pois são modelos lineares. O que funciona para certo tipo de situação não funciona para a realidade de desenvolvimento de um software.
A premissa é conseguir saber o que o cliente precisa antes de começar a desenvolver o sistema. Teoricamente é fácil, mas na prática começa a entrar outras variáveis que dificultam o processo. Nós da TeamWare trabalhamos com extrema incerteza e extrema volatilidade. As coisas são muito incertas, ou seja, eu acho que sei o que o cliente quer, ele acha que também sabe, mas nenhum dos dois sabe o que realmente deve ser feito. No final do projeto o produto é apresentado e não era nada do que o cliente precisava.
Quanto maior o projeto, mais o pessoal tenta usar métodos formais e tradicionais de controle, e isso aumenta o risco de falhas. Os métodos formais e tradicionais passam uma falsa impressão de segurança. Quando eu analiso um projeto desses, avalio qual é a taxa e o volume de requisitos não validados que o projeto possui. Portanto, tentamos trabalhar com a taxa e velocidade na qual podemos validar os requisitos de forma precisa e funcional. Temos ciência de que, dos requisitos que o cliente coloca no início do projeto, 65% deles raramente (ou nunca) serão utilizados.
Quando vamos desenvolver um sistema, desconhecemos o problema, as necessidades, e o ambiente no qual vamos trabalhar. O Desenvolvimento Ágil permite obter conhecimento e adaptação de todas essas variáveis, ou seja, passamos a conhecer todas as regras de negócio, as formas de desenvolver as funcionalidades, os processos, a cultura da empresa e o cliente.
O pessoal que tem dificuldade em entender o Desenvolvimento Ágil são pessoas que possuem modelos mentais constantes e invariáveis. Geralmente as pessoas aprendem na teoria uma forma de desenvolver o sistema, mas depois quando aplicam na prática concluem que surgem grandes imprevistos e contratempos. Normalmente a explicação que se tem é que a equipe não tem disciplina ou as pessoas não seguem o processo de forma correta. Eu uso uma forma de divulgar o Desenvolvimento Ágil: através de diálogo socrático com os clientes. Eu faço o cliente observar as disfunções, os atrasos nos projetos e as mudanças constantes de requisitos, e assim o deixo chegar às próprias conclusões.
O que nós vemos hoje é uma taxa impressionante de fracassos em projetos de software, e a coincidência é que eles são muito parecidos. Então, se nós analisarmos o motivo no qual os projetos falham tão similarmente, vamos concluir que talvez eles estejam utilizando algo inadequado, como o Desenvolvimento em Cascata, por exemplo.
Juan Bernabó
Fundador e Diretor Executivo – TeamWare