Homem desenhando um diagrama

Abordagem ágil ou clássica no gerenciamento de projetos

Agile é um conjunto de princípios e idéias com base nos quais o gerenciamento de projetos é realizado. A principal característica da abordagem é a flexibilidade: as tarefas são definidas, executadas e transformadas, dependendo da situação, e a disposição para mudar é mais importante do que seguir o plano original.

Origem do ágil

Dois eventos lançaram as bases para o surgimento de uma abordagem de gerenciamento de projetos Agile.

Em 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaram um artigo, “Um novo jogo para desenvolver novos produtos”, na Harvard Business Review, que descrevia uma nova maneira de desenvolver produtos comparando-os a uma partida de rugby. No jogo, os membros da equipe atingem o objetivo, respondendo constantemente a uma situação em mudança e se adaptando a ela. Também no gerenciamento de projetos – a equipe deve ser capaz de responder rapidamente às mudanças nas necessidades dos clientes e outros fatores externos com um custo mínimo.

O segundo evento ocorreu em 2001, quando um grupo de especialistas em gerenciamento de software e projetos se reuniu para descobrir o que era comum em seus projetos de maior sucesso. O resultado foi o “Manifesto da Metodologia Ágil de Desenvolvimento de Software” , que descreve as idéias e princípios subjacentes ao método Agile.

O que escolher: abordagem ágil ou clássica no gerenciamento de projetos?

A abordagem clássica ao gerenciamento de projetos envolve planejamento rigoroso, uma sequência estrita de etapas e o conteúdo inalterado do projeto durante todo o tempo de trabalho nele. No início do trabalho no projeto, já se sabe qual será o produto, quanto tempo e dinheiro serão necessários para desenvolvê-lo.

A principal característica do trabalho em projetos de acordo com as idéias e os princípios do Agile é que, no início do trabalho em um projeto, não se sabe qual será o produto final e o ciclo de vida do projeto.

O gerenciamento tradicional funciona melhor em um ambiente estável, onde é necessário um resultado final estritamente definido e o orçamento é estritamente fixo. Geralmente é usado no campo da engenharia, fabricação e construção.

O Agile é adequado para projetos em que o produto final é incerto ou seu ambiente de aplicativos está mudando rapidamente. Esse estilo de gerenciamento é escolhido pelas empresas de desenvolvimento de software e pelas startups, pois ajuda a responder mais rapidamente às solicitações dos clientes e às mudanças do mercado, além de adaptar o produto a um ambiente em mudança.

Como o gerenciamento de projetos ágil é organizado

De acordo com o Agile, um projeto não é dividido em etapas sucessivas, como nos métodos clássicos de gerenciamento de projetos, mas em subprojetos que, como resultado, são montados em um produto acabado.

Desenvolvimento e consideração do conceito, definição de metas e objetivos, nomeação de um líder e outras atividades de lançamento são realizadas para todo o projeto. Planejamento, design, desenvolvimento e teste já são realizados no nível do subprojeto.

O trabalho no projeto é realizado em ciclos curtos de 2 a 4 semanas, chamados de “sprints”, cada um composto por um grande número de tarefas e tem seu próprio produto final e resultado.

Essa abordagem permite que você forneça rapidamente os resultados do trabalho em elementos individuais do projeto e faça alterações neles sem alterar outras partes e custos significativos.

Vantagens e desvantagens do Agile

O Agile, como qualquer outra metodologia, tem vantagens e desvantagens.

Benefícios ágeis

  • O método de gerenciamento ajuda a alterar ou adaptar rapidamente o projeto de acordo com os novos requisitos.
  • Os trabalhadores permanecem mais motivados trabalhando em uma série de pequenos subprojetos rápidos.
  • Maior atenção às necessidades específicas do cliente.
  • Promove estreita colaboração entre os membros da equipe e intenso feedback das tarefas.

Desvantagens ágeis

  • Para alguns técnicos, a habilidade e o desejo de trabalhar em equipe.
  • Um processo longo e complexo de transição para esse modelo de gestão, uma vez que o Agile é um conjunto de princípios segundo os quais é necessário reestruturar os processos e valores da empresa.

Técnicas especiais ajudam a adaptar os princípios do Agile às necessidades de cada organização em particular: Scrum, Kanban, Lean e outros.

Ágil ou Flexível

Você pode ler sobre o histórico da aplicação e desenvolvimento de abordagens flexíveis em nosso artigo “The Unknown History of Agile”

Lembre-se da tecla:

Desde os anos 30 do século XX, os profissionais e teóricos da administração procuram maneiras de melhorar a eficiência do trabalho e se livrar das perdas. Havia um ciclo de Deming (PDCA), métodos de manufatura enxuta na Toyota, uma compreensão dos efeitos negativos do tempo de inatividade, superprodução, trabalho desigual, sobrecarregando os funcionários, armazenagem etc.

Em 1986, um artigo dos pesquisadores japoneses Ikujiro Nonaka e Hirotaka Takeuchi publicou o artigo “New New Product Development Game”, que ilustrava a perda de tempo e informações ao transferir um produto sequencialmente de um designer para um desenvolvedor, de um desenvolvedor para um testador, e assim por diante. Os autores do artigo recomendaram que os especialistas das etapas subsequentes fossem incluídos no trabalho anterior, mesmo que o produto ainda não esteja totalmente desenvolvido para economizar tempo na criação do produto. Em essência, é proposta uma equipe multifuncional.

Em 1993, Jeff Sutherland e Ken Schwaber propuseram que a estrutura Scrum, baseada na auto-organização de uma equipe pequena, contém iterações curtas de desenvolvimento (sprints), de acordo com os resultados de cada sprint, o cliente recebe uma versão viável e aprimorada do produto.

Vamos considerar em mais detalhes como o produto é entregue no Agile. Vamos começar com a abordagem incremental – essa é a criação rápida de um produto com funcionalidade limitada, mas funcional. Essa abordagem permite que você verifique e ajuste rapidamente hipóteses sobre o produto que está sendo criado e ajuste rapidamente as direções de desenvolvimento adicional. Por exemplo, se o Cliente nos solicitar um retrato da Mona Lisa, dividiremos a tela inteira em seções e criaremos cada seção sequencialmente. Esse formato não implica modificações nos fragmentos já criados, mas cada fragmento é integral e já pode ser exibido ao cliente, sem aguardar o final do projeto.

Abordagem incremental
Abordagem incremental

Abordagem incremental

A abordagem iterativa é repetir operações para melhorar os resultados do estágio anterior (iteração). No exemplo da Mona Lisa, primeiro criamos um rascunho de toda a imagem e, gradualmente, camada por camada, iteração por iteração, nos aproximamos do resultado final. Ao mesmo tempo, os resultados de cada iteração podem ser demonstrados ao Cliente e, com base no feedback, faça ajustes.

Abordagem iterativa
Abordagem iterativa

Abordagem iterativa

Ambas as abordagens são usadas no desenvolvimento de produtos. O Agile está procurando um equilíbrio entre as duas abordagens. Para um retrato de Mona Lisa, o artista primeiro cria um esboço de toda a imagem (todo o produto com qualidade mínima é uma iteração) e um fragmento de cor (incremento). Depois, ele refina todo o esboço e adiciona o próximo fragmento, e assim por diante. Duas abordagens são combinadas, o artista desenvolve o produto de forma iterativa-incremental. Este exemplo combina abordagens incrementais e iterativas.

Abordagem incremental iterativa
Abordagem incremental iterativa

Abordagem incremental iterativa

Outro exemplo Se precisarmos conectar dois assentamentos ao longo da estrada (por exemplo, vamos omitir as restrições legislativas, as regras para a implementação de projetos de construção e as peculiaridades da indústria de estradas). Como isso pode ser feito usando uma abordagem iterativa-incremental: primeiro construímos uma estrada de terra entre os dois assentamentos ao longo de todo o comprimento (esta é uma iteração) e colocamos no asfalto a primeira seção do asfalto (este é um incremento). Em um modo limitado, podemos iniciar uma mensagem no carro e obter feedback – onde são necessárias melhorias, quais áreas precisam ser pavimentadas em que sequência – nosso produto é incrementado. Em seguida, a estrada deve receber iluminação, marcação, sinais ao longo de todo o comprimento – para realizar outra iteração do desenvolvimento do produto.

É importante que cada iteração e incremento dentro do período selecionado, que geralmente é chamado de sprints, seja pequeno no tempo (no Scrum – de uma semana a um mês). Ao mesmo tempo, temos um produto em funcionamento, obtemos feedback do cliente e dos usuários e podemos modificar o produto com flexibilidade (verifique nossas hipóteses). No caso do gerenciamento clássico de projetos, obteríamos o produto no final do projeto, mas suas características podem não se adequar ao cliente ou aos usuários, e tempo e recursos adicionais serão necessários para aprimoramento.

Conclusão

O gerenciamento clássico do projeto (“cascata”) é baseado na sequência das etapas do trabalho e na transferência do produto acabado para o cliente no final do projeto.

O Agile se oferece para construir o trabalho em um formato diferente: entregar ao cliente, em breves sprints, um produto que já tenha valor para ele, embora limitado, e receber feedback rapidamente para ajustar a direção do trabalho.

Ambas as abordagens têm sua própria zona de aplicação efetiva. Com base em nossa experiência, formulamos as principais diferenças nas abordagens:

RecursoAbordagem clássicaÁgil
Oferta de valor (resultado operacional)Acontece no final do projetoÉ realizado à medida que o projeto é implementado na forma de elementos de trabalho do produto. A abordagem iterativa-incremental é usada.
Teste de hipótesesComo regra, é realizada na fase de pré-projeto, antes do início do projeto.Realizado pela equipe durante o projeto para melhorar o produto. Algumas hipóteses podem ser invalidadas
PlanejamentoDetalhado, até o final do projeto. O método do caminho crítico é usado para estimar os prazos. Em projetos com alta incerteza, o método de onda que se aproxima é usado.Empírico, com base em dados históricos de elementos de produtos implementados
Estilo de gestãoVertical de gerência: Comitê Diretor -> Curador, Cliente -> Gerente de projetoAuto-organização dentro da equipe. Uma equipe plana sem uma hierarquia interna.
Atitude em relação à mudançaComo regra, tem um caráter negativo – muda como conseqüência da implementação de riscos e do aparecimento de problemas. Requer um processo formal para analisar as consequências e recalcular o caminho crítico do projeto, análise de alternativas.As mudanças fazem parte do processo de desenvolvimento. A fonte das mudanças é incl. melhor entendimento do produto com base na experiência.
Tipo de pensamento, relacionamentoNormalmente determinado pela cultura da organização, geralmente com uma mentalidade fixaÉ necessária uma mentalidade flexível para trabalhar com sucesso em ambientes de alta incerteza
Métricas do projeto% de implementação, desvio do plano, método de volume ganho, data prevista de conclusãoGráfico de queima, Gráfico cumulativo de funções implementadas (Gráfico de queima), Tempo de colocação no mercado
Disponibilidade de manuaisBem estruturado, descrito em detalhes (PMBoK, PRINCE2). Padrões e práticas da indústria.Estruturas de nível superior (por exemplo, Scrum). Muitas práticas individuais (reunião diária, retrospectiva, sprint etc.)
Área de Aplicação Eficaz“Sistemas complexos” de acordo com o modelo Kinevin (Cynefin) – muito trabalho, agentes (partes interessadas). O produto e seus requisitos são conhecidos, o escopo do trabalho pode ser descrito e corrigido. Os limites do projeto são fixos.“Sistemas emaranhados” de acordo com o modelo Cynefin – não conhecemos o produto e / ou o processo de sua criação. O escopo do projeto não está definido. Limites do projeto borrados

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *