Pensei que essa segunda parte da série não ia sair nunca! A disciplina de Gerência de Configuração e a Papel em Flor bombando nas encomendas tomaram um pouco de tempo mas finalmente está no ar a segunda parte da série sobre Scrum.

Depois de fazer uma pequena introdução sobre metodologias ágeis finalmente vamos focar no Scrum. Vamos conhecer os conceitos básicos do Scrum individualmente e depois entender a forma como eles constituem o processo.

Papéis

Dentro do Scrum podem ser encontrados os seguintes papéis.

Product owner – é o responsável por esclarecer as regras de negócio, elencar e priorizar as funcionalidades desejadas, aceitar/rejeitar o produto e dar o feedback sobre o software produzido. É o cliente do software ou alguém considerado pelo cliente como capaz de responder pelas suas necessidades e pelas regras de negócio associadas.

Scrum Master – é o mais próximo da figura de gerente dentro do processo. Entretanto o Scrum Master não tem a atribuição de delegar tarefas ou de fiscalizar o trabalho de um integrante da equipe, por exemplo, como os gerentes normalmente tem. O time é auto-gerenciável. O Scrum Master atua como facilitador e mediador garantindo que o time seja sempre produtivo e nada interfira no processo de desenvolvimento. Também é o responsável por garantir que as práticas do Scrum sejam seguidas (as reuniões, os artefatos, etc). Quanto maior o nível de maturidade do time menor a importância do Scrum Master.

Scrum Team – o time é um grupo multidisciplinar, de 5 a 9 pessoas, que vai projetar, desenvolver, testar e implantar o software. Como falei anteriormente o time é auto-gerenciável. Não há quem delegue tarefas. Cada pessoa escolhe que tarefa vai assumir dentro do que foi definido para o sprint. Se algum integrante encontra dificuldade em uma tarefa o Scrum Master (ou alguém no grupo que possua conhecimento sobre o domínio em questão no caso de uma dificuldade técnica) deve ajudar. Se algum integrante não está trabalhando com o comprometimento suficiente o grupo deve cobrá-lo. Ou seja, a função de controle não pertence a um gerente e sim ao próprio time como um todo. O time deve escolher a melhor maneira de trabalhar para cumprir os objetivos do projeto. O time tem que estar comprometido com o projeto. Todos ali devem ser porcos.

Artefatos

Product Backlog – uma lista com toda e qualquer funcionalidade (e sua respectiva prioridade) que o projeto possa vir a ter. Pelo que você já conhece de Scrum dá pra perceber que o Product Backlog é mantido pelo Product Owner. O PO pode adicionar ou alterar funcionalidades a qualquer tempo desde que essas funcionalidades não estejam dentro do sprint atual.

Sprint Backlog – contém as funcionalidades do Product Backlog que, baseado na prioridade definida pelo cliente e na complexidade estimada, o time e o PO escolheram para executar no sprint. Quando vão entrar no Sprint Backlog as funcionalidades são quebradas em tarefas específicas que serão implementadas pelo time.

Burn-down chart – é uma forma rápida de visualizar o trabalho restante. Pode haver um para o sprint e um geral para o projeto. Mostra dia a dia o quanto de trabalho já foi ‘queimado’. Com ele você vê facilmente os pontos em que o projeto não rendeu o esperado e pode investigar os motivos e corrigir pra melhorar a produtividade.

Burn-down chart: você pode ver claramente quantos pontos o time vem entregando por iteração. É muito simples notar que no quinto sprint a equipe produziu muito mais que no quarto, por exemplo.

Eventos

Sprint Planning - reunião entre o time e o Product Owner para negociar o que será produzido no sprint. Com base na prioridade definida pelo PO o time vai dividindo as funcionalidades do Product Backlog em tarefas menores e estimando a complexidade dessas tarefas. O PO é fundamental para esclarecer qualquer dúvida à respeito das funcionalidades e do comportamento esperado do sistema pois provavelmente elas vão aparecer enquanto o time está estimando a complexidade das tarefas. Quando o time achar que tem o suficiente pra o sprint para de adicionar coisas ao Sprint Backlog e define o objetivo do sprint. O objetivo deve ser definido em alto nível. Algo como: “O usuário deve ser capaz de realizar uma compra no site” é um exemplo de objetivo para um sprint.

Daily Scrum – todos os dias durante o sprint o time deve se encontrar no mesmo lugar e no mesmo horário (geralmente pela manhã) para fazer o Daily Scrum. A reunião deve durar no máximo 15 minutos e todos ficam de pé. O objetivo da reunião é manter a equipe e o Scrum Master informados de todo o progresso e das dificuldades que possam estar atrasando o desenvolvimento do progresso. Qualquer pessoa pode participar mas só os porcos podem falar. Cada membro deve responder a três perguntas:

  • O que você fez ontem?
  • O que você fará hoje?
  • Existe algum impedimento no seu caminho?

Com isso todo o time tem uma visão completa do progresso do desenvolvimento e os problemas são identificados no máximo em um intervalo de um dia.

Sprint Reviews – uma reunião informal realizada no final de cada sprint. O objetivo é apresentar (e demonstrar o uso se for o caso) do que foi produzido no sprint. Idealmente o time deve ter completado tudo o que foi trazido para o Sprint Backlog mas o fundamental mesmo é que o objetivo do sprint seja alcançado. Qualquer pessoa pode assistir.

Sprint Retrospectives – uma reunião também realizada ao final do sprint. O time reflete sobre a sprint que acabou e procura maneiras de melhorar o processo, se existe alguma coisa que deveriam começar a fazer, alguma coisa que deveriam parar de fazer e o que deveriam continuar fazendo.

 

Bom, com isso você já conhece o Scrum. No próximo post apresentaremos um esquema de como esses eventos e artefatos se relacionam durante o projeto. Até lá.

 

[Editado] Aqui estão todos os links da série O que é Scrum

Parte 1 – Uma visão geral sobre metodologias ágeis

Parte 2 – Conceitos básicos