O que há de tão bom no Agile? Uma cartilha sobre metodologia ágil
Agile Define como Agile Management Systems que existem há algum tempo, mas que ganharam moeda nos últimos tempos. De fato, o Gerenciamento Ágil é consistente nas principais tendências de gerenciamento de projetos de quase todos os blogs de gerenciamento de projetos de TI todos os anos.
As aplicações do Agile em projetos baseados em TI são incontestáveis, pois encontram uso não apenas em projetos de software de TI, mas também no desenvolvimento e inovação de produtos.
Então, o que há de tão bom no Agile? Pergunte aos funcionários que passaram de um sistema tradicional para o Agile, e eles podem lamentar as reuniões constantes e as "reuniões sobre reuniões".
Acontece que o Agile tem muito mais do que apenas reuniões e feedback. O objetivo é capacitar as equipes e remover maneiras sequenciais de desenvolvimento do projeto, para que haja mais flexibilidade e inovação. Embora isso signifique reuniões e resultados mais frequentemente do que com os sistemas tradicionais, também significa que há uma menor chance de iterações e alterações posteriormente no ciclo do projeto.
Ele está sendo apontado como a solução para problemas comuns que afetam projetos relacionados à TI. O que exatamente é e como é melhor que os sistemas tradicionais?
Necessidade de metodologia ágil - práticas de gerenciamento
Qualquer pessoa que tenha trabalhado em metodologia ágil em projetos de desenvolvimento de software terá uma idéia de alguns dos problemas comuns que surgem durante um projeto: mudança de escopo, prazos que parecem impossíveis de cumprir e recursos em excesso.
As metodologias ágeis tradicionais no Gerenciamento de Projetos tiveram muitas desvantagens, devido às quais eles não conseguiram lidar com o ambiente de negócios em constante mudança, especialmente no desenvolvimento de software, e as situações acima foram, infelizmente, muito comuns. Isso não quer dizer que os métodos tradicionais não sejam aplicáveis em lugar algum. Eles ainda são a melhor aposta para projetos nos quais a ideia é totalmente formada desde o início.
As práticas de gerenciamento ágil tornaram-se a necessidade da hora, porque atendiam às seguintes necessidades de um produto lançado em um ambiente dinâmico:
- Necessidade de velocidade para chegar ao produto no mercado
- Necessidade de flexibilidade para acomodar várias alterações nas especificações
- Falhas no cenário de 'divisão do trabalho'
- Dilema do cliente
- Necessidade de redução de custo
Necessidade de velocidade para chegar ao produto no mercado:
Vivemos em um ambiente de ritmo acelerado, em que flexibilidade e velocidade são fundamentais para o sucesso.
A tecnologia é um dos setores de mudança mais rápida do setor. Há uma idéia, produto ou inovação mais recente a cada minuto. Nesse cenário, a abordagem tradicional de gerenciamento de projetos falha. Um projeto seqüencial depende necessariamente das etapas da metodologia ágil serem concluídas satisfatoriamente em ordem. As linhas de tempo em projetos gerenciados tradicionalmente são sempre um ponto de discórdia.
Organizações e equipes que não são dinâmicas perderão a corrida para aqueles que se transformam de acordo com o ambiente em mudança.
Necessidade de flexibilidade para acomodar várias alterações nas especificações:
As expectativas e os requisitos do cliente geralmente mudam ao longo do desenvolvimento do produto. Antes que os Sistemas de Gerenciamento Agile fossem mainstream, os projetos em TI falhavam frequentemente porque o sistema tradicional de gerenciamento de projetos era construído para "avançar". Se houve alguma alteração, os clientes geralmente sentiam o aperto em suas carteiras ou cronogramas. O modelo tradicional de gerenciamento de projetos, adaptado de outras indústrias, simplesmente não estava funcionando para uma indústria dinâmica como a TI.
Divisão de trabalho:
No modelo tradicional, existem fases distintas, começando com a análise de requisitos do sistema e levando à liberação e manutenção do produto. Isso resulta na divisão do trabalho e na rotulagem dos membros como 'designers', 'programadores' ou 'testadores'. Mas, na realidade, os recursos atuais são extremamente multifuncionais e essa distinção clara de papéis não é viável na maioria dos projetos.
Dilema do cliente:
Em projetos voláteis, muitas vezes, os clientes não sabem ao certo qual deve ser seu produto final, com todas as especificações. As funcionalidades e os requisitos geralmente mudam à medida que partes do trabalho são feitas. Modelos tradicionais, como o modelo Waterfall, enfatizam a clareza em relação ao produto final, e os desvios nos planos exercem uma enorme pressão sobre o sistema. Isso nos leva ao último fator que levou ao desenvolvimento de sistemas Agile.
Necessidade de redução de custo:
Tradicionalmente, as mudanças nos requisitos a qualquer momento após o início do projeto eram desencorajadas. Em vez disso, os custos para qualquer componente adicional eram altos, às vezes proibitivamente. Portanto, era imperativo incluir todos os cenários possíveis no próprio estágio de planejamento. Isso significava que todos os cenários foram considerados e uma solução proposta. Mas como é quase impossível saber com certeza qual parte do produto o usuário prefere, as equipes geralmente desenvolvem "versões inchadas" de um produto. Isso continha todos os cenários possíveis, dos quais um usuário típico usaria não mais que 20%. Isso resultou em custos e desenvolvimento desnecessários.
Desnecessário dizer que isso significava que todos os projetos eram globais em seu planejamento.
E quando surgiu um cenário não planejado totalmente novo, havia um custo extra de qualquer maneira, apesar de todo o planejamento.
Um grupo de pessoas se reuniu em fevereiro de 2001 para discutir exatamente isso: a necessidade de um modelo flexível e ágil de desenvolvimento de software que ajudasse a desenvolver produtos que realmente funcionavam para o cliente e o desenvolvedor. O resultado foi o “Manifesto Ágil”, que foi um benefício do desenvolvimento de software de metodologia ágil, ou seja, um conjunto de quatro princípios, tão simples quanto descritivos. Doze “princípios ágeis”, explicando como os sistemas ágeis realmente funcionariam em um ambiente de projeto, também foram desenvolvidos.
Através deste trabalho, chegamos ao valor:
- Indivíduos e interações sobre processos e ferramentas
- Software que trabalha sobre uma documentação completa
- Colaboração do cliente sobre negociação de contrato
- Respondendo a mudanças após seguir um plano
Ou seja, enquanto houver valor nos itens à direita, valorizamos mais os itens à esquerda.
Os 12 princípios ágeis
Os 12 princípios ágeis são um conjunto de conceitos orientadores por trás do manifesto ágil que dão suporte às equipes de projeto na implementação de projetos ágeis. Eles são:
- Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso.
- Congratulando-se com os requisitos de mudança, mesmo no estágio final de desenvolvimento. Os processos de metodologia ágil aproveitam a mudança para a vantagem competitiva do cliente.
- Forneça software de trabalho com frequência, de algumas semanas a alguns meses, com preferência para a escala de tempo mais curta.
- Pessoas de negócios e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.
- Crie projetos em torno de indivíduos motivados. Dê a eles o ambiente e o apoio de que precisam e confie neles para fazer o trabalho.
- O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa cara a cara.
- O software de trabalho é a principal medida de progresso.
- Os processos de metodologia ágil promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente.
- A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.
- A simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial.
- As melhores arquiteturas, requisitos e projetos emergem das equipes auto-organizadas.
- A intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, depois ajusta e ajusta seu comportamento de acordo.
Exemplo de um projeto que precisa de gerenciamento ágil
Imagine uma startup que desenvolva um aplicativo móvel para um cliente. Congelar todo o design do aplicativo antes do início do desenvolvimento pode ser desastroso. Também há tempo limitado para realizar a pesquisa de mercado, definir um plano detalhado, decidir sobre as variantes que eles querem oferecer e desenvolver o produto. Além do enorme custo envolvido nessa abordagem, eles correm o risco de que outra empresa desenvolva o aplicativo antes de fazê-lo.
A metodologia ágil no gerenciamento de projetos ajuda a superar esses problemas. Sob esse sistema, o aplicativo é desenvolvido em etapas, com interação do cliente todos os dias e entregas ou etapas do projeto identificadas, por exemplo, a cada semana.
Várias equipes também podem trabalhar no mesmo aplicativo, para que o tempo de desenvolvimento seja reduzido drasticamente.
As funcionalidades são refinadas a cada reunião e o produto final reflete a necessidade final. Eles aprendem passo a passo o que funciona para o cliente e improvisam as ofertas até obterem o produto desejado.
Na abordagem tradicional ao gerenciamento de projetos, seria possível pensar em todas as revisões antes de liberar o produto. Isso resultaria em prazos perdidos, aumento de cargas de trabalho e inflação de custos. Além disso, o produto pode ter perdido completamente sua relevância no momento do lançamento.
Como exatamente o Agile Management funciona?
Embora o Gerenciamento Agile seja referido principalmente como um conceito de TI, seus usos não se limitam ao setor de TI. Por exemplo, a varejista de roupas da cadeia Zara usou os princípios do Agile Management para transformar seus negócios.
Usando os princípios ágeis, a Zara fabricou produtos em pequenos lotes, em vez de se concentrar em grande produção antes da nova temporada. A empresa evitou os custos relacionados ao alto estoque e ofertas de desconto imprevisíveis por esse método.
Alguns dos principais aspectos do Agile Project Management são:
- O Gerenciamento Ágil de Projetos segue uma abordagem flexível.
O Agile Management recebe bem-vindos adições e alterações ao longo do desenvolvimento do produto, em vez de adequá-lo às especificações originais.
- Projetos ágeis geralmente são divididos em partes separadas do trabalho, com equipes envolvidas no desenvolvimento de uma ou mais dessas partes.
Portanto, é possível ter, por exemplo, quatro equipes trabalhando simultaneamente em diferentes partes de um projeto, para que os prazos do projeto sejam reduzidos. As equipes coordenam entre si e com o cliente diariamente as entregas.
- Há reuniões diárias sobre o progresso ou obstáculos no projeto, com feedback constante.
Após receber o feedback do cliente, as alterações são incorporadas e as equipes passam para o próximo bloco. Esse processo continua a fornecer um produto mais dinâmico e mais adequado às necessidades do cliente.
- Há um maior envolvimento dos membros da equipe, em vez de uma abordagem de cima para baixo.
No Ciclo de Vida de Desenvolvimento de Software, os membros da equipe estão envolvidos em todas as etapas: requisitos, design, desenvolvimento e testes de metodologia ágil. Como há uma visão geral regular da eficiência da tarefa, os membros da equipe ajustam o comportamento e os procedimentos de acordo.
- O perfil do gerente de projeto em um projeto Agile mudará de uma função tradicional.
Ele não está mais gastando muito tempo planejando ou monitorando recursos, mas agora gasta mais tempo colaborando com equipes e garantindo que o quadro geral esteja sempre à vista. Essa não é uma transição fácil, e os gerentes que passam para os sistemas Agile precisam se adaptar rapidamente para que o projeto seja bem-sucedido.
Algumas palavras sobre o Scrum:
O Scrum é um dos frameworks mais populares para a implementação da Metodologia Ágil. O que é metodologia ágil? Ele é anterior ao Agile e foi proposto pela primeira vez em 1986 e implementado nas indústrias automotiva e de impressoras.
Metodologia ágil com scrum não é sinônimo; existem outras estruturas que podem ser usadas para implementar o Agile, mas o Scrum é um dos mais eficazes e provavelmente os mais populares. O que é scrum? Normalmente, o Scrum tem apenas três funções: proprietário do produto, equipe e mestre do Scrum. O mestre da metodologia Scrum não é um gerente de projetos. As responsabilidades de uma função tradicional de gerente de projeto são divididas entre as três funções de gerenciamento de projeto Scrum. O projeto é incorporado a uma série de iterações de comprimento fixo chamadas sprints. O sucesso de cada sprint de metodologia ágil gera uma sensação de progresso tangível e inspiração contínua. O objetivo de cada iteração é produzir um produto funcional que possa ser demonstrado às partes interessadas. O Scrum Master da metodologia ágil trabalha com o proprietário e a equipe do produto para facilitar a conclusão das metas, removendo os obstáculos. A equipe de desenvolvimento de metodologia ágil é multifuncional e inclui testadores, designers e engenheiros de operações, além de desenvolvedores.
Gerenciamento tradicional de projetos: a cachoeira
Um dos mais tradicionais sistemas de gerenciamento de projetos tradicionais é o Waterfall. Foi frequentemente utilizado desde os anos 70. Existem várias metodologias em cascata conhecidas e amplamente implementadas em projetos de TI. Isso inclui o PRINCE2, que foi criado pelo governo do Reino Unido para seu setor público.
Bem como o nome sugere, é um fluxo de trabalho seqüencial. O produto final é fixado no início do projeto. Em seguida, as várias etapas do fluxo de trabalho são concluídas em sequência (início da concepção, análise, design, construção, teste, implementação e manutenção). Depois que a etapa anterior é concluída, os desenvolvedores passam para a próxima etapa. O plano do projeto deve ser à prova de idiotas; Depois que um estágio na sequência é concluído, os desenvolvedores não podem revisitar o mesmo sem iniciar tudo de novo. É uma abordagem estática da metodologia ágil em Gerenciamento de Projetos. Não há espaço para mudanças ou erros e o plano de projeto da metodologia ágil deve ser seguido diligentemente.
É possível fazer uma analogia entre o Gerenciamento de cachoeiras e a pintura de uma obra-prima. A imagem da obra-prima final já está na mente do artista, e ele trabalha constantemente para isso. Se, por qualquer motivo, o produto final for diferente do que ele visualizou, ele não poderá modificá-lo facilmente.
Ágil ou Cachoeira?
- O que é Agile? O Agile é mais adequado para equipes pequenas que trabalham em projetos incrementais e evolutivos, enquanto o Waterfall é adequado para grandes esquemas ou projetos de desenvolvimento. O gerenciamento em cascata pode ser mais adequado para indústrias como a indústria da construção. O Agile é usado em projetos mais dinâmicos, como os da indústria de TI.
- Os sistemas ágeis exigem membros da equipe altamente qualificados que possam lidar com todas as fases do projeto. Requer uma mudança drástica no papel de gerente de projetos. O processo em cascata é estruturado de maneira mais tradicional, linear e talvez seja mais fácil de entender para não desenvolvedores e novos no desenvolvimento de software.
- Muitas organizações acham a metodologia Waterfall reconfortante, pois é melhor documentada. O Agile é conhecido por não enfatizar documentação extensa. É mais dependente de pessoas, o que pode ser desconfortável em organizações onde a taxa de atrito é alta.
- Projetos diretos menores podem não exigir uma estrutura de metodologia Agile e um modelo sequencial em cascata também pode funcionar.
Onde isso está indo?
A metodologia de desenvolvimento ágil representa mais de dois terços de todos os projetos de TI nos EUA, de acordo com uma pesquisa realizada pela HP em maio de 2015.
Mas o Agile nem sempre é a solução 'perfeita'. Não é uma solução única e, como resultado, muitas organizações (24% de acordo com a pesquisa da HP) adotaram agora uma abordagem híbrida.
Um híbrido de métodos Agile e Waterfall poderia aproveitar as vantagens de ambos. Essa abordagem híbrida pode funcionar em projetos complicados com clientes externos e grandes equipes. Essa abordagem foi descrita por Erick Bergmann e Andy Hamilton. É um compromisso entre os dois métodos, permitindo que as equipes de software trabalhem 'ágeis', enquanto as equipes de desenvolvimento de hardware e os gerentes de produto usam o método tradicional.
Mark Fromson, consultor digital, aponta outra maneira pela qual um híbrido pode funcionar:
Dividir o projeto em fases do tipo cascata para permitir contratos de lances fixos e escopo definido em uma fase menor, mas mantendo o projeto fluido como um todo.
Independentemente da forma como as equipes futuras assumirão, fica claro que o desenvolvimento da metodologia Agile chegou para ficar. Permitiu flexibilidade, vantagens de tempo e custo, juntamente com o fator mais importante de todos: proporcionar uma sensação de satisfação e uma atmosfera motivadora às pessoas que trabalham nesses projetos.
Fonte:
Para o Manifesto Ágil e Os 12 Princípios Ágeis - www.agilemanifesto.org
Cursos relacionados: -
Gerenciamento Ágil de Projetos - Aprenda Metodologias Ágeis