Usuário(a):Felipe Raulickis/Testes
Teorias Ágeis[editar | editar código-fonte]
A metodologia ágil é um modelo e uma filosofia que propõe alternativas à gestão de projetos tradicional e tem a função de aprimorar o processo de desenvolvimento de um produto ou serviço. O objetivo final é fazer entregas com rapidez e com maior frequência, conforme surgem as necessidades do cliente.
A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.
Métodos ágeis também enfatizam o software funcional como uma medida primária de progresso. Combinado com a comunicação cara-a-cara, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos, mas reduzindo o tempo de produção de documentação mais útil.
Surgimento da teoria ágil[editar | editar código-fonte]
Desde seus primórdios, a indústria de desenvolvimento de software seguiu uma metodologia tradicional. Nela, temos as seguintes fases: levantamento e análise de requisitos, desenho da arquitetura, implementação, testes, produção e manutenção. Embora tecnicamente correta, essa metodologia é vista como desnecessariamente rígida. Ao tornar o processo tão formal, ela impede que os clientes tenham o desenvolvimento na velocidade que necessitam.
Além disso, muitas empresas utilizavam e algumas ainda usam a metodologia Waterfall (ou “cascata”), umas das mais tradicionais formas de se gerenciar projetos. Na abordagem surgida nos anos 1970, todas as etapas são seguidas de forma sequencial. Mas o modelo pode gerar muitos problemas de gestão, pois uma etapa só é iniciada quando a anterior for inteiramente concluída.
Com a maturação da indústria de software, problemas com um possível delay entre as necessidades do cliente e as entregas começaram a surgir, e a necessidade de encontrar novas soluções se tornou clara. Foi então criada a metodologia ágil, que tinha, como o nome indica, a função de agilizar o processo de desenvolvimento, principalmente no que diz respeito à utilização do software pelo cliente.
Assim, em 2001, um grupo de programadores lançou o Manifesto Ágil, pregando uma metodologia que tem como objetivo satisfazer os clientes entregando com rapidez e com maior frequência versões do software conforme as necessidades.
Ou seja, a partir de uma versão publicada, embora não absolutamente completa, pode-se evoluir o software de acordo com as necessidades do cliente e das demandas da sociedade. Do contrário, o produto final demoraria tanto para ficar pronto que poderia se tornar obsoleto.
Afinal, é melhor ter esse produto para entregar e com a possibilidade dele ser melhorado com o tempo do que passar todo o processo sem uma oferta, e depois ela ser ultrapassada pela de um concorrente.
Manifesto Ágil[editar | editar código-fonte]
O manifesto da metodologia ágil é composto por 4 valores principais, listados abaixo :
- “Indivíduos e interações mais que processos e ferramentas”
- “Software funcional mais que documentação abrangente”
- “Colaboração do cliente mais que negociação de contratos”
- “Responder a mudanças mais que seguir um plano”
No mesmo manifesto, seus idealizadores listam ainda princípios pelos quais se guiam. São pontos como a priorização de se satisfazer o cliente por meio “da entrega adiantada e contínua de software de valor”, a aceitação de “mudanças de requisitos”, o compromisso com a entrega de um “software funcional com frequência de semanas ou meses”, entre vários outros.
Como é fácil perceber, o manifesto propõe uma flexibilização maior, com menos burocracia e que aceita mudanças no meio do caminho. Repare que o manifesto não nega as partes formais, apenas prega que se devem priorizar as partes mais fluidas do processo.
Metodologias e frameworks[editar | editar código-fonte]
Feature Driven Development[editar | editar código-fonte]
Normalmente abreviado como FDD, este tipo de metodologia ágil foi concebido entre 1997 e 1999 por Jeff De Luca, em Singapura. E se traduz literalmente como “Desenvolvimento guiado por funcionalidade”. As tarefas são decompostas em pequenas funcionalidades, pulverizando o trabalho. É composto de 5 princípios básicos:
- Desenvolver um Modelo Abrangente
- Construir uma Lista de Funcionalidades
- Planejar por Funcionalidade
- Detalhar por Funcionalidade
- Construir por Funcionalidade
As vantagens desta forma de gestão ágil se originam principalmente do fato de cada feature ser muito uma unidade mínima do projeto total. Isso faz com que cada tarefa, descrição, teste e alteração seja sempre minimalista, dando agilidade ao processo e gastando menos tempo e recursos humanos.
eXtreme Programming[editar | editar código-fonte]
Também conhecida como XP, esta gestão ágil foi criada em 1997 para focar mais em práticas de engenharia. Por isso, é mais comum na área de desenvolvimento de software. Ela visa a otimizar a qualidade e resposta às solicitações dos clientes. Seus princípios incluem:
- Simplicidade: Remover funções consideradas desnecessárias
- Feedback: Contato frequente com cliente, testando o produto e recebendo sugestões
- Mudanças: Adaptações constantes no produto até atingir a etapa final
O método XP é ideal para situações onde o cliente não sabe com clareza o que deseja. Através do suporte constante de especialistas, consegue-se maior agilidade nas alterações do produto.
Scrum[editar | editar código-fonte]
Criado por Jeff Sutherland nos anos 80 como um processo de desenvolvimento interativo e incremental, este é um dos métodos mais populares de implementação do agile. Baseia-se na realização de “sprints” periódicos de resolução de pendências e em reuniões fixas. Normalmente os sprints têm 2 ou 4 semanas, e as reuniões são diárias (“daily”).
Ele traz como característica principal o componente humano do processo de desenvolvimento. Entre suas vantagens, está a possibilidade de trabalhar com menor participação do cliente. Além disso, o Scrum mantém a equipe motivada e o resultado mais refinado por priorizar qualidade em vez de um prazo reduzido.
Nexus[editar | editar código-fonte]
O Nexus é um framework que possibilita implementar o Scrum em larga escala em uma empresa, unindo de três a nove times de Scrum para trabalhar na entrega de um único produto ou resultado no final de cada Sprint. O Nexus também prevê três responsáveis por entrelaçar as equipes, o chamado Time de Integração, que é composto por:
- um Product Owner
- um Scrum Master
- pelo menos um membro de cada time Scrum
A composição desse time, entretanto, não é fixa: ela pode mudar ao longo do tempo de forma a refletir as necessidades do Nexus. As atividades comuns dessa equipe incluem: mentoria, consultoria, e destacar as dependências e problemas entre os times.
Kanban[editar | editar código-fonte]
O kanban é um método organizacional que visa aumentar a produtividade e otimizar a realização das tarefas e das entregas. O termo significa “tabuleiro”, e o sistema visa acompanhar, de maneira visual, prática e utilizando poucos recursos, o andamento dos fluxos de produção nas empresas.
O Kanban foi criado pela japonesa Toyota na década de 1960 e faz parte da metodologia JIT (Just in Time), um sistema de administração da produção que determina que deve ser feito somente o imprescindível para realização da etapa seguinte do processo, em um fluxo de trabalho contínuo. Em outras palavras: fazer apenas o que é necessário, quando necessário e na quantidade necessária.
Essa metodologia propõe a utilização de cartões ou post-its em um quadro para indicar e acompanhar, de maneira visual, prática e utilizando poucos recursos, o andamento dos fluxos de produção nas empresas. De um lado do quadro, ficam as tarefas que precisam ser executadas, o que pode ser chamado de “Backlog”. E, do outro, as etapas de execução: em andamento e entregue. Você pode alterar o nome dessas etapas de acordo com seus processos internos. Conforme as tarefas são desempenhadas, o cartão ou post-it é colocado no campo correspondente ao status da tarefa.
Bibliografia[editar | editar código-fonte]
http://agilemanifesto.org/iso/ptbr/manifesto.