fbpx
Search
Close this search box.
Search
Close this search box.
Início Jobzera Gestão ágil de projetos com Scrum

Gestão ágil de projetos com Scrum

por Julie Soares
1,2K visualizações

Gerencie com elasticidade e produtividade

O Scrum é um método ágil que ajuda a gerenciar projetos e a criar novos produtos de maneira eficiente e colaborativa. Ele se concentra em uma abordagem iterativa e incremental, em que as equipes trabalham em pequenos ciclos de desenvolvimento, chamados de sprints. Ao final de cada sprint, a equipe entrega um produto funcional e revisa o trabalho realizado para melhorar o próximo sprint.

Neste artigo nós vamos ver:
  • Fundamentos dos métodos ágil
  • Fundamentos do Scrum
  • Aplicação do Scrum

Fundamento dos métodos ágeis

O manifesto ágil

O manifesto ágil é composto por duas partes: os valores ágeis e os princípios ágeis. Ele não é um método ou metodologia de gerenciamento, mas sim uma declaração de crenças e valores que guiam as práticas de desenvolvimento ágil de software.

Os valores ágeis incluem o indivíduo e as interações, o software em funcionamento, a colaboração com o cliente e a resposta às mudanças.

Já os princípios ágeis incluem a satisfação do cliente através da entrega contínua e rápida de software de valor, a aceitação de mudanças nos requisitos, a entrega de software funcionando com frequência, a colaboração entre o cliente e a equipe de desenvolvimento, o estímulo ao desenvolvimento sustentável e contínuo, a atenção à excelência técnica e ao design simples, a auto-organização da equipe e a reflexão constante para melhorar o desempenho.

Valores do manifesto ágil

1. Indivíduos e interações mais que processos e ferramentas

Esse valor do Manifesto Ágil ressalta a importância das pessoas em uma equipe de desenvolvimento de software.

Afinal, são elas que, com suas habilidades e características únicas, criam os produtos e serviços. Não se trata apenas de seguir diagramas e processos, mas sim de valorizar as pessoas envolvidas no trabalho e permitir que elas atuem de forma colaborativa.

Os processos devem servir como uma ferramenta para auxiliar a equipe, e não como uma imposição que as engessa. Dessa forma, é possível criar um ambiente de trabalho mais humano e produtivo.

2. Software em funcionamento mais que documentação abrangente

O valor “Software em funcionamento mais que documentação abrangente” destaca a importância de focar na entrega de um software que realmente funcione e atenda às necessidades do cliente, em vez de se concentrar apenas em documentação detalhada. É importante lembrar que, embora a documentação possa ser útil, ela não substitui um software em pleno funcionamento como evidência de que um trabalho valioso foi realizado.

No entanto, não devemos interpretar esse valor como uma desculpa para não documentar o projeto. A documentação pode ser importante para ajudar a equipe a desenvolver o software, mas deve ser produzida apenas na quantidade necessária para o trabalho ser realizado. Não faz sentido gastar tempo e recursos em documentação abrangente que não será útil para a entrega do produto final.

Portanto, o objetivo é encontrar um equilíbrio entre ter um software funcional e uma documentação adequada para ajudar na sua construção, mas sem gastar mais tempo e recursos do que o necessário.

3. Colaboração com o cliente mais que negociação de contratos

Nas metodologias ágeis, a colaboração com o cliente é fundamental e valorizada, não há distinção entre “nós” e “eles”, todos trabalham juntos em busca do mesmo objetivo: desenvolver um software de valor para o cliente. Essa colaboração envolve um relacionamento de companheirismo, tomada de decisões conjunta e comunicação ágil e eficiente, tornando muitas vezes a necessidade de adendos contratuais desnecessários. O foco é atender as necessidades do cliente de forma ágil e efetiva, através da participação ativa de todos os envolvidos no processo.

4. Responder a mudanças mais que seguir um plano

Em projetos de software, é importante estar preparado para lidar com mudanças. Por isso, é necessário encontrar um equilíbrio entre planejar e se adaptar. Em projetos com alta incerteza, é fundamental ser ágil e capaz de mudar rapidamente. O desenvolvimento de software envolve muita incerteza, então é preciso ser flexível e estar aberto a mudanças. Embora planejar seja importante, seguir um plano ultrapassado pode prejudicar o sucesso do projeto. Por isso, é necessário estar disposto a responder a mudanças e adaptar o plano conforme necessário.

 

Leia também o artigo relacionado:

Como definir um modelo de gestão em agências e ambientes complexos

Princípios do manifesto ágil

1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

O foco no desenvolvimento do produto está na satisfação dos clientes. Gera-se, desde cedo e frequentemente, retorno ao investimento dos clientes no projeto a partir da entrega de partes do produto que atendam às suas necessidades. Esse princípio se opõe à prática de se seguir um plano detalhado, sugerindo que a prioridade está em se adaptar e buscar, em cada momento, o que de fato trará valor aos clientes, para entregar-lhes o mais cedo e frequentemente possível.

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.

Um dos princípios fundamentais do Scrum é aceitar mudanças de requisitos, mesmo que seja no fim do desenvolvimento. Isso significa que o processo ágil se adequa a mudanças para que o cliente possa tirar vantagens competitivas. É importante entender que mudanças são naturais no processo de desenvolvimento do produto, e não devem ser tratadas como algo negativo. Na verdade, trabalhar em ciclos curtos de feedback permite que os clientes possam acompanhar a evolução do produto à medida que entendem melhor suas necessidades. Então, ao invés de considerar as mudanças como custosas e indesejadas, o Scrum encoraja a adaptação às necessidades do cliente para melhor atendê-lo.

3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

Este princípio do desenvolvimento ágil incentiva a entrega frequente de partes funcionais do software aos clientes e usuários em um curto período de tempo, que pode variar de semanas até meses. Isso traz benefícios para o cliente, que já começa a ter retorno do investimento desde o início do projeto, e também para a equipe, que pode receber feedback sobre o que já foi entregue e adaptar o produto às necessidades do cliente com mais agilidade. Dessa forma, o risco de entregar algo que o cliente não vai utilizar é reduzido. É importante ressaltar que esse princípio é contrário à ideia de realizar uma única grande entrega apenas no final do projeto.

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

Esse princípio tem como objetivo unir as pessoas envolvidas no projeto, sejam elas ligadas ao negócio ou desenvolvedores, em torno de um objetivo comum: garantir a geração de valor para os clientes. Isso é feito através de uma cooperação contínua durante todo o projeto, com interações frequentes.

Dessa forma, evita-se a situação comum de antagonismo entre as pessoas de negócios e os desenvolvedores, que muitas vezes não se comunicam e estão em lados opostos.

A colaboração e a comunicação constante são fundamentais para o sucesso de um projeto de desenvolvimento de software.

5. Construir projetos ao redor de indivíduos motivados, Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

Construir projetos em torno de pessoas motivadas, oferecendo-lhes um ambiente e suporte adequados e confiando em sua capacidade de realizar o trabalho, é fundamental para o sucesso do projeto. Afinal, são as pessoas que constroem o produto. Este princípio se opõe à ideia de que o produto é construído apenas com as melhores ferramentas e processos, sem considerar as pessoas envolvidas.

A melhor maneira de transmitir informações dentro de uma equipe de desenvolvimento é através da comunicação face a face. É uma forma direta, síncrona e enriquecida pela entonação de voz, olhar e linguagem corporal, entre outros fatores. Quando não é possível a comunicação presencial, como em um projeto distribuído, é importante utilizar da melhor forma possível a tecnologia disponível para se aproximar do modelo presencial.

6. Software funcional é a medida primária de progresso

O progresso do projeto ocorre à medida que partes do produto que tragam valor ao cliente são entregues. Esse princípio se opõe à prática de se gerar artefatos como protótipos e extensos documentos de planos e especificações e, assim, acreditar que se progrediu no projeto.

7. O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara

A comunicação cara a cara é direta, síncrona e enriquecida pela entonação de voz, olhar e linguagem corporal, entre outros fatores, sendo a melhor forma de comunicação entre membros do time de desenvolvimento e o mundo externo. Quando a comunicação presencial não é viável (em um projeto distribuído, por exemplo), é uma boa prática fazer o melhor uso possível da tecnologia disponível para se aproximar da comunicação. Esse princípio se opõe à utilização de documentos, e-mails, telefone e teleconferência, entre outros, como formas padrão de comunicação em um projeto.

8. devem ser capazes de manter indefinidamente, passos constantes

O objetivo desse princípio é manter um ritmo de trabalho constante e sustentável para o time de desenvolvimento de software. Para isso, é importante que todas as partes envolvidas no projeto estejam comprometidas em manter esse ritmo, incluindo usuários e patrocinadores. É importante evitar exigir do time mais trabalho do que ele é capaz de produzir, o que muitas vezes leva a práticas como horas extras, trabalho em fins de semana e pressa excessiva para cumprir prazos de entrega. Essas práticas podem resultar em insatisfação dos membros do time, menor produtividade e qualidade inferior do produto final. Portanto, é fundamental que o ritmo de trabalho seja mantido em um nível que possa ser sustentado a longo prazo, para garantir a qualidade do produto e a satisfação dos membros da equipe.

9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

Manter uma atenção constante à excelência técnica e ao bom design é fundamental para aumentar a agilidade do processo de desenvolvimento do produto. Quando o produto é projetado e produzido com qualidade e excelência técnica, é mais fácil modificá-lo e aceitar mudanças como algo natural no processo de desenvolvimento. Isso é essencial para manter a agilidade do projeto. É importante destacar que esse princípio se opõe à ideia de que a qualidade deve ser sacrificada em prol da velocidade e da flexibilidade no desenvolvimento do produto.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito

O princípio da simplicidade busca evitar o desperdício no desenvolvimento do produto ao não se realizar trabalho que não é necessário. Isso inclui não desenvolver funcionalidades que os clientes não precisam ou soluções desnecessariamente complexas. Além disso, é importante evitar um planejamento excessivamente detalhado ou documentos extensos que não agregam valor ao produto. Esse princípio se opõe à crença de que o sucesso do projeto depende de uma quantidade significativa de trabalho e documentação.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis

Equipes auto-organizáveis tendem a produzir as melhores arquiteturas, requisitos e designs. Isso ocorre porque essas equipes têm maior autonomia e liberdade para decidir a melhor forma de realizar o trabalho em direção às metas acordadas. Com essa autonomia, os membros da equipe são responsáveis por seus próprios resultados e se sentem mais motivados e engajados no trabalho. Dessa forma, a equipe é capaz de produzir um produto melhor, atendendo às necessidades do cliente de forma mais eficiente.

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo

Através dessa prática de inspeção e adaptação contínuas, a equipe consegue identificar pontos de melhoria em seu trabalho e promover uma melhoria constante em seu processo de desenvolvimento. Esse princípio reforça a importância de uma cultura de aprendizado e de uma mentalidade voltada para a busca constante de aprimoramento.

Fundamentos do Scrum

Definição do Scrum

Scrum é um framework ágil dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

O framework Scrum consiste de times Scrum associados a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum

As regras do Scrum integram os papéis, eventos e artefatos, administrando as relações e interações entre eles.

Princípios do Scrum

Papéis
Papéis centrais do Scrum: Dono do Produto, Scrum Master e Time Scrum.

Controle de processos empíricos
Três ideias principais: transparência, inspeção e adaptação.

Auto-organização
Pessoas motivadas a compartilhar responsabilidades, gerando um ambiente mais criativo e innovador, mais propício ao crescimento.

Cobraboração

É um processo de criação de valor compartilhado que precisa de todos os Stakeholders, trabalhando e interagindo em conjunto para garantir o maior valor. Também enfoca as dimensões fundamentais dotrabalho colaborativo: consciência, articulação e apropriação.

Priorização baseada em valor
Entregar o máximo de valor de negócio em um período de tempo mínimo.

Time-boxing
O SCRUM trata o tempo como uma restrição limitante. Todas essas reuniões são Time-boxed.

Desenvolvimento iterativo
O desenvolvimento iterativo ajuda a gerenciar melhor as mudanças e construir produtos que satisfaçam as necessidades dos clientes.

Controle de processos empíricos

O Scrum é um framework ágil para gerenciamento de projetos que se baseia no controle de processos empíricos pela transparência, inspeção e adaptação.
Esses três pilares são fundamentais para o sucesso do Scrum, pois permitem que o time de desenvolvimento trabalhe de forma colaborativa, com foco no resultado final.

Em conjunto, esses três pilares ajudam a promover uma cultura de aprendizado contínuo e a garantir que o produto final seja entregue de forma eficiente e eficaz.

Transparência

A transparência requer que aspectos significativos do processo devem ser visíveis para aqueles que são responsáveis pela sua execução. Isso ajuda a garantir que as informações importantes sejam compartilhadas e que todos entendam o que está acontecendo no projeto.

  • Declaração da Visão do Projeto clara e acessível, que possa ser vista por todos.
  • Backlog Priorizado do Produto aberto, com Estórias de Usuário priorizadas
  • Cronograma de Planejamento da Release
  • Utilizar ferramentas como um Scrumboard, Gráfico Burndown e outras fontes de informação relevantes.
  • Realização de Reuniões Diárias diárias,
  • Realizar Reuniões de Revisão do Sprint.

Inspeção

A inspeção refere-se ao ato de inspecionar o trabalho e o progresso em relação aos objetivos. A inspeção deve ser feita com frequência e de forma criteriosa para identificar problemas e desvios em relação ao planejamento inicial.

  • Reunião Diária
  • Identificação de riscos
  • Refinamento do Backlog do Produto
  • Demonstrar e Validar a sprint
  • Solicitações de Mudança,
  • Refinamento do Backlog
  • Processo de Retrospectiva do Sprint
  • A Reunião de Retrospectiva do Projeto

Adaptação

A adaptação envolve a mudança no comportamento para lidar com as informações obtidas por meio da inspeção e garantir que o objetivo seja alcançado.

  • Uso de um Scrumboard comum
  • Completar as tarefas do Sprint atual.
  • Coletar feedback dos clientes e de outros stakeholers
  • Criar Épicos, Backlog Priorizado do Produto e Conduzir o Planejamento da Release.
  • Inspeção e aprovação das entregas, feitas pelo Dono do Produto e pelo cliente no processo deDemonstrar e Validar o Sprint.

Desenvolvimento Iterativo

No Scrum, o foco é na construção iterativa do produto, começando pelas partes mais valiosas e arriscadas, para que a cada Sprint haja um incremento no produto.

Isso significa que a cada ciclo, é possível ter um pedaço do produto pronto para uso. Quando se alcança o número suficiente de incrementos, o produto está pronto para ser entregue aos investidores.

Mas engana-se quem pensa que o Scrum é um método sem planejamento ou que requer menos esforço nessa área. Na verdade, o planejamento no Scrum é feito de forma iterativa e incremental, sendo realizado em cada reunião de revisão e planejamento de Sprint, além das reuniões diárias.

O esforço dedicado ao planejamento é constantemente atualizado e adaptado às mudanças ao longo do tempo, o que não acontece no modelo tradicional.

Aplicação do Scrum

O Scrum é um framework simples, mas altamente eficaz, que permite ao time de desenvolvimento trabalhar de forma colaborativa, iterativa e flexível, focando na entrega de valor ao cliente. Com os três pilares do Scrum – transparência, inspeção e adaptação – o time é capaz de lidar com mudanças, imprevistos e incertezas, promovendo a melhoria contínua e a excelência no desenvolvimento de software.

1. Papéis e responsabilidades

No Scrum, existem três papéis principais: o Product Owner, o Scrum Master e o Time de Desenvolvimento. Cada um deles possui responsabilidades específicas que garantem o sucesso do projeto.

a. Scrum Master

O Scrum Master é o responsável por garantir que o processo do Scrum seja aplicado corretamente, de modo a maximizar os resultados do time. Ele atua como facilitador, ajudando o time a entender e seguir as regras do Scrum, além de remover quaisquer obstáculos que possam impedir o progresso da equipe. O Scrum Master não é o líder do time, mas sim um coach que ajuda a equipe a ser autogerenciável.

b. Dono do Produto

O Dono do Produto é a pessoa que representa os interesses do cliente e dos usuários finais do produto. Ele é responsável por gerenciar o backlog do produto, ou seja, a lista de funcionalidades, requisitos e melhorias que devem ser desenvolvidos pela equipe. O Dono do Produto também define as prioridades do backlog do produto, decidindo o que será implementado em cada Sprint. Ele trabalha em conjunto com o Time de Desenvolvimento para garantir que as necessidades dos clientes sejam atendidas.

c. Time de Desenvolvimento

Por fim, o Time de Desenvolvimento é o grupo de profissionais responsável por criar o produto. Ele é composto por desenvolvedores, testadores, analistas e outras funções que sejam necessárias para construir o produto. O Time de Desenvolvimento é autogerenciável, o que significa que ele deve decidir como trabalhar para atender as metas da Sprint. A equipe é encorajada a colaborar e se auto-organizar, a fim de garantir a qualidade do produto e a entrega dentro dos prazos estabelecidos.

2. Artefatos

a. Visão do Produto

É uma descrição de alto nível do que se espera que o produto entregue pelo projeto seja. É importante para garantir que todos os envolvidos no projeto tenham uma compreensão comum do que está sendo desenvolvido e por que é importante.

b. Backlog do Produto

É uma lista ordenada de tudo o que é necessário para que o produto final seja entregue. Ele é gerenciado pelo Product Owner e é atualizado constantemente à medida que o projeto evolui. O Backlog do Produto é a base para a criação do Backlog da Sprint.

c. Backlog da Sprint

É uma lista de tarefas que a equipe de desenvolvimento precisa realizar durante a Sprint para que possa entregar o incremento esperado. É criado durante o planejamento da Sprint e é atualizado diariamente.

d. Incremento

É a soma de todas as tarefas concluídas durante a Sprint e representa o progresso que foi feito na entrega do produto final. O objetivo de cada Sprint é entregar um incremento que possa ser utilizado pelos usuários finais.

e. Histórias de usuários

São descrições curtas e simples de funcionalidades que o produto deve ter, escritas do ponto de vista do usuário final. São utilizadas para definir o Backlog do Produto e o Backlog da Sprint.

f. Definição de Pronto

Definição de pronto: é um conjunto de critérios que a equipe de desenvolvimento deve atender para que uma tarefa possa ser considerada como “concluída”. A Definição de Pronto ajuda a garantir que todas as tarefas entregues durante a Sprint estejam concluídas e prontas para uso.

g. Quadro de Tarefas

Scrum Task Board: é uma representação visual das tarefas do Backlog da Sprint, organizadas em colunas de acordo com o seu status. É utilizado para monitorar o progresso do trabalho durante a Sprint e para garantir que todas as tarefas sejam concluídas dentro do prazo.

h. Burndown chart

É um gráfico que mostra a quantidade de trabalho restante na Sprint em relação ao tempo. É utilizado para monitorar o progresso do trabalho e para garantir que a equipe esteja no caminho certo para entregar o incremento esperado no final da Sprint.

3. Eventos

a. Sprint

O Sprint é um evento fundamental do Scrum e define um período de tempo limitado em que um conjunto de atividades é executado para produzir um incremento de produto. O Sprint é um período de tempo fixo, geralmente de duas a quatro semanas, no qual o Time Scrum se dedica a trabalhar na entrega do incremento do produto.

b. Reunião de Planejamento

Na Reunião de Planejamento da Sprint, o Time Scrum se reúne para discutir e planejar o trabalho que será realizado durante o Sprint. É o momento em que o Product Owner apresenta o backlog do produto, o Time Scrum decide qual trabalho será realizado durante o Sprint e estabelece a meta da Sprint.

c. Reunião diária

A Reunião Diária é uma reunião rápida de 15 minutos que acontece diariamente durante o Sprint. Nela, o Time Scrum se reúne para discutir o progresso do trabalho, identificar problemas e ajustar o plano para o dia seguinte. É uma oportunidade para o Time Scrum se manter sincronizado e garantir que o trabalho esteja progredindo conforme o planejado.

d. Retrospectiva da Sprint

Na Revisão da Sprint, o Time Scrum se reúne para apresentar o incremento do produto concluído durante o Sprint para o Product Owner e outras partes interessadas. É uma oportunidade para obter feedback sobre o produto e planejar as próximas atividades a serem realizadas.

Os eventos do Scrum são essenciais para manter o Time Scrum alinhado e garantir que o trabalho esteja progredindo de maneira eficiente e eficaz. É importante que todos os membros do Time Scrum participem ativamente de todos os eventos para garantir o sucesso do projeto.

Conceito Time Boxing

O time boxing é um conceito importante no framework Scrum e em outros métodos ágeis. Ele consiste em definir um tempo máximo para a realização de atividades, como reuniões, sprints, entre outros eventos. Isso permite que a equipe se concentre nas tarefas a serem realizadas, evitando desperdício de tempo e aumentando a produtividade.

Existem dois tipos de time boxing: duração fixa e duração máxima. No primeiro, o evento tem um tempo determinado e, se todo o trabalho previsto for finalizado antes do fim do tempo, mais trabalho pode ser adicionado. Já no segundo, o evento tem uma duração máxima e é encerrado assim que todo o trabalho previsto for concluído.

As vantagens de usar o conceito de time boxing são muitas. Ele ajuda a manter as reuniões mais focadas e objetivas, evita o desperdício de tempo e aumenta a produtividade da equipe. Além disso, permite que a equipe tenha uma melhor noção da velocidade de trabalho e do que pode ser entregue em cada sprint.

Em resumo, o time boxing é uma técnica muito importante para maximizar a eficiência do trabalho em projetos Scrum e em outras abordagens ágeis. Com ele, é possível manter a equipe focada, otimizar o tempo de trabalho e aumentar a produtividade.

War Room

Na metodologia Scrum, os eventos são momentos muito importantes de comunicação entre o time. E, para que esses eventos aconteçam de forma eficiente, é fundamental que o ambiente esteja adequado para a realização de cada um deles. Nesta aula, vamos aprender como escolher o local ideal para o time.

O Scrum recomenda que o time esteja localizado em um mesmo ambiente de trabalho, também conhecido como Sala de Guerra ou War Room. Esse espaço deve ser projetado de forma que os membros do time possam se comunicar facilmente, circular livremente e trabalhar em conjunto. Apesar de ser um local barulhento, devido às conversas constantes, esse “barulho” é o que chamamos de comunicação osmótica e é extremamente importante para o progresso do projeto e do time. Afinal, quando duas pessoas conversam sobre um problema, outra pessoa pode ouvir e contribuir para a solução.

A Sala de Guerra ideal não deve possuir divisórias e deve permitir que o time se sente junto para garantir a comunicação cara-a-cara. É importante que todos estejam confortáveis e que haja espaço suficiente para todos.

No entanto, em grandes projetos, pode ser difícil reunir todos os membros em um mesmo local. Nesse caso, é necessário fazer o melhor uso possível das ferramentas de comunicação para facilitar a interação entre todos os membros. O uso de ferramentas de vídeo-chamada como Skype, Hangout e outras é altamente recomendado para manter a equipe alinhada e garantir o sucesso do projeto.

Os Processos Scrum

Cada das dessas fases do processo Scrum incluem suas entradas, ferramentas e saídas. Essas fases são essenciais para o sucesso da implementação do Scrum em qualquer organização.

Durante cada processo, algumas entradas, ferramentas e saídas são necessárias e outras são opcionais, dependendo das particularidades do projeto, organização ou indústria. No entanto, é importante destacar que as entradas, ferramentas e saídas indicadas como obrigatórias são cruciais para o sucesso do Scrum.

Essas fases do Scrum são importantes para garantir que as equipes possam colaborar e trabalhar juntas de forma eficaz para atingir os objetivos do projeto. É importante que todas as partes envolvidas entendam o processo para garantir que o projeto seja concluído com sucesso.

1. Início

1.1. Criar a Visão do Projeto

Serve como base para o desenvolvimento dos Épicos. Reuniões do Grupo de Usuários podem ser realizadas para discutir Épicos apropriados.

1.2. Identificar o Scrum Master e o(s) Stakeholder(s)

O Scrum Master e o(s) Stakeholder(s) são identificados com base em critérios específicos.

1.3. Formar o Time Scrum

Neste processo, os membros do Time Scrum são identificados. Normalmente, o Dono do Produto é o responsável por selecionar os membros do time, mas pode contar com a ajuda do Scrum Master.

1.4. Desenvolver os Épicos

Serve como base para o desenvolvimento dos Épicos. Reuniões do Grupo de Usuários podem ser realizadas para discutir Épicos apropriados.

1.5. Criar o Backlog Priorizado do Produto

Nesse processo, Épicos são refinados, processados e, em seguida, priorizados, para que um Backlog Priorizado do Produto seja criado para o projeto. Os Critérios de Pronto também são estabelecidos neste momento.

1.6. Conduzir o Planejamento da Releas

O time Central do Scrum revisa as Estórias de Usuário no Backlog Priorizado do Produto para desenvolver um Cronograma de Planejamento da Release, que é essencialmente um cronograma de implementação faseado que pode ser compartilhado com os stakeholders do projeto. A Duração do Sprint também é determinada neste processo.

2. Planejar e Estimar

2.1. Criar as Histórias de Usuário

Neste processo, as Histórias de Usuário são criadas juntamente com seus critérios de aceitação. Geralmente, é o Dono do Produto quem escreve as Histórias de Usuário, garantindo que os requisitos do cliente estejam claros e compreensíveis por todos os interessados. O Time Scrum pode participar de exercícios de escrita de Histórias de Usuário. As Histórias de Usuário são incorporadas ao Backlog Priorizado do Produto.

2.2. Aprovar, Estimar, e Comprometer as Estórias de Usuário

Neste processo, o Dono do Produto aprova as Histórias de Usuário para o Sprint. Em seguida, o Scrum Master e o Time Scrum estimam o esforço necessário para realizar as funções descritas em cada História de Usuário e o Time Scrum compromete-se a entregar os requisitos do cliente sob a forma de Histórias de Usuário Aprovadas, Estimadas e Comprometidas.

3. Implementar

3.1 Criar os Entregáveis

Neste processo, o Time Scrum trabalha duro nas tarefas do Backlog do Sprint para criar os Entregáveis do Sprint. É comum utilizar um Scrumboard para acompanhar o trabalho e as atividades que estão sendo realizadas. Se houver questões ou problemas, o Time Scrum pode atualizá-los no Registro de Impedimentos.

3.2. Reunião diária

A Reunião Diária é outro processo fundamental no Scrum. Essa reunião diária é realizada em um tempo limitado e altamente focado chamado de Reunião Diária. É o momento em que os membros do Time Scrum podem atualizar uns aos outros sobre seus progressos e quaisquer impedimentos que possam estar enfrentando. Essa reunião ajuda a manter todos no caminho certo e a resolver problemas rapidamente.

3.3. Criar o Backlog do Refinamento do Backlog Priorizado do Produto Sprint

É um processo contínuo que deve ser realizado regularmente. É essencial que o Backlog Priorizado do Produto seja atualizado e mantido de forma adequada. Em uma Reunião de Revisão do Backlog Priorizado do Produto, as mudanças ou atualizações no Backlog podem ser discutidas e incorporadas adequadamente ao Backlog Priorizado do Produto.

4. Revisão e Restrospectiva

4.1 Convocar o Scrum dos Scrums

Neste processo, os representantes do Time Scrum são convocados para as Reuniões do Scrum de Scrums (SoS), em intervalos pré-determinados ou conforme necessário, para colaborar e acompanhar seus respectivos progressos, impedimentos e as dependências entre si. Esse processo é relevante apenas em projetos grandes onde vários Times Scrum estão envolvidos.

4.2. Demonstrar e Validar o Sprint

Neste processo, o Time Scrum apresenta os Entregáveis do Sprint ao Dono do Produto e aos stakeholders relevantes, em uma Reunião de Revisão do Sprint. O objetivo dessa reunião é garantir a aprovação e aceitação do Dono do Produto para os Entregáveis desenvolvidos no Sprint. 

 4.3 Retrospectiva do Sprint

Retrospectiva do Sprint—Neste processo, o Scrum Master e o Time Scrum se reúnem para discutir as lições aprendidas durante o Sprint. Essa informação é documentada como lições aprendidas, que poderão ser aplicadas em Sprints futuros. Muitas vezes, como resultado dessa reunião, podem ocorrer Pontos de Melhoria Acordados ou Recomendações do Scrum Guidance Body Atualizadas.

5. Release

5.1 Enviar os Entregáveis

Todos os membros do Time Scrum entregam ou transferem os Entregáveis Aceitos para os stakeholders relevantes. É importante que seja feito um acordo formal chamado de Contrato de Prestação de Trabalho, para documentar a finalização bem-sucedida do Sprint.

5.2. Retrospectiva do Projeto

Já no processo de Retrospectiva do Projeto, que marca a conclusão do projeto, os stakeholders e o Time Central do Scrum se reúnem para fazer uma análise retrospectiva do projeto e identificar, documentar e internalizar as lições aprendidas. Essas lições podem levar à documentação de Pontos de Melhoria Acordados, que serão implementados em projetos futuros. É fundamental aprender com as experiências anteriores e aplicar esse conhecimento em futuros projetos para garantir uma melhoria contínua no processo de desenvolvimento.

Resumo das responsabilidades

Dono do Produto

• Criar os requisitos iniciais gerais do projeto e manter o projeto em andamento
• Nomear as pessoas adequadas para os papéis de Scrum Master e Time Scrum
• Fornecer os recursos financeiros para o início do projeto e durante o seu andamento
• Determinar a Visão do Projeto
• Avaliar a viabilidade e garantir a entrega do produto ou serviço
• Garantir a transparência e e clareza dos itens do Backlog Priorizado do Produto
• Decidir o conteúdo mínimo para release comercial
• Fornecer os Critérios de Aceitação para as Estórias de Usuário a serem desenvolvidas em um Sprint
• Inspecionar as entregas
• Decidir a duração do Sprint

Scrum Master

• Garantir que os processos do Scrum sejam corretamente seguidos por todos os membros

do time, incluindo o Dono do Produto
• Assegurar que o desenvolvimento do produto ou serviço está ocorrendo sem problemas e que os membros do Time Scrum tem todas as ferramentas necessárias para a realização do trabalho
• Supervisionar a Reunião de Planejamento da Release e agendar as outras reuniões

Conclusão

Neste artigo, exploramos a metodologia ágil Scrum e suas diversas práticas e processos. Vimos como o Scrum pode ser aplicado em diferentes projetos e equipes, trazendo maior eficiência e produtividade aos processos de desenvolvimento. Aprendemos sobre os papéis essenciais dentro de um Time Scrum e como cada um contribui para o sucesso do projeto. 

Além disso, discutimos a importância da transparência, inspeção e adaptação contínuas, fundamentais para a melhoria contínua e para garantir que o projeto esteja sempre alinhado às necessidades do cliente. Esperamos que este eBook tenha sido útil para você, que agora tem uma visão clara e detalhada do Scrum e suas práticas. 

 

Leia também o artigo relacionado:

Mindfulness: A prática essencial para uma vida mais consciente e equilibrada

Você pode gostar

bala-elastica-logotipo-htb

Descubra um mundo de conteúdos peculiares sobre Branding, Sustentabilidade, Viagens, Cultura e Mercado de Trabalho na Bala Elástica – seu drops de inspiração digital!

Contato

© 2023 – Bala Elástica. Todos os direitos reservados. Projetado e Desenvolvido por Bala Elástica