Posts com Tags Product Owner(PO)

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: , , , , , , ,