Como Scrum: Um Guia Prático

  • Na atual indústria de TI, o conceito de Agile tornou-se bastante popular. Todo mundo está falando. Quase todas as empresas de TI adotaram algum nível de agilidade.

    Canvas do processo Scrum – Paradigma Visual

    Existem também muitos métodos sob a égide do desenvolvimento ágil, incluindo Extreme Programming (XP), Scrum, Crystal Methods, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development (DSDM) e leve. RUP, Desenvolvimento Orientado a Testes (TDD) e muito mais. Entre os muitos métodos de desenvolvimento ágil, a implementação do Scrum é mais popular.

    Guarda-chuva de Método Ágil

    Ágil ou Cachoeira? Veja as Figuras

    O relatório mais recente do Standish Group cobriu os projetos que eles estudaram entre 2013 e 2017. Para este período, a quebra geral de sucesso, desafio e fracasso é mostrada abaixo para ágil e cascata, com projetos Agile sendo aproximadamente 2X mais propensos a ter sucesso, e 1/3 menos propenso a falhar.

    (Fonte: vitalitychicago.com —  Comparando as taxas de sucesso do projeto Waterfall e Agile )

    Waterfall vs Agile, qual é melhor?

    Este artigo compartilha principalmente o entendimento do Scrum, o processo de implementação do Scrum e as mudanças trazidas pela implementação do Scrum, e explica o que é um Scrum em execução.

    O que é Scrum?

    Scrum é uma estrutura para desenvolver e manter produtos complexos e é um processo de desenvolvimento incremental e iterativo. Nessa estrutura, todo o processo de desenvolvimento consiste em vários ciclos de iteração curtos, um ciclo de iteração curto chamado Sprint, e cada Sprint dura de 2 a 4 semanas.

    No Scrum, use o Product Backlog para gerenciar as necessidades do produto. A carteira de produtos é classificada de acordo com a prioridade de implementação, tendo o valor comercial como principal princípio da classificação. No Sprint, a equipe Scrum selecionou os requisitos de maior prioridade do Backlog do produto para desenvolvimento. Os requisitos selecionados são discutidos, analisados ​​e estimados na Reunião de Planejamento do Sprint para obter uma lista de tarefas chamada Sprint backlog. Quando a equipe Scrum conclui todas as tarefas na lista de pendências do Sprint, o Sprint termina e prossegue para o próximo ciclo de iteração do Sprint.

    Por que o Scrum falhou em algumas empresas

    Scrum tem um grande valor. No entanto, é difícil implementar Scrum em algumas empresas. Algumas pessoas dizem que o Scrum não tem efeito substantivo em sua organização. Por que eles têm esse resultado? Os principais motivos podem ser:

    • Agile é mais rápido  — A equipe do projeto não tem uma compreensão correta do ágil. Simplesmente pensa que a agilidade é rápida, ou seja, que acompanha o progresso, e pode estar livre de qualquer restrição do sistema.
    • Agile é mais rápido, ou precisamos trabalhar horas extras  — ouvi dizer que algumas empresas precisam desenvolver uma nova função. Por causa da implementação do scrum, a equipe do projeto é obrigada a trabalhar horas extras, e as tarefas de desenvolvimento de 2 semanas ou mais serão liberadas em uma semana. A implementação do Scrum significa que a equipe do projeto está trabalhando horas extras, o que leva a um “medo” na agilidade da equipe do projeto;
    • O Product Backlog não é bem mantido  — PO não pode ser qualificado para o trabalho, não pode dividir histórias de usuários eficazes ou a divisão de histórias do usuário não é razoável, não pode realizar desenvolvimento de geração incremental;
    • Problema de formação de equipe  — Scrum tem uma alta demanda por equipes auto-organizadas, mas muitos membros da equipe sentem que não estão à altura dos padrões de auto-organização;
    • Falta de cultura Agile  — O Scrum preconiza a transparência do trabalho, a finalização do projeto em tempo real e o reconhecimento da tarefa de cada pessoa. O Sprint Board e o burndown chart do projeto estão desobstruídos, e muitas pessoas não se sentem confortáveis ​​com isso;
    • Inspeção e adaptação não implementadas  — No processo de iteração, o problema não pode ser descoberto a tempo, ou o problema é encontrado e o problema não pode ser resolvido de forma eficaz, o que faz com que a equipe do projeto se sinta frustrada. e muitos mais.

    Se o conhecimento do Scrum estiver apenas preso em:

    “Tenho uma ideia pela manhã, será realizada à tarde e estará online à noite.”

    É inadequado. Na minha opinião, o Scrum é definitivamente valioso. As principais funções do Scrum incluem:

    • O Scrum pode garantir a priorização do desenvolvimento do backlog do produto que tenha alto valor para os clientes e atenda melhor às necessidades dos usuários.
    • Comparado com o método de desenvolvimento sob o processo em cascata, ao implementar o Scrum, a equipe pode dobrar a eficiência do desenvolvimento e maximizar o papel da equipe;
    • Scrum pode encurtar os ciclos de desenvolvimento e aumentar a eficiência da entrega do projeto.

    No entanto, implementar o Scrum não significa que ele não esteja sujeito a regras e restrições do projeto. Então, qual é a postura correta para implementar o Scrum?

    Etapas para implementar o Scrum

    1. Atribuir uma PO

    PO é o proprietário do produto, que é uma função, e PO é o único proprietário da lista de tarefas do produto de gerenciamento. Claro, em algumas empresas o PO já existe como uma organização — por exemplo, nossa empresa implementou o PO como uma organização na implementação do Scrum.

    Como proprietário, deve ter uma visão geral; compreender profundamente as informações e direção da indústria; ser capaz de entender a direção do produto, se encarregar do planejamento e gerenciamento de curto e médio e longo prazo do produto; ser capaz de realizar pesquisas de usuários e planejamento de funções de produtos de acordo com os requisitos estratégicos da empresa, acompanhando as necessidades em constante mudança e continuando a inovar os produtos.

    Além disso, se você usar o PO como uma organização, em um projeto de desenvolvimento de software, a equipe do PO pode incluir outras partes interessadas, como gerentes de produto, usuários finais.

    2. Formar uma equipe de desenvolvimento

    A equipe é o implementador do produto e é responsável por entregar o potencial de Incremento Entregável e os incrementos de produto “concluídos” ao final de cada Sprint.

    A equipe inclui principalmente pessoal de desenvolvimento e teste, e a equipe deve ser capaz de implementar a visão do produto do PO.

    O tamanho da equipe deve ser de 5 a 9 pessoas.

    A equipe Scrum também deve ser multifuncional e membros com a capacidade “full stack” são mais preferíveis, mesmo  que seja difícil de implementar na maioria das empresas.

    3. Selecione Scrum Master

    O Scrum Master é responsável pelo processo Scrum e atende o PO e a equipe de desenvolvimento. O Scrum Master deve ter um senso de ritual e pode efetivamente e eficientemente organizar a reunião de plano iterativo, reunião diária permanente, reunião de demonstração de função e reunião de revisão retrospectiva; o Scrum Master deve ter um alto grau de execução e manter a credibilidade para ajudar a equipe. Foco em metas de entrega e objetivos de qualidade para garantir que as equipes entreguem produtos de alta qualidade com eficiência; conduzir equipes para construir processos eficientes, orientar equipes sobre valores, princípios e práticas ágeis; ser responsável por treinar outros membros da equipe para garantir que o Scrum seja usado corretamente; Comunicação, gerenciamento de problemas, resolução de conflitos, ajudam a equipe a eliminar todos os obstáculos.

    4. Manter o backlog do produto

    O Product Backlog é uma coleção de todos os itens do backlog e é baseado na estratégia da empresa e na visão do produto. PO classifica todos os itens no backlog do produto de acordo com a ordem de prioridade de acordo com os valores de negócios e forma uma lista de itens priorizados. O  backlog do produto pode ser servido como o “roteiro” do desenvolvimento do produto. Para entender o contexto do produto, os itens do backlog do produto são a melhor referência.

    Todos os dias enfrentamos novas demandas de novos concorrentes, o que significa que a PO deve otimizar continuamente o design de seu produto e ajustar as prioridades do backlog do produto para lidar com as novas mudanças.

    Nesse processo, o PO deve consultar todas as partes interessadas e equipes para garantir que as pendências do produto reflitam as verdadeiras reivindicações do usuário.

    5. Estimativa ágil usando o Story Point

    A estimativa relativamente ágil é normalmente realizada no planejamento do sprint ou retoque durante um sprint e o backlog do produto é avaliado pela equipe junto com o responsável pelo trabalho real de desenvolvimento e teste.

    Para conduzir o planejamento do sprint de forma mais eficiente na prática, o PO e o Scrum Master farão uma estimativa aproximada antes da reunião de planejamento do sprint. Eles precisam fazer esse tipo de perguntas, como:

    • Veja se o plano de sprint é viável?
    • Há informações suficientes para concluir essas questões?
    • A divisão do item do backlog do produto é razoável?

    Quando a equipe de desenvolvimento realiza uma estimativa, é recomendável abandonar o método tradicional (ou seja, quantas horas devem ser atribuídas à tarefa) e usar a abordagem de estimativa ágil usando o story point – o número de Fibonacci (1, 2, 3, 5 , 8, 13, 21…) Formulário para avaliar o esforço necessário para a implementação de um item.

    No momento da estimativa, a equipe precisa primeiro identificar um item de backlog que pode estar em forma de história de usuário como referência para a estimativa. Além disso, é importante observar que  quando o ponto de história único da avaliação é maior que 21, a história do usuário precisa ser dividida novamente, e o ponto de história do usuário único não é superior a 8 é o estado ideal.

    Método de estimativa ágil

    6. Reunião de planejamento da Sprint

    Esta é a primeira reunião Scrum real. Equipe, Scrum Master e PO sentam-se juntos para planejar o conteúdo do sprint. Como um projeto de desenvolvimento de software, inserindo a história do usuário do sprint de planejamento, a história do usuário deve ter sido dividida e o design visual concluído.

    O ciclo de sprint é geralmente fixo, principalmente por 2 a 4 semanas. A equipe começa com a história do usuário com a prioridade mais alta na lista de tarefas do produto para ver o quanto pode ser feito em um sprint.

    Se a equipe já realizou vários sprints, por referência a:

    • Os “pontos da história” concluídos nas iterações anteriores,
    • A equipe pode estimar os pontos de história aproximados para esta iteração.
    • “Story points” é equivalente à velocidade da equipe.

    O Scrum Master e o Time devem se esforçar para aumentar esse número em cada iteração do sprint.

    Todos os membros da equipe devem formar um consenso sobre o objetivo de um sprint, ou seja, o que precisa ser realizado em uma iteração de sprint. Na reunião de planejamento do sprint, o PO precisa informar à equipe a ordem de prioridade da implementação da história do usuário. A equipe promete quantas histórias eles poderão concluir na próxima iteração do sprint. No processo de sprint, ninguém pode alterar unilateralmente o conteúdo do sprint sem autorização.

    7. Reunião Diária

    O Daily Stand-up é a fonte de vitalidade do Scrum. Os participantes geralmente incluem PO, Scrum Master e equipe. A equipe se comunica internamente em um local fixo e em um horário fixo todos os dias. O  horário geralmente é de manhã, a duração não é superior a 15 minutos, e em pé. O Scrum Master faz as  seguintes perguntas aos membros da equipe:

    • O que você fez ontem?
    • Que trabalho você pretende fazer hoje?
    • O que são impedimentos e obstáculos?

    O significado disso é permitir que toda a equipe saiba claramente o progresso de cada tarefa durante este ciclo de sprint e se todas as tarefas podem ser concluídas no prazo.

    As tarefas da equipe não são atribuídas de cima para baixo, mas são decididas por sua própria iniciativa e voluntariamente. Se a tarefa anterior não for concluída, você não poderá solicitar a próxima tarefa e não poderá reivindicar duas tarefas que não podem ser concluídas no mesmo dia.

    O Scrum Master é responsável por eliminar os obstáculos enfrentados pelos membros da equipe.

    8. Acompanhe o progresso do projeto com o quadro de tarefas do Scrum

    No Scrum, o trabalho deve ser transparente, e a prática mais comum é implementar um quadro de tarefas do Scrum.

    Algumas equipes são boas em usar ferramentas de terceiros para usar o quadro eletrônico do Scrum, como Visual Paradigm ou Jira; algumas equipes ficam felizes em usar grandes quadros brancos físicos offline.

    Independentemente de você usar um quadro Scrum eletrônico ou um quadro branco físico, as colunas do Kanban geralmente incluem três partes: a lista de tarefas, os itens em andamento e os itens concluídos. À medida que o progresso da iteração avança, a equipe atualizará imediatamente o assunto para a coluna Scrum Kanban correspondente todos os dias.

    Quadro de Tarefas Scrum — Paradigma Visual

    9. Acompanhamento do progresso com gráficos de esgotamento

    Outra ferramenta para tornar o trabalho transparente é o gráfico de burn-out. Na figura abaixo, um eixo representa a carga de trabalho e o outro representa o tempo. Todos os dias o Scrum Master registra os pontos restantes a serem concluídos e os desenha no gráfico de burnout. Idealmente, o gráfico é uma curva descendente, chegando a zero à medida que o restante do trabalho é concluído.

    用燃尽图跟踪进度

    10. Demonstração do Produto

    Revisão do Scrum e Reunião Retrospectiva – Paradigma Visual

    A seção de demonstração do Guia do Scrum é chamada de Reunião de Revisão do Sprint, que afirma que deve incluir demonstrar o trabalho feito pela equipe de desenvolvimento e responder perguntas sobre o incremento do produto. A reunião geralmente é realizada antes do lançamento desta iteração. O trabalho mais importante desta reunião é verificar os cenários de implementação das histórias de usuários com avaliações de aceitação com cada um dos itens concluídos para cumprir a definição de feito.

    Esta reunião é onde qualquer pessoa pode ser participante, não apenas PO, Scrum Master e equipe, mas também stakeholders, negócios e gerentes, e até clientes.

    Esta é uma reunião aberta onde qualquer pessoa pode ser participante, não apenas PO, Scrum Master e equipe, mas também stakeholders, negócios e gerentes, e até mesmo clientes.

    As equipes devem mostrar apenas os itens que atendem à definição de feito, ou seja, os resultados que podem ser entregues sem ter que fazer mais trabalho. Esse resultado pode não ser um produto completo, mas pelo menos é um recurso completo e utilizável para o usuário final.

    11. Retrospectiva do Sprint

    A reunião de retrospectiva do sprint geralmente é realizada no segundo dia após o término deste Sprint.

    A reunião de retrospectiva do sprint deve revisar cuidadosamente as seguintes questões:

    • O que aconteceu foi melhorado;
    • Por que aconteceu?
    • Por que o ignoramos na época;
    • Como podemos acelerar o trabalho.

    Como equipe, para tornar esse processo de retrospectiva de sprint eficaz, a equipe precisa confiar uma na outra. Devemos lembrar da discussão e argumentos baseados em questões técnicas e de projeto:

    • Não existe certo absoluto, errado e preocupação,
    • Incentivar colisões técnicas;
    • Não pode envolver discussões sobre ataques pessoais;
    • Resista às pessoas com óculos coloridos para ver as pessoas,
    • Orientar a todos para uma discussão racional;
    • Aceite corajosamente os desafios dos outros,
    • Aceite suas próprias imperfeições.
    • Responsável por seus próprios processos e resultados,
    • brainstorming e buscar soluções para os problemas. Isso é crucial.

    Por fim, a equipe identifica uma das melhorias mais valiosas e a define como a principal prioridade para o próximo sprint. Você precisa definir o que é “bem-sucedido” de maneira concreta e acionável para que possa determinar rapidamente se as melhorias foram feitas na próxima reunião de revisão do sprint.

    Após o término do último sprint, comece a inserir a nova iteração do sprint.

    Resumo

    Scrum  é uma combinação de 3355. Os conceitos centrais do framework scrum podem ser simplesmente memorizados como 3.3.5.5 da seguinte forma:

    3 papéis

    3 Artefatos

    5 eventos

    5 valores

    • Abrir
    • Respeito
    • Coragem
    • Foco
    • Comprometimento

    Os objetivos do 3355 estão por trás dos três pilares do Scrum

    • Transparente
    • Inspeção
    • Adaptação

    A Definição de “Pronto” (DoD) é alcançada através do cumprimento dos 3 pilares por meio de 5 eventos da  equipe Scrum .

    Estrutura Scrum 3355

Leave a Reply

O seu endereço de email não será publicado.