Quais são os limites para o desenvolvimento ágil de software? Essa é, provavelmente, uma pergunta que passa pela cabeça de muitas pessoas (inclusive na minha). Infelizmente, não há respostas fáceis para essa questão e, para piorar um pouco, há alguns mal entendidos clássicos a respeito do tema, que ofuscam a nossa mente, e que eu gostaria de ajudar a esclarecer.
Muitos profissionais do nosso meio (desenvolvedores, professores, conferencistas, etc) têm as seguintes ideias (a meu ver equivocadas) sobre Agile:
- É bacana, mas apenas para projetos de pequeno porte.
- Tem a desvantagem de produzir código de baixa reusabilidade.
- Agile e modelos de qualidade são excludentes entre si.
Creio que essas ideias surgem pois tais pessoas têm uma visão muito pequena sobre a realidade da cultura ágil atual. A maioria delas olha para os processos individualmente, como se Agile fosse SCRUM ou XP ou LEAN ou FDD ou WHATEVER. Ora, nenhum profissional sério acredita que qualquer um desses métodos irá, sozinho, resolver todos os problemas e situações que o moderno desenvolvimento de software exige. Realmente nenhum deles tem esse poder. Agile é algo bem mais abrangente do que isso...
Agile é um conjunto de práticas, processos, ferramentas, princípios e valores que formam um arcabouço útil para desenvolver projetos de qualquer porte. É pura Engenharia de Software. Duvida? O SEI, criador do CMMI, não. Publicou um relatório convocando a comunidade de qualidade de software a utilizar práticas ágeis para atender as áreas de processo do modelo CMMI. O título é: "CMMI or Agile: Why not embrace both?". Sugestivo, não?
As técnicas mais quentes da Engenharia de Software atual estão presentes nos métodos ágeis. TDD, DDD, integração contínua, automação do desenvolvimento e testes, cliente on-site, time-boxed iterations, desenvolvimento iterativo, etc. Todas essas técnicas nasceram no seio das comunidades ágeis e estão sendo consumidas por todos os tipos de projetos (os grandes inclusive rs).
Acredito que o que falta para o Agile conseguir mais respeito nas rodas "intelectuais" do mundo do software é um maior número de links entre a Engenharia de Software e as técnicas e práticas ágeis mais utilizadas. Algo que da minha parte pretendo contribuir com a minha futura dissertação de mestrado.
Postagens
O que eu acho é que processos mais tradicionais, como o RUP por exemplo, são mais cômodos, pq são cartilhas a serem seguidas.
ResponderExcluirDesenvolvimento ágil requer mais disciplina. Disciplina é uma palavra que vejo sempre associada à métodos ágeis, isso tira os envolvidos da sua zona de conforto.
Como eu tinha colocado pra vc por email, com todo o arcabouço oferecido pelo Agile, não vejo motivos para uma equipe não conseguir lidar com projetos de grande porte e quanto a baixa reusabilidade, vai contra td o que o Evans prega.
Excelente post!
Abçs
Fala Rafa,
ResponderExcluirConcordo com seu pensamento: desenvolvimento ágil tem tudo a ver com disciplina.
Disciplina para:
- Fazer testes sempre (de unidade e funcionais);
- Evoluir o model e o design simultaneamente;
- Gerar sempre código limpo e legível;
- Respeitar prazos e compromissos;
- Colaborar com o cliente sempre;
- Automatizar ao máximo o processo.
Tudo isso gera excelentes resultados, porém é necessário muito trabalho e dedicação para uma equipe amadurecer e trabalhar sempre dessa forma.
É o que muitos não enxergam. Ou não querem enxergar...
Abs,
Professor, tudo bem?
ResponderExcluirA meu ver, o maior limite do Agile é a mente de quem usa. As pessoas não conseguem ver o benefício quando pensam nas mudanças que pelas quais passarão.
"Ah, ter reunião todo dia?" "Ter que ficar falando oq fez?" Não conseguem ver o processo como um todo, mas sim pequenos fragmentos que acabam por contestar... Sem razão!
Outro fator, percebi que para um time "Agile" funcionar bem, é necessário investimento. Não apenas em estrutura, como máquinas, cadeiras, mesas... mas em pessoal. Dois fatores eu vejo que influenciam:
1)Não adianta "colocar" Agile em uma equipe de juniors sem experiência alguma ou onde seniors não vão querer transmitir conhecimento. Os júniors serão sufocados, e se os seniors não ajudarem, o "Agile" que foi utilizado vai virar piada na empresa.
2)Realmente para funcionar, vai ter que se gastar um bom dinheiro. Ter funcionários bons e qualificados sai caro. E ao mesmo tempo, proporcionar uma boa infra-estrutura, afinal de contas, sem máquina boa é impossível ter um bom prazo e um desenvolvimento feliz.
Mas seguindo a risca as "regras" do Agile, o projeto sai mais coeso, fica mais claro o seu processo, e o cliente pode ir "saboreando" aos poucos seu produto.
As pessoas pegam exemplos de Agile mau aplicados e botam como verdade absoluta!
Eita, falei muito né?
Inté+ \o_
Fala rapaz,
ResponderExcluirTudo bem, e vc?
Ótimas observações.
A palavra-chave é maturidade!
Agile funciona bem em ambientes maduros: desenvolvedores, gerentes e clientes alinhados com as obrigações e benefícios das práticas ágeis de gestão de projetos e engenharia.
Sem isso, o risco de falha é enorme...
Abraços,