O projeto para o desenvolvimento de um produto se inicia para suprir algum objetivo ou necessidade de negócios, seja de um cliente específico, de um grupo de clientes ou visando uma oportunidade de mercado. A Visão do Produto é a forma mais utilizada para traduzir esse objetivo a ser alcançado.
Desenvolvimento de produto e o Time Scrum
Product Owner é o responsável por definir o produto iterativa e incrementalmente. Ele deve definir, comunicar e manter a Visão do Produto relativamente constante ao longo do projeto.
O Product Owner é único. Ele trabalha com os clientes do projeto e com quaisquer outras partes interessadas que possam contribuir para o entendimento e definição da Visão do Produto.
O grupo de partes interessadas do projeto também inclui os próprios usuários do produto, que receberão ao longo do desenvolvimento partes prontas do produto para serem utilizadas.
Antes do desenvolvimento do produto começar, o projeto geralmente passa por uma fase inicial na qual definições e preparativos básicos são realizados. Essa fase possui uma duração que depende do que e de quanto é necessário se definir e preparar.
É chamada por alguns de “pré-jogo” ou, por outros, equivocadamente de “Sprint Zero”, já que o trabalho realizado nessa fase, como será visto mais adiante, de forma alguma caracteriza um Sprint.
Ainda nessa fase inicial, decide-se quem serão as pessoas a trabalhar no projeto, que formarão o Time de Scrum: além do Product Owner, são elas os membros do Time de Desenvolvimento e o ScrumMaster.
Esse processo de escolha varia de organização para organização. Entre diferentes possibilidades, pode haver um departamento responsável pela seleção de pessoal, pode-se partir de um Product Owner ou ScrumMaster que escolhe na organização o resto do time, ou se pode designar para o projeto um time que já trabalha junto, por exemplo.
Papéis do Scrum
O Time de Desenvolvimento realiza o trabalho de desenvolvimento do produto. Ele é multidisciplinar, o que significa que possui, em seus membros, todo o conhecimento necessário para realizar esse trabalho.
O Time de Desenvolvimento é também auto-organizado, ou seja, ele próprio define como irá realizar o trabalho e gerenciar seu progresso em direção a metas de negócios acordadas com o Product Owner.
O ScrumMaster é o responsável por garantir que os impedimentos que o Time de Desenvolvimento encontrar em seu trabalho sejam removidos, atuando quando necessário como um agente de mudança na organização. Esses impedimentos geram o risco de não atingirem os objetivos.
O ScrumMaster está presente e age como um facilitador em todas as reuniões do Scrum, facilita o trabalho do dia a dia do Time de Desenvolvimento e facilita as interações entre o Time de Desenvolvimento e o Product Owner.
Ele também ensina Scrum ao Time de Scrum e a se auto-organizarem. O ScrumMaster é tão neutro quanto possível e possui soft skills, ou seja, competências comportamentais e pessoais, para realizar seu trabalho.
Ainda nessa fase de pré-jogo, pode ser necessário especificar uma arquitetura básica de produto, de forma a reduzir os riscos de decisões tardias que invalidariam o que já foi produzido. Pode ser também necessário criar ou adaptar uma infraestrutura que servirá de suporte para o desenvolvimento do produto.
A ideia é gerar apenas o mínimo necessário e suficiente para reduzir os riscos, mas sem engessar o desenvolvimento do produto nem gerar grandes desperdícios.
O Product Backlog é uma lista priorizada: exemplos utilizando software, planilha ou notas adesivas
Antes do início do desenvolvimento, o Product Owner inicia, a partir da Visão do Produto, a criação de uma lista ordenada (priorizada), incompleta e dinâmica de itens que representam o que ele acredita que será produzido ao longo do projeto. Essa lista é chamada de Product Backlog.
Os itens do alto do Product Backlog são os mais importantes naquele momento e, por essa razão, possuem mais detalhes para serem desenvolvidos primeiro. Os itens mais abaixo têm gradativamente menos detalhes.
O Product Backlog inicial pode ser longo, contendo desde itens pequenos e bem detalhados até itens grandes e vagos. Mas ele também pode conter apenas uma quantidade de itens necessária para se iniciar o desenvolvimento. O Product Backlog evoluirá ao longo de todo o projeto e será frequentemente modificado com a adição, subtração, reordenamento e modificação de seus itens.
User Story é a forma preferida de times Ágeis para representar cada um dos itens do Product Backlog que tratam de necessidades ou objetivos de negócios, descrevendo-os sob o ponto de vista dos usuários do produto e de uma forma concisa, simples e leve.
A User Story não é, no entanto, parte do framework Scrum, e cabe ao Time de Scrum definir a forma que melhor lhe serve para representar o itens do Product Backlog.
Exemplo de padrão para User Stories
O Time de Scrum então está pronto para iniciar o primeiro de vários ciclos do projeto, nos quais o trabalho de desenvolvimento do produto será realizado. Esses ciclos são chamados de Sprints. O projeto com Scrum acontece Sprint após Sprint. Assim, ao terminar um Sprint, inicia-se imediatamente o seguinte.
Os eventos do Scrum — o próprio Sprint e as reuniões de Sprint Planning, de Daily Scrum, de Sprint Review e de Sprint Retrospective — possuem uma duração máxima ou fixa definida, chamada de timebox. Os timeboxes são importantes, pois evitam o desperdício, limitando o tempo em que um objetivo deve ser alcançado, além de ajudar a criar um ritmo ou uma regularidade no trabalho realizado.
Pode-se ver o ciclo completo do Scrum na figura abaixo (Schwaber & Beedle, 2002; Schwaber, 2004).
Quer sabe mais sobre Agilidade?
- Agilidade
- Certified Scrum Professional (CSP)
- CSP: Formas de se conquistar pontos
- Kanban
- PMP: como solicitar PDUs ao PMI
- Scrum
- User Stories
