1- Metodologias ageis

Prévia do material em texto

Caro(a) estudante, ao ler este roteiro você iniciará o aprendizado do novo mundo das metodologias ágeis. Os conceitos que serão apresentados são de metodologias que proporcionam a melhora em processos de fabricação de produtos/serviços, destacando a melhora em tempo e custo.
Podemos destacar os seguintes tópicos de aprendizado:
Definição de Metodologias Ágeis
· Definição de Metodologias Ágeis
· Habilidades para utilização/implementação de métodos ágeis.
· Definição dos métodos: Lean Software Development, SCRUM e eXtreme Programming.
· Novas Tendências de Métodos Ágeis:  Kanban,  DevOps, Squads & Tribes, Agile Scaling e Change Management.
· Exposição de Casos de Sucesso.
Bons estudos!
Introdução
Hoje, podemos destacar cada vez mais a inserção de métodos ágeis por empresas, que buscam principalmente melhorar a qualidade de seus produtos e realizar a produção de forma mais rápida.
São diversos os casos de sucesso e que fazem com que essas empresas queiram aplicar as metodologias. Podemos destacar os mais utilizados, como o Scrum, Kanban e o eXtreme Programming; mas também os que vêm surgindo como uma nova opção, como o DevOps.
Mas como os Métodos Ágeis funcionam? Quais as principais características e quais os motivos pelos quais são aplicados? Métodos ágeis são aplicáveis somente na área de software ou posso aplicar em diversas outras áreas? São perguntas importantes e iremos responder no decorrer do conteúdo que será exposto. A partir de agora, mergulhe no mundo das metodologias ágeis.
Conceito de Métodos Ágeis
Algumas pessoas geram confusão em relação ao termo “ágil”,  pensando que o termo remete a uma construção mais rápida - o que é totalmente relativo em se tratando de metodologias ágeis. Vejamos um exemplo: Uma construção tradicional levanta colunas, vigas, lajes, até no último andar realizando todos os procedimentos necessários de construção o mais rápido que pode. O foco é fazer tudo em menos tempo possível (18 meses para a conclusão). Agora, esta mesma construção em um modelo ágil irá realizar os procedimentos, interrompendo no terceiro mês de obra a fim de montar um apartamento decorado completo, deixando visível o potencial do empreendimento (20 meses para conclusão). Destaca-se que os 20 meses são mais ágeis que 18 devido a atendermos o objetivo real, que não é realizar a construção de forma mais rápida, e sim oferecer algo diferenciado (AUDY, 2015).
O manifesto ágil fala da entrega antecipada de valor, de forma interativa, a fim de satisfazer o cliente com qualidade e realizando correções necessárias. No exemplo citado, podemos destacar que isso é possível realizando o apartamento decorado, buscando agregar valor ao número de participantes e interessados, bem como promover a satisfação.
Mas quando surgiu o Manifesto Ágil? O surgimento se deu a partir de diversos profissionais que estavam praticando novos métodos de desenvolvimento de software, e nasceram em meados dos anos 1990. Novos frameworks começaram a surgir, sendo conhecidos inicialmente como métodos leves. No ano de 2001, ocorreu uma reunião onde estavam presentes dezessete profissionais que trabalhavam com esses métodos e, assim, se deu definitivamente o surgimento e a propagação de paradigmas ágeis (GOMES, 2014).
O objetivo do encontro era trocar ideias sobre os métodos utilizados e formas de melhorar o desempenho de seus projetos. Nessa reunião, os profissionais perceberam que cada um utilizava uma prática diferente ou adaptada a determinada necessidade, e, a partir disso, decidiram criar um documento que possuía o nome de “Manifesto Ágil” (SBROCCO; MACEDO, 2012).
Esse manifesto, assim, foi criado considerando a velocidade que era demandada para novos sistemas de software e com o objetivo de abandonar os métodos antigos. Trata-se de um documento que encoraja o uso de melhores métodos para o desenvolvimento de sistemas, contendo princípios para os processos de desenvolvimento ágil (SBROCCO; MACEDO, 2012).
Princípios Ágeis
O Método Ágil possui 12 princípios que são essenciais para a sua aplicação. Podemos destacar esses princípios a seguir (AUDY, 2015):
1. A prioridade é satisfazer o cliente, entregando softwares com qualidade e em tempo hábil;
2. Mesmo com o desenvolvimento avançado, aceita-se mudanças impostas de requisitos para que clientes tirem vantagens e sejam competitivos;
3. Softwares são entregues funcionando em determinados períodos, sendo semana ou meses, levando-se em consideração o período mais curto;
4. No curso do projeto, desenvolvedores e todo pessoal envolvido a negócios devem se envolver e trabalhar em conjunto;
5. Deve-se dar ambiente e suporte necessários aos indivíduos, tornando-os assim motivados e confiantes de que cumprirão o seu trabalho;
6. É essencial manter uma conversa cara a cara; com isso é possível transmitir informações eficazes para o time de desenvolvimento;
7. Software funcional é a medida primária de progresso;
8. Deve-se promover um ambiente sustentável;
9. Deve-se ter atenção a técnicas utilizadas e bom design para o aumento da agilidade;
10. Aplicar a arte da simplicidade no trabalho;
11. Os times devem ser auto organizáveis, o que melhora a obtenção de requisitos, arquiteturas e designs;
12. O time deve otimizar seu comportamento de acordo com a necessidade, para que assim fique mais efetivo.
Benefícios dos Métodos Ágeis
Uma das motivações para a utilização dos métodos ágeis é o valor agregado ao cliente com qualidade e velocidade. Métodos Ágeis auxiliam organizações a responderem mais rapidamente às necessidades do mercado, o que gera vantagem competitiva.
Podemos afirmar, assim, que existem alguns benefícios ao se utilizar métodos ágeis, como, por exemplo, maior retorno sobre o investimento realizado no desenvolvimento do produto, seja por meio de lucros diretos ou de benefícios pela utilização do produto.
Outro benefício está atrelado à gestão de mudanças de prioridades, na qual uma comunicação constante e boa com o cliente e um planejamento detalhado do que está próximo a ser realizado evita desperdícios e custos desnecessários, o que, consequentemente, gera maior satisfação do cliente.
Temos, ainda, a geração de maior produtividade e melhor visibilidade do projeto em relação às informações importantes e transparentes. É perceptível que as equipes ficam mais motivadas, devido a ritmos sustentáveis de trabalho, sendo que algumas organizações diminuem horas extras e madrugadas de trabalho (SBROCCO; MACEDO, 2012).
Citamos, ainda, uma melhor disciplina na engenharia, o que contribui com a entrega de um produto com melhor manutenibilidade e com muito menos defeitos. Os processos de desenvolvimento com métodos ágeis são mais facilmente compreendidos pela equipe, o que os torna simplificados, além de oferecer uma maior otimização, adaptação e maior eficiência (AUDY, 2015).
Por fim, podemos citar, também, a redução de risco e redução de custos como benefícios. Métodos ágeis possibilitam que certas incertezas em relação ao projeto sejam estimadas e distribuídas de forma inteligente, para que assim o risco seja balanceado. Já em relação aos custos, equipes ágeis são menos propensas a desenvolver funcionalidades desnecessárias ou com baixa prioridade (GOMES, 2014).
Habilidades para Utilização/Implementação de Métodos Ágeis
Os processos de adoção de metodologias ágeis em empresas podem ter muito da equipe a favor, ou, ainda, contra. O apoio de coordenadores, gerência e direção são fundamentais para que, mesmo com obstáculos, consiga-se inserir as metodologias no dia a dia das empresas.
Mas devemos entender que implementar métodos ágeis é impossível sem que haja uma mudança de cultura na empresa. É necessário envolver toda a equipe da empresa para que assim percebam o valor que as metodologias ágeis podem entregar.
Além disso, é importante romper entraves hierárquicos para a implantação do método ágil, como, por exemplo, assegurar entregas mais rápidas, ter visibilidade de processos e resultados por clientes, identificar o que é ou não valor para os envolvidos no projeto, propiciar que os produtostenham valor, e também, analisar riscos e o que é gerado com qualidade.
Dessa forma, para incorporar métodos ágeis em empresas pode-se planejar iniciativas, como a identificação de pessoas que têm o conhecimento e que possam ajudar a levar os métodos ágeis para a empresa. Também é importante que haja cursos e treinamentos com empresas que entendam de métodos ágeis; reforçando e inserindo treinamentos internos.
É importante, também, a proximidade de todos da equipe, já que os projetos devem ser acompanhados dia a dia, criando assim um ambiente favorável entre equipe e seus superiores. Isso ocorrerá com a comunicação ativa entre os envolvidos e por meio dos cursos, guias e outros.
A equipe influencia e muito na adesão, por esse motivo, é importante realizar um pacto com a equipe, listando um conjunto de ações para uma convivência adequada, se o time julga necessário. Assim, criar um quadro indicando o que se quer e o que não se quer é fundamental. A lista de informações inseridas neste quadro deve ser espontânea.
Na parte do “queremos”, por exemplo, a equipe pode incluir que quer ser ouvida e respeitada dadas as devidas circunstâncias. Ter uma transparência nas ações é importante para a sustentação de metodologias, sabendo o que é prioridade e o que é desperdício, por exemplo.
Na parte do “não queremos”, deve-se colocar tudo o que não cause perturbação no ambiente de trabalho e que não cause desrespeito aos colegas da equipe.  Isso é essencial para que não seja levado nada para o pessoal e o fluxo do projeto ocorra de forma adequada (AUDY, 2015).
Software Development, SCRUM e eXtreme Programming
A partir de agora, iremos começar a definir algumas das metodologias ágeis existentes, identificando as principais características para que seja possível entender o funcionamento de cada método. A princípio, neste tópico iremos falar sobre Lean Software Development, Scrum e eXtreme Programming.
Lean Software Development – Desenvolvimento de Software Enxuto
Também é conhecido como um método de Desenvolvimento de Software Enxuto; apresenta valores ágeis, agrega valor em outras metodologias e propicia boas práticas. Ele é baseado na metodologia conhecida como Lean Manufacturing (manufatura enxuta), que foi desenvolvida pela Toyota (RIBEIRO; RIBEIRO, 2015).
Este método está ligado diretamente à redução do desperdício, como, por exemplo, documentação excessiva, funcionalidades e rotinas que não foram solicitadas, e também tempo de desenvolvimento. Tudo isso, com o propósito de aumentar a velocidade de produção, melhorar a qualidade dos produtos e obter um produto com menor custo associado (SABBAGH, 2014).
Para a possibilidade de aplicação do método, são identificados 7 (sete) princípios essenciais, que podemos visualizar a seguir (RIBEIRO; RIBEIRO, 2015):
1. Eliminar o Desperdício: princípio que possui a ideia de eliminar tudo aquilo que não gera valor ao produto, sempre levando-se em consideração a visão do cliente. O desperdício é classificado em categorias, sendo: MURA: Desperdício gerado desenvolvendo o que não foi solicitado pelo cliente acreditando que um dia poderá ser útil. MURI: Desperdício gerado pela falta de planejamento e também pelo excesso de burocracia. MUDA: Desperdício gerado pela cultura de trabalho, como: espera, defeitos, inventário, transporte desnecessário e outros.
2. Empoderar o time: deve-se envolver todo o time de trabalho, respeitando seus conhecimentos e deixando que eles sejam responsáveis por decisões técnicas necessárias para o sucesso do projeto.
3. Entregar Rapidamente: significa fornecer ao cliente uma versão do produto para a utilização, de forma rápida, para que assim possa aumentar o retorno sobre o investimento. Isso se dá devido à priorização de funcionalidades importantes pelo cliente, sendo assim produzido primeiro, e sendo utilizado mais cedo pelo usuário.
4. Otimizar o Todo: está relacionado com a compreensão de todo trabalho que o cliente deseja e como otimizá-lo da melhor forma possível. Deve-se levar em conta também que a equipe e o processo de trabalho sejam seguidos em conjunto.
5. Construir com Qualidade: a qualidade deve ser assegurada com a construção em todo processo de desenvolvimento, podendo utilizar técnicas de refatoração e testes.
6. Adiar Decisões: significa equilibrar o planejamento antecipado com a tomada de decisões e decidir o mais tarde possível. Em muitos projetos decide-se inicialmente várias premissas, o que sempre traz riscos ao projeto, como estar restrito a uma solução limitada por uma tecnologia, por exemplo.
7. Amplificar Aprendizagem: está relacionada ao aprendizado contínuo, a criação de conhecimento, feedbacks e outros, transformando esses conhecimentos em produto.
O Lean recomenda, ainda, a utilização de métricas e indicadores para auxiliar em mudanças que serão realizadas, podendo envolver desde o feedback do cliente à qualidade dos produtos implementados.
Scrum
Esse método emprega uma abordagem interativa e incremental realizando o aperfeiçoamento da previsibilidade e o controle de riscos. Sua história é baseada no artigo escrito por Hirotaka Takeuchi e Ikujiro Nonaka, em que utilizaram o esporte rugby como uma metáfora para descrever os benefícios da auto-organização de equipes. Jeff Sutherland, Ken Schwaber e Mike Beedle aderiram às ideias e as aplicaram na área de desenvolvimento de software (RIBEIRO; RIBEIRO, 2015).
Como os outros métodos, o Scrum baseia-se em determinados pilares. No caso do Scrum, os pilares estão relacionados à transparência, inspeção e adaptação. Em relação à transparência, o processo deve ser visível a todos os envolvidos no projeto. Na inspeção, o processo deve ser inspecionado regularmente na busca por anomalias ou de possíveis melhorias no processo. E, por fim, a adaptação, na qual caso a inspeção detecte algum problema a ser ajustado ou melhorado, as adaptações devem ser feitas o mais rápido possível (SABBAGH, 2014).
O sucesso do Scrum depende muito das pessoas que compõem o time e que se comprometem a alcançar os objetivos propostos, todos focam no trabalho e são engajados para realizar o trabalho de forma correta e todos são participantes do projeto e dos desafios que possam surgir.
O Time Scrum
O Time Scrum é composto por um Product Owner (dono do produto), por um time de desenvolvimento e por um Scrum Master. O time possui características de ser auto-organizável e multifuncional. A característica auto-organizável diz respeito a escolha da melhor forma para a complementação de um trabalho, em vez de serem dirigidos por outros de fora do time. Já os times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe (RUBIN, 2018).
O Time Scrum é projetado para ter flexibilidade, criatividade e produtividade, demonstra estar aumentando sua efetividade e maximizando as oportunidades para feedback. Com o time realizam-se entregas incrementais de produto e garantem que uma versão funcional do produto esteja sempre disponível (SCHWABER; SUTHERLAND, 2017).
O Product Owner
O Product Owner é também conhecido como dono do produto. Ele maximiza o valor do trabalho que o Time de Desenvolvimento realiza, expressa claramente e ordena itens para alcançar melhores metas, e garante a clareza dos itens para o time desenvolvimento (RUBIN, 2018).
Além disso, o Product Owner é uma pessoa que pode representar o desejo de um comitê. Para que ele tenha sucesso, todos os envolvidos devem respeitar a sua decisão, que são visíveis no conteúdo e na priorização do backlog (lista de tarefas) do Produto (AUDY, 2015).
O Time de Desenvolvimento
Este consiste de profissionais que realizam o trabalho de entregar os “avanços” do produto “pronto” ao final de cada sprint (reunião de pessoas), de cada dia. Os times de desenvolvimento normalmente são estruturados e gerenciam seu próprio trabalho. Assim, eles possuem as seguintes características (SCHWABER; SUTHERLAND, 2017):
· Auto-organizáveis;
· Multifuncionais;
· Os integrantes não recebem títulos, independente doque eles fazem na equipe;
· A equipe não é dividida em subtime, independente dos conhecimentos de cada um;
· Os integrantes podem ter habilidades específicas, mas a responsabilidade sempre será do time de desenvolvimento como um todo.
Com relação ao tamanho, um time de desenvolvimento ideal deve ser pequeno para se manter ágil, mas grande o suficiente para terminar um trabalho significativo. Times menores podem encontrar restrições de habilidades, sendo assim incapazes de entregar um determinado incremento no produto; mas também em times muito grandes será exigida muita coordenação (SBROCCO; MACEDO, 2012).
O Scrum Master
O Scrum Master é responsável por promover e suportar o Scrum, fazendo com que todos entendam a teoria, prática, regras e valores do Scrum.  O Scrum Master serve o Product Owner garantindo que objetivos, escopo e domínio do produto sejam entendidos; é responsável por encontrar técnicas para o gerenciamento do Backlog do Produto; ajuda o time Scrum a entender as necessidades de itens, compreendendo o planejamento do produto; além disso, garante a compreensão e prática da agilidade e facilita os eventos Scrum (SCHWABER; SUTHERLAND, 2017).
O Scrum Master também trabalha em função do time de desenvolvimento, oferecendo assim treinamentos importantes sobre o método Scrum, ajudando na criação de produtos de valor, removendo possíveis impedimentos para o progresso correto do time e facilita eventos Scrum (GOMES, 2014).
Por fim, o Scrum Master também trabalha para a organização, liderando e treinando a organização, ajudando funcionários e partes interessadas na compreensão e desenvolvimento de produtos, planejando implementações e outros.
Eventos Scrum
Os Eventos Scrum são utilizados para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum. Todos os eventos são eventos com duração máxima. Assim sendo, quando se inicia um Sprint, a duração é fixada, não podendo ser aumentada ou reduzida (AUDY, 2015).
Além da Sprint, cada evento possui uma oportunidade de inspecionar e adaptar alguma coisa que se deseja realizar. Possíveis falhas na inclusão de eventos resultarão na redução da transparência e em problemas para inspecionar e adaptar (RUBIN, 2018).
Sprint
É a principal característica do Scrum e tem duração consistentes durante o desenvolvimento; e essa nova etapa Sprint inicia imediatamente após a conclusão da anterior. Cada Sprint é composta por um planejamento, reuniões diárias, trabalho de desenvolvimento, revisão da Sprint e uma retrospectiva (AUDY, 2015).
O planejamento deve ser adequado, pois durante a Sprint não são realizadas mudanças que causem perigo, nas quais as metas de qualidade não diminuem. Cada Sprint não deve ser maior que um mês de duração, possui uma meta do que é para ser construído, permite previsibilidade e limita o risco ao custo de um mês corrido.
Cancelamento da Sprint
Somente o Product Owner pode cancelar a Sprint e isso poderá ocorrer se as condições de mercado ou tecnologias mudarem e o objetivo atual do projeto se tornar ultrapassado. O cancelamento de Sprints consome recursos e são traumáticos para o Time Scrum; e devido a isso e a curta duração de uma Sprint, é que raramente cancelamentos fazem sentido (SCHWABER; SUTHERLAND, 2017).
Planejamento da Sprint
É onde todo o trabalho a ser realizado na Sprint é planejado e para que isso seja possível deve-se responder a alguns questionamentos, como: O que pode ser entregue como resultado do incremento da próxima Sprint? Como o trabalho necessário para entregar o incremento será realizado? (SCHWABER; SUTHERLAND, 2017).
Meta da Sprint
É um objetivo definido para a Sprint e que fornece uma direção para o Time de Desenvolvimento, em relação ao porquê de estar construindo determinado incremento. A meta é criada na reunião de planejamento. O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de Desenvolvimento trabalhar em conjunto em vez de em iniciativas separadas (RUBIN, 2018).
Reunião Diária
É um evento de aproximadamente 15 minutos destinado ao Time de Desenvolvimento e é realizado em todos os dias da Sprint. É nesta reunião que ocorre todo o planejamento que acontecerá no próximo dia, o que resultará na otimização do trabalho. Além disso, nesta reunião também verifica-se o que foi realizado da reunião anterior (SBROCCO; MACEDO, 2012).
A reunião aumenta a probabilidade do objetivo da Sprint ser atingida, mas deve-se seguir uma estrutura específica, que pode ser realizada através de perguntas como: o que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint? O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint? Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint? (RUBIN, 2018).
As reuniões diárias, por fim, melhoram a comunicação entre os membros do time e removem e identificam impedimentos do desenvolvimento, sendo assim, uma reunião chave para características como inspeção e adaptação.
Revisão da Sprint
A Revisão Sprint é realizada ao final da Sprint e é destinada a inspecionar o que foi realizado (incremento). A revisão é uma reunião informal, de no máximo 4 horas de duração para uma Sprint de um mês. Para Sprints menores, esse evento é usualmente menor (AUDY, 2015).
A revisão da Sprint inclui determinados elementos, como (SCHWABER; SUTHERLAND, 2017):
· Os participantes incluem o Time Scrum e os stakeholders chaves convidados pelo Product Owner;
· O Product Owner indica os itens que ficaram “Prontos” e quais não ficaram;
· O Time de Desenvolvimento discute o que foi bem, problemas encontrados e como foram resolvidos, dentro de uma sprint;
· O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde às questões sobre o incremento;
· O grupo todo colabora sobre o que será feito em próximos passos;
· Revisão de como o mercado ou o produto pode ter mudado e o que deve ser feito;
· Revisão de tempo, orçamento, potenciais capacidades, e mercado para a próxima versão.
Retrospectiva da Sprint
É uma oportunidade para o Time Scrum inspecionar a si próprio e poder criar possíveis melhorias que possam ser aplicadas.  Sempre ocorre após a Revisão da Sprint e antes de se planejar o que será feito na próxima Sprint. Como propósito, a retrospectiva deve (SCHWABER; SUTHERLAND, 2017):
· Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;
· Identificar e ordenar os principais itens que foram bem e as potenciais melhorias;
· Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho.
Artefatos do Scrum
Os artefatos do Scrum representam o trabalho e são especificamente projetados para maximizar a transparência das informações chave, de modo que todos tenham o mesmo entendimento dos artefatos. Logo, iremos detalhar um pouco mais dos artefatos existentes.
Backlog do Produto
É uma lista ordenada de tudo o que deve ser necessário no produto, mas ele nunca está completo. Os primeiros estabelecem requisitos inicialmente melhor entendidos, evoluindo conforme o produto vai também evoluindo.
O backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que devem ser feitas nas futuras versões. Os itens do backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. Um backlog do Produto é usado para descrever o trabalho previsto para o produto (RUBIN, 2018).
Backlog da Sprint
É um conjunto de itens do backlog do Produto selecionados para a Sprint, e é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto” (RUBIN, 2018).
O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir o objetivo e é um plano com detalhes suficientes que as mudanças no progresso sejam entendidas durante a Reunião Diária.
Incremento
É a soma de todos os itens do Backlog do Produto completadosdurante a Sprint e é uma parte principal inspecionável de trabalho pronto, sendo um passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser utilizado (AUDY, 2015).
eXtreme Programming
É uma metodologia que se ajusta a pequenas e médias equipes de desenvolvimento. Esta metodologia também é conhecida pelas siglas XP e possui características marcantes, como feedback constante, abordagem incremental e comunicação entre as pessoas envolvidas.
A XP foi criada em 1996, e apresentada por Kent Beck a OOPSLA (Object-Oriented Programming, Systems, Languages and Applications). Essa metodologia tem como objetivo atender as necessidades dos clientes com qualidade e da forma mais simples possível, entregando projetos de forma rápida e dentro do prazo definido (SBROCCO; MACEDO, 2012).
Utiliza um modelo incremental, desta forma, na medida em que o software é utilizado, novas melhorias são implementadas. É uma metodologia flexível que pode ser adaptada a projetos distintos.
A XP possui alguns valores essenciais, como a “comunicação”. Essa propõe que desenvolvedores devem se comunicar com clientes de forma direta. Assim, as chances do projeto ficar com pendências são reduzidas, pois faz que o cliente se sinta parte do desenvolvimento. A comunicação é importante pois possibilita um outro valor, chamado feedback (TELES, 2014).
A ideia do feedback é que, à medida que, o software é implementado, o cliente o utiliza, retornando argumentos sobre determinadas funcionalidades. E permite ainda que o cliente esteja sempre avaliando o produto e transmitindo determinados problemas para os desenvolvedores do projeto. Além, é claro, de que o cliente vai aprendendo com os sistemas e colaborando sempre com a fase de adaptação e treinamento, ao qual utilizando esta metodologia, não se torna necessário (WILDT; MOURA; LACERDA; HELM, 2015).
Em relação ao valor “simplicidade”, a característica principal diz respeito a não implementação de recursos desnecessários aos objetivos do software. Assim, para que a comunicação e o feedback funcionem corretamente, a equipe de desenvolvimento deve agir com simplicidade na resolução daquilo que o cliente deseja. O XP prega que devemos pensar no agora, naquilo que possa agregar e ser entregue ao cliente rapidamente (SBROCCO; Macedo, 2012).
Por fim, temos o valor “coragem”, que exige que os desenvolvedores tomem atitudes complexas ou de alto risco. Assim, ao receber a proposta para desenvolvimento e a lista dos requisitos, a equipe deve discutir e decidir como atacar o problema, sempre estabelecendo um contato próximo com o cliente, devendo ter coragem para modificar, sugerir ou agir sobre algo (TELES, 2014).
Práticas da XP
A XP possui um conjunto de boas práticas que são expressas por atitudes que devem ser seguidas pela equipe de desenvolvimento. Podemos destacar os Padrões de Desenvolvimento, cujo objetivo é que todos consigam entender rapidamente os códigos uns dos outros. Essa prática possibilita a integração via código (WILDT; MOURA; LACERDA; HELM, 2015).
Outra prática é relacionada a Design Simples, que possibilita a convivência facilitada com as alterações que o sistema pode sofrer. Já para a prática de o cliente sempre estar disponível ou presente, o que possibilita que o sistema o atenda plenamente, pois conforme o software é implementado, o cliente tem a visão de como ele vai ficar, além de sugerir possíveis mudanças (TELES, 2014).
Podemos citar também a prática de Programação em Pares, ou também conhecido como pair programming, cuja características é a programação em dupla. Na programação pareada, enquanto um desenvolvedor digita o código, o outro, de forma simultânea, vai revisando possíveis erros de programação e a sugestão de melhorias. Uma característica também é a troca de experiência entre a dupla de programadores. Temos também a prática Refactoring, que é uma prática de correção e melhoria, porém o objetivo não é sair refazendo tudo, mas sim melhorar o que já foi feito (SBROCCO; MACEDO, 2012).
Novas Tendências de Métodos Ágeis:  Kanban,  DevOps, Squads & Tribes, Agile Scaling e Change Management.
Existem diversas outras metodologias sendo utilizadas por empresas, consideradas novas tendências. A partir de agora, iremos definir brevemente algumas delas que podem ser inseridas em qualquer empresa, dependendo dos objetivos.
KanBan
A origem se deu no Sistema Toyota de Produção e é fundamental para o conceito de produção puxada, em que há um esforço para a redução máxima de estoque, matéria prima e outros, eliminando assim desperdícios por meio de uma produção contínua e entregas em tempo real.
O Sistema Kanban controla a fabricação de produtos conforme a quantidade e tempos necessários para a etapa de produção. É aplicado em diversas áreas, como a de desenvolvimento de software, serviços e outras que possuem interação entre pessoas.
O Kanban possui diversas características e objetivos, como minimizar inventário e estoques de insumos; reduzir o tempo total de produção; evitar gargalos no fluxo entre etapas do processo; descentralização e auto-organização no controle de produção e estoque; garantir a cadência e o controle puxado do sistema, sem interrupções e outros (REINERTSEN; ANDERSON; PINTO, 2011).
DevOps
Essa metodologia utiliza-se da comunicação entre os participantes para integrar os desenvolvedores de software e os profissionais de tecnologia. Com isso, o modelo aproxima o desenvolvimento das operações objetivando a simplificação de processos, integração de áreas, maior qualidade e redução de tempo (SATO, 2014).
Também é conhecida como uma metodologia com implementação ou entrega contínua, padronização ambientes de desenvolvimento e auxiliando no gerenciamento de novas versões.
Existem diversas melhorias que essa metodologia pode propiciar, além das já citadas, podemos destacar a integração entre áreas, a automação de tarefas, modernização da TI da empresa, estímulo à colaboração, empoderamento dos times de tecnologia da informação, e por fim, elasticidade e escalabilidade (SATO, 2014).
Squads & Tribes
Esta metodologia está sendo uma grande tendência e é um modelo organizacional que agrupa funcionários em pequenos grupos multidisciplinares com determinados objetivos. Esse modelo vem se popularizando principalmente no meio das Startups (uma empresa emergente que tem como objetivo desenvolver ou aprimorar um modelo de negócio). Como vantagem, devido a multidisciplinaridade, soluções para um determinado objetivo acontecem de forma mais ágil, porém é necessário que cada Squad (modelo organizacional) tenha autonomia para tomar decisões (GOMES, 2018).
Para essa autonomia funcionar, como dito, é necessário a comunicação, e é por isso que essa metodologia possui chapters, tribes e guilds; que são responsáveis por manter alinhados todos os objetivos. Temos que chapters são linhas destinadas ao alinhamento de informações do que acontece em cada squad. Já tribes é a junção de dois ou mais squads que possui como características objetivos parecidos. Por fim, temos os guilds que são grupos de pessoas formadas em qualquer área, mas que possuem um interesse por assuntos em comum (GOMES, 2018).
Podemos citar ainda, que o modelo trabalha com as características de descentralização, transparência e também em relação a constante evolução.
Agile Scaling
Sua estrutura é baseada nos métodos Scrum, eXtreme Programming e o  Lean. É uma abordagem que fornece uma visão muito grande dos princípios e práticas para escalar a abordagem Agile e seus benefícios.
Sua estrutura é composta por níveis estratégicos, táticos e operacionais, fornecendo um conjunto de práticas, onde no nível de equipe estabelece um modelo de processos ágeis baseados nos métodos Scrum e XP; no nível do programa estabelece esforços de equipes ágeis integradas; e no nível do portfólio, os programas estão de acordo com a estratégia de negócio (ROTHMAN, 2016)
Change Management
É uma metodologia estrutural que garante que qualquer mudança possa ser implementada em todos os detalhes. Ela possui característicascomo escala, onde a mudança pode afetar parte ou toda organização; a magnitude, que são as mudanças significativas no estado atual; e também, a duração e importância estratégica (CARLI, 2015).
Esta metodologia prioriza o fator humano, já que com ela novos líderes e novas habilidades devem surgir; envolve todas as esferas da organização, pois deve-se ter uma gestão de mudanças para que a implementação de todas as transformações sejam adotadas.
Como toda metodologia ágil, deve-se ter também a comunicação entre a equipe, com clareza em repassar informações aos canais das empresas. Deve-se ter uma atenção a equipe, pois cada um encara de forma diferenciada as mudanças que acontecem. Por esse motivo os líderes são importantes, pois são responsáveis pelas conversas com a equipe (CARLI, 2015).
Casos de Sucesso: Métodos Ágeis
Metodologias Ágeis estão cada vez mais sendo inseridas no meio empresarial, e claro, como toda inserção de uma nova metodologia, é importante verificar casos de sucesso. Esses casos de sucesso influenciam a adoção por futuras empresas das mais variadas áreas.
Dessa forma, iremos a partir de agora, visualizar alguns casos de sucesso da inserção de metodologias ágeis em empresas.
Caso 1: CISCO
Método: Scaled Agile Framework
Ano: 2015
Um produto específico da Cisco (Plataforma de Faturamento de Assinantes), que antes era realizado por uma metodologia cascata. Os defeitos eram muitos, prazos atrasados e muitas horas extras. Ao mudarem para essa metodologia, a Cisco criou três características importantes, como capacitação nos métodos ágeis, defeitos/correções e projetos. A equipe tinha reuniões de 15 minutos que determinavam itens de trabalho. Combinavam métodos ágeis do Scaled Agile Framework aos de Scrum. Algumas práticas do XP também foram utilizadas. Como resultados tiveram Object Style.
Fonte: 5 Success Stories That Will Make You Believe in Scaled Agile. Object Style
https://www.objectstyle.com/agile/scaled-agile-success-story-lessons
Caso 2: Primavera
Método eXtreme Programming
Primavera
Trata-se de uma empresa de software com mais de 20 anos de existência que desenvolve projetos e soluções de software. Desenvolve projetos de alta complexidade, atendendo inúmeros clientes, e possui um grupo de desenvolvedores das mais diversas linguagens e tecnologias. Começou a utilizar a Extreme Programming em seus projetos com o objetivo de levantar a autoestima de seus desenvolvedores que sempre trabalhavam exaustivamente em projetos, não vendo os resultados. Muitas vezes trabalhavam fora de horário e ficavam descontentes com isso. A XP resolveu esses problemas e o resultado da experiência é uma base de clientes altamente satisfeitos, e a equipe altamente motivada com um ambiente de desenvolvimento energético (SBROCCO; MACEDO, 2012, p. 157).
Caso 3: Banco Nacional do Canadá
Método: Scrum
Ano: 2012
Expõe a adoção do Ágil pelo Banco Nacional do Canadá que tinha como desafio equilibrar os requisitos de conformidade e práticas ágeis para obter o máximo de agilidade possível. Como resultados, tiveram Object Style.
5 Success Stories That Will Make You Believe in Scaled Agile. Object Style
https://www.objectstyle.com/agile/scaled-agile-success-story-lessons
Conclusão
Concluímos nosso estudo sobre a importância das metodologias ágeis para o processo de gestão de processos e para a produção de produtos/serviços. É fato a crescente demanda de qualidade e tempo na implementação de softwares, o que resulta na aplicação das metodologias ágeis por parte da empresa.
É importante destacar que, nas metodologias ágeis, a equipe se torna importante em todo o processo de produção e deve estar sempre atualizada do que deve ser feito, das novas tecnologias e entusiasmada para a conclusão do projeto.
Os vários tipos de métodos existentes podem, ainda, estar entrelaçados em um projeto, sendo aplicada cada característica existente, dependendo do tipo de projeto. Essas metodologias, hoje, são importantes para a demanda mercadológica, tanto de softwares quanto de quaisquer outros produtos.