Publicado em

Histórias de Usuário (User Stories)

Cada item do Product Backlog de um produto de software, precisa ser detalhado de alguma forma, para que o time de desenvolvimento possa construir um software.

No modelo tradicional, é muito comum a utilização de documento de levantamento de requisitos, especificações técnicas, especificações funcionais, diagramas dos diversos tipos (caso de uso, atividades, sequência entre outros).

No Scrum, não é diferente, você poderá utilizar qualquer uma das técnicas acima e outras várias para detalhar as necessidades dos usuários e o que precisará ser desenvolvido.

Entre as mais comuns, estão os Casos de Uso, com seus diagramas e detalhamentos, descrições textuais simples (até mesmo o famoso papel de pão) e acredito que a mais difundida, as histórias de usuário.

Continue lendo “Histórias de Usuário (User Stories)”

Publicado em

Artefatos Scrum – Sprint Backlog

Durante a segunda parte da reunião de Planejamento da Sprint, é construído o Backlog da Sprint. Esse artefato lista as tarefas que serão necessárias para transformar um item do Product Backlog em um incremento de software “pronto”.

A responsabilidade de construir esse artefato é do time de desenvolvimento, que irá listar o que é necessário para criar o produto pronto. Deve-se listar todas as tarefas pertinentes para desenvolver o item, desde a modelagem de dados, construção da interface, desenvolvimento das regras de negócio, testes específicos, etc. Somente o Time de Desenvolvimento poderá adicionar ou remover tarefas do Sprint Backlog e poderá fazê-lo a qualquer momento.

Continue lendo “Artefatos Scrum – Sprint Backlog”

Publicado em

Artefatos Scrum – Product Backlog

O Product Backlog ou Backlog do Produto, é uma lista ordenada de todos os requisitos desejados para o produto, é a única fonte destes requisitos para um determinado produto. Essa lista nunca é completa, ou seja, é um artefato vivo que vai sendo modificado enquanto o produto existir. Para quem está acostumado à metodologias tradicionais, essa última definição soa estranho.

Vou explicar melhor. Como já mencionado, o Scrum se baseia no processo empírico, ou seja, o aprendizado vem com a experiência e o tempo. Desta forma, a lista de requisitos de um produto (product backlog), no início, na concepção do produto, ainda é tem muitas incertezas e requerimentos desconhecidos. Desta forma, a lista inicial contém apenas o que é conhecido, os requisitos principais. A medida que o software vai sendo concebido, novas funcionalidades e requisitos vão surgindo, assim, essa lista vai sendo alterada.

Continue lendo “Artefatos Scrum – Product Backlog”

Publicado em

Eventos do Scrum – Revisão da Sprint (Sprint Review)

É chegado o fim da Sprint, todas as atividades realizadas, todos os itens do backlog do produto, selecionados para a Sprint, estão concluídos. E agora? O que fazer com isso que foi criado pelo time de desenvolvimento?

Agora é a hora de mostrar o que foi feito, na “Sprint Review” ou Revisão da Sprint.

Esse evento ocorre no final da Sprint, com duração de 4 horas para Sprints de 30 dias (Sprints menores, tempo menor) e tem por objetivos:

  • Apresentar o produto desenvolvido para o dono do produto e stakeholders
  • Receber o feedback do dono do produto e stakeholders.
  • Receber o aceite do dono do produto e stakeholders.

Continue lendo “Eventos do Scrum – Revisão da Sprint (Sprint Review)”

Publicado em

Eventos do Scrum – Retrospectiva da Sprint (Sprint Retrospective)

A Retrospectiva da Sprint (Sprint Retrospective), é o último evento dentro da Sprint, ocorre logo após finalizada a reunião de revisão da Sprint e antes do próximo Sprint Planning e é a oportunidade para identificar as lições aprendidas na Sprint.

O foco da reunião não é o produto em si, mas sim o processo. Essa reunião é fundamental para construir uma equipe mais interativa, motivada, produtiva e colaborativa.

Como todos os eventos, esse evento é “Time-Boxed” e tem duração máxima de 3 horas para uma Sprint de 30 dias. Neste evento participam todos os membros do time de desenvolvimento e o Scrum Master. Já o Product Owner não é obrigatório.

Basicamente, são respondidas 3 questões:

  1. O que fizemos de bom e devemos manter?
  2. O que pode ser melhorado?
  3. Como vamos implementar as ações para melhorar?

Continue lendo “Eventos do Scrum – Retrospectiva da Sprint (Sprint Retrospective)”

Publicado em

Eventos do Scrum – Daily Scrum – Reunião diária

Após terminada a reunião de planejamento, é dado início às atividades definidas no backlog da Sprint, que serão realizadas para entregar o item do backlog do produto, ou seja, o trabalho de desenvolvimento para entregar o software pronto é iniciado.

Diariamente, os membros do time de desenvolvimento se reúnem para realizar a “Daily Scrum” ou reunião diária. Essa reunião é um evento Time-Boxed de 15 minutos. É importante que o tempo não seja excedido, mas pode ser menor caso todos já tenham falado e o objetivo for alcançado.

Nesta reunião, devem ser respondidas 3 perguntas básicas:

  1. O que eu fiz desde a última reunião, que contribui para o time alcançar a meta da Sprint.
  2. O que farei até a próxima reunião, para atingir a meta da Sprint.
  3. Há algum impedimento no meu trabalho.

Continue lendo “Eventos do Scrum – Daily Scrum – Reunião diária”

Publicado em

Eventos Scrum – Planejamento da Sprint (Sprint Planning)

A Sprint começa pelo planejamento, logo o Sprint Planning é o primeiro evento oficial do framework Scrum dentro da Sprint.

Essa reunião é realizada por todo o time Scrum, ou seja, Dono do Produto, Time de Desenvolvimento e Scrum Master, dividida em duas partes iguais, com tempo máximo de 4 horas cada parte (total de 8 horas) para uma Sprint de 30 dias (para sprints menores que 30 dias, normalmente o tempo da reunião é menor proporcionalmente) e aonde são respondidas duas questões chaves:

  1. O que será desenvolvido na Sprint?
  2. Como será desenvolvido?

Continue lendo “Eventos Scrum – Planejamento da Sprint (Sprint Planning)”

Publicado em

Eventos do Scrum – A Sprint

O Scrum possui 5 eventos ou cerimônias em seu framework, dos quais, todos são obrigatórios. Esses eventos são todos “Time-Boxed”, tem tempo máximo definido. Apenas o Sprint, uma fez definida a sua duração, ela é fixa e não pode ser encurtado e nem alongado, os demais eventos, podem ser encerrados antes, desde que o seu objetivo tenha sido alcançado.

Esses eventos servem para manter os 3 pilares do Scrum, que são a transparência, inspeção e adaptação, não realizar ou realizar somente parte dos eventos, irão prejudicar esses 3 pilares.

Se caso a empresa ou a equipe decidir não realizar algum destes eventos, por julgar desnecessário, deve-se repensar se a empresa está preparada para o Scrum ou as pessoas não entenderam o Scrum, pois retirar qualquer um destes eventos não é possível implantar o Scrum na empresa. Lembre-se, o Scrum é fácil de entender, mas difícil de dominar.

Continue lendo “Eventos do Scrum – A Sprint”