Capacidade de adaptação é uma característica indispensável no cenário competitivo do mercado atual e, quando se trata de gerenciamento de projetos, a situação não é diferente. Principalmente em projetos relacionados a tecnologia, a Metodologia Scrum se tornou extremamente popular por ser um método ágil, dinâmico e funcional.
Nesse post você vai entender melhor a metodologia Scrum e como aplica-la corretamente na gestão de projetos. Siga lendo para aprender!
O que é metodologia scrum?
Metodologia Scrum é a prática ágil mais conhecida entre todas as existentes. Ela agrupa conceitos, práticas e ferramentas para gerenciar projetos, especialmente projetos de software.
Se você trabalha com tecnologia, é bem provável que já tenha ouvido falar da Metodologia Scrum. Isso porque ela foi criada especialmente para atender a projetos de desenvolvimento de software. Entretanto, com o tempo, a metodologia começou a ser aplicada em outros tipos de projeto, especialmente os que possuem um escopo pouco conhecido e há incertezas em relação aos requisitos.
O nome Scrum vem do Rugby e é referente ao trabalho em conjunto de um time para atingir um “goal”, que pode ser traduzido como gol ou objetivo, uma meta.
No Scrum, o trabalho de um projeto deve ser dividido em Sprints, que são pequenos ciclos de trabalho (de 2 a 6 semanas) que geram pequenas entregas. Essas entregas acrescentam um incremento ao produto final. Ou seja, ao fim de cada ciclo/Sprint, é entregue mais um “pedaço” do projeto. No caso de software, uma nova funcionalidade no produto.
As práticas do Scrum podem ser adaptadas ao contexto de cada organização. Entretanto, seus princípios ágeis dão a característica de que o escopo do projeto é planejado aos poucos conforme novas informações vão sendo conhecidas e o que já foi feito é entregue, testado e colocado em funcionamento.
Essa é a principal diferença do Scrum (e outros métodos ágeis) em relação às metodologias tradicionais. Se no método cascata, por exemplo, o escopo é totalmente planejado antes do início do projeto, no Scrum novos planejamentos são feitos conforme novos “pedaços” do projeto são entregues e disponibilizados ao cliente.
Vantagens do scrum
Descentralização do gerenciamento
Uma das partes principais do funcionamento do time no Scrum é que a equipe deve ser autônoma e auto gerenciável. Isso significa que há uma descentralização do gerenciamento, evitando sobrecarga de uma pessoa e permitindo tomadas de decisão mais colaborativas.
Além disso, as informações também ficam descentralizadas. Portanto, todos sabem o que se passa no projeto, de modo que ideias e sugestões podem surgir de toda a equipe. Assim, os membros da equipe ajudam uns aos outros e todos são capacitados para tomar decisões assertivas.
Ajuda na organização das atividades
No Scrum, todo o trabalho do projeto é dividido em ciclos (Sprints). Ao final de cada Sprint, quando é entregue uma nova parte do projeto, são feitas reuniões para revisar o que foi feito e planejar o próximo ciclo.
Todo esse processo ajuda a evitar que o trabalho do projeto se torne um caos e as atividades fiquem desorganizadas. Sendo assim, o Scrum ajuda manter a organização do trabalho e, por consequência, evita retrabalho, atrasos e perda de produtividade.
Ajuda a incorporar mudanças no escopo
Em metodologias preditivas, é mais difícil aplicar alterações no decorrer dos projetos. No Scrum, por sua vez, as mudanças e novidades no escopo são esperadas a, às vezes, até desejadas.
Sendo assim, a metodologia Scrum oferece flexibilidade suficiente para que o projeto seja adaptado a novas situações sem que seu andamento seja comprometido, de modo a tornar mais fácil a alteração de prioridades.
Ajuda a entregar um produto de qualidade
A metodologia Scrum traz uma série de práticas que ajudam a entregar um produto final de qualidade mesmo com as mudanças ocorridas ao longo de sua realização. Os eventos focados no planejamento e revisão dos processos são responsáveis por isso.
Ao término de cada Spint, é necessário entregar um produto utilizável que será validado pelo product owner (falaremos mais sobre isso a frente). Essa prática, assim como as reuniões para revisão e planejamento de atividades, impacta no resultado final do projeto, ajudando a entregar um produto de qualidade.
Como funciona a metodologia Scrum?
O funcionamento da metodologia Scrum envolve alguns papéis, artefatos, eventos e ferramentas. Vamos explicar cada um deles para que você entenda como tudo isso funciona:
Papéis
Product Owner
O Product Owner, ou simplesmente PO, é como um guardião dos interesses do usuário do produto. Ele pode ser o usuário do produto final ou alguém que represente esses usuários.
É o Product Owner quem decide as funcionalidades que serão ou não desenvolvidas e a ordem em que isso ocorrerá, além de manter a equipe informada sobre o desejado no desenvolvimento do projeto. Ele também é responsável por apontar melhorias no projeto e aprovar funcionalidades implementadas.
Ele também deve ajudar a esclarecer as dúvidas que a equipe pode vir a ter e, por tudo isso, deve estar envolvido diariamente com o time, promovendo comunicação e planejamento.
Scrum Master
O Scrum Master é um líder-servil para o time Scrum. Ele não possui autoridade sobre a equipe, mas sim sobre os processos. Sua principal responsabilidade é disseminar os valores, princípios e práticas do Scrum, de modo a auxiliar na adaptação da metodologia para o contexto em que o projeto está inserido.
O Scrum Master também deve ajudar o time a superar empecilhos que possam surgir durante a realização do projeto, assim como proteger a equipe de fatores que possam atrapalhar a produtividade. Ainda, o Scrum Master é um elo entre o trabalho do time e o Product Owner.
Development Team
O Development Team, como o próprio nome diz, é a equipe de desenvolvimento. Essa equipe deve conter entre três a nove pessoas e, se houver mais profissionais envolvidos no desenvolvimento, o ideal é criar vários times.
Uma quantidade muito grande de pessoas na mesma equipe favorece a desorganização e dificulta o autogerenciamento, o que faz com que se perca o essencial de uma equipe no Scrum.
Vale lembrar, também, que não há uma divisão exata de tarefas entre os membros do time. Toda nova demanda pode ser assumida por qualquer um que tenha maior disponibilidade de tempo e condições para realiza-la.
Scrum Team
Scrum Team ou Time Scrum é toda a equipe envolvida no projeto: o product owner, o scrum master e o development team. Não há tarefas exclusivas e nem hierarquia na equipe; todos trabalham conjuntamente para entregar tudo o que foi acordado para aquela Sprint.
Dependendo do contexto em que o projeto está inserido, pode ser necessário criar outros papéis além desses que estão determinados pela metodologia.
Artefatos
Product Backlog
O Backlog de um produto/projeto é uma lista de entregas a serem feitas ao longo do projeto. No caso de projetos de software, é uma lista de funcionalidades. Essas entregas têm prioridades específicas e pequenas descrições.
Os requisitos no Product Backlog não devem ser excessivamente detalhados, pois isso poderia gerar um grande consumo de tempo e geração de documentos, indo contra os princípios ágeis do Scrum. Na verdade, os requisitos devem ser detalhados apenas até a definition of ready, ou seja, até que os detalhes sejam suficientes para que aquela entrega comece a ser desenvolvida.
Quem dá a palavra final sobre o que deve ou não estar no product backlog e sobre a priorização de cada entrega é o Product Owner.
Sprint Backlog
O Sprint Backlog é o conjunto de entregas que serão feitas em uma Sprint. Cada Sprint Backlog é elaborado com requisitos presentes no Product Backlog. Sendo assim, em cada Sprint é desenvolvido um grupo de requisitos que estavam no backlog do produto.
Diferentemente do product backlog, o Sprint Backlog não pode sofrer alterações, a não ser que se trate de um requisito equivocado ou que pode causar algum erro no projeto. Nesse caso, esse requisito deve ser paralisado, mas não substituído. Entretanto, no geral, aquilo que foi planejado para a Sprint deve ser realizado.
Definition of Ready
Definition of Ready é o nível ideal de detalhamento de um requisito. Quando dizemos que um requisito foi detalhado até o Definition Of Ready, estamos dizendo que ele foi definido até o ponto em que o time possui todas as informações necessárias para começar a trabalhar naquela entrega. Ou seja, Definition Of Ready é o ponto onde já existem informações suficientes para que um requisito comece a ser desenvolvido.
Definition of Done
O definition of done indica os critérios de aceite da entrega. Quando uma entrega atendeu a todos os critérios de aceite, podemos dizer que ela pode ser considerada concluída e, portanto, atingiu definition of done.
Preste atenção: a definition of ready indica que um requisite está suficientemente detalhado para começar a ser desenvolvido, enquanto que a definition of done indica que o trabalho está concluído.
Eventos
Sprint planning meeting
Sprint Planning é a reunião que antecede uma Sprint. Ela é dividida em duas partes e todos os membros (Product Owner, Scrum Master, Scrum Team e Development Team) participam dela.
Na primeira parte, são selecionados e detalhados os requisitos que vão compor a Sprint. Na segunda parte, cada item colocado na Sprint tem seu tempo estimado e é decomposto em tarefas necessárias para sua entrega.
Daily Scrum Meeting
A Daily Scrum Meeting é uma reunião diária que o Scrum Team realiza para se manter alinhado sobre o andamento do projeto. Essa reunião não deve durar mais do que 15 minutos e, por isso, o ideal é que todos fiquem de pé, para evitar que os participantes se acomodem e alonguem a reunião.
No daily scrum, cada membro do time deve responder às seguintes perguntas:
- O que você fez no dia anterior?
- O que você fará hoje?
- Existe algum impedimento para a realização das suas atividades?
Se algum impedimento for citado na daily scrum, é dever do Scrum Master remover esse empecilho do caminho do projeto. No caso de o Scrum Master não ser capaz de fazer isso sozinho, ele deve garantir que alguém do time o ajude nessa missão.
Sprint Review Meeting
A Sprint Review ocorre quando a Sprint termina. Ela serve para mostrar ao product owner as novas entregas feitas ou funcionalidades implementadas, no caso de software. Sendo assim, seu objetivo é averiguar e adaptar o produto que está sendo construído. Trata-se de um evento informal com duração máxima de 4 horas.
Sprint Retrospective
A Sprint Retrospective ocorre logo em seguida da Sprint Review. Aqui, é analisado o trabalho que foi feito e são discutidas ideias para melhoria dos processos nas próximas Sprints. Ou seja, ao invés de analisar as funcionalidades implementadas, como na Sprint Review, são revisados os processos executados.
Nessa reunião, cada membro do time scrum especifica comportamentos que os membros devem começar a ter, parar de ter e continuar a ter no decorrer do trabalho do projeto.
Ferramentas
Burndown Chart
O Burndown Chart é um gráfico que indica as tarefas que precisam ser feitas e o tempo disponível para tal. E serve para verificar atrasos com mais facilidade. O gráfico deve ser atualizado todos os dias para que possa ser acompanhado o progresso das atividades.
Kanban Board
O Kanban é um quadro que ajuda a organizar as atividades e controlar o andamento de cada uma delas. São utilizados cartões (geralmente post-its) com os nomes de cada tarefa. Esses cartões são agrupados em colunas que indicam o status daquelas atividades, que normalmente é fazer, fazendo ou feito.
Cada vez que uma tarefa muda de status, seu cartão deve ser movido para outra coluna que indique seu novo estágio. A principal vantagem dessa ferramenta é que ela facilita a comunicação e a organização, possibilitando que todos possam ver o andamento de cada atividade olhando para o quadro.
Ainda, é importante lembrar que o Scrum não é a única metodologia ágil de gestão de projetos, apesar de ser a mais conhecida. É importante escolher a metodologia que melhor se aplica às necessidades dos projetos da empresa. Para saber mais sobre outras metodologias ágeis, assista ao webinar: Ágil é mais que SCRUM: Metodologias Ágeis preenchendo o formulário abaixo!
Existe algum documento que posso usar quando o projeto for paralisado ??