Início do projeto
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 realizar o trabalho e gerenciar seu progresso em direção às metas de negócios acordadas com o Product Owner.
O Scrum Master é o responsável por garantir que os impedimentos que o Time de Desenvolvimento encontre 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 atingir 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 é o mais neutro 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, a fim de reduzir os riscos de decisões tardias que invalidem o que já foi produzido. Também pode ser necessário criar ou adaptar uma infraestrutura que sirva de suporte ao desenvolvimento do produto.
A ideia é gerar apenas o mínimo necessário para reduzir os riscos, 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, têm mais detalhes para serem desenvolvidos primeiro. Os itens mais abaixo têm, gradativamente, menos detalhes.
O Product Backlog inicial pode ser longo, abrangendo desde itens pequenos e bem detalhados até outros grandes e vagos. Mas ele também pode conter apenas a quantidade necessária de itens para 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).
Planejamento do Sprint
O Sprint se inicia com a reunião de Sprint Planning (ou Planejamento de Sprint), na qual se planeja o trabalho a ser realizado no próprio Sprint. Nessa reunião, o Time de Desenvolvimento e o Product Owner negociam, com base nos itens do alto do Product Backlog, o que será desenvolvido.
Ou seja, facilitados pelo ScrumMaster, eles selecionam um conjunto de itens do alto do Product Backlog que julgam ser capazes de desenvolver na duração do Sprint, o que é apenas uma previsão.
E então estabelecem um objetivo ou meta de negócios a ser alcançada com o desenvolvimento desses itens, chamada de Meta do Sprint. O Time de Desenvolvimento, então, se compromete com atingir essa Meta do Sprint.
Organizando os itens para o planejamento de sprint
É importante que os itens do Product Backlog estejam preparados para que a reunião de Planejamento de Sprint seja eficiente e produtiva. Itens que chegam à reunião sem detalhes suficientes, por exemplo, podem colocar todo o Sprint em risco.
Exemplo de Definição de Preparado para um Planejamento de Sprint
Para garantir que esses itens estejam preparados para serem discutidos na reunião de Sprint Planning, pode-se criar e utilizar uma Definição de Preparado. São critérios claros que definem o que é necessário para que um item esteja preparado para ser colocado em desenvolvimento.
Caso um Time de Scrum opte pelo uso de uma Definição de Preparado, o Time de Desenvolvimento passa a ter a prerrogativa de recusar, na reunião de Sprint Planning, um item que não esteja preparado conforme essa definição.
Além do detalhamento necessário, outros critérios da Definição de Preparado podem incluir, por exemplo, que o item seja pequeno o suficiente e possua os Critérios de Aceitação definidos, entre outros.
No primeiro Sprint, o Time de Desenvolvimento ainda não tem dados para gerar métricas sobre sua capacidade de trabalho. Ele pode estimar os itens do Product Backlog individualmente para possibilitar a futura obtenção dessas métricas úteis para o planejamento.
Story Point é uma unidade muito utilizada por times ágeis em suas estimativas. A partir dos Sprints seguintes, o Time de Desenvolvimento pode utilizar como parâmetro a média da quantidade de trabalho entregue nos últimos Sprints, medida em Story Points.
Outra forma de obter essas métricas é dividir e deixar sempre os itens do Product Backlog bem pequenos, com pouca variação de tamanho entre si, para, então, contar o número de itens entregues nos últimos Sprints e calcular a média.
Em qualquer caso, a quantidade de trabalho esperada para ser realizada por Sprint é chamada de Velocidade do Time de Desenvolvimento.
Exemplo de Quadro de Tarefas (Sprint Backlog) para um Planejamento de Sprint
Além de selecionar, juntamente com o Product Owner, os itens e definir uma meta, o Time de Desenvolvimento também cria um plano de como o que foi selecionado será desenvolvido. Esse plano geralmente é expresso por tarefas a serem realizadas durante o Sprint.
O conjunto de itens selecionados e seu respectivo plano é chamado de Sprint Backlog e geralmente é representado em um Quadro de Tarefas.
Desenvolvimento com Scrum
Vamos falar sobre desenvolvimento com Scrum? Após a reunião de Sprint Planning, inicia-se o trabalho de desenvolvimento propriamente dito dos itens do Sprint Backlog. Os membros do Time de Desenvolvimento definiram, durante a reunião de Sprint Planning, como o trabalho será realizado. Agora, são os responsáveis por se auto-organizar para realizar esse trabalho e por monitorar seu progresso rumo à Meta do Sprint.
O desenvolvimento inicia-se a partir do primeiro item do Sprint Backlog, que é o item mais importante para se atingir a Meta do Sprint. Os diferentes membros do Time de Desenvolvimento realizam as tarefas necessárias, comunicando-se e colaborando sempre que necessário. Ao completar o primeiro item, seguem juntos para o item seguinte, e assim por diante.
Cada dia de trabalho de desenvolvimento, os membros do Time de Desenvolvimento se reúnem por, no máximo, quinze minutos, preferencialmente no mesmo horário e no mesmo local, para a reunião do Daily Scrum. O objetivo da reunião é garantir a visibilidade de seu trabalho entre eles e planejar, informalmente, o próximo dia de trabalho. O ScrumMaster pode, se necessário, facilitar a reunião, mas sua presença não é obrigatória.
A reunião de Daily Scrum é um ótimo momento para atualizar o Gráfico de Sprint Burndown, uma ferramenta que o Time de Desenvolvimento pode utilizar para monitorar seu progresso no Sprint. Esse gráfico possui no eixo x os dias de trabalho no Sprint e no eixo y a quantidade de trabalho restante, que pode ser medida pela quantidade de tarefas restantes ou por algum tipo de estimativa realizada sobre as tarefas, por exemplo. O Time de Desenvolvimento marca no gráfico a quantidade de trabalho restante no dia corrente.
No seu dia a dia de trabalho, é comum que os membros do Time de Desenvolvimento se deparem com desafios. Sempre que encontram algo que os impede de realizar seu trabalho, eles avisam ao ScrumMaster, que inicia imediatamente a remoção desse impedimento.
Um Product Owner acessível ao longo do Sprint permite que o Time de Desenvolvimento esclareça dúvidas de negócios sobre os itens em desenvolvimento que naturalmente surgem. Ao mesmo tempo, o Product Owner mantém contato constante com os clientes do projeto e demais partes interessadas para entender suas necessidades ou objetivos de negócios mais urgentes, colher feedback e, assim, atualizar o Product Backlog, em um trabalho contínuo de Refinamento do Product Backlog.
O Product Owner também busca interagir com o Time de Desenvolvimento para preparar itens para o Sprint seguinte. Para realizar esse Refinamento do Product Backlog, eles podem se reunir em sessões agendadas ou esse trabalho pode ser contínuo ao longo do Sprint. Em qualquer caso, pode-se utilizar uma Definição de Preparado como critério para definir o que significa um item estar preparado.
Encerramento do Sprint
Ao final normal do Sprint, o Time de Desenvolvimento deverá ter gerado, a partir dos itens do Sprint Backlog, um Incremento do Produto entregável, que representa valor visível para os clientes do projeto. Ser entregável significa que nenhum trabalho adicional é necessário para que esse Incremento do Produto seja entregue aos clientes do projeto. Entregar ou não o Incremento ao final do Sprint, no entanto, é uma decisão de negócios e, mesmo que já seja possível, cabe ao Product Owner decidir quando fazê-lo.
Caso, no transcorrer do Sprint, a Meta do Sprint perca o seu sentido, o Product Owner pode decidir cancelar o Sprint, antecipando o seu encerramento. Essa é uma situação de exceção e raramente ocorre.
No último dia do Sprint, Product Owner e Time de Desenvolvimento se reúnem em duas reuniões consecutivas de inspeção e adaptação, ambas facilitadas pelo Scrum Master. Na primeira reunião, de Sprint Review, faz-se a inspeção e adaptação do produto, enquanto, na reunião de Sprint Retrospective, faz-se a inspeção e adaptação da forma de trabalhar do Time de Scrum.
O Product Owner convida os clientes do projeto e demais pessoas relevantes para a reunião de Sprint Review, para que possam prover feedback sobre o que foi produzido durante o Sprint. Nessa reunião, o Time de Desenvolvimento e o Product Owner apresentam e demonstram para os presentes o que foi produzido no Sprint, para então obterem feedback deles.
Definição de Pronto
Exemplo de Definição de Pronto
A Definição de Pronto é um acordo entre o Product Owner e o Time de Desenvolvimento sobre o que é necessário para que um item ou o Incremento do Produto, como um todo, seja considerado pronto e, assim, passe a fazer parte do produto em desenvolvimento. A definição de Pronto é a mesma para todos os itens do Product Backlog que representem funcionalidades a serem desenvolvidas. Idealmente, ela é utilizada para garantir que o Incremento do Produto gerado no Sprint seja entregável.
O Time de Desenvolvimento utiliza a Definição de Pronto ao criar o plano de desenvolvimento dos itens na reunião de Sprint Planning, e o Product Owner a utiliza para verificar, no final do Sprint, se os itens estão realmente prontos. Apenas os itens prontos, de acordo com a Definição de Pronto, podem ser apresentados na reunião de Sprint Review.
O feedback obtido dos clientes e de outras pessoas relevantes presentes na reunião de Sprint Review é utilizado pelo Product Owner como matéria-prima para alterações no Product Backlog, ou seja, para modificar o produto em desenvolvimento de forma a melhor atender às necessidades dos clientes.
Após a reunião de Sprint Review, o Time de Desenvolvimento e o Product Owner realizam a reunião de Sprint Retrospective, facilitada pelo ScrumMaster. Nela, ambos identificam o que foi bem no Sprint corrente, e que por essa razão pode ser mantido no próximo Sprint, e o que pode melhorar, buscando formas práticas e traçando planos de ação para fazê-lo. O objetivo desse processo de melhoria contínua é tornar o Time de Scrum cada vez mais efetivo.
Uma vez terminada a reunião de Sprint Retrospective, o Sprint se encerra. Um novo Sprint inicia-se imediatamente após o término da anterior (respeitando, claro, os fins de semana e feriados).
Entregas
Sempre que o Incremento do Produto ou a soma de Incrementos do Produto representar valor suficiente e já puder ser utilizada, é importante que chegue a seus usuários o mais rápido possível. A isso chamamos Release!
Por meio de entregas frequentes, o time de Scrum pode obter feedback dos usuários do produto e, assim, reduzir os riscos e produzir o produto certo. O Time de Scrum pode também dar um senso de progresso do projeto aos seus clientes e demais partes interessadas e pode prover retorno ao investimento realizado pelos clientes do projeto.
A estratégia de entregas a ser utilizada no projeto é definida pelo Product Owner. Ele decide quando e com que frequência elas serão realizadas e quem as receberá — algum grupo de usuários que pode experimentar o produto e prover feedback ou, sempre que possível, o usuário final. Assim, o Product Owner decide se a entrega será realizada cada vez que um item estiver pronto (em entrega contínua), ao final de cada Sprint, sempre que ele julgar adequado ou após alguns Sprints, visando um objetivo ou meta de negócios definida.
Nesse último caso, pode-se realizar uma reunião de Release Planning para cada entrega. Essa reunião é realizada em algum momento antes do início dos trabalhos para a entrega correspondente e, portanto, deve acontecer durante o último Sprint do Release anterior (ou durante o pré-jogo, para a primeira entrega).
Na reunião de Release Planning, Product Owner e Time de Desenvolvimento estabelecem o Plano de Release, que contém uma data aproximada de entrega, um objetivo ou meta a ser atingido, chamado de Meta da Release, e um conjunto de itens selecionados a partir do alto do Product Backlog. Essa reunião não substitui as de Sprint Planning que serão realizadas para cada Sprint da Release.
O progresso em direção à data de entrega e, portanto, ao cumprimento da Meta da Release é inspecionado Sprint a Sprint, e a ferramenta mais utilizada para esse propósito é o Gráfico de Release Burndown. Esse gráfico possui no eixo x os Sprints da Release e no eixo y a quantidade de trabalho restante, que pode ser medida pela quantidade de itens restantes entre os previstos para a Release ou por estimativas realizadas sobre os itens, por exemplo. O Product Owner marca no gráfico a quantidade de trabalho restante ao final de cada Sprint, momento em que o Plano da Release é revisto. Outras ferramentas, como o Gráfico de Release Burnup, podem ser utilizadas em seu lugar.
Exemplo de Release Burndown
Final do Projeto
Um projeto, em geral, possui uma duração determinada. Na realidade, um projeto pode ser encerrado por diversas razões, dependendo do contexto: o tempo do contrato expirou, o valor suficiente foi entregue aos clientes do projeto, o contrato permite que o projeto seja interrompido, o orçamento do projeto acabou ou o contrato foi cancelado, entre outras.
No momento em que o projeto passa a ser considerado terminado, espera-se que as necessidades ou objetivos de negócios de maior importância já tenham sido entregues. O projeto terá sido bem-sucedido se, por meio de suas entregas frequentes, a Visão do Produto tiver sido alcançada.
Após o término normal de um projeto, geralmente é necessária sua manutenção, em uma fase que podemos chamar de “pós-jogo”. Embora não haja fórmula definida para esse trabalho, sabe-se que o uso de Scrum, por suas características, não costuma ser a melhor opção. Métodos orientados a pedidos ou tickets, como o Kanban, criado por David Anderson, geralmente são mais apropriados para essa fase do projeto.
