Para entender um pouco mais sobre o conceito de projetos e a metodologia de gestão “em cascata”, acesse a primeira parte deste artigo aqui.
Antes de começar, gosto de esclarecer dois conceitos: por que framework e não metodologia ágil? Embora muitas pessoas utilizem incorretamente o termo “metodologia” para se referir a projetos conduzidos sob os valores e princípios ágeis, ele é impreciso.
Metodologia tem a ver com orientações de certa forma prescritivas, um conjunto de regras a serem seguidas. Ao ler o Guia do Conhecimento em Gestão de Projetos do PMI, por exemplo, nós temos não apenas a declaração de inúmeras situações de projeto, como também referências sobre como agir em cada uma delas, inclusive em casos de problema e dificuldades – as chamadas “melhores práticas”.
Já no framework esse aspecto de prescrição não está presente; ele oferece diretrizes gerais de condução, acompanhamento e engajamento, mas deixa a critério das equipes de projeto decidir como e por meio de quais ferramentas o framework será implantado. Sendo assim, é comum haver adaptações mesmo de frameworks bastante disseminados – como o Scrum e o Kanban, por exemplo –, o que é plausível e até estimulado pelos próprios organizadores do Manifesto Ágil.
A propósito, o Manifesto surgiu em 2001, durante um encontro entre 17 profissionais[1] que já praticavam formas mais “leves” de conduzir projetos e que discutiram quais deveriam ser os métodos essenciais para o desenvolvimento de software. O resultado disso ficou conhecido como “Manifesto Ágil”, e representa os quatro valores mais importantes a reger uma iniciativa desse tipo. São eles:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Embora tenha sua origem no desenvolvimento de software, o Manifesto pode ser expandido para qualquer outro contexto de projetos. É importante enfatizar também que, ainda que seja dada uma relevância maior para os componentes do lado esquerdo dessas afirmações, destacados em negrito, ele não prescinde daquelas retratadas à direita. Sendo assim:
– processos e ferramentas são úteis e oferecem um bom suporte, mas nunca podem ser colocados em um patamar mais elevado do que o das próprias pessoas. Devemos considerar que as interações humanas têm o “poder” de resolver problemas crônicos de comunicação ou entendimento. Por isso, a ênfase nesse aspecto;
– embora documentação seja importante, principalmente para fases pós-implantação, quando (geralmente) times diferentes assumem as rotinas de correção e melhorias de software, o aspecto essencial por que um projeto é realizado é ter um produto funcionando corretamente: este é o maior indicador de que algo foi construído e é a partir dele que os clientes, sejam internos ou externos, vão comprovar o valor entregue;
– colaboração é a palavra-chave de projetos. Em vez de administrar conflitos do tipo eu (time de projeto) contra eles (clientes), o Manifesto reforça a importância do trabalho em conjunto, desde a concepção de um produto ou serviço, a fim de que as partes cocriem a solução e tenham suas necessidades efetivamente atendidas;
– o framework deve estar aberto a correções de rota. Observar o contexto macro e, em especial, o feedback do cliente é fundamental para que o desenvolvimento atenda a essas mudanças e seja funcional após a entrega. Ao contrário do modelo em cascata, em que mudanças de escopo geram requerimentos que então passam por um comitê de aprovação composto pelos principais stakeholders, aqui o time de projeto apenas discute a organização e (re)priorização dessas tarefas, a fim de assimilá-las em seu escopo de trabalho.
O Manifesto Ágil foi posteriormente “completado” com doze princípios para orientar ações e escolhas de métodos e ferramentas, no intuito de maximizar o resultado dos projetos. São eles:
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado;
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas;
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo;
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
5. Construir projetos em torno de indivíduos motivados, dando a eles o ambiente e o suporte necessário e confiando neles para fazer o trabalho;
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é por meio de conversa face a face;
7. Software funcionando é a medida primária de progresso;
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade;
10. Simplicidade: a arte de maximizar a quantidade de trabalho não realizado é essencial;
11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis;
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
Tendo isso em mente, falemos sobre um dos frameworks mais populares.
Scrum
O Scrum é um dos principais métodos ágeis. Ele nasceu em meados dos anos 90, quando dois caras, Jeff Sutherland e Ken Schwaber, cansados dos projetos confusos, com cronogramas irrealistas e orçamentos apertados em que trabalharam até então buscaram novas formas de se organizar e realizar as atividades. Devido a sua versatilidade, ele pode ser utilizado em diferentes contextos e complexidades: desde uma campanha publicitária até a estruturação de informações do FBI[3]. Segundo a definição de seus criadores:
É um framework por meio do qual as pessoas podem lidar com problemas complexos, enquanto entregam produtos de forma eficaz e criativa, gerando o maior valor possível.
Ao contrário da metodologia em cascata, o Scrum funciona a partir de iterações incrementais que vão, aos poucos, construindo seu produto / serviço. E diferente do PMBOK também, o guia de implementação[3] possui meras 19 páginas, em comparação às quase 800 daquele. Isso significa que se trata de um método fácil de aprender, ainda que nem sempre fácil de aplicar.
A etapa inicial é caracterizada pela definição de papéis:
– Scrum Master (“SM”): aqui a figura do Gerente de Projetos é substituída pelo Scrum Master, profissional que garante a orientação do time em relação ao framework e responsável por remover os impedimentos apontados pela equipe nas cerimônias diárias. A propósito, este é um erro comum de organizações que tentam (ou dizem) aplicar este método: confundir o papel desses dois profissionais e alocar um GP sob um projeto dito ágil; ou então descrever como responsabilidade do SM “gerenciar um projeto ágil”. No Scrum não há “gestão” propriamente dita, muito menos reuniões de status;
– Product Owner (P.O. ou Dono do Produto): representa seu cliente final, tomando decisões acerca da priorização de funcionalidades e aderência aos requerimentos levantados. É o principal canal de comunicação entre o time de projeto e seus stakeholders;
– Time de desenvolvimento: equipe multidisciplinar responsável pela entrega do produto.
Note que não há uma hierarquia entre esses papeis – todos atuam de forma colaborativa, comprometidos com a entrega da melhor solução possível e sempre mantendo o foco no cliente e sua experiência. No caso do SM, costuma-se falar em servant leader, ou seja, um líder que serve ao grupo (em vez de controlá-lo).
Uma vez definidos os representantes de cada papel, o projeto tem início com a criação de um backlog de produto, isto é, uma lista contendo todas as tarefas que precisam ser realizadas para que o objetivo seja atingido. A partir dela, e baseado na interpretação dos interesses do cliente final, o P.O. priorizará essas tarefas, segundo sua relevância e perspectiva de valor entregue ao cliente. Vale ressaltar que o backlog nunca estará completo – conforme o projeto avança e os ciclos se sucedem, novos requerimentos e tarefas surgirão e serão incluídos nele.
O Scrum funciona sob cerimônias que são realizadas periodicamente dentre os membros do time de desenvolvimento, SM e PO:
– Daily Scrum (ou daily meeting ou stand up meeting): são reuniões diárias envolvendo o SM além do time de desenvolvimento. Idealmente, elas devem acontecer no início – ou o mais próximo possível disso – do trabalho. Sua duração não pode exceder 15 minutos, pois tem por finalidade um alinhamento rápido sobre os pontos mais relevantes que estão ou serão desenvolvidos. Nela, cada um dos participantes responde a três perguntas: (1) o que fiz ontem; (2) o que farei hoje; (3) se existem impedimentos à realização do meu trabalho. A partir dessas informações, o time todo consegue se atualizar a respeito do progresso, bem como compartilhar possíveis problemas a tempo de serem resolvidos – neste caso, cabe ao SM a responsabilidade de organizar junto aos stakeholders as estratégias mais pertinentes para removê-los do caminho;
– Planning: encontro para organização do trabalho que será realizado no ciclo de iteração seguinte, a chamada Sprint. Tendo em vista a priorização de tarefas organizada no backlog de produto, o time de desenvolvimento “puxa para si” uma determinada quantidade de trabalho que julga capaz de realizar nesse período. Como padrão, as Sprint duram duas semanas consecutivas, embora esse número possa variar conforme necessidades do contexto. Uma característica fundamental desses encontros de planejamento é o compromisso do time em realizar as tarefas com as quais se comprometeram e a autonomia para tomar essa decisão. Autonomia e protagonismo são as palavras-chave de um time ágil, que com o tempo vai se tornando cada vez mais entrosado e preciso em suas estimativas;
– Refining (ou Review): geralmente na metade de uma Sprint, o time se reúne para discutir o andamento das tarefas e revisar prioridades. Eventualmente, por questões inerentes ou não ao projeto, pode ser necessário ajustar os próximos passos. Assim, o ritmo de entregas pode ser mantido, bem como a proposta de entrega de valor ao cliente. Neste encontro, a participação do P.O. é imprescindível, pois é a pessoa com maior domínio dos requerimentos e experiência do cliente em relação às entregas sendo feitas;
– Retrospectiva: ao final de uma Sprint, o time todo se reúne para discutir o trabalho realizado e entregue. O que deu certo? O que poderia ser melhor? Quais lições podemos levar para as próximas Sprints? Mais do que uma ocasião para apontar dedos, este é um momento de reflexão sobre os caminhos que o projeto seguiu e como eles podem ser otimizados dali em diante. Também é o evento para que os membros do time parabenizem iniciativas de destaque e demonstrações de colaboração, comprometimento, ideias e esforço – minha sugestão é que este seja justamente o ponto de partida de uma Retrospectiva. Para isso, muitos times usam formas lúdicas de discussão com modelos baseados em desenhos, personagens do cinema e contextos inusitados. Por exemplo:
Na figura acima, o navio representa o time do projeto; as âncoras são os fatores e comportamentos que “reduziram a velocidade da navegação”; as nuvens soprando indicam iniciativas, ideias e comportamentos que deram velocidade às entregas; e, por fim, a ilha é o objetivo que deveria (ou foi) alcançado. É produtivo deixar que as pessoas interajam com a figura, colocando post-its e pequenas notas exemplificando cada uma dessas situações. Ao SM cabe o papel de fomentar a participação de todos e, principalmente, impedir que a Retrospectiva se transforme em uma sessão para “lavar roupa suja”.
Essas cerimônias são então repetidas a cada nova Sprint, até que o produto esteja acabado. Ou melhor: uma vez finalizado, o produto entra em um looping de melhorias contínuas. Ao contrário dos projetos em cascata, em que todo o trabalho é entregue de uma só vez ao final do ciclo, no Scrum isso acontece em estágios sucessivos a partir de um MUP[5] (minimun usable product ou protótipo minimamente utilizável, se preferir), que vai sendo incrementado.
Um princípio vital do Scrum é a noção de transparência. Todos no time precisam ter pleno conhecimento do que os demais estão fazendo, o nível de avanço do projeto e os objetivos esperados. Sendo a visibilidade tão fundamental, recomendo a utilização de quadros (Kanban) para disponibilizar uma “gestão à vista” de tudo o que está sendo feito.
Kanban
Neste tópico, trato o Kanban como ferramenta de suporte ao Scrum e não como método (que tem uma série de nuances distintas). Esses quadros ajudam o time a se localizar em termos de tarefas a serem realizadas, bem como seus responsáveis, e o progresso geral do projeto. Isso evita uma série de perguntas aborrecidas sobre “o que você está fazendo?”, “quando fica pronto?” e similares.
A partir do Kanban, o time reforça seu papel de autogestão, atualizando a evolução do projeto. Comumente, isso é feito durante o Daily Scrum (que tal realizar este encontro de frente para um quadro Kanban?).
A representação mínima de um Kanban requer 3 colunas: “a fazer” (backlog), “em andamento” e “concluído”. Conforme o time evolui na aplicação da ferramenta, novas colunas poderão ser incorporadas para representar etapas-chave do projeto. As tarefas serão identificadas por cartões (post its) que, por sua vez, serão movidos pelo time (respeitando a responsabilidade de cada um pela tarefa) através dessas colunas, conforme o trabalho for sendo desenvolvido. Posteriormente publicaremos um artigo dedicado ao Kanban para auxiliá-los nessa jornada 😉
Melhor do mundo?
Não existe um método “melhor”; existe um método mais adequado às necessidades e contexto do projeto que você está desenvolvendo. Em startups e empresas envolvidas em circuitos de inovação, há uma tendência pela utilização do Agile, dada sua flexibilidade a mudanças e ciclos incrementais de produto. Por outro lado, um profissional certificado como PMP tem como vantagem poder atuar em qualquer projeto em qualquer lugar do mundo, visto que a metodologia em cascata representada pelo PMBOK é universal.
Minha sugestão é que você experimente essas duas formas em iniciativas de sua empresa, a fim de se familiarizar com elas. Com tempo, você elegerá uma principal e começará a customizá-la para obter resultados ainda melhores.
[1] Alistair Cockburn, Andrew Hunt, Arie van Bennekum, Brian Marick, Dave Thomas, James Grenning, Jeff Sutherland, Jim Highsmith, Jon Kern, Ken Schwaber, Kent Beck, Martin Fowler, Mike Beedle, Robert C. Martin, Ron Jeffries, Steve Mellor e Ward Cunningham.
[2] Vide https://agilemanifesto.org/.
[3] Este case é contado no livro “Scrum”, do Jeff Sutherland, indicado na sessão “Saiba mais”.
[4] Vide referência do “Scrum Guide”.
[5] Na Arquitetura RH, temos dado preferência ao termo MUP em vez de MVP (minimun viable product) para refletir a importância da experiência do cliente com o produto.
Saiba mais em:
– SUTHERLAND, Jeff. Scrum – a arte de fazer o dobro do trabalho na metade do tempo. São Paulo: Sextante, 2019.
– SUTHERLAND, Jeff & SCHWABER, Ken. Scrum Guide. Disponível em https://scrumguides.org/.
