[ad_1]
Agile é uma metodologia para abordar o desenvolvimento de software. Ele consiste em diferentes estruturas, como SCRUM ou Kanban, que ajudam as equipes de desenvolvimento a construir, testar e coletar continuamente feedback sobre seus produtos.
O Agile consiste em quatro princípios básicos:
- Indivíduos e interações sobre processos e ferramentas
- Software que trabalha sobre uma documentação completa
- Colaboração do cliente na negociação do contrato
- Respondendo à mudança seguindo um plano
Vou revisitar esses princípios mais tarde e dar mais sentido a eles. Para fazer isso, é importante dar um passo atrás e entender as práticas de desenvolvimento de software que foram utilizadas anteriormente.
Cascata
O desenvolvimento em cascata é uma abordagem muito linear para construir um produto. Tem pouco ou nenhum espaço para feedback ou iteração até que o produto esteja completamente construído e testado.
Funciona assim: as equipes passam semanas (e às vezes meses) redigindo documentos de requisitos do produto.
Antes que qualquer código seja realmente escrito, gerentes de produto, analistas e designers irão reunir um grande documento que descreve os requisitos do produto em detalhes extremos.
Para dizer o mínimo, este é um processo longo e trabalhoso em que, inevitavelmente, algumas coisas passam despercebidas.
Aqui está um experimento de pensamento simples. Pense na pesquisa do Google ou em um cliente localizador de e-mail.
Agora tente imaginar o documento de requisitos para esses produtos.
Sem dúvida, coisas importantes serão perdidas. Simplesmente não se pode conceber o caso de uso, a escala ou o escopo de como esses produtos irão evoluir com o tempo.
Se você construiu um produto – como construtor solo ou como membro de uma equipe – provavelmente se identifica com essa afirmação.
Quando tudo é acordado, as especificações são entregues à equipe de engenharia, que então desenvolve o produto de acordo com as especificações, alavancando dados qualitativos e quantificados e entradas.
Quando tudo estiver codificado, o teste começa.
Se for um produto complexo, o teste e a correção de bugs podem levar semanas ou meses, pois o produto inteiro precisa passar por uma revisão rigorosa. Quando os testadores e gerentes de produto aprovam os requisitos de teste, o produto está pronto para ser enviado para produção.
Há uma série de deficiências no desenvolvimento em cascata e aqui estão algumas.
Falta de mecanismos de feedback integrados
E se a equipe de desenvolvimento seguir exatamente as especificações e descobrir que vê-lo ganhar vida não é tão atraente quanto a equipe de produto pensava que fosse? Ou pior ainda, e se houver um erro no documento de especificação?
No desenvolvimento em cascata, você não saberá a resposta a essas perguntas até que o produto já esteja construído.
O desenvolvimento de produtos pode levar a grandes custos fixos. Se o produto não funcionar, esses custos podem se tornar custos irrecuperáveis.
Os custos irrecuperáveis são inimigos do construtor porque um custo irrecuperável é um custo que já foi incorrido e não pode ser recuperado.
E se o roteiro mudar?
Isso acontece o tempo todo. Acontece no computador que você está usando para ler este artigo, na sua empresa e em grandes e pequenas empresas de tecnologia.
E se o roteiro mudar e a equipe precisar voltar sua atenção para outra coisa? Em Cachoeira, você fica com um produto inutilizável. Pense: rigidez.
Novamente, se você não puder transformar seus custos fixos em algo flexível, você ficará com uma conta grande e não muito para mostrar por ela.
Todo o trabalho dedicado, prazos estressantes, calandragem de quadro branco, e até tarde da noite não levarão aos resultados que você queria no início do projeto.
O produto coleta poeira até ser finalmente enviado
Em vez de melhorias incrementais sendo entregues à produção ao longo de um período de tempo, a metodologia em cascata espera para entregar o produto inteiro até o final.
Embora essa seja uma abordagem razoável para construir um carro, não é uma ótima abordagem para software.
O software, ao contrário dos carros, é flexível nas entradas de design.
As pessoas não podem usar carros produzidos pela metade. Mas usamos software parcialmente construído o tempo todo.
Entrar no Agile
O Agile ajuda a resolver esses problemas, permitindo que as equipes de desenvolvimento de produtos criem continuamente recursos que agregam valor. Ele também permite que as equipes obtenham feedback sobre seu trabalho de forma consistente e façam as alterações necessárias.
Com o emprego de métodos Agile, as equipes enviam de forma consistente e previsível pequenos pedaços de código para a produção em um ritmo rápido.
Depois de concluírem qualquer tipo de recurso que agregue valor, eles o testam e lançam para o mundo. Esta é uma abordagem iterativa para a construção de tecnologia.
Em vez de levar meses para construir um produto final e executar um teste de ponta a ponta, o desenvolvimento do Agile permite que as equipes criem continuamente partes menores do produto final e as adicionem à produção ao longo do tempo.
Isso significa que o teste é mais rápido, pois você está apenas testando a compatibilidade da parte mais recente do código. Isso também significa que os usuários e as partes interessadas ficam mais felizes porque conseguem ver e utilizar as melhorias mais recentes do produto continuamente.
Considere ambas as abordagens de um exemplo real de remodelação de uma cozinha. Digamos que demore seis meses para fazer bem a reforma.
Waterfall sugere que o empreiteiro e sua equipe reconstruam a cozinha inteira e, em seguida, revele toda a cozinha ao cliente após o término dos seis meses.
Embora o trabalho seja feito no mesmo período de tempo, o proprietário fica no escuro. Perguntas simples, como como está indo, ficam sem resposta. Pior de tudo, os proprietários não conseguem usar nenhuma peça da cozinha até o final.
Com o Agile, o empreiteiro iria descobrir o que sua equipe poderia fazer a cada poucas semanas e, então, permitir que seu cliente visse e usasse enquanto eles reformavam o resto.
Talvez consigam substituir os armários no primeiro mês, as bancadas no segundo mês e, no terceiro mês, instalem uma nova geladeira e fogão. Não é um mau resultado para ambas as partes!
Na segunda abordagem, o proprietário obtém o benefício de usar partes da cozinha antes que tudo esteja concluído. Em vez de o novo fogão ficar parado e juntando poeira, ele está sendo utilizado assim que estiver em condições de ser utilizado.
E talvez o dono da cozinha queira trocar um armário por uma prateleira?
O empreiteiro agora pode pelo menos planejar essa mudança antes que os seis meses acabem e deixar o proprietário saber como isso afetará o cronograma do projeto.
Aparentemente, ambas as partes podem trabalhar juntas e se comunicar de forma transparente para garantir que os resultados e o trabalho corretos sejam realizados.
Esses são alguns dos muitos benefícios do Agile. Ambas as partes estão em melhor situação.
Tente levar esta lição adiante enquanto você aprende novas habilidades de desenvolvimento no freeCodeCamp e aplica suas habilidades em projetos.
Vamos considerar alguns outros exemplos no mundo do software
Revisitando os quatro princípios do Agile, podemos agora começar a encontrar exemplos de aplicação do Agile no mundo real e digital.
Agora, espero que você possa ver como esses princípios são um ataque direto ao processo em cascata.
Princípio # 1: Indivíduos e interações sobre processos e ferramentas
Ter um processo sólido e um conjunto de ferramentas é muito importante no Agile. No entanto, valorizar indivíduos e interações em vez de ferramentas permite mais criação de valor e produção.
Membros individuais da equipe podem inovar.
Em vez de forçar as pessoas a se conformarem a idéias e especificações estritas, você pode dar a elas mais largura de banda para experimentação.
Parte de colocar os indivíduos sobre as ferramentas é a experimentação com novos fluxos de trabalho. Um exemplo relevante para a inovação no desenvolvimento de software Agile é o codec, um programa de computador que codifica ou decodifica um fluxo de dados digital ou sinais.
o Codec H266 / VVC usa cerca de metade dos dados para transmitir vídeos em 4K. E é reconhecido como a solução de codificação mais eficiente para o futuro streaming de 4K e até 4K VR em tempo real.
Como essa descoberta foi feita? Foi feito por pessoas que usam Agile para resolver problemas de compressão de vídeo.
Especificamente, foi feito porque os indivíduos tiveram liberdade para construir, testar, experimentar e inovar durante um período de tempo. Eles não foram orientados a construir a cozinha do zero e voltar em seis meses.
Eles deram pequenos passos na direção certa. Este resultado é instrutivo.
Aqui está um segundo exemplo: quando Última passagem foi adquirida pela LogMeIn, a LogMeIn estava tão interessada na tecnologia quanto na cultura de design que a Lastpass implementou para construir produtos.
Que tipo de cultura era essa? Aquele que priorizou o Agile.
O Agile não apenas traz produtos ao mercado com mais rapidez, mas também cria resultados criativos e sinérgicos valiosos.
A criação de valor está inserida na cultura do Agile.
Princípio # 2: Software de trabalho sobre documentação abrangente
Este deve ser óbvio agora. Em vez de especificações detalhadas e planejamento, apenas escreva algumas linhas de código que funcionem.
Teste-o. Obtenha feedback sobre isso. Enviá-lo.
Então, faça de novo.
Repetir.
Um exemplo altamente relevante deste processo de repetição é encontrado em Formulários em chamas.
Eles criaram um software para facilitar a coleta de dados móveis. Eles não escreveram toda a empresa antes do lançamento; eles escreveram algumas linhas de código, testaram e enviaram.
À medida que ganhavam impulso, eles aceleravam seus testes e etapas iterativas.
E eles repetiam o que funcionava e jogavam fora o que não funcionava. Os resultados falam por si.
Princípio nº 3: colaboração do cliente na negociação do contrato
O Agile promove um ciclo de feedback rápido para obter feedback do cliente e das partes interessadas.
O que poderia ser melhor do que trabalhar de trás para frente a partir do que os usuários e clientes reais desejam?
eu tenho um mentor de negócios que avisou que, em vez de analisar demais o que os clientes desejam por meio de um planejamento infinito, basta manter a simplicidade. “Mitigar distrações”, disse ele.
Eu escrevi sobre o princípio KISS em freeCodeCamp e esse conselho certamente é verdadeiro no Agile: crie algo pequeno e veja se seus clientes gostam.
Se o fizerem, continue.
Princípio nº 4: Respondendo à mudança ao invés de seguir um plano
Os loops de feedback rápido geram mudanças e ajustes rápidos. Isso é o que torna o Agile tão bom para equipes de desenvolvimento.
É por isso que você deve abraçá-lo.
Os roteiros sempre mudam, esta é uma constante conhecida. Usando metodologias Agile, as equipes podem responder às mudanças ouvindo o feedback do cliente e fazendo os ajustes necessários.
Há momentos em que responder a mudanças significa ajustar seu produto ou mudar a forma como você pensa sobre os usuários ou a concorrência.
Um exemplo clássico que os alunos de agile podem observar no espaço de e-commerce é vendendo na amazon. Como você se ajusta rapidamente à competição? Uma maneira é construir comunidades fechadas ou experimentar diferentes estratégias de lançamento de produtos.
É aconselhável implementar soluções táticas e maleáveis.
Existe um provérbio maravilhoso: “Não podemos mudar a direção do vento. Só podemos ajustar nossas velas. ”
Quando penso em Agile, penso neste ditado.
Agile é sobre aprendizado, Agile é sobre ensino. Agile significa flexibilidade.
Você pode praticar o Agile no seu dia a dia de trabalho ou tirar Cursos online para desenvolver ainda mais.
Algumas pessoas são inteligentes o suficiente para prever o que seu cliente deseja. Eles sabem para que lado o vento está soprando.
Mas, para nós, mortais, o Agile é uma metodologia para contornar nossas deficiências em compreender o que os clientes desejam.
É o sistema que nos permite ajustar constantemente nossas velas.
[ad_2]
Fonte
