O Manifesto Ágil Explicado e Como Aplicá-lo

O que é o Manifesto Ágil?

O Manifesto Ágil é uma declaração escrita que inclui quatro valores e 12 princípios destinados a melhorar as formas de trabalhar no desenvolvimento de software.

Mais filosófico do que prescritivo, o Manifesto foi concebido para ser adaptável a diferentes dimensões de equipas, objetivos e condições.

Os 4 valores do Manifesto Ágil

O Manifesto Ágil oficial é composto por estes 4 valores:

1. Indivíduos e interações mais do que processos e ferramentas
2. Software funcional mais do que documentação abrangente
3. Colaboração com o cliente mais do que negociação contratual
4. Responder à mudança mais do que seguir um plano

É interessante notar que os autores acompanharam os valores desta declaração clarificadora: "Isto é, embora exista valor nos elementos à direita, valorizamos mais os elementos à esquerda."

Tal reforça a ideia de que o Manifesto Ágil não consiste em seguir um determinado processo ou utilizar uma ferramenta ágil específica. Trata-se de adotar uma mentalidade específica.

Os 12 princípios do Manifesto Ágil

Além dos quatro valores, o Manifesto Ágil apresenta 12 princípios de apoio que explicam como interpretar e aplicar os valores em projetos ágeis.

1. Coloque o cliente em primeiro lugar

A prioridade máxima é satisfazer o cliente através da entrega antecipada e contínua de software valioso.

2. Dê as boas-vindas à mudança

Dê as boas-vindas à mudança de requisitos, mesmo numa fase tardia do desenvolvimento. Os processos ágeis aproveitam a mudança para proporcionar uma vantagem competitiva ao cliente.

3. Faça entregas frequentes

Entregue software funcional com frequência, desde algumas semanas até alguns meses, dando preferência a prazos mais curtos.

4. Colabore entre equipas

As pessoas do negócio e os programadores devem trabalhar em conjunto diariamente ao longo de todo o projeto.

5. Desenvolva o talento

Crie projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o apoio de que precisam e confie neles para realizar o trabalho.

6. Converse

O método mais eficiente e eficaz de transmitir informação a uma equipa de desenvolvimento e dentro dela é a conversa presencial.

7. Meça o que importa

O software funcional é a principal medida do progresso.

8. Mantenha um ritmo de trabalho que evite o esgotamento

Os processos ágeis promovem um desenvolvimento sustentável. Os patrocinadores, programadores e utilizadores devem conseguir manter indefinidamente um ritmo constante.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

9. Concentre-se na qualidade e o trabalho avançará mais depressa

A atenção contínua à excelência técnica e a uma boa conceção aumenta a agilidade.

10. Aceite a simplicidade

A simplicidade–a arte de maximizar a quantidade de trabalho que não é realizado–é essencial.

11. Não faça microgestão

As melhores arquiteturas, requisitos e designs surgem de equipas auto-organizadas.

12. Refletir e ajustar

A intervalos regulares, a equipa reflete sobre como se tornar mais eficaz e, em seguida, ajusta o seu comportamento em conformidade.

História, autores e origem do Manifesto Ágil

No mundo tecnológico, o Manifesto Ágil é discutido com a mesma reverência e irreverência que qualquer texto sagrado transmitido ao longo do tempo.

Em fevereiro de 2001, 17 profissionais de software que se autodenominavam “The Agile Alliance” reuniram-se no estado norte-americano do Utah para desenvolver aquilo a que chamaram “Manifesto para o Desenvolvimento de Software Ágil”. O documento, que enfatiza quatro valores e 12 princípios, é agora conhecido como o Manifesto Ágil.

Os autores do Manifesto Ágil são frequentemente referidos como a Agile Alliance e incluíam representantes de vários processos de desenvolvimento, incluindo programação extrema, Scrum e Crystal. 

Uma breve visita ao site oficial do manifesto apresenta os autores num cenário que pode fazer lembrar uma sociedade secreta ou um encontro dos pais fundadores. Era evidente que a sua intenção era criar algo que deixasse um impacto duradouro no setor. E deixou.

Embora as pessoas que se reuniram no Utah não tenham sido pioneiras dos princípios ágeis em geral, consolidaram os valores que vinham a formar-se há algum tempo nos bastidores do mundo do desenvolvimento de software.

Hoje, a metodologia ágil está presente em quase todos os setores.

Os autores incluíam:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

Porque é que o Manifesto Ágil é (ainda) importante

O Manifesto Ágil continua a ser relevante devido ao seu foco em formas de trabalhar centradas nas pessoas e à flexibilidade que permite.

As rápidas mudanças tecnológicas são frequentemente acompanhadas por alterações nos requisitos dos projetos. O Manifesto Ágil permite aos gestores de projeto dar prioridade à adaptabilidade e à colaboração, criando um ambiente de projeto responsivo e resiliente que consegue simultaneamente entregar trabalho, inovar e mudar de direção quando necessário.

Promove também uma mentalidade centrada no cliente, valorizando soluções funcionais em detrimento de documentação exaustiva. Isto permite aos gestores de projeto recolher feedback desde cedo e aperfeiçoar continuamente o seu trabalho, garantindo que o projeto está estreitamente alinhado com as necessidades dos utilizadores. Esta abordagem iterativa e orientada para o cliente aumenta as taxas de sucesso e a satisfação com os projetos.

Como aplicar o Manifesto Ágil

Vamos analisar um pouco mais profundamente cada um dos quatro valores do manifesto ágil. Ao rever os valores fundamentais, exploraremos também os 12 princípios que desenvolvem cada um deles.

Valor n.º 1: Indivíduos e interações em vez de processos e ferramentas

A essência do ágil são as pessoas. O ágil realça que uma equipa trabalha em conjunto, colabora estreitamente e toma decisões de forma autónoma. O ágil não consiste em dizer a uma equipa o que fazer ou o que construir. 

Nos projetos ágeis, a comunicação deve fluir livremente e ser contínua, não ser definida e agendada. Trabalhar em silos isolados não faz parte do ágil.

Avalie a comunicação da equipa

Pergunte a si próprio: você e a sua equipa têm conversas presenciais? Ou dependem de emails, documentos e determinadas ferramentas de mensagens muito apreciadas (não vamos mencionar nomes)? 

Mesmo que trabalhe remotamente, ter uma conversa presencial pode permitir que as coisas aconteçam mais rapidamente. Sobretudo quando uma equipa está a formar-se, a comunicação síncrona promove a confiança e a abertura e ajuda a criar relações.

Seja menos controlador

Todos somos culpados disto ocasionalmente. Mas a confiança é essencial para o ágil. Procura algo que possa implementar imediatamente? NÃO FAÇA MICROGESTÃO (sim, era mesmo para gritar).

É tentador detalhar as tarefas, distribuí-las pela equipa e acompanhá-las até cumprirem o prazo imposto (ou não), para que tenha controlo sobre tudo. Mas, para capacitar verdadeiramente a sua equipa, precisa de recuar um pouco e permitir que assuma a responsabilidade pelo seu trabalho!

Incentive uma equipa auto-organizada

Não se trata de gerir — trata-se de liderar e facilitar. Uma equipa auto-organizada é uma equipa que escolhe a melhor forma de realizar o seu trabalho. Deve decidir como transformar o trabalho pendente em código pronto para lançamento. Mas não leve isto ao extremo oposto, deixando de prestar qualquer ajuda ou orientação — a equipa continua a precisar de uma visão, motivação e ajuda para resolver impedimentos.

Nesse caso, como pode deixar de distribuir tarefas e determinar, em vez disso, como facilitar o trabalho?

Não se preocupe demasiado com o processo ou a ferramenta

Eu sei, eu sei — no mundo da gestão de projetos ágil, fala-se constantemente de ferramentas de gestão de projetos e de software de gestão de projetos ágil.

Mas a verdade é esta: o seu cliente não se preocupa com o seu processo interno de fluxo de trabalho ágil. Nem deve preocupar-se.

A agilidade consiste em adotar uma abordagem centrada no cliente e permitir que a sua equipa entregue um trabalho melhor e mais valioso. Falaremos mais sobre a abordagem centrada no cliente mais adiante!

Elimine os silos

Os silos dificultam a colaboração e, por isso, afastam-nos dos valores ágeis. 

Para se afastar dos silos, considere estas sugestões:

• Coloque a equipa no mesmo local: Sim, mais uma vez. É ótimo que os seus designers possam sentar-se perto uns dos outros e conversar sobre design, mas não será melhor se conversarem com os programadores sobre a criação deste excelente produto? Sei que isto pode ser difícil de implementar numa organização maior ou em ambientes remotos, mas até mesmo reunirem-se num canal partilhado do Slack ou realizarem sessões de trabalho colaborativo agendadas, nas quais as pessoas possam realizar trabalho concentrado em simultâneo e à distância, pode manter a sua equipa mais ligada.
• Desencoraje as transferências entre departamentos: A abordagem mais compartimentada, semelhante à em cascata, em que cada departamento trabalha por etapas (UX, depois design, depois desenvolvimento e, por fim, QA), pode frequentemente causar falhas de comunicação e aumentar o desperdício num projeto. Considere incentivar a sua equipa a trabalhar em conjunto nas funcionalidades, em vez de as transferir ao longo de uma cadeia. Mesmo que trabalhe em sprints, mas com um sprint de design inicial, envolva os seus programadores no sprint de design — afinal, serão eles a construir isto!

Valor n.º 2: Software funcional em vez de documentação abrangente

Lembre-se de que o manifesto não diz para eliminar a documentação — simplesmente atribui mais valor aos elementos da esquerda do que aos da direita. Isto significa que a documentação continua a existir. Por exemplo, o Scrum utiliza histórias de utilizador para indicar a um programador como começar o desenvolvimento.

Mas o que pode fazer para se afastar da documentação pesada e morosa e passar rapidamente a algo tangível?

Simplifique a documentação que utiliza

Identifique quaisquer pontos problemáticos ou impedimentos no seu processo. Depende demasiado da documentação? Demora uma eternidade a elaborar o documento de requisitos perfeito, passa imenso tempo a definir o âmbito funcional e depois fica sem tempo para desenvolver o produto? Reduza a documentação desnecessária:

• Concentrando-se nas tarefas de design e desenvolvimento que contribuirão diretamente para o produto, em vez de num documento escrito que, em última análise, não será utilizado
• Organizando workshops logo no início para definir requisitos e próximos passos, em vez de redigir documentos extensos. Documente e partilhe os resultados através de fotografias e notas breves.

Comece rapidamente o desenvolvimento

Redigir grandes volumes de documentação de requisitos é uma forma de mapear as necessidades da empresa, do cliente e do utilizador. Mas, em última análise, ver algo a funcionar, a comportar-se e a reagir é muito mais útil.

Considere algumas das seguintes formas de fazer o seu projeto avançar rapidamente:

• Reduza o período inicial de descoberta ou definição: Limitar o tempo que dedica à definição e à resolução das questões permite chegar mais rapidamente a algo que os designers e programadores possam abordar. Pode acelerar o processo utilizando estas perguntas para a sessão de descoberta.
• Organize workshops: A realização de workshops com a equipa reúne as partes interessadas para tomarem decisões mais rapidamente.
• Altere o seu plano do projeto: Definiu primeiro o âmbito, depois o design e, por fim, o desenvolvimento? Considere antecipar o desenvolvimento e fazer com que designers e programadores produzam algo em conjunto, mais cedo.

Utilize métodos de prototipagem em vez de modelos planos

Em vez de encarar o progresso como um documento de definição ou um modelo plano que é uma caixa de verificação para aprovação do cliente, mostre-lhe algo que se torne parte do produto final.

Utilize a prototipagem rápida para pôr algo a funcionar e torná-lo utilizável — e, mais importante ainda, para obter algo que possa testar com os clientes. Recolher comentários sobre um protótipo torna-se uma forma útil de acompanhar o progresso, em vez de depender de um resultado que não tem a vantagem de fazer parte do produto final.

Pode criar protótipos com diferentes níveis de fidelidade:

• Baixa fidelidade: Modelos clicáveis. É o que deve utilizar quando precisa de criar rapidamente algo para testar com os clientes, sobretudo um teste da aparência e da experiência, bem como de interações simples.
• Média fidelidade: Utilização de algum movimento ou animação.
• Alta fidelidade: HTML funcional. Utilizado para interações complexas, mas pode ser desenvolvido até se transformar em código pronto para lançamento.

Os protótipos de alta fidelidade estão mais próximos de “software funcional” do que os outros tipos, mas podem exigir mais tempo para serem produzidos. Os protótipos de baixa ou média fidelidade oferecem uma orientação melhor aos programadores do que os modelos planos.

Entregue rapidamente algo ao utilizador final ou ao cliente

Este é um aspeto importante.

Com lançamentos frequentes de software funcional, o cliente pode interagir com quaisquer novas funcionalidades que tenham sido lançadas. Em vez de esperar até ao final do projeto por um lançamento em grande escala, entregar valor ao cliente mais cedo é essencial para obter um produto melhor.

Como pode conseguir entregas mais frequentes na sua organização?

• Reveja o plano do projeto ou o roteiro do projeto: Planeou concluir o desenvolvimento e só depois fazer o lançamento no final do projeto? Em vez disso, trabalhe com a sua equipa para dividir o trabalho em funcionalidades ou blocos de trabalho que possam ser lançados de forma independente ao longo do projeto.
• Concentre-se nos bloqueios: Uma parte essencial da sua função é ajudar a desbloquear a equipa quando surgem problemas. Como pode ajudá-la a entregar de forma mais eficiente? Existem formas de trabalhar que estão a atrasar os lançamentos? Realizar uma retrospetiva da iteração com a sua equipa pode revelar oportunidades para melhorar os processos.
• Automatize: Se a sua organização investe muito esforço nos lançamentos, automatize os processos sempre que possível. Por exemplo, os testes e a implementação automatizados podem poupar trabalho manual e reduzir o esforço necessário para um lançamento. Fale com a sua equipa de desenvolvimento ágil sobre os processos que utiliza e as oportunidades de automatização.

Valor n.º 3: colaboração com o cliente em vez de negociação do contrato

Em vez de elaborar, no início de um projeto, um contrato extremamente específico que detalhe os resultados, o âmbito, o orçamento e os prazos exatos, mantenha o seu contrato ágil tão abrangente quanto possível. Tome decisões ao longo do projeto colaborando estreitamente com os seus clientes e partes interessadas.

O desenvolvimento ágil não consiste em passar imenso tempo a definir os requisitos antecipadamente. Trata-se de iniciar um projeto e aprender à medida que avança, com base nos testes realizados pelos clientes e no retorno obtido a partir de software funcional.

Adote uma abordagem centrada no cliente

Adoro esta citação de um artigo de Neil Killick:

“Um pensador ágil pergunta continuamente: ‘Qual é a forma mais simples/rápida de proporcionar valor ao cliente?’ Faz essa pergunta diariamente? Se não, esse é o seu primeiro passo.”

Não são apenas os designers e programadores que devem pensar desta forma — os gestores de projetos também. Somos igualmente responsáveis por disponibilizar o melhor produto ou serviço possível a um cliente. O seu cliente, o utilizador do seu produto ou serviço, deve estar no centro de tudo o que faz.

Coloque o cliente final no centro do plano

Em vez de planear em torno de resultados e estimativas, planeie em torno de resultados valiosos para o cliente. O que queremos que o cliente faça e porquê? Como iremos medir se isto funciona?

Reoriente a conversa para se concentrar no valor que proporcionámos ao cliente, em vez de no número de itens de trabalho que entregámos.

Envolva estreitamente o seu cliente

Em vez de realizar uma reunião semanal de acompanhamento do estado e depois entregar o trabalho ao seu cliente e às partes interessadas no final de um determinado período, procure envolver o seu cliente diariamente no projeto.

Se estiver a seguir mais um processo Scrum, faça do cliente o proprietário do produto. O proprietário do produto é responsável por reunir os requisitos empresariais, técnicos e dos clientes. Obter a aceitação e a colaboração do cliente desde cedo e com frequência é fundamental para evitar atrasos. Em última análise, isto gera um produto ou serviço melhor para o cliente final.

Envolva um cliente distante

Se o seu cliente não tiver tempo para contribuir para o projeto ou não estiver envolvido por qualquer outro motivo, certifique-se de que alguém da equipa representa o cliente. É fundamental que alguém tenha em consideração as necessidades dos clientes e da empresa.

Mesmo que o cliente não esteja envolvido no dia a dia, certifique-se de que comunica regularmente com ele e, no mínimo, envolva-o em quaisquer discussões de planeamento ágil e definição de prioridades. Trabalhe com ele para demonstrar os benefícios do seu envolvimento.

Implemente um roteiro do produto

Considere utilizar um roteiro do produto para traçar a evolução do seu produto. Um roteiro do produto comunica o plano para o produto e apresenta visualmente as funcionalidades previstas para entrega. Um roteiro não é fixo no início de um projeto; pelo contrário, evolui ao longo do tempo para refletir alterações nas prioridades.

Certifique-se de que fala com os seus utilizadores finais ou clientes

Não posso deixar de salientar isto — deve tentar testar o seu produto com utilizadores finais e clientes desde cedo e com frequência. 

Os testes oferecem muitos benefícios:

• Pode garantir que o seu produto satisfaz as necessidades dos clientes, ou seja, o produto é valioso para o cliente e, consequentemente, para a empresa? Isto ajuda-o a avaliar a adequação do produto ao mercado.
• Pode incorporar o feedback dos clientes no seu processo de conceção e desenvolvimento, resultando num produto final melhor.
• Pode obter informações úteis para orientar trabalhos futuros.

• A questão frequentemente apontada relativamente aos testes com clientes é o orçamento — podem ser dispendiosos. Eis algumas formas de testar, independentemente do orçamento do seu projeto:

Testes de guerrilha: Gosto muito deste método porque é barato e fácil. Ofereça pagar um café real (ou virtual) às pessoas se estas responderem a algumas perguntas sobre os seus designs ou protótipo. É mais difícil especificar quem responde às suas perguntas, mas algum feedback rápido pode ser útil ao testar o aspeto visual, a sensação de utilização ou interações simples.

Questionários: Para recolher dados quantitativos de um leque mais vasto de pessoas, pode criar um questionário para avaliar o design ou aprofundar o comportamento dos clientes.

Sites como o usertesting.com: Pode carregar os seus designs num destes sites e recrutar pessoas através deles (utilizando critérios, se necessário). Estas pessoas irão então navegar pelos seus designs, registar as suas opiniões e responder a perguntas.

Testes presenciais: Sim, esta pode ser uma opção mais dispendiosa, uma vez que provavelmente terá de recrutar pessoas e pagar incentivos; no entanto, pode ser inestimável se estiver a testar interações complexas ou funcionalidades de alto risco.

Valor n.º 4: Responder à mudança em vez de seguir um plano

Os projetos ágeis e em cascata não poderiam ser mais diferentes neste aspeto. Nos projetos tradicionais de desenvolvimento de software, define os requisitos, os custos e os prazos antecipadamente, ao passo que a abordagem ágil permite e promove a mudança.

A mudança é boa! Não é maléfica! Quantos planos de projeto correram exatamente como os criou no início? Não muitos, diria eu (trabalhei em projetos com dezenas de iterações do plano do projeto).

Os planos são a melhor estimativa num determinado momento, que pode consolidar à medida que avança — no entanto, tendem a não permitir alterações. O que acontece se as necessidades do cliente mudarem? Se a empresa mudar de rumo? Se o seu cliente alterar as prioridades? Se a funcionalidade especificada não for tão simples de desenvolver como pensava.

As formas ágeis de trabalhar abraçam a incerteza através de uma abordagem de planeamento adaptativo (como o póquer de planeamento). Por exemplo, os valores do Scrum determinam que a equipa planeia o trabalho sprint a sprint. Antes de iniciar um período de trabalho com duração definida, as equipas ágeis retiram itens da lista de pendências e dão-lhes prioridade para desenvolvimento.

Embora exista frequentemente pressão para fixar os custos, o calendário e o âmbito no início de um projeto, ser mais realista relativamente às incertezas que enfrenta resulta muitas vezes num produto final muito melhor. Em última análise, é isto que você, o cliente e as suas partes interessadas devem querer. 

Eis algumas formas de começar a permitir alterações nos seus projetos e a incentivar uma maior flexibilidade:

Crie um plano “simplificado” para satisfazer as partes interessadas

“Mas precisamos de um plano!”, exclamam as suas partes interessadas. Em vez de as assustar ao dizer: “Surpresa, não há plano!”, crie um plano de lançamento simplificado para lhes transmitir confiança numa abordagem um pouco menos formal.

Se está a fazer gestão ágil de projetos com processos Scrum, terá uma lista de histórias de utilizador priorizadas e estimadas no seu backlog. Trabalhe com o responsável pelo produto para as agrupar em versões preliminares e associe-as ao seu roteiro do produto.

Tente não planear tudo, anulando assim os benefícios da utilização da metodologia Scrum. Mostre às partes interessadas o que está a planear nas duas ou três primeiras versões e, em seguida, explique-lhes que o novo planeamento é essencial para uma forma de trabalhar ágil; irá comunicar atualizações e versões adicionais à medida que avança. Esperemos que isto lhes dê a confiança de que precisam!

Introduza gradualmente a equipa numa abordagem baseada em sprints

Mike Cohn, no seu artigo “Introduzir um processo ágil numa organização”, sugere ajudar as equipas a familiarizarem-se gradualmente com o Scrum através da definição de um conjunto de tipos de sprint, por exemplo:

• Criação de protótipos
• Recolha de requisitos
• Análise e conceção
• Implementação
• Estabilização

Eis como ele descreve os benefícios desta abordagem:

“Trabalhamos depois com as equipas para definir os artefactos que resultarão de cada tipo de sprint. A utilização de tipos de sprint introduz formalidade suficiente para que as equipas consigam visualizar mais claramente o caminho a seguir no projeto. À medida que as equipas se tornam mais competentes com a informalidade do processo ágil, abandonam gradualmente o conceito de tipos de sprint.”

Esta é outra forma de estruturar o seu plano de versões. Se atribuir um “tipo” a cada sprint, as partes interessadas conseguem ver como o plano ganha forma, evitando que tenha de garantir funcionalidades. A sua equipa também obtém uma melhor noção do trabalho que irá realizar.

Afaste-se de prazos fixos

Dar um prazo à sua equipa ou comunicar uma data fixa ao cliente são estratégias destinadas ao fracasso ou, pelo menos, a causar stress ao longo do caminho. Promover a confiança entre si, a sua equipa e o seu cliente ou parte interessada é essencial para demonstrar que irá entregar valor ao cliente final, além de cumprir a entrega.

Lembre-se de que está a tentar reduzir a necessidade de múltiplos pontos de controlo e aprovações. A implementação de prazos no seu projeto não o ajudará a atingir este objetivo. Também não é positivo estar constantemente a pressionar a sua equipa, exigindo o trabalho que ela “prometeu” entregar.

Como mencionei acima, os roteiros e os planos de versões podem ser um bom mecanismo para abandonar uma abordagem baseada em datas fixas. Dar às partes interessadas uma noção do que será lançado num futuro próximo pode tranquilizá-las, demonstrando que existe um plano.

Utilize um âmbito baseado no tempo e nos materiais

Se tiver um âmbito com preço fixo e entregáveis fixos, é difícil entregar de uma forma mais ágil. Pode certamente aplicar algumas das técnicas que já mencionei, como permitir uma equipa mais colaborativa. No entanto, ficará limitado na capacidade de responder e se adaptar à mudança, permitir que a equipa determine em que irá trabalhar ou utilizar uma abordagem mais centrada no cliente.

Trabalhe com a sua equipa interna e com o cliente para estabelecer um âmbito baseado no tempo e nos materiais — ou seja, o cliente paga por uma equipa, em vez de pagar por entregáveis fixos. Inicialmente, os clientes podem ficar nervosos se não souberem exatamente o que irão receber.

Para atenuar esta preocupação, pode incluir no âmbito um backlog de atividades ou tarefas que possam ser consideradas para o lançamento. Especifique no contrato que a equipa irá rever o planeamento e priorizar o backlog com a contribuição do cliente à medida que o projeto avança (embora possa não abordar todos os itens).

Para ajudar a gerir prioridades e entregáveis em mudança, as equipas podem recorrer a software de gestão ágil para repriorizar continuamente o backlog e a ferramentas de colaboração para o desenvolvimento de software para coordenar a colaboração entre funções.

Desta forma, não se compromete com um âmbito fixo, mas o cliente terá menos preocupações quanto ao aspeto do produto final.

Continue a acompanhar o progresso

Acompanhar e visualizar o progresso não deixa de ser importante na ausência de um plano formal do projeto. Manter o progresso visível para a equipa e para as partes interessadas não só garante que não perde de vista potenciais bloqueios e estrangulamentos, como também mantém as partes interessadas informadas. 

A utilização de um quadro WIP ao estilo Kanban ou de painéis de controlo ágeis funciona bem em projetos ágeis. Depois de visualizar o seu processo, pode começar a delinear as tarefas e atividades de apoio. Isto ajuda a identificar estrangulamentos que pode desbloquear para facilitar uma entrega mais rápida ao cliente.

Críticas ao Manifesto Ágil

Como qualquer outra metodologia de gestão de projetos, o ágil não é perfeito. Os críticos salientam que os autores do Manifesto Ágil eram um grupo homogéneo que poderá não ter considerado abordagens alternativas ao trabalho, como os benefícios do trabalho remoto ou a forma de aplicar o ágil fora do âmbito do desenvolvimento de software.

Levado longe demais, o ágil pode significar decisões tomadas por um comité, abrandando o ritmo de trabalho. A falta de documentação pode acabar por prejudicar a entrega do projeto, especialmente num ambiente remoto, onde a comunicação assíncrona é fundamental.

Se decidir utilizar o ágil nos seus projetos, consulte os valores e princípios do ágil. São um guia útil para manter sob controlo as piores tendências do ágil.

Leia mais sobre o debate sobre se o ágil é uma metodologia ou uma mentalidade aqui.

Agilidade, não ágil

Um último pensamento: lembre-se da retrospetiva! Como afirma o Manifesto:

Em intervalos regulares, a equipa reflete sobre como se tornar mais eficaz e, em seguida, ajusta o seu comportamento em conformidade.

Independentemente do tipo de processo que está a utilizar, a retrospetiva é uma forma eficaz de analisar a maneira como está a trabalhar e de otimizar o sucesso. Certifique-se de que inclui regularmente retrospetivas de projetos no processo que utilizar — e de que dispõe de um mecanismo para incorporar aquilo que aprendeu! PS: É importante conseguir que os membros mais reservados da sua equipa participem também nas retrospetivas — eis como.

O que se segue?

Para saber mais sobre como implementar formas ágeis de trabalhar e aprender com os melhores gestores de projetos do setor, consulte as nossas opções de adesão ao DPM.