Metodologia Ágil, Framework Scrum – Parte IV

review2Scrum – Parte IV

Na terceira parte, vimos as duas cerimônias voltadas para planejamento e controle do desenvolvimento do produto. É hora de mostrar o que foi feito e aprender com acertos e erros.

Sprint Review

É a cerimonia que o Development Team apresenta as User Stories desenvolvidas para o Product Owner e o mesmo analisa o que foi feito e o que não foi feito baseado na definição de Pronto. É o momento também que o Development Team conversa com o Product Owner a respeito das dificuldades que tiveram na Sprint, bem como sobre as User Stories candidatas a entrarem na próxima Sprint em termos de valor de negócio. Neste momento também é quando o Scrum Team também pode/deve sugerir oportunidades de negócio que apareceram de Sprints passadas.

Ao final, tem-se um incremento do produto aprovado ou não pelo Product Owner, baseado nos critério de Pronto e no Objetivo da Sprint, e temos também um Product Backlog revisado. Isso fornece visibilidade a todos do desenvolvimento do produto. Novamente, o princípio de Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto está sendo satisfeito e também Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Essa reunião deve ter duração de 1 hora por semana de Sprint.

retrospectiveSprint Retrospective

É a cerimonia de visão do processo como um todo. Ocorre após a Sprint Review e deve ter uma duração de 45 min por semana de Sprint. É nessa reunião que o Scrum Team discute a respeito de pessoas, relacionamentos, processos e ferramentas. É uma reunião aberta, onde todos devem expressar suas opiniões a fim de implementar melhorias para as próximas Sprints. As melhorias levantadas devem ir para um plano de ação com itens a serem melhorados. Um dos objetivos é melhorar ao ponto de alcançar a auto-organização e uma equipe funcional de forma plena. É nessa reunião que é satisfeito o princípio Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Seguindo a teoria do Scrum, todos os eventos no fornece uma forma de Inspeção e Adaptação e os artefatos, transparência para o Scrum Team e interessados em geral.

Como vimos, o Scrum é um framework que não nos diz como?, nos diz o que?. Os processos que iremos executar, as ferramentas que iremos utilizar, somos livres para escolher.

Isso satisfaz o princípio de Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho e Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. Esse princípio especificamente, deixa à critério do time decidir o que pretender fazer. Se for suficiente para determinado produto, então é o certo. Os projetos/produtos são diferentes, cada qual com suas particularidades, não precisa ser igual para todos.

E por fim, com as definições dos papéis e das cerimonias, o que se pretende é satisfazer o princípio de que Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

Referências:
The Scrum Guide – Scrum.org
Scrum e XP direto das das Trinceiras InfoQ

Startseite


http://manifestoagil.com.br

Por FERNANDO MORALLES

Postado em: 27 de março de 2013

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário