Como a Microsoft pode lançar novas versões de cada um de seus projetos a cada três semanas ? Ou por que o Google pode atualizar seus aplicativos de desktop e móveis toda semana ou duas, enquanto outras empresas levam anos?
Histórias como essas são por que o culto ao gerenciamento de projetos Agile tem tantos seguidores devotos.
Em vez de desenvolvimento de software tradicional, como o método Waterfall, em que você pode passar vários meses ou anos em um projeto sem mostrá-lo ao usuário, o Agile se move rapidamente, libera frequentemente e reage às reais necessidades de seus usuários.
O desenvolvimento ágil tira a ênfase de você e a coloca nos seus clientes . É uma pequena mudança, mas que pode ter grandes resultados.
De acordo com uma pesquisa do Project Management Institute , as organizações ágeis concluíram os projetos no prazo 65% das vezes, contra 40% para empresas não-ágeis. Eles também cumpriram 75% de suas metas, contra 56% dos não-ágeis e até aumentaram sua receita 37% mais rapidamente!
Desenvolvimento mais rápido. Mais lançamentos. Mais receita. Por que você não gostaria de incluir o gerenciamento de projetos Agile em sua própria equipe? Bem, como qualquer ferramenta ou método, o Agile tem suas próprias peculiaridades. E embora seja usado por todos, do Google à Microsoft, ao Spotify, Apple e Facebook, você precisa saber o que está por baixo da superfície antes de mergulhar de cabeça.
Este guia irá levá-lo desde as origens do Agile, até seus principais valores e princípios, como saber se o Agile é adequado para sua organização e fornecer um plano de sete etapas para implementar o gerenciamento de projetos Agile em sua própria equipe.
O que exatamente é o Agile?
No fundo, o Agile não é tanto uma metodologia como uma filosofia. É um termo genérico para uma abordagem ao gerenciamento de projetos que prioriza mudanças incrementais e orientadas por feedback no desenvolvimento de software. (Entraremos nas metodologias e como realmente usar o Agile posteriormente).
Para entender por que o Agile funciona tão bem, precisamos fazer uma lição de história. Até as últimas décadas, o método Waterfall era a maneira predominante de desenvolver software (e a maioria dos produtos). Isso significou gastar uma quantidade enorme de tempo e esforço adiantado, reunindo recursos e planejando várias decisões importantes baseadas apenas em suposições.
Mas na década de 70, ficou claro que esse método não estava funcionando. Para desenvolvedores ‘modernos’, o método Waterfall parecia constrangedor, regulado e muito lento. E quando a geração de hackers entrou na força de trabalho no final dos anos 90, esse sentimento só foi amplificado. O método em cascata conta com previsibilidade e sequência, mas o que esses desenvolvedores de software precisavam era de um método de gerenciamento de projeto mais flexível que abrisse espaço para erros, bugs, contratempos e feedback de usuários reais.
Assim, em 2001, um grupo de 17 pessoas se reuniu para criar uma “ alternativa aos processos de desenvolvimento de software pesados, orientados por documentação ”. Depois de alguns dias, eles surgiram com um documento descrevendo suas crenças sobre como os projetos de software deveriam ser executados. Eles chamavam de Manifesto Ágil .
Como parte do Manifesto, os criadores do Agile definiram 4 valores-chave aos quais todos os projetos Agile devem aderir:
- Indivíduos e interações sobre processos e ferramentas
- Software de trabalho sobre documentação abrangente
- Colaboração do cliente sobre negociação de contrato
- Respondendo a mudanças após seguir um plano
Agora, eles não significavam que você deveria jogar fora suas ferramentas, documentação e planos aprimorados pelo tempo. Porém, embora essas coisas sejam valiosas para qualquer esforço de desenvolvimento, os itens à esquerda devem ser seu foco principal: pessoas, protótipos, colaboração e iteração. Para apresentar suas crenças de uma forma mais acionável, eles também divulgaram uma lista de 12 princípios orientadores para quem executa um projeto Agile:
- A prioridade mais alta é satisfazer o cliente através de entrega antecipada e contínua
- Bem-vindo a mudar os requisitos, mesmo no final do desenvolvimento
- Forneça software de trabalho com freqüência, de algumas semanas a alguns meses
- As partes interessadas e os desenvolvedores devem colaborar diariamente
- 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.
- As reuniões presenciais são consideradas o formato mais eficiente e eficaz para o sucesso do projeto
- Um produto final de trabalho é a medida final do progresso
- Os processos ágeis 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
- Simplicidade – maximizar o trabalho não realizado – é um elemento essencial
- As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas
- A intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, depois ajusta e ajusta seu comportamento de acordo.
Se você pensa no desenvolvimento de software hoje, esses princípios, e o Agile em geral, podem ser vistos como uma resposta às expectativas dos usuários.
Os usuários não se preocupam com a documentação, eles se preocupam com o software de trabalho. Eles não se importam com o seu plano de longo prazo, querem o que querem agora . Eles querem um bug corrigido ontem, não em uma semana ou com o próximo lançamento (sempre que houver).
Todos nós nos tornamos consumidores muito carentes, e o Agile é uma maneira fantástica de garantir que as necessidades do usuário sejam destacadas sempre que você estiver desenvolvendo um novo software.
Como saber se o ágil é adequado para sua equipe (e por que talvez não seja)
Tudo isso parece ótimo na superfície, mas nem todos os projetos se beneficiam do gerenciamento de projetos Agile. Portanto, antes de abordarmos as especificidades do trabalho com o Agile, vamos aprofundar um pouco mais.
O Agile pode ser um grande afastamento de como sua empresa ou seus colegas de equipe estão acostumados a trabalhar. Significa mover-se rapidamente, o que significa que nem tudo será explicado ou planejado com antecedência. Portanto, você precisa saber se seu ambiente pode ou não lidar com esse tipo de mudança.
Para fazer isso, há cinco perguntas que você precisa responder honestamente:
1. Você está disposto a iniciar um projeto sem saber onde vai acabar?
Você sabe o ditado ‘falha rápido?’ Refere-se ao gerenciamento de projetos ágil. Com o Agile, você está se movendo rapidamente e continuamente testando com usuários reais. O que pode ser super estressante se você é um maníaco por controle.
Antes de adotar o Agile, pergunte-se o quanto você se sente confortável em lançar uma versão menos concluída do seu produto para os usuários testarem? Você se sente bem ao lançar um MVP (Produto mínimo viável) ou acha que seu projeto precisa ser totalmente preparado antes que ele possa ver a luz do dia?
2. Você é avesso a riscos?
Como dissemos antes, o Agile tem como objetivo implantar e aprender continuamente com seus erros. O que significa que você está potencialmente assumindo um nível de risco mais alto do que faria se adotasse um estilo de gerenciamento de projeto mais tradicional.
A sua cultura é uma startup que monta as calças, onde o risco é o seu nome do meio? Ou você está no precipício do fracasso e precisa garantir que tudo corra imediatamente (o que, se formos honestos, nunca acontece)? Se você estiver seguindo a rota Agile, é melhor estar preparado para enfrentar quaisquer problemas desconhecidos que surgirem ao longo do caminho.
3. Qual é a flexibilidade da sua equipe?
No Agile, você trabalha com seus clientes para melhorar o produto. Mas isso nem sempre ocorre com designers, desenvolvedores e fabricantes de todos os tipos com um ego (ou seja, todos nós). Pergunte a si mesmo se seus principais participantes podem colocar seu ego de lado e ajustar seus esforços e idéias com base nas necessidades do cliente.
4. Quão rigorosa é a hierarquia da sua empresa?
Um dos princípios fundamentais do Agile não é apenas trabalhar com seus usuários, mas também que os desenvolvedores terão acesso às principais partes interessadas diariamente. Para algumas empresas, isso é um exagero. Como é sua cultura? Existe uma hierarquia rígida estabelecida ou as pessoas na época farão parte do processo de desenvolvimento?
5. Como você mede o progresso? E sucesso?
Síndrome de novo objeto brilhante e Agile não se misturam. O gerenciamento de projetos ágil tem tudo a ver com trabalhar para refinar continuamente seus processos e melhorar seu produto. Portanto, se é mais provável que você corra atrás da próxima ideia emocionante e deixe a última desmoronar, não terá os melhores resultados que o Agile tem a oferecer. Reserve um minuto para ver como você e sua cultura definem progresso e sucesso. Você consegue ver que pequenos passos constantes o aproximam de seu objetivo final?
Como implementar o Gerenciamento Ágil de Projetos em sua equipe técnica
Se não te assustamos nessa última seção, parabéns! Você está pronto e disposto a mudar a maneira como sua equipe aborda o gerenciamento de projetos e começar a criar produtos da maneira Agile.
Agile é tudo sobre ritmo. Quando você tem vários ciclos interdependentes de planejamento e entrega, suas equipes precisam verificar mais do que qualquer outra coisa. Como gerente de projeto ou líder de equipe, é seu trabalho ter essa visão de 10.000 metros para garantir que todos estejam trabalhando juntos sem problemas.
O Agile é uma mistura de planejamento, execução, aprendizado e iteração constantes, mas um projeto básico do Agile pode ser dividido em sete etapas:
Etapa 1: defina sua visão com uma reunião de estratégia
O que é isso?
No início de um novo projeto Agile, você precisa definir uma necessidade ou visão clara de negócios que o seu projeto está abordando. Em essência, você precisa responder por que está fazendo o que está planejando fazer? É uma questão geral, mas essa é a crença principal a que você se referirá ao construir.
Para empresas de produtos, uma das melhores maneiras de definir sua visão é usar o que é chamado de Elevator Pitch :
- Para: (Nosso Cliente Alvo)
- Quem: (Declaração da Necessidade)
- O: (Nome do produto) é um (Categoria do produto)
- Que: (Benefício chave do produto, motivo imperioso para comprar e / ou usar)
- Ao contrário: (Alternativa competitiva primária)
- Nosso Produto: (Declaração Final de Diferenciação Primária)
Se você não está construindo um produto, provavelmente ainda poderá ver como pode ajustar rapidamente esse tom para corresponder às metas do seu projeto.
Quem deveria estar lá?
É aqui que você entra no seu projeto, para que muitas partes interessadas importantes estejam presentes, incluindo executivos, gerentes e diretores relevantes, bem como todos os proprietários de produtos.
Quando isso acontece?
Sua reunião de estratégia deve ocorrer antes do início de qualquer projeto ou pelo menos anualmente para garantir que sua missão ainda seja válida, com reuniões periódicas para atualizações.
Quanto deve demorar?
Isso é totalmente subjetivo, mas uma reunião estratégica adequada pode levar de 4 a 16 horas (apenas não seguidas!)
Etapa 2: crie o roteiro do seu produto
O que é isso?
Após a validação da sua estratégia, é hora do proprietário do produto traduzir essa visão em um roteiro do produto . Esta é uma visão de alto nível dos requisitos para seu projeto, com um prazo curto para quando você desenvolverá cada um deles.
A parte ‘solta’ aqui é importante. Você não está gastando dias ou semanas planejando todas as etapas, mas simplesmente identificando, priorizando e estimando aproximadamente o esforço que cada peça do seu produto levará para criar um produto utilizável.
Então, como isso é para um projeto Agile? Roman Pichler , especialista em gerenciamento de produtos , sugere trabalhar com um roteiro de produtos orientado a objetivos , que às vezes também é chamado de baseado em tema :
“Os roteiros orientados para metas se concentram em metas, objetivos e resultados, como aquisição de clientes, aumento do engajamento e remoção da dívida técnica. Os recursos ainda existem, mas são derivados dos objetivos e devem ser usados com moderação. Use, no máximo, de três a cinco recursos por objetivo, como regra geral. ”
Para cada uma dessas metas, você deve incluir cinco informações principais: Data, Nome, Meta, Recursos e Métricas
Isso fornece uma idéia clara do que precisa ser feito, quando e como você medirá o sucesso.
Quem deveria estar lá?
O roteiro do produto é feito pelo Dono do Produto, mas também deve incluir a participação e participação de outras partes interessadas no projeto – pense nos representantes da equipe de marketing, vendas, suporte e desenvolvimento.
Quando isso acontece?
O roteiro precisa estar em vigor antes de você começar a planejar sprints, por isso é melhor começar a criá-lo diretamente após a reunião de estratégia.
Quanto deve demorar?
Como tudo no gerenciamento de projetos Agile, você deseja avançar rapidamente, em vez de se concentrar no planejamento inicial. No entanto, seu roteiro é um mapa literal da sua missão ao seu MVP e deve levar o tempo necessário para se sentir confiante de que você cumpriu todas as metas aplicáveis.
Etapa 3: prepare-se para um plano de lançamento
O que é isso?
Agora que temos uma estratégia e um plano, é hora de definir algumas linhas de tempo provisórias.
Nesta fase, o proprietário do produto cria um cronograma de alto nível para o lançamento do software em funcionamento. Como os projetos Agile terão vários lançamentos, você deve priorizar os recursos necessários para iniciar primeiro.
Por exemplo, se o seu projeto iniciar em novembro, você poderá definir o lançamento do MVP para o início de fevereiro, com um recurso de alta prioridade lançado em maio seguinte. Tudo isso depende da complexidade do seu projeto e da duração dos seus “sprints” – os períodos de trabalho dedicados a cada objetivo (no qual entraremos em seguida!). Uma versão típica inclui 3 a 5 desses sprints.
Quem deveria estar lá?
Um plano de libertação é como reunir as tropas. O proprietário do produto, os gerentes de projeto e todos os membros da equipe devem estar lá. Você também pode trazer algumas partes interessadas importantes para adicionar mais força e estimular a equipe.
Quando isso acontece?
No mínimo, seus planos de versão devem ser criados no primeiro dia de qualquer nova versão e revisados pelo menos a cada trimestre.
Quanto deve demorar?
Seja realista quanto tempo levará um lançamento, mas não deixe que isso o atrapalhe. Uma sessão típica de planejamento de liberação deve levar de 4 a 8 horas.
Etapa 4: é hora de planejar seus sprints
O que é isso?
É hora de passar da macro para a micro visão, pois o proprietário do produto e a equipe de desenvolvimento planejam “sprints” – ciclos curtos de desenvolvimento nos quais tarefas e objetivos específicos serão realizados. Um sprint típico dura entre 1 a 4 semanas e deve permanecer na mesma duração durante todo o projeto, pois isso permite que as equipes planejem o trabalho futuro com mais precisão, com base no desempenho passado.
No início de um ciclo de sprint, você e sua equipe criarão uma lista de itens de lista de pendências que você acha que pode concluir nesse período que permitirá criar software funcional. Então, é tão simples quanto usar uma das metodologias Agile para trabalhar com elas (que abordaremos mais detalhadamente abaixo).
Quem deveria estar lá?
O planejamento da sprint é um esforço da equipe e, portanto, o proprietário do produto, os gerentes de projeto e todos os membros da equipe devem estar presentes para expressar seus pensamentos e preocupações.
Quando isso acontece?
O planejamento do sprint ocorre no início de cada ciclo do sprint. Por exemplo, se você estiver fazendo sprints semanais, fará uma sessão de planejamento toda segunda-feira (ou qualquer dia da semana em que você escolher começar).
Quanto deve demorar?
O planejamento da sprint define o tom do ciclo. Portanto, embora você não queira gastar muito tempo nesse estágio, pode levar de duas a quatro horas de forma realista. Mas uma vez que você planejou seu sprint, você está literalmente indo às corridas.Coloque todos na mesma página.
Etapa 5: mantenha sua equipe no caminho certo com as apresentações diárias
Ao longo de cada corrida, você precisa de oportunidades para garantir que nenhum obstáculo esteja surgindo e atrapalhando a conclusão de seus objetivos a tempo. É aí que entra a reunião diária, ou “Standup” no idioma do Agile.
Um standup é uma reunião diária de 15 minutos em que sua equipe se reúne para discutir três coisas:
- O que você completou ontem?
- No que você está trabalhando hoje?
- Há algum obstáculo no caminho?
Embora isso possa parecer um aborrecimento para alguns de sua equipe, essas reuniões são essenciais para promover o tipo de comunicação que impulsiona o gerenciamento de projetos Agile. O Agile depende de reagir rapidamente aos problemas e expressá-los em um espaço público é uma maneira poderosa de promover a colaboração entre equipes.
Etapa 6: o Sprint está pronto? Está na hora de fazer uma revisão
O que é isso?
Se tudo correu como planejado, até o final do seu ciclo de sprint, você deve ter um software em funcionamento. Nesse momento, é hora de revisar o que foi feito e mostrá-lo às pessoas da sua equipe e aos principais interessados. Pense nisso como o Agile show-and-tell.
A chave aqui é verificar seu plano inicial para garantir que todos os requisitos foram atendidos. Como proprietário do produto, é sua escolha aceitar ou recusar determinadas funcionalidades. Se algo deu errado, pergunte por quê? Como você pode ajustar o próximo sprint para que sua equipe atinja seus alvos? Agile é tudo sobre aprendizado e iterações contínuas, e isso significa em seus processos e em seu produto.
Quem deveria estar lá?
Toda a sua equipe, bem como as principais partes interessadas, deve estar na sua revisão do sprint para verificar o progresso e expressar seu apoio.Pare as distrações, coloque seus projetos em linha.
Quando isso acontece?
A revisão do sprint ocorre no final de cada sprint.
Quanto deve demorar?
Basta dizer não aos powerpoints e apresentar dissertações. A revisão do sprint deve levar apenas uma ou duas horas no máximo.
Etapa 7: o que vem a seguir? Decida o que focar na retrospectiva do sprint
O que é isso?
Para que o gerenciamento de projetos Agile funcione, você precisa ter uma próxima etapa clara após cada etapa. Isso é determinado durante a retrospectiva do sprint. Depois que um sprint é concluído e os recursos são exibidos, é hora de decidir qual trabalho será feito a seguir. Você aprendeu algo durante o sprint que muda sua linha do tempo ou visão inicial para o projeto?
Não planeje simplesmente, mas também reserve um tempo para discutir como foi o sprint anterior e como você poderia melhorar o próximo.
Quem deveria estar lá?
A retrospectiva é uma extensão natural da revisão e, portanto, enquanto seus stakeholders podem sair, o restante da equipe deve estar envolvido e fornecer suas idéias.
Quando isso acontece?
Faz mais sentido que a retrospectiva do sprint ocorra logo após a revisão do sprint.
Quanto deve demorar?
Mais uma vez, mantenha-o curto e doce. Uma hora ou duas no máximo é provavelmente tudo o que você precisa para fazer uma análise e planejar o próximo resumo.
O que acontece agora?
Nesse ponto, você deve ter um software funcional para o qual possa enviar, obter feedback e planejar novos recursos ou correções. Esse envio, aprendizado e construção contínuos é o que torna o Agile tão poderoso. Em vez de simplesmente trabalhar no backlog, você está lançando produtos e vendo como as pessoas interagem com eles. Isso significa que, em vez de trabalhar em um produto por um ano apenas para liberá-lo e descobrir que algumas das principais funcionalidades estão ausentes, você pode descobrir isso depois de um sprint e ajustá-lo de acordo.
Como implementar o Agile: As 3 principais metodologias do Agile explicadas
Nesse ponto, você pode se sentir pronto para mergulhar no Agile e trazê-lo para sua equipe. No entanto, há mais um passo que precisamos seguir. Como dissemos anteriormente, Agile é um termo mais abrangente para uma filosofia de gerenciamento e desenvolvimento de projetos. Para usar essas idéias ao máximo, algumas pessoas muito inteligentes desenvolveram metodologias ágeis que você pode seguir.
Essas metodologias são todas bastante semelhantes, mas do ponto de vista da implementação, cada uma tem sua própria mistura de práticas, terminologia e táticas.
Vamos dar uma olhada no top 3 e detalhar como eles são diferentes:
Scrum
O Scrum é provavelmente a metodologia Agile mais conhecida e geralmente os dois andam de mãos dadas. É especialmente popular no mundo do desenvolvimento de software, graças à sua simplicidade, produtividade comprovada e capacidade de atuar como uma estrutura abrangente para as várias práticas promovidas por outras metodologias Agile.
Veja como funciona:
Com o Scrum, o “Product Owner” trabalha em estreita colaboração com sua equipe para identificar e priorizar seus objetivos ou recursos e adicioná-los ao que é chamado de “Product Backlog”. O backlog pode consistir em recursos, correções de bugs, requisitos não funcionais – praticamente tudo o que precisa ser feito para fornecer o software em funcionamento.
Com esse atraso, o Dono do produto decide prioridades e as equipes se inscrevem para fornecer “incrementos potencialmente entregáveis” de software durante seus Sprints, que normalmente duram 30 dias. Depois que a equipe se comprometer com o backlog da Sprint, nada mais poderá ser adicionado a ela, exceto pela equipe. No final do Sprint de 30 dias, o backlog é analisado e reprioritizado (se necessário) e tudo começa novamente.
Para uma visão mais aprofundada da implementação do Scrum, confira este post do cliente do Planio, Alex Lemm, na Software AG .
Kanban
Como o Scrum, o Kanban é uma metodologia Agile criada em torno da entrega contínua, mantendo as coisas simples e sem sobrecarregar a equipe de desenvolvimento. O Kanban baseia-se em torno de 3 princípios básicos:
Visualize seu fluxo de trabalho em um ‘quadro’
Ser capaz de ver todos os itens nos quais você está trabalhando no contexto um do outro pode ser incrivelmente informativo e ajudar a manter as coisas claras e simples quando os projetos ficam complexos. As ferramentas kanban (como o Planio!) Usam um estilo de ‘quadro’ para ver todos os seus itens e onde eles se encaixam no fluxo de tarefas a fazer a realizar.
Mantenha seu trabalho em andamento (WIP) limitado
Como no Scrum, onde a lista de pendências é definida antes do seu sprint e nada pode ser adicionado (exceto pela equipe), o Kanban conta com as equipes que sabem quanto podem realmente fazer em cada sprint.Pare o caos do e-mail bagunçando sua caixa de entrada.
Tenha os próximos passos claros
Para manter o fluxo do Kanban em movimento, você sempre deve saber o que acontece depois que um item é concluído. Isso significa manter sua lista de pendências priorizada e atualizada.
(você pode ler tudo sobre como trabalhar com o Kanban aqui).
Programação Extrema (XP)
A programação extrema (XP) não é extrema no sentido do Mountain Dew, mas é um pouco diferente das outras metodologias que discutimos.
O XP é uma abordagem mais disciplinada ao gerenciamento de projetos Agile, que envolve alto envolvimento do cliente, ciclos rápidos de feedback, testes e planejamento contínuos e trabalho em equipe próximo para fornecer software de trabalho rapidamente. Para se ter uma idéia, um XP Sprint típico dura apenas 1 a 3 semanas.
A “receita” original do XP descrita pelo engenheiro de software Kent Beck, foi baseada em quatro valores – simplicidade, comunicação, feedback e coragem – com 12 práticas de suporte. É definitivamente mais complexo que outras metodologias e se parece com isso na prática:
No XP, existem ciclos de feedback apertados, nos quais o “cliente” trabalha em estreita colaboração com a equipe para definir e priorizar metas granulares chamadas “Histórias do usuário”. A equipe estima, prioriza e planeja a entrega dessas histórias, obtendo mais feedback do cliente até que esteja pronto para o lançamento.
Considerações finais sobre a implementação do gerenciamento de projetos Agile
Parabéns! Agora você deve ter uma compreensão clara da aparência do gerenciamento de projetos Agile e algumas das maneiras poderosas de usá-lo em suas próprias equipes.
No entanto, há uma última peça do quebra-cabeça. Com todas essas informações, organização e priorização acontecendo, você precisa de uma ferramenta adequada de gerenciamento de projetos para manter seu projeto Agile em andamento. O melhor software aborda três pontos problemáticos comuns ao processo de gerenciamento de projetos Agile:
- Relatórios e métricas: itens como rastreamento e projeção de tempo, relatórios de progresso fáceis de entender para as partes interessadas, garantia de qualidade e uma visão geral do progresso
- Comunicação: a capacidade de manter todos no caminho certo com atualizações para equipes locais e distribuídas, listas de tarefas compartilhadas, feedback e atribuições
- Avaliação do projeto: funcionalidade em torno da identificação e correção de obstáculos ou gargalos, avaliação de desempenho e garantia de controle financeiro
Comments are closed.