Seguindo o fluxo do Scrum, a Reunião de Revisão ocorre logo após o período de desenvolvimento da Sprint. O objetivo desta reunião é apresentar ao Product Owner (PO) todos os entregáveis que foram produzidos pelo time Scrum e ela conta com a participação do time, do Scrum Master (SM), do PO e de qualquer outro interessado no projeto. Durante essa reunião, o time tem a responsabilidade de mostrar ao PO o trabalho que foi feito, o SM tem a responsabilidade de evitar que a reunião saia do seu propósito inicial e o PO tem a responsabilidade de aprovar, ou não, as novas funcionalidades mostradas.

E por que é o time quem apresenta o que foi produzido? Na verdade, essa responsabilidade é uma das mais importantes do time e deve sempre ser respeitada. Durante as reuniões de planejamento, o time se compromete com o PO a fazer determinados itens do Product Backlog e, ao fim do ciclo de trabalho, é ele quem deve mostrar ao PO e assumir a responsabilidade pelo que foi produzido. Além disso, o time também deve discutir com o PO as soluções encontradas e ouvir sugestões e impressões sobre o que foi apresentado.

O papel do PO nesta reunião é avaliar se o que foi produzido está de acordo com o que era esperado e validar a Sprint. Para a Sprint ser validada, é preciso que as funcionalidades entregues pelo time cumpram a meta da Sprint, acordada na Reunião de Planejamento. O fato de algum item do Sprint Backlog ser reprovado pelo PO não indica, necessariamente, que a Sprint não teve sucesso. Se o item reprovado não estiver relacionado à meta da Sprint, ela pode ser validada ainda assim. Só temos que ter em mente o seguinte: se um item é reprovado pelo PO, mesmo que parte dele possa ser entregue, todo ele voltará para o Product Backlog e nenhum ponto será considerado na velocidade do time. Em uma próxima Sprint, de acordo com a necessidade do PO, esse item volta para o Sprint Backlog, com a mesma estimativa, e aí, então, o trabalho que falta para finalizá-lo será realizado.

O que foi dito no post “Por que liberar versão em produção é como correr no asfalto” também vale para esse momento de validação do trabalho realizado. Por isso, na GPE, procuramos seguir as seguintes práticas: montar um roteiro da apresentação e testar o projeto em um servidor local. Ao montar um roteiro da apresentação, é possível pensar em todos os passos que devem ser realizados para a apresentação das funcionalidades produzidas, o que permite que o time reveja todo o fluxo e verifique se algo passou despercebido e precisa ser revisto. Ao realizar o teste em um servidor local, o time pode simular o ambiente que será utilizado na apresentação e tentar identificar e corrigir possíveis problemas de configuração de ambiente. Essas práticas permitem que o time tenha mais tranquilidade durante a reunião e evita problemas em que a resposta é a já famosa “na minha máquina estava funcionando”, mesmo que realmente estivesse.

Uma última prática deve ser sempre utilizada: não deixem para contactar o PO apenas na Reunião de Revisão. Quanto mais opiniões e impressões forem coletadas durante o processo de desenvolvimento, maior será a chance de o item do Sprint Backlog ser aprovado.

E então? Ficou alguma dúvida? Não deixem de mandar seus comentários e assista à vídeo-aula sobre Reunião de Revisão na Universidade Scrum!

The post O que é Reunião de Revisão? – FAQ Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O que é?

No framework Scrum o andamento do trabalho da Sprint é inspecionado diariamente pela própria equipe de desenvolvimento, através da reunião denominada Reunião Diária. Essa reunião tem como objetivo trabalhar o autogerenciamento da equipe.

Na reunião diária todos os membros da equipe devem comunicar o que fizeram desde a última reunião e o que estão se comprometendo a fazer na próxima reunião. Nessa hora fica visível para os demais membros os problemas enfrentados pela equipe, bem como os impedimentos que cada membro possa ter sofrido. Problemas técnicos não devem ser discutidos, podem ser abordados para permitir o agendamento de uma reunião técnica com o objetivo de resolvê-los, nesse momento o foco é na transparência do trabalho.

É uma das principais cerimônias do Scrum, é onde a equipe demonstra, diariamente, seu comprometimento com o andamento da Sprint e pode alterar seu planejamento para atingir a meta da mesma, além de manter a transparência dentro da equipe e o foco no entregável, um dos principais conceitos do Scrum.

Quando e como?

A reunião diária, como o próprio nome diz, deve acontecer diariamente, de preferência no fim ou no início do trabalho. Deve ter duração curta, de cerca de 15 minutos e, para ajudar isso, deve ser feita com todos os membros em pé diante do Quadro de Tarefas. Devem participar da reunião todos os membros da equipe de desenvolvimento e, de forma facultativa, o Scrum Master da equipe.

Durante a reunião, basta cada membro da equipe responder à 3 perguntas:

1. O que fiz desde a última reunião diária?
2. O que irei fazer até a próxima reunião diária?
3. Quais foram meus impedimentos?

E então, ficou alguma dúvida sobre a Reunião Diária? Não deixe de comentar aqui suas dúvidas e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

The post O que é Reunião Diária? FAQ Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Continuando com a série FAQ Scrum, no post de hoje falaremos sobre a Sprint. Veremos o que é a Sprint, como é criada e o que é feito ao iniciar, durante e ao final de uma Sprint.

Na metodologia Scrum, o processo de desenvolvimento é dividido em ciclos regulares ao longo do tempo. Sprint é cada um destes ciclos. De acordo com a definição que podemos encontrar no post Aprendendo os termos Scrum – Glossário, temos que a Sprint “Representa um ciclo de trabalho no Scrum. Esse ciclo pode ser de qualquer tamanho, mas normalmente é de 1, 2 ou 4 semanas, que é o Timebox das Sprints. As Sprints devem ter sempre a mesma duração.” A cada Sprint um conjunto de requisitos (histórias de usuários)  é implementado, tendo como resultado um incremento do produto que está sendo desenvolvido.

Na figura abaixo temos um esquema representando a dinâmica de uma Sprint.

Início da Sprint – Planejamento

Primeiramente, ao de iniciar a Sprint, é preciso definir que histórias do Product Backlog serão implementadas no ciclo que está se iniciando. Para isso as histórias no Product Backlog devem estar em uma ordem de prioridade definida pelo PO e devem estar estimadas pela equipe de desenvolvimento.

Uma vez que o Product Backlog esteja priorizado e estimado, a equipe realiza uma reunião de planejamento (Planejamento 1) para selecionar as histórias que serão incluídas na Sprint de modo a acomodá-las dentro do tempo da Sprint e respeitando a ordenação definida pelo PO. Este conjunto de histórias incluídas na Sprint é chamado de Sprint Backlog.

Uma vez definido o Sprint Backlog, o trabalho pode então ser iniciado! Neste momento a equipe de desenvolvimento parte para uma segunda parte do planejamento (Planejamento 2), no qual cada história é subdividida em tarefas menores a fim de se ter um maior controle sobre o desenvolvimento de cada história individualmente.

Agora é mãos à obra! Temos as histórias a serem implementadas e as tarefas a serem realizadas para a implementação de cada história.

Execução da Sprint

Durante a execução da Sprint, a equipe executa as tarefas para a realização das histórias seguindo a ordem de prioridade definida pelo PO. Ao longo da Sprint a equipe pode utilizar o gráfico de Burndown para ter noção se está atrasada ou adiantada em relação ao objetivo da Sprint e tomar providências se for necessário.

Diariamente a equipe de desenvolvimento se reúne para falar o que foi feito no dia anterior, quais são seus impedimentos e o que será feito no dia atual. Caso hajam impedimentos, o SM busca resolvê-los o mais rápido possível para que a equipe possa dar prosseguimento normal aos trabalhos da Sprint. O SM também participa desta reunião diária.

Recomenda-se que não haja qualquer alteração no tempo da Sprint nem nas tarefas do Sprint Backlog. 

Final da Sprint – Reunião de Revisão e Reunião de Retrospectiva

Ao final da Sprint é realizada a reunião de Revisão. Nesta reunião, a equipe apresenta as histórias implementadas na Sprint, mostrando o seu resultado para o PO. O PO então analisa a resolução de cada história junto à equipe de desenvolvimento e decide se aprova ou não cada uma delas. As histórias reprovadas retornam para o Product Backlog e ficam disponíveis para serem incluídas em uma nova Sprint. Nesta reunião, aproveitando que PO e equipe estão juntos, também podem ser discutidas histórias do Product Backlog que não tenham sido bem compreendidas pela equipe de desenvolvimento e o futuro do trabalho sendo executado.

Após a reunião de revisão o time faz a reunião de Retrospectiva. Nesta reunião todos compartilham a suas opiniões e refletem sobre o que funcionou e o que não funcionou ao longo da Sprint. É feita uma discussão sobre os pontos positivos e negativos da Sprint, com o objetivo de reforçar o que foi bom e levantar soluções para o que foi ruim. Assim, a cada Sprint a equipe vai aprendendo e melhorando o seu processo e produto.

Aproveite e dê uma passada na Universidade Scrum e assista ao vídeo sobre o Trabalho na Sprint. Até o próximo post!

The post O que é Sprint? – FAQ Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Dando continuidade à série

O que é isso de fato, quando e como ele deve ser criado?

Além disso, veremos quais papéis devem estar envolvidos na criação deste artefato que direcionará o trabalho da equipe Scrum durante a próxima Sprint, ou seja, durante o próximo ciclo de desenvolvimento.

O que é?

O Sprint Backlog representa

 tudo o que deverá ser feito durante a próxima Sprint do seu projeto. Ele surge a partir do que foi levantado e listado, pelo Product Owner, no Product Backlog. A maioria dos itens que estão no Product Backlog serão implementados 

um dia, mas para serem considerados para fazer parte do Sprint Backlog eles devem estar preparados, estimados e priorizados, segundo a definição de preparado estabelecida no início do projeto.

A escolha dos itens que farão parte do Sprint Backlog deve estar de acordo com a Meta da Sprint, que define qual o objetivo do Product Owner com aquela Sprint, ou seja, o que ele espera que o produto seja capaz de fazer quando chegar o fim daquele ciclo de desenvolvimento. E é essa Meta que direciona o Product Owner e a Equipe Scrum para definir quais itens do Product Backlog farão parte do Sprint Backlog.

Quando e como?

O Sprint Backlog é criado durante a Reunião de Planejamento, onde os três papéis do Scrum estão envolvidos. Nesse momento, os itens de Backlog que serão considerados já devem estar preparados, e deixá-los preparados é tarefa do Product Owner. Com os itens preparados, a Equipe Scrum estima o esforço de trabalho para cada um deles e, de acordo com a Meta da Sprint, esses itens são priorizados e uma determinada quantidade deles se torna o Sprint Backlog, sendo detalhados em tarefas. 

Essa quantidade é definida a partir da análise do que a Equipe Scrum consegue concluir no próximo ciclo de trabalho e o que realmente deve ser realizado para que a Sprint cumpra a Meta estabelecida.

É aconselhável que nem todos os itens do Sprint Backlog estejam diretamente relacionados à Meta. Isso porque, caso não seja possível concluir um deles, a Meta estará comprometida e, assim, a Sprint não terá sucesso.

Outro ponto importante é que o Sprint Backlog não deve ser mudado porque a Meta da Sprint não pode ser mudada. Além disso, incluir um novo item ao Sprint Backlog pode ocasionar a não conclusão de um outro item. Por isso, itens novos só podem entrar no Sprint Backlog se estiverem relacionados à Meta e se forem contribuir para o seu cumprimento de uma forma que os itens já presentes não cumprirão.

E então? Ficou alguma dúvida sobre Sprint Backlog? Não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

The post O que é o Sprint Backlog? – FAQ Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Dando continuidade a série FAQ Scrum, hoje falaremos de Histórias e Product Backlog. No post Aprendendo os termos Scrum – Glossário, nós já aprendemos a definição desses dois termos, mas não nos custa relembrar:

“Histórias – São itens do Product Backlog que representam parte do produto a ser implementado. As Histórias devem conter uma descrição detalhada do que deve ser implementado.”

“Product Backlog – Lista de itens, ou Histórias, que devem ser implementados para a criação do produto desejado ou desenvolvimento do projeto.”

Ok, mas como funciona essa coisa de História e Product Backlog na realidade?

Vamos começar pelas Histórias:

Como dito acima, elas representam uma parte do produto a ser implementado, uma necessidade que foi levantada e que o Product Owner (PO)* do projeto deseja que seja implementada. Geralmente, as Histórias são levantadas durante uma reunião entre equipe, Scrum Master e PO e não existe nenhum nível de granularidade pré-estabelecido para elas. Uma história pode descrever desde a alteração de um label na tela até a criação de uma nova funcionalidade do sistema. O importante é verificar se o que deve ser implementado ao realizar aquela história foi realmente compreendido pela equipe.

É possível que em algumas Histórias a equipe sinta a necessidade de dividir o trabalho previsto para que se tenha maior controle do que deve ser feito. Não há problemas. Durante a reunião, a equipe pode e deve sugerir ao PO que determinada história seja dividida em várias ou tenha sua descrição alterada. A função da equipe não é apenas desenvolver a funcionalidade desejada, mas também encontrar, junto com o PO, a melhor maneira de concluir as Histórias levantadas.

Agora vamos falar do Product Backlog:

Todas as Histórias levantadas pelo PO compõem o Product Backlog. Nele estão listadas todas as necessidades já identificadas para o projeto, ordenadas por prioridade pelo PO. É importante ressaltar que o Product Backlog nunca está completo, ele se atualiza a medida que o desenvolvimento do projeto vai avançando e novas necessidades são encontradas. A cada iteração do projeto, é possível que novas Histórias entrem no Product Backlog e novas prioridades sejam estabelecidas.

Antes de iniciar o desenvolvimento, cada história deve ser dividida em tarefas. Cada tarefa deve representar um passo, que deve ser concluído em até 1 dia de trabalho, para finalizar a funcionalidade contemplada naquela história. Um ponto importante a ser considerado ao estabelecer as tarefas de uma história é que, idealmente, toda a equipe deve trabalhar no desenvolvimento dela. Dessa forma, todos podem compartilhar o conhecimento relacionado àquela história e a produtividade da equipe também aumenta.

E na sua equipe? Os conceitos de História e Product Backlog já estão bem compreendidos? Aproveite para assistir ao tutorial sobre Product Backlog da Universidade Scrum.

* Para saber mais sobre os papéis do Scrum, veja o post Quais são os papéis do Scrum? – FAQ Scrum

The post Histórias e o Product Backlog – FAQ Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.