Você, caro leitor, que vai começar a ler este texto e que aplica a metodologia ágil no seu dia a dia de forma religiosa talvez já discorde de cara, mas peço uma chance para apresentar as possibilidades e benefícios que o Scrum pode trazer na gestão de projetos waterfall de forma complementar.

O que trago aqui é uma oportunidade de gestores de projetos, startups, equipes de trabalho e até mesmo grandes empresas poderem iniciar uma transição de metodologias de forma mais fácil, e que possam se adaptar às mudanças entendendo os benefícios que o Scrum pode adicionar.

Antes de mais nada, é importante entender de forma sucinta e resumida o que cada uma das metodologias possuem como teoria básica e quais são seus objetivos claros:

Metodologia Waterfall – Papéis e Responsabilidades

Waterfall: A palavra que em inglês que significa cascata, é considerada a forma mais tradicional de gerenciar projetos.

Nesta abordagem, todas as etapas são seguidas de forma sequencial. As fases básicas geralmente são de definição de requisitos, planejamento, execução e validação, podendo variar dependendo do tipo de iniciativa.

O modelo em cascata só permite que o projeto avance quando uma fase está inteiramente completa. Voltar algumas etapas, dar saltos para frente ou sobrepor atividades não é permitido. Além disso, no Waterfall os requisitos são totalmente definidos no início do projeto e geralmente sofrem pouca ou nenhuma alteração durante sua execução.

Quando falamos de papéis e responsabilidades, geralmente o time formado por essa metodologia possui alguns componentes:

1. O analista/especialista de negócios fica responsável por delegar os pedidos e necessidades do projeto.
2. O gerente de projetos mapeia os riscos, acompanha as datas de conclusão de tarefas até a entrega final além de garantir que não ocorra mudanças de escopo durante tempo de projeto.
3. O time de desenvolvimento é quem bota a mão na massa e faz o projeto nascer baseado no escopo pré definido.
4. Já os papéis de UX, designer e UI são quem desenham os protótipos e garantem que a melhor experiência de uso seja implementada a fim de atender os anseios do usuário final.
5. QA, profissional que realiza as baterias de testes a fim de encontrar possíveis erros de navegação e uso, são profissionais que garantem a qualidade da entrega.

Reparem que aqui não falamos sobre desenvolvimento de software em específico. Essa talvez seja a metodologia que se aplica em qualquer tipo de projeto. 

 

Scrum – Papéis e Responsabilidades

De forma resumida, é uma metodologia ágil para gestão e planejamento de projetos de software focado em entregas de valor.

No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são interativas, ou seja, o trabalho é dividido em interações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

No Scrum um time de desenvolvimento é chamado de Squad e como regra, precisam ter:

1. PO (Product Owner): é quem define as prioridades da lista do Product Backlog e quem traz as necessidades do usuário final do projeto de forma detalhada através do que chamamos de “estórias”.
2. Scrum Master/Team Lead: Responsável por fazer com que a metodologia ágil seja aplicada, blindar o team Dev de impactos externos e remover impedimentos que interfiram no dia a dia de um Squad Team. Em alguns casos, esse profissional tem a missão de fazer a gestão do projeto e dos recursos utilizados no mesmo.
3. Team Dev: São os desenvolvedores de software, os profissionais que fazem tornar real e tangível o Product Backlog. Geralmente, divididos entre front end (layout) e back end (estrutura técnica), esses profissionais fazem o desenvolvimento do software.
4. QA: Profissional que realiza as baterias de testes a fim de encontrar possíveis erros de navegação e uso, são profissionais que garantem a qualidade da entrega.
5. Por fim aqui também temos os papéis de UX, Designer e UI que são quem desenham os protótipos e garantem que a melhor experiência de uso seja implementada no software.

 

Ritos do Scrum aplicáveis no Waterfall

Dado que cada metodologia possui suas particularidades e que a aplicação de uma nova metodologia demanda tempo, esforço e (muita) força de vontade, algumas empresas têm encontrado maneiras “alternativas” de encontrar o modelo que melhor se aplica ao seu negócio ou tentando implementar algumas práticas gradativamente.

Mudanças de mindset nem sempre são tão rápidas de serem absorvidas e às vezes barreiras de reatividade (de pessoas inclusive) devem ser quebradas para poder engajar os times. O ideal é que essa migração de metodologia seja feita da maneira mais tranquila possível, sem traumas.

Nota: Em teoria, ambas metodologias pregam regras e não concordam com tais adequações. Segundo os criadores, a aplicação deve ser 100% seguida religiosamente a risca para que se possa garantir maior eficiência e os resultados esperados.

Mas, nem sempre uma empresa ou equipe de trabalho consegue aplicar os métodos de forma integral, portanto vão aqui algumas práticas do Scrum para quem esteja buscando uma migração de metodologia (Waterfall para o Scrum) de forma gradativa.

Scrum Daily

São reuniões realizadas diariamente em horários pré determinados. Quem participa dessas reuniões são todos os membros envolvidos de um Squad a fim de entender o que foi feito no dia anterior, o que será feito no dia atual e se existem quaisquer impedimentos que impactem o trabalho de seguir seu fluxo natural. Aqui, algumas informações super relevantes desse rito ágil:

1. duração máxima de 15 minutos, de forma que todos os participantes possam falar;
2. todos em pé, em ambiente longe de ruídos que possam impactar a comunicação. Isso facilita a objetividade da reunião;
3. o responsável por apoiar e mediar essa reunião é Scrum Master/Team Lead. É ele também que deverá atuar na remoção de impedimentos.
4. normalmente essas reuniões são realizadas antes do início da jornada de trabalho, no início do dia.

Grooming

Como vimos acima, a metodologia ágil consiste em quebrar um projeto em estórias. O intuito do Grooming é dar o máximo de detalhes possíveis para o desenvolvimento de um software para facilitar o entendimento do que precisa ser feito, ou seja, quebrar ainda mais as estórias. Geralmente o Grooming é realizado pelo PO e Scrum Master em uma reunião que antecede a Planning, mas há um ótimo ganho quando o mesmo é realizado por todo o time em tempo de desenvolvimento.

Informações relevantes para esse rito:

1. o intuito de quebrar estórias é facilitar a visualização dos to-dos (o que fazer), então quanto mais simples a leitura, melhor;
2. diferente do modelo Waterfall, na metodologia Scrum, o Backlog é mutável, um organismo vivo que pode sofrer mudanças ao longo do projeto. O Grooming proporciona informações relevantes quando houver alguma “change” no escopo do projeto.

Retrospective Sprint

Realizadas sempre ao final de cada Sprint Backlog é também aplicada nos finais de cada Release. Todos os team members de Squad participam e explicam como foi a Release our Sprint anterior respondendo a três perguntas básicas:

1. O que devemos continuar fazendo? (Pontos Positivos)
2. O que devemos parar de fazer? (Pontos Negativos)
3. O que devemos começar a fazer? (Plano de Ação)

Cada integrante da Squad tem o direito de responder as primeiras duas perguntas. Assim que finalizada a 1ª rodada de respostas, o time discute e traça a estratégia do Plano de Ação baseados nos pontos negativos encontrados. Neste rito, o Scrum Master/Teamlead é responsável por consolidar todas as informações e organizar o chamado QFQQ (Quem Faz o Quê e Quando).

Essa reunião é uma excelente oportunidade de entender como está o clima do time e colher feedbacks preciosos. Ou até mesmo, se for necessário, lavar aquela roupa suja que ficou “em aberto”, em algum momento durante o projeto.

Gestão Visual – Kanban

Um grande aliado da metodologia Ágil são os boards, que demonstram a fase de cada uma das estórias e features do Backlog Sprint. A forma em que é aplicada a gestão visual Kanban de um projeto pode ser feito através de ferramentas digitais (JIRA, Trello, Basecamp, entre outros) ou de forma manual. O intuito da gestão visual é que o time reconheça rapidamente quais são os principais problemas que atrasam o projeto como um todo.

Ambas as possibilidades demandam esforço perene de todo o time, ou seja, todos são responsáveis por manter atualizados os itens do Backlog Sprint. Sem o engajamento necessário, esse tipo de ferramenta pode se tornar facilmente obsoleto caso entre em desuso. 

Resumidamente, os ritos acima descritos, se aplicados gradativamente ao dia a dia de uma metodologia Waterfall, com certeza irão apresentar melhora de performance e entrega. O ideal é que independente da forma de gerenciamento de um projeto, seja mensurado o valor que isso traz, os benefícios e vantagens.

 

Referências:

https://www.projectbuilder.com.br/blog/guia-da-gestao-de-projetos-metodologia-waterfall/

https://www.desenvolvimentoagil.com.br/scrum/