As exaustivas horas empregadas em transitar desde a concepção de um sistema de software até a sua entrega, passando pelos ajustes normalmente necessários, são prazerosamente recompensadas quando vemos o nosso cliente utilizando as tecnologias que desenvolvemos. Entretanto, desenvolver um software de médio/grande porte é um desafio e tanto. Que o digam aqueles diretamente envolvidos nas árduas atividades de levantar os requisitos, implementar, testar e entregar as soluções para atender as necessidades dos clientes.
A complexidade dessas atividades é tão grande e o processo de desenvolvimento de um sistema de software tende tão facilmente a se tornar caótico que diversas abordagens de desenvolvimento vêm sendo propostas desde o início da engenharia de software, normalmente como respostas a necessidades e problemas específicos identificados nos ambientes reais.
Uma das práticas comumente defendidas é a de que modelar uma solução técnica preferencialmente utilizando UML (vide seção Links) melhora a qualidade da solução e a manutenibilidade de um produto de software. Mas, quando uma empresa se depara com a necessidade real de escolher entre codificar rapidamente ou elaborar modelos e especificações em um projeto que está atrasado, normalmente tenho visto que se tende à primeira alternativa.
É claro que quando olhamos para notações como a UML,com os seus 14 diferentes diagramas (versão 2.5), e para a nossa necessidade de entregar software cada vez mais rapidamente, podemos pensar que esse grande volume de diagramas foi criado somente para nos deprimir, somente para que pensemos: “É claro que temos muitos bugs para resolver... Não fizemos nenhum diagrama”.
Como resposta aos processos prescritivos, e muitas vezes pesados, de desenvolvimento, que acabaram impondo uma carga excessiva de documentação para determinados ambientes e equipes na tentativa de dar mais rigor e formalidade ao caos, surgiram diversas abordagens ágeis. Como definido desde o início no manifesto ágil (vide seção Links), a proposta central das abordagens ágeis de desenvolvimento de software valoriza:
- Indivíduos e interações, mais que processos e ferramentas;
- Software em funcionamento, mais que documentação abrangente;
- Colaboração com o cliente, mais que negociação de contratos;
- Responder a mudanças, mais que seguir um plano.
Daí se observa a tendência de que práticas das abordagens ágeis já estejam estabelecidas em grande parte das organizações de software brasileiras, como: as reuniões diárias, ciclos curtos de desenvolvimento, entregas frequentes, interação face-to-face com fornecedores de requisitos, entre outras. Assim, muitas organizações de software encontraram na adoção de práticas das abordagens ágeis uma interessante alternativa para desenvolver seus projetos.
Entretanto, uma infeliz interpretação de “software em funcionamento, mais que documentação abrangente” no dia a dia das organizações de software tem resultado na redução ou quase extinção da modelagem nos projetos. Nas minhas andanças ministrando aulas, cursos e consultorias, já ouvi muitas vezes a expressão: “...aqui nós não fazemos nenhum tipo de modelagem porque somos ágeis ...”. Parte-se do princípio de que ser ágil resulta em necessariamente abandonar qualquer tipo de modelo que possa representar o software que está sendo desenvolvido. Infelizmente essa é uma interpretação errônea.
Esse comum abandono do uso de modelos no desenvolvimento de software, na verdade, tem origem no entendimento das motivações que nos levam a modelar. Antes de pensar se devemos, ou o quanto de esforço devemos aplicar para elaborar modelos, a pergunta essencial a ser feita é: Porque modelamos um software?
Para responder a essa complexa pergunta, podemos tomar como base o que pensam Martin Fowler (vide seção Links), Scott Ambler (vide seção Links) e muitos outros: nós modelamos para entender,comunicar e documentar, exatamente nessa ordem de importância.E aqui começamos a discutir sobre a ideia central da modelagem ágil:nós não modelamos somente para documentar, nós modelamos em primeiro lugar para entender (Figura 1).
![Porque modelamos um software?](http://arquivo.devmedia.com.br/revistas/es/imagens/89/modelagem_agil/Porque_modelamos.png)
Figura 1. Porque modelamos um software?
Vamos pensar no seguinte cenário: um analista vai até o cliente para entender um problema específico que esteja enfrentando e que precisa ser resolvido com apoio de um sistema de software. Juntamente com o cliente, o analista rascunha em alguns “quadradinhos e bolinhas” a arquitetura da solução que irá atender as necessidades do cliente. Ao final da reunião, o analista desenhou o que está na Figura 2. Ambos ficam muitos satisfeitos com o desenho da arquitetura proposta e o analista volta para a sua empresa.
![Modelando para entender (sem preocupação com a notação)](http://arquivo.devmedia.com.br/revistas/es/imagens/89/modelagem_agil/Modelando_entender.png)
Figura 2. Modelando para entender (sem preocupação com a notação)
Para o entendimento do problema e definição de uma arquitetura básica de solução, os “quadradinhos” do analista foram perfeitos, mas para poder repassar essa ideia para os demais membros da equipe de desenvolvimento o analista terá que explicar o que cada símbolo representa: “Veja bem... Os quadrados são computadores, os círculos são sistemas, ou coisa parecida, já as linhas tracejadas...”. ...
Confira outros conteúdos:
![autor](http://www.devmedia.com.br/imagens/fotoscolunistas/482847_20160607112329.png)
Perguntas frequentes
Nossos casos de sucesso
Eu sabia pouquíssimas coisas de programação antes de começar a estudar com vocês, fui me especializando em várias áreas e ferramentas que tinham na plataforma, e com essa bagagem consegui um estágio logo no início do meu primeiro período na faculdade.
Estudo aqui na Dev desde o meio do ano passado!
Nesse período a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha
empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta é continuar estudando e praticando para ser um
Full-Stack Dev!
Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma é bem intuitiva e muuuuito didática a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!
Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda não tinha visto. A didática é do jeito que qualquer pessoa consegue aprender. Sério, to apaixonado, adorando demais.
Adquiri o curso de vocês e logo percebi que são os melhores do Brasil. É um passo a passo incrível. Só não aprende quem não quer. Foi o melhor investimento da minha vida!
Foi um dos melhores investimentos que já fiz na vida e tenho aprendido bastante com a plataforma. Vocês estão fazendo parte da minha jornada nesse mundo da programação, irei assinar meu contrato como programador graças a plataforma.
Wanderson Oliveira
![linkedin](https://cdn-icons-png.flaticon.com/512/174/174857.png)
Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exercícios práticos que não tem como não aprender, estão de parabéns!
Obrigado DevMedia, nunca presenciei uma plataforma de ensino tão presente na vida acadêmica de seus alunos, parabéns!
Eduardo Dorneles
![linkedin](https://cdn-icons-png.flaticon.com/512/174/174857.png)
Aprendi React na plataforma da DevMedia há cerca de 1 ano e meio... Hoje estou há 1 ano empregado trabalhando 100% com React!
Adauto Junior
![linkedin](https://cdn-icons-png.flaticon.com/512/174/174857.png)
Já fiz alguns cursos na área e nenhum é tão bom quanto o de vocês. Estou aprendendo muito, muito obrigado por existirem. Estão de parabéns... Espero um dia conseguir um emprego na área.
Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.