Posts com Tags Product Backlog

O Sprint e os Artefatos do Scrum

No Scrum existem vários Time-Boxes que são utilizados para gerar regularidade. Os Time-Boxes mais importantes no Scrum são: a sprint planing meeting(planejamento de versão), o sprint, a reunião diária, a revisão do sprint e a retrospectiva do sprint. O coração do scrum para Schwaber (2010) é o sprint, que é uma iteração de um mês ou menos dentro da qual é feito um esforço de desenvolvimento. Ao final de cada sprint tem se como resultado um pequeno incremento de software que é potencialmente entregável após isto a equipe pode iniciar um novo sprint.

O Scrum utiliza quatro artefatos principais. O backlog de produto que é uma lista priorizada de tudo que pode ser necessário desenvolver em  um software. O backlog de sprint que é uma lista de tarefas  priorizadas no backlog de produto  e que ao final de uma sprint, resultará em um incremento. Um burndown que é um gráfico através do qual é medido a velocidade do time. Um burndown  de release que mede o product backlog restante ao longo do tempo de um plano de release. E um burndown de sprint mede os itens do backlog de sprint restantes ao longo do tempo de um sprint (SHWABER, 2010).

Figura 4 – O Ciclo de Vida da Metodologia Scrum

Adaptado de: 3MONTHS, 2011

A Figura 4 representa o ciclo de vida desenvolvimento de software utilizando a metodologia Scrum. Nela pode-se observar que o product owner e a equipe, baseados na visão inicial do produto, definem as histórias a serem desenvolvidas, ou seja o backlog de produto. Este por sua vez é dividido em pequenas “histórias” menores, pela equipe e pelo product owner. Posteriormente o product owner escolhe então quais dessas histórias serão priorizadas para o sprint originando assim um backlog de sprint.

Após definir-se o backlog do sprint a equipe realiza uma reunião na qual estabelece as suas metas durante o sprint; trata-se da sprint plane meeting (reunião de planejamento do sprint) onde estabelece suas metas durante o sprint. O próximo passo da espiral representa o incremento produzido durante o sprint. É nessa etapa que ocorre o desenvolvimento do produto. Uma vez que o novo incremento foi desenvolvido, devidamente testado e integrado ao sistema a equipe faz uma revisão do sprint nela a equipe apresenta o que foi realizado durante o sprint e demonstra as novas funcionalidades incorporadas. O product ownwer testa, para verificar se o item atende suas expectativas e determina se a meta do sprint foi ou não atingida.

O próximo passo é a retrospectiva do sprint, nela são levantados o que aconteceu de bom, o que foi ruim e o que deve melhorar. O objetivo dessa reunião é trazer melhoria contínua ao trabalho da equipe. Feito isso o backlog de produto é atualizado e o ciclo é reiniciado. Acima do circulo maior, que representa o sprint, tem se outro circulo menor que representa a iteração diária onde são cumpridas as metas diárias que compõem o Sprint. Durante o sprint diário, os membros do time fazem uma pequena reunião de 15 minutos (reunião scrum diária), sempre de pé, no mesmo horário e local. Nela cada membro conta o que fez desde a última reunião o que pretende fazer e se está tendo algum problema.

De acordo com Kniberg (2007) o Scrum fornece bases para a gestão do processo de desenvolvimento, mas não se preocupa com como será feito o desenvolvimento. O XP por sua vez sugere as práticas a serem seguidas para o desenvolvimento de um projeto e não se preocupa com a gestão. Sendo assim muitas equipes ágeis utilizam XP e Scrum juntos, onde um fornece boas práticas de desenvolvimento e o outro, boas práticas de gestão. Devido a essa extensibilidade os autores agilistas tendem a adotar o termo framework e não metodologia quando se referem a elas.

Novas metodologias surgem o tempo todo e as vezes pode parecer dificil escolher uma “correta”. Nesse sentido, Henrajani (2007) afirma que todo projeto deve ter alguma estrutura de processo básico que precisa seguir. Não ter nenhum processo é ruim, mas o excesso deles é igualmente ruim. Sendo assim cabe a equipe encontrar o equilibrio correto, considerando as necessidades do cliente, o tamanho do projeto e as metas da equipe.

Referências:

SCHWABER, Ken. Guia do Scrum. Scrum Alliance, 2010. Disponível em: < http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf >  acesso em 04 abr. 2011.

3MONTHS. Project Lyfecycle. Disponível em: < http://blog.3months.com/wp-content/uploads/2010/01/project_lifecycle_v1cc.png > acesso em: 04 abr. de 2011.

HENRAJANI, Anil. Desenvolvimento ágil em Java com Spring, Hibernate e Eclipse. São Paulo: Pearson Prentice Hall, 2007.

KNIBERG, Henrik. Scrum e XP Direto DasTrincheiras: Como nós fazemos Scrum. InfoQueue, 2007. Disponível em < http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches > Acesso em 14 nov. 2010.

KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum : Obtendo o Melhor de Ambos. InfoQueue, 2007. Disponível em <http://www.infoq.com/br/minibooks/kanban-scrum-minibook> Acesso em 14 nov. 2010.

Tags: , , , , , , , ,

A Equipe e os Papéis no Scrum

O framework Scrum é formado por times scrum e os papéis a estes associados, time boxes (eventos com duração fixa) artefatos e regras. Os times scrum são configurados de modo a otimizar a flexibilidade e a produtividade. Por esse motivo os membros de um Time Scrum são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada grupo possui três papéis:

  • o Product Owner(PO) que é o responsável por garantir o retorno sobre o investimento (return on investment – ROI) do projeto. Ele representa e defende os interesses do cliente, é ele quem cria, prioriza e mantém a lista de funcionalidades (Backlog de Produto) do projeto. Para exercer a função de Product Owner deve-se ter visão estratégica, disponibilidade, criatividade, poder de persuasão, ser comunicativo e conhecer bem as necessidades dos clientes  –  muitas vezes esse papel pode ser assumido pelo cliente ou um representante do mesmo;
  • o Scrum-Master que é o responsavel por garantir  o uso do Scrum, remover impedimentos e proteger a equipe das interferências externas. Ele auxilia o product owner no processo de priorização dos requisitos. Deve ser responsavel, facilitador, humilde, comunicativo, influente e organizado.;
  • o Time Scrum que deve estimar o tempo e o esforço envolvido nos itens de projeto e definir as metas das Sprints, visando produzir produtos com alta qualidade e valor para o cliente. Deve ser multidisciplinar, comunicativo, comprometido, autogerenciado e capaz de resolver conflitos; normalmente é composto de 5 a 9 pessoas.

Tags: , , , , , , ,

O Ciclo de Vida do Framework Scrum

A figura acima representa o ciclo de vida do desenvolvimento de software utilizando o framework Scrum. Nela podemos observar que o Product Owner e a equipe, baseados na visão inicial do produto, definem as histórias a serem desenvolvidas, ou seja o Backlog de Produto.

Posteriormente quebram-no em pequenas “histórias” menores, originando vários Backlogs de Sprint. O Product Owner escolhe então quais histórias serão priorizadas para o Sprint.
Após definir o Backlog do Sprint a equipe realiza uma reunião na qual planeja e estabelece as metas para o Sprint; trata-se da Sprint Plane Meeting (Reunião de Planejamento do Sprint). Na próxima etapa ocorre o desenvolvimento do produto. Uma vez que o novo incremento foi desenvolvido, devidamente testado e integrado ao sistema a equipe faz uma Revisão do Sprint nela a equipe apresenta o que foi realizado durante o Sprint e demonstra as novas funcionalidades incorporadas. O Product Ownwer testa, para verificar se o item atende suas expectativas e determina se a meta do Sprint foi ou não atingida.

O próximo passo é a Retrospectiva do Sprint, nela são levantados o que aconteceu de bom, o que foi ruim e o que deve melhorar. O objetivo dessa reunião é trazer melhoria contínua ao trabalho da equipe. Feito isso o Backlog de Produto é atualizado e o ciclo é reiniciado. Acima do circulo maior, que representa o Sprint, tem se outro circulo menor que representa a pequena reunião de 15 minutos (Reunião Scrum Diária), realizada pela equipe sempre no mesmo horário e local. Nela cada membro conta o que fez desde a última Daily Scrum, o que pretende fazer e se está tendo algum problema.

Tags: , , , , , , , , , , ,

O Scrum

O Scrum é um framework de desenvolvimento de software, criada por Jeff Sutherland no início da década de 1990. Muitos de seus fundamentos foram incorporados da industria automobilistica japonesa. Assim como o XP é conhecida e utilizada  mundialmente.

O Scrum (nome derivado de uma formação tática adotada no jogo de rugby) é uma metodologia ágil que foi desenvolvida por Jeff Sutherland e sua equipe no início dos anos 90. Posteriormente Shwaber e Beedle aperfeiçoaram os métodos do scrum. Os pricípios do Scrum são coerentes com as ideias do Manifesto Ágil. Por esse motivo, assim como no  XP, o Scrum também visa maximizar a comunicação e o compartilhamento de conhecimento, minimizar a supervisão, adaptar-se de forma ágil as mudanças, produzir sucessivos incrementos de software, valorizar os testes e adotar uma documentação minimalista, geralmente feita após o final de cada iteração. Enfatiza ainda o uso de um conjunto de “padrões de processo de software” que se mostraram eficientes para projetos com prazos curtos, requisitos mutáveis e negócio crítico (PRESSMAN, 2006).

Nos screencasts abaixo, e compreenda um pouco mais os conceitos do  framework Scrum.







Referências:

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

Tags: , , , , ,