Scrum

Scrum para Iniciantes

Como este blog tem por objetivo compartilhar aquilo que estou aprendendo, nada mais certo que começar com aquele resumão de Scrum para quem ainda está dando os primeiros passos. Este post foi originalmente publicado no blog da empresa onde eu trabalhava, a Total Commit.

O Scrum é um processo de desenvolvimento destinado a resolução de problemas complexos, como costuma ser o ambiente de desenvolvimento de software. No entanto, não fica restrito a essa aplicação. Outros ambientes com equipes multidisciplinares já estão se tornando adeptos da solução.

É um método iterativo e incremental, o que significa dizer que a cada iteração (repetição) é entregue um incremento de produto pronto que agregue valor ao cliente.

Papéis

A equipe é formada por membros com capacidade multidisciplinar. Todas as competências necessárias ao desenvolvimento de um software devem estar presentes, mas não há pessoas especificamente designadas para cada uma delas. Isto significa que cada membro pode ter mais de uma competência e todos contribuem para o trabalho completo e entregue. A responsabilidade também é partilhada por todos, não havendo um chefe. O time é auto-organizável e toma as decisões coletivamente.

Time scrum

Um time Scrum é composto por três papéis, a saber:

  1. Time de Desenvolvimento – Os membros do time de desenvolvimento são aqueles responsáveis pelas tarefas de desenvolvimento da aplicação: Testes, Design, Codificação, Banco de Dados…
  2. Product Owner (PO) – Representa os Stakeholders e o negócio, é o dono do produto. Funciona como um interlocutor entre o time e o cliente e deve estar disponível para o time, pois é o responsável por esclarecer os requisitos e garantir que o time de desenvolvimento não tenha dúvidas na execução de suas tarefas para efetuar uma entrega realmente valiosa para o cliente.
  3. Scrum Master – O Scrum Master é o facilitador do time scrum e tem um papel crucial para o sucesso do framework (Metodologia). Ele garante que as cerimônias (reuniões) do processo sejam realizadas como definido pelo Scrum Guide, remove impedimentos que estejam impactando no desenvolvimento da equipe, atua como coach do time na autogestão, auxilia na geração e manutenção de ferramentas visuais como gráficos e quadros que têm por objetivo ilustrar o avanço do time nas sprints.

Backlog

O backlog é uma lista de requisitos do projeto, ordenada por prioridade. O requisito de maior valor para o negócio deve estar no topo da lista e o PO (Product Owner) é o responsável pela sua administração. A ele cabe detalhar cada item de maneira que esteja claro para a equipe o que se espera do desenvolvimento e promover as mudanças necessárias caso haja mudança no escopo, repriorizando as tarefas. Dada a natureza mutável do desenvolvimento de software, é esperado que as necessidades dos clientes mudem ao longo do tempo. É preciso que o Product Owner seja flexível para conduzir essas adaptações.

Sprint Planning

No início de cada iteração, a equipe conduz uma reunião de planejamento, quando seleciona no Backlog as tarefas que realizará naquela Sprint. A partir daí, este conjunto de tarefas passará a se chamar Sprint Backlog e será gerido pela equipe. O Scrum Master será o responsável por remover impedimentos e bloquear comunicações externas à equipe, caso estas interrompam o time sem agregar valor ao trabalho.

Sprint

É o intervalo de 2 a 4 semanas nas quais as atividades de desenvolvimento se dão. Uma sprint tem duração fixa. Uma vez definida, deve se manter inalterada ao longo do projeto. Uma das principais razões para isto é que desta forma se pode calcular a velocidade de desenvolvimento do time e planejar sprints cada vez mais eficientes. O Scrum Master deve motivar o time a se tornar cada vez mais produtivo no mesmo espaço de tempo.

Daily Meeting

A cada dia de uma Sprint é realizada uma reunião de acompanhamento com regras bem definidas:

  • Deve ser realizada no mesmo horário e no mesmo local todo dia;
  • Deve ter a duração máxima de 15 minutos;
  • Os participantes devem responder a três perguntas:
    • O que você realizou ontem?
    • O que você pretende realizar hoje?
    • Há algum impedimento para que você alcance o objetivo da sprint?

Esta reunião coloca todos a par do que está sendo desenvolvido na Sprint até o momento e também serve para comunicar ao Scrum Master os impedimentos enfrentados pelo time. O Scrum Master não precisa estar presente na Daily, mas deve garantir que ela ocorra e ser informado dos impedimentos.

Sprint Review

Esta reunião tem por objetivo permitir ao time rever o trabalho que foi feito e efetuar uma demonstração do produto funcionando. O cliente também pode participar da reunião, caso em que pode aproveitar a oportunidade para fazer críticas e sugestões de melhorias sem precisar esperar o término do projeto. Ocorre a cada final de Sprint e pode contar também com o Product Owner, outros Scrum Master, a gerência e engenheiros de outros projetos.

Sprint Retrospective

É o momento destinado à adaptação do método Scrum. Nesta oportunidade são revistos os erros e acertos do time em relação a pessoas, processos, relacionamentos e ferramentas, para que se possa reforçar os pontos fortes e minimizar os pontos fracos. Também se pode dar sugestões para melhorar o produto e fortalecer o conceito de melhoria contínua. O momento certo de fazer a retrospectiva é ao final da Sprint, após a reunião de Sprint Review.

Conclusão

Por se tratar o Scrum de uma metodologia que prevê transparência, inspeção e adaptação como pilares, ele representa inúmeras vantagens para o cliente. Favorece a participação ativa no desenvolvimento e permite que ele esteja sempre acompanhando a evolução do desenvolvimento através dos radiadores de informação (quadro scrum, gráfico burn down), que são públicos e estão disponíveis a todos.

O scrum dá inúmeras oportunidades de corrigir problemas o mais cedo possível, fornecendo a chance de alterar o curso do projeto ou da estratégia antes que o projeto esteja muito avançado e seja muito caro ou desinteressante seguir.

A entrega contínua de valor é outra grande vantagem para o cliente, que recebe de tempos em tempos um incremento útil do produto que pediu e pode assim avaliar, testar e propor melhorias com frequência. Ao contrário das metodologias tradicionais que tem uma reunião inicial de kickoff e o cliente só tem contato com o produto quando ele é entregue pronto ao final do projeto.

Assim, essa metodologia é ágil por prever mudanças, erros e correções no projeto ao longo do desenvolvimento do mesmo, podendo agir nesses pontos com maior rapidez e eficiência.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s