Qual é o melhor cenário para o funcionamento da metodologia da cascata?

Um rápido alinhamento de expetativas

Este artigo aborda o conceito de “projeto”, sua estrutura, nuances, desafios e oportunidades, além de dois dos principais métodos para gestão de projetos: o modelo tradicional, em “cascata”, e o Agile. Não fazem parte do escopo deste texto discussões sobre ferramentas nem estratégias sobre gestão propriamente dita, embora façamos diversos comentários sobre pontos de atenção e cuidados a serem tomados.

Antes de falar sobre metodologias, frameworks e formas de gestão, é importante entender o que, exatamente, é um projeto. De acordo com a definição do Guia PMBOK (Project Management Body of Knowledge), projeto

“é um esforço temporário empreendido para criar um produto, serviço ou resultado único. Projetos são realizados para cumprir objetivos através da produção de entregas (…) tangíveis ou intangíveis.”

Dessa forma, devemos entendê-lo como uma iniciativa que tem começo e fim, e que busca algum tipo de melhoria nos mais diversos diferentes âmbitos: ferramentas, métodos, processos, produtos, políticas, serviços, dentre outros. Afinal, ninguém faz um projeto para que as coisas continuem do jeito que estão, certo? (Embora, alguns tenham resultados um tanto… controversos — as famosas iniciativas de pioria.)

Um dos maiores desafios de um projeto tende a ser a interdependência de ações: como ele promove a conjunção de tarefas entre diversas áreas e disciplinas de uma (ou mais) organização, um dos elementos-chave para o sucesso é estabelecer a comunicação e a coordenação adequadas de suas atividades. E isso pode ser feito de diversas maneiras, como veremos à frente. Mesmo em projetos de cunho individual — quando planejamos um programa de desenvolvimento pessoal, uma mudança de residência ou um plano de carreira, por exemplo –, há envolvimento e interdependência de outras pessoas e situações.

Outro ponto importante é entender que algumas iniciativas podem constituir ou não um projeto de acordo com o contexto em que estão inseridas. Por exemplo: para mim, que nunca construí um carro na vida (sequer um de rolimã), fazê-lo seria um projeto; para o operário da linha de produção da indústria automobilística, construir um carro faz parte de um processo, já que representa uma atividade repetida, para qual já existe uma organização de trabalho funcional.

Feito o entendimento inicial sobre o conceito de projeto, vamos às formas de gerenciá-lo.

Projetos em cascata

O PMI — Project Management Institute — foi criado nos Estados Unidos em 1969 com o objetivo de pesquisar, discutir e formular as boas práticas de gestão de projetos. Na década de 1980, seus fundadores desenvolveram os primeiros programas de certificação na área, dando aos profissionais aprovados o título de PMP — Project Management Professional (hoje são mais de 370.000 ao redor do mundo). Um tempo depois, no começo dos anos 90, a primeira versão do PMBOK — o Project Management Body of Knowledge, traduzido aqui como Guia do Conhecimento em Gestão de Projetos — foi publicada [1].

O PMI funciona por meio de “capítulos”, que são escritórios abertos em diversas cidades do mundo e que realizam fóruns de discussão relacionados ao tema, formação e certificação de profissionais, além de fomentar uma rede de associados que atuam na disseminação de sua metodologia de gestão de projetos, contida no PMBOK. Este, por sua vez, consolida as chamadas melhores práticas de gestão de projetos e representa a consolidação do trabalho de pesquisa de milhares de profissionais da área que foram, ao longo dos anos, compilando suas experiências, desafios, cases de sucesso e, assim, aprimorando as práticas vigentes. O guia está dividido em dez áreas de conhecimento, aqui descritas muito brevemente:

• aquisições: processos necessários para comprar ou adquirir produtos, serviços ou resultados externos à equipe do projeto;
• comunicação: processos necessários para assegurar que as informações do projeto sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas, gerenciadas, controladas, monitoradas e finalmente organizadas de maneira oportuna e apropriada;
• cronograma: processos necessários para gerenciar o término pontual do projeto;
• custos: processos envolvidos em planejamento, estimativas, financiamentos, gerenciamento e controle dos custos, de modo que atenda, honre e respeite o orçamento aprovado;
• escopo: processos necessários para assegurar que o projeto contemple todo o trabalho necessário, e apenas o necessário, para que o mesmo termine com sucesso;
• integração: processos e atividades necessárias para identificar, definir, combinar, unificar e coordenar as várias áreas envolvidas;
• qualidade: processos para incorporação da política de qualidade da organização com relação ao planejamento, gerenciamento e controle dos requisitos de qualidade do projeto e do produto para atender as expectativas das partes interessadas;
• recursos: processos para identificar, adquirir e gerenciar os recursos materiais, tecnológicos e afins, bem como as pessoas necessárias para a conclusão bem-sucedida do projeto;
• riscos: processos de condução de planejamento, identificação, monitoramento e análise de gerenciamento de risco, planejamento e implementação de resposta;
• stakeholders ou partes interessadas: processos promovidos para identificar as pessoas, grupos ou organizações que podem impactar, serem impactados ou ainda se sentirem impactados pelo projeto, analisando suas expectativas e respectivo impacto, para o desenvolvimento de estratégias visando o engajamento eficaz nas decisões e execução do projeto

O termo “projeto em cascata” (waterfall project) remonta ao estilo de uma de suas principais ferramentas, o diagrama de Gantt (Gantt chart), que é faseado, lembrando os degraus da queda d’água de uma cachoeira:

Cada fase representa uma etapa de avanço do projeto e, para que a etapa seguinte tenha início é necessário que a anterior esteja totalmente concluída — o que acontece por meio de um termo de aceite assinado pelos gestores e stakeholders do projeto. O objetivo é garantir que o time e o contexto estejam prontos para avançar para o próximo bloco de atividades definido durante etapa de planejamento, sem que tarefas pendentes possam gerar problemas ou atrasos.

Em termos de estrutura, um projeto em cascata geralmente é definido pelas seguintes etapas:

• Termo de Abertura, com desmembramento em um Plano de Projeto: compreende a definição do objetivo a ser atingido, bem com as delimitações de escopo a ser entregue, prazo de execução, pessoas e áreas envolvidas, orçamento disponível e o plano de comunicação do projeto. Esta etapa é particularmente crítica, pois uma definição imprecisa do trabalho a ser realizado certamente resultará em uma série de problemas no decorrer de sua execução, seja por falta de clareza sobre o que precisa ser feito e o que será entregue ou desalinhamento de expectativas / informação. As consequências, em qualquer dos casos, partem de conflitos entre as equipes até a criação de produtos e serviços que não atendem aos objetivos desejados. Nas Oficinas de Projetos que realizo, costumo compartilhar com os participantes o trecho de um filme chamado Pentagon Wars (1998, com direção de Richard Benjamim e traduzido no Brasil como “Máquina de guerra”). Baseado em um evento verídico, a criação de um veículo blindado de transporte de tropas pelo Exército Americano, ele traz uma visão contundente a respeito da importância da definição de escopo (em determinado momento, a situação de caos assume até ares cômicos);

• Kick-off: cerimônia de abertura oficial do projeto. Em geral, neste evento participam todas as pessoas envolvidas e afetadas pelo projeto, que tomarão ciência dos termos de abertura e, quase sempre, realizarão etapas de integração para que se conheçam e ambientalizem. Isto é importante, pois os projetos tendem, cada vez mais, a ser iniciativas multidisciplinares, conduzidos com a participação de pessoas de diferentes áreas e perfis, e que doravante estarão atuando juntas;
• Análise e entendimento: esta fase pode ser subdividida em duas etapas, AS IS e TO BE. O AS IS é um desenho sistêmico e/ou de processos, procedimentos, políticas, práticas e comportamentos atuais, que já são executados normalmente dentro do escopo definido para o projeto. Por sua vez, o TO BE é uma proposta de melhoria, correção ou transformação trazida pelo projeto. Aqui existe uma nuance importante, porque o sucesso do desenho do cenário futuro (TO BE) depende do entendimento correto do AS IS — afinal, ninguém quer repetir os erros presentes, tampouco complicar ainda mais as coisas. Uma dificuldade com que times de projeto frequentemente se deparam é a falta de definições claras e documentação acerca dos processos existentes. E as pessoas que os executam nem sempre seguem um padrão lógico, não havendo descrições objetivas sobre o que elas recebem do processo anterior (entradas) e o que entregam para o próximo (saídas). Sem isso, é difícil garantir qualidade, acuracidade e até os prazos de entrega das informações;
• Realização: é a execução propriamente dita, partindo do documento de entendimento. Nesta fase são produzidas também as especificações técnicas que darão suporte ao desenvolvimento das atividades. Dependendo da natureza do projeto, esta tende a ser uma das fases mais longas;
• Testes & homologação: nesta etapa, o time de projeto, com o auxílio das áreas e pessoas que receberão a entrega desse projeto, testam a solução desenvolvida a fim de garantir que ela (1) cumpre as propostas declaradas no Plano do Projeto e (2) é aderente às necessidades levantadas durante a fase de Entendimento. Para testar uma solução, a equipe de projeto elabora roteiros com etapas que devem ser realizadas, bem como os resultados esperados a partir de uma determinada sequência de tarefas. Aqui entram importantes questões de qualidade: embora o time de projeto também realize um ciclo de testes chamados unitários, para filtrar erros e problemas mais genéricos, os testes de integração mais importantes são conduzidos pelas partes interessadas (áreas de negócio, clientes etc.) na solução. São essas equipes que validarão especificidades, regras de negócio, questões legais, tributárias, contábeis, regulatórias, dentre outras. Entretanto, não basta um teste simples — enviesado — em que dados corretos são usados para se chegar a um resultado correto. É imprescindível que se realize testes amplos, incluindo situações consideradas incorretas, para garantir que elas serão bloqueadas ou impedidas de seguir adiante. Um teste de qualidade eficaz aborda quatro perspectivas:

• Idealmente, esse é o mínimo que precisa ser feito, garantindo-se que a entrada errada gera resultados errados e que a entrada certa gera resultados certos. Em sistemas de TI isso é importante, mas existem algumas áreas em que isso é absolutamente crítico. Pense na Medicina: um médico analisa informações de exames e conclui que seu paciente tem uma doença grave e precisa passar por uma cirurgia de alto risco — só que os dados dos exames não tinham precisão e, na verdade, esse paciente estava apenas com uma doença simples, que poderia ser tratada em casa, com antibióticos (falso positivo). Ou então: os dados do exame indicam que está tudo bem e, com base nisso, o médico autoriza sua liberação. Chegando em casa, ele tem uma piora expressiva (falso negativo). Sem dúvida, isso terá implicações bastante graves. Por fim, o time responsável pela implantação pode testar unitariamente as funcionalidades de um projeto, mas não a sua integração, justamente para evitar que vieses e conhecimento prévio dos caminhos empregados na construção do projeto afetem a qualidade desse teste;
• Implantação (Go-Live): momento em que a solução homologada pelas partes interessadas pelo projeto (stakeholders) é efetivamente ativada, disponibilizada ao mercado ou colocada em ambiente de Produção. A partir daí, inicia-se uma fase de monitoramento para verificação de eventuais erros ou problemas não captados nos ciclos de teste, além de ajustes de rota que somente serão possíveis quando o produto ou serviço estiver sendo utilizado em larga escala. Embora o projeto em si seja encerrado, processos de melhoria e aprimoramento contínuo assumem a direção e, eventualmente, trazem elementos que vão conduzir a um novo projeto.

Durante muito tempo, esta metodologia foi a mais utilizada para planejamento, execução e entrega de projetos nas mais distintas frentes: construção civil, projetos de defesa, desenvolvimento de software, engenharia de produtos, pesquisa de medicamentos, programas educacionais etc. É, de longe, a mais popular: são cerca de 700.000 membros do PMI em quase todos os países do mundo, embora desde o início dos anos 2000 tenha começado a perder espaço para os frameworks ágeis, especialmente no contexto tecnológico, com o despontar das empresas de tecnologia e startups, como veremos a seguir.

Isso tem a ver com a velocidade com que as mudanças têm ocorrido nos últimos anos e a flexibilidades que esse cenário requer: um projeto em cascata funciona sob a tríade custo, escopo e tempo — fatores que estão diretamente interligados. Qualquer alteração em um deles, portanto, implica em alteração nos demais. Essas alterações, por sua vez, precisam passar por um comitê de aprovação denominado Comitê de Gestão de Mudanças (Change Management Board), que poderá autorizar ou não sua inclusão no âmbito das atividades definidas no Plano de Projeto. Em caso positivo, elas, bem como todas as etapas subsequentes — incluindo as que estiverem em andamento — terão de ser replanejadas, a fim de atualizar esse Plano adequadamente.

No contexto da Indústria 4.0, caracterizado pela “disrupção” em inúmeras esferas, a gestão de projetos sob essa metodologia pode gerar entraves para o tempo de resposta oferecido a essas mudanças do mercado, tornando uma entrega de projeto obsoleta antes mesmo que ela esteja finalizada — e comitês de mudança podem não ser rápidos o suficiente para retomar o passo, tendo em vista todas as etapas (e assinaturas) necessárias para aprovação de mudanças.

Ainda assim, a metodologia de gestão de projetos em cascata é sem dúvida uma das mais robustas do mercado, contando com a experiência e a colaboração de milhares de profissionais que se dedicam ao seu aperfeiçoamento contínuo. Seja entusiasta dela ou não, em algum momento você certamente vai se deparar com os famosos diagramas de Gantt feitos no MS Project, caso isso ainda não tenha ocorrido.

Frameworks ágeis

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 [2] 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 [3]

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 software, 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:

• nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado;
• 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;
• entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo;
• pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
• 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;
• 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;
• software funcionando é a medida primária de progresso;
• os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
• contínua atenção à excelência técnica e bom design aumenta a agilidade;
• simplicidade: a arte de maximizar a quantidade de trabalho não realizado é essencial;
• as melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis;
• 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 [4]. 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 [5] 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 papeis:

• 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á ssas 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 [6] (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.

Saiba mais em:

- Project Management Institute, Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), 6ª edição, 2017.

- 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.

[1] Atualmente estamos na 7ª edição, que possui cerca de 800 páginas e pode ser baixada (somente membros associados) a partir do site dos capítulos do PMI ou adquirida a partir de livrarias e e-commerce em geral.

[2] 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.

[3] Vide https://agilemanifesto.org/.

[4] Este case é contado no livro “Scrum”, do Jeff Sutherland, indicado na sessão “Saiba mais”.

[5] Vide referência do “Scrum Guide”.

[6] Tenho 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.