Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Agile é um termo que descreve abordagens de desenvolvimento de software que enfatizam a entrega incremental, a colaboração em equipe, o planejamento contínuo e o aprendizado contínuo. O termo Agile foi cunhado em 2001 no Manifesto Agile. O manifesto estabeleceu princípios para orientar uma abordagem melhor para o desenvolvimento de software. Em sua essência, o manifesto declara quatro instruções de valor que representam a base do movimento Agile. Conforme escrito, o manifesto afirma:
Chegamos ao valor:
- Indivíduos e interações em vez de processos e ferramentas.
- Software em funcionamento em vez de documentação abrangente.
- Colaboração com o cliente em vez de negociação de contratos.
- Responder a mudanças em vez de seguir um plano.
O manifesto não implica que os itens do lado direito dessas instruções não sejam importantes ou necessários. Em vez disso, os itens à esquerda são simplesmente mais valorizados.
Métodos e práticas agile
É importante entender que Agile não é uma coisa. Você não faz Agile. Em vez disso, Agile é uma mentalidade que impulsiona uma abordagem para o desenvolvimento de software. Como não há uma abordagem única que funcione para todas as situações, o termo Agile passou a representar vários métodos e práticas que se alinham com as instruções de valor no manifesto.
Os métodos Agile, que geralmente são chamados de estruturas, são abordagens abrangentes para as fases do ciclo de vida do DevOps: planejamento, desenvolvimento, entrega e operações. Eles prescrevem um método para realizar o trabalho, com diretrizes e princípios claros.
O Scrum é a estrutura Agile mais comum e a que a maioria das pessoas começa. As práticas ágeis, por outro lado, são técnicas aplicadas durante as fases do ciclo de vida de desenvolvimento de software.
- Planejar o Poker é uma prática de estimativa colaborativa projetada para incentivar os membros da equipe a compartilhar sua compreensão do que significa feito . Muitas pessoas acham o processo divertido, e provou ajudar a promover o trabalho em equipe e melhores estimativas.
- A CI (integração contínua) é uma prática comum de engenharia Agile que envolve a integração de alterações de código ao branch principal com frequência. Um build automatizado verifica as alterações. Como resultado, há uma redução na dívida de integração e uma ramificação principal continuamente transportável.
Essas práticas, como todas as práticas agile, carregam o rótulo Agile , porque são consistentes com os princípios no manifesto agile.
O que o Agile não é
Como Agile ganhou popularidade, muitos estereótipos e interpretações incorretas lançaram uma sombra negativa sobre sua eficácia. É fácil dizer "Sim, estamos fazendo Agile", sem qualquer responsabilidade. Tendo esse ponto em mente, considere algumas coisas que Agile não é.
- Agile não é codificação de cowboy. Agile não deve ser confundido com uma abordagem "vamos descobrir conforme vamos" para o desenvolvimento de software. Tal idéia não poderia estar mais longe da verdade. O Agile requer uma definição de valor feito e explícito que é entregue aos clientes em cada sprint. Embora o Agile valorize a autonomia para indivíduos e equipes, ele enfatiza a autonomia alinhada para garantir que o aumento da autonomia produza um valor maior.
- Agile não é sem rigor e planejamento. Pelo contrário, as metodologias e as práticas agile normalmente enfatizam a disciplina no planejamento. A chave é o planejamento contínuo em todo o projeto, não apenas planejando antecipadamente. O planejamento contínuo garante que a equipe possa aprender com o trabalho que executa. Por meio dessa abordagem, eles maximizam o retorno sobre o investimento (ROI) do planejamento.
"Planos são inúteis, mas planejar é tudo." — Dwight D. Eisenhower
- Agile não é uma desculpa para a falta de um roteiro. Esse equívoco provavelmente fez mais mal ao movimento Agile em geral. Organizações e equipes que seguem uma abordagem Agile sabem absolutamente para onde estão indo e os resultados que desejam alcançar. Reconhecer a alteração como parte do processo é diferente de pivotar em uma nova direção a cada semana, sprint ou mês.
- Agile não é desenvolvimento sem especificações. É necessário em qualquer projeto manter sua equipe alinhada sobre por que e como o trabalho acontece. Uma abordagem Agile para especificações inclui garantir que as especificações sejam de tamanho certo e que reflitam adequadamente como a equipe sequencia e entregas funcionam.
- O Agile não é incapaz de acomodar o trabalho não planejado e outras interrupções. É importante concluir sprints no agendamento. Mas só porque surge um problema que desvia o desenvolvimento não significa que um sprint tem que falhar. O Teams pode planejar interrupções designando recursos antecipadamente para problemas e problemas inesperados. Em seguida, eles podem resolver esses problemas, mas manter-se no controle do desenvolvimento.
- Agile não é inadequado para grandes organizações. Uma reclamação comum é que a colaboração, um componente fundamental das metodologias agile, é difícil em grandes equipes. Outra reclamação é que abordagens escalonáveis para Agile introduzem estrutura e métodos que comprometem a flexibilidade. Apesar desses equívocos, é possível dimensionar os princípios agile com êxito. Para obter informações sobre como superar essas dificuldades, consulte Dimensionamento do Agile para grandes equipes.
- Agile não é ineficiente. Para se adaptar às necessidades de mudança dos clientes, os desenvolvedores investem tempo a cada iteração para demonstrar um produto funcional e coletar comentários. É verdade que esses esforços reduzem o tempo que passam no desenvolvimento. Mas a incorporação de solicitações de clientes no início economiza tempo significativo mais tarde. Quando os recursos permanecem alinhados com a visão do cliente, os desenvolvedores evitam grandes revisões.
- Agile não é um ajuste ruim para os aplicativos atuais, que geralmente se concentram no streaming de dados. Esses projetos normalmente envolvem mais cargas de trabalho etl (extração-transformação-carga) de dados do que interfaces do usuário. Esse fato dificulta a demonstração de software utilizável em um agendamento consistente e apertado. Mas ajustando metas, os desenvolvedores ainda podem usar uma abordagem Agile. Em vez de trabalhar para realizar tarefas a cada iteração, os desenvolvedores podem se concentrar na execução de experimentos de dados. Em vez de apresentar um produto funcional a cada poucas semanas, eles podem tentar entender melhor os dados.
Por que Agile?
Então, por que alguém consideraria uma abordagem Agile? É claro que as regras de engajamento em torno da construção de software mudaram fundamentalmente nos últimos 10-15 anos. Muitas das atividades são semelhantes, mas a paisagem e os ambientes em que as aplicamos são visivelmente diferentes.
- Compare como é comprar software hoje com o início dos anos 2000. Com que frequência as pessoas dirigem para a loja para comprar software de negócios?
- Considere como os comentários são coletados dos clientes sobre produtos. Como uma equipe entendeu o que as pessoas pensavam sobre seus softwares antes das mídias sociais?
- Considere a frequência com que uma equipe deseja atualizar e melhorar o software que ela fornece. As atualizações anuais não são mais viáveis em relação à concorrência moderna.
Diego Lo Guidice, da Forrester, diz que é melhor em seu blog, Transforming Application Delivery (outubro de 2020).
"Tudo mudou drasticamente. Sustentabilidade, além de verde e limpo, significa que o que construímos hoje tem que ser facilmente e rapidamente alterado amanhã. Os planos estratégicos são de curto prazo e o planejamento e a mudança são contínuos." — Diego Lo Guidice, Forrester
As regras mudaram, e as organizações em todo o mundo agora adaptam sua abordagem ao desenvolvimento de software adequadamente. Métodos e práticas ágeis não prometem resolver todos os problemas. Mas eles prometem estabelecer uma cultura e um ambiente onde as soluções emergem através da colaboração, do planejamento e do aprendizado contínuos e do desejo de enviar software de alta qualidade com mais frequência.
Próximas etapas
Decidir usar a rota Agile para o desenvolvimento de software pode introduzir algumas oportunidades interessantes para aprimorar o processo de DevOps. Um conjunto chave de considerações se concentra em como o desenvolvimento agile compara e contrasta com a abordagem atual de uma organização.