Reunião de planejamento da sprint (Sprint planning meeting)

A reunião de planejamento da sprint é uma reunião crítica, provavelmente a mais importante no Scrum e servirá para gerar confiança suficiente ao Product Ownerpara que apoie o time de desenvolvimento e deixe-o livre para atuar dentro do planejamento.

Esta reunião possui um time-box com no máximo oito horas para uma sprint de um mês de duração. Para sprints menores, este evento deve ser proporcionalmente menor. O envolvimento do Scrum Master se faz necessário para que também contribua com o produto final. O Scrum Master ajuda a garantir que a reunião ocorra, que os participantes entendam seu objetivo e ainda ensina o Time Scrum a se manter dentro dos limites do time-box .

De acordo com Schwaber e Sutherland (2016, p. 9), “o número de itens selecionados do Backlog do Produto para a sprint é o único trabalho do Time de Desenvolvimento. Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima sprint”. Os autores indicam que as entradas da reunião de planejamento da sprintincluem:

• o Backlog do Produto;
• o mais recente incremento do produto;
• a capacidade projetada do Time de Desenvolvimento durante a sprint;
• o desempenho passado do Time de Desenvolvimento.

Cada sprint é uma iteração que segue um ciclo (PDCA). Para desenvolver um determinado produto, é possível ter inúmeras sprints. Ao final de cada sprint bem-sucedida a equipe terá produzido um incremento potencialmente integrável, quer dizer, com qualidade, testado, completo e pronto, por isso a reunião de planejamento é tão importante. Nesta reunião a meta da sprint é definida. Há um provérbio popular que diz: “Se você não sabe em qual porto quer chegar, não importa a direção dos ventos”... Então definir uma meta é essencial ao sucesso da sprint.

A meta de uma sprint deve ser SMART :

SMART.

Fonte: elaborado pelos autores

A reunião de planejamento da sprint deve buscar responder as seguintes questões:

• Qual é o objetivo (ou meta) da sprint?
• O que pode ser entregue como resultado do incremento da próxima sprint?
• Como o trabalho necessário para entregar o incremento será realizado?

Reunião de planejamento da sprint.

Fonte: RIBEIRO (2013)

Vamos identificar os envolvidos e o fluxo de atividades na reunião de planejamento da sprint , com base nestas perguntas, de acordo com Schwaber e Sutherland (2016):

• O Time de Desenvolvimento identifica as funcionalidades que serão desenvolvidas durante a sprint. O Product Owner promove um debate sobre o objetivo que a sprintdeve alcançar e os itens de Backlog do Produto que, se completados na sprint, alicerçarão este objetivo ou meta. Todo o Time Scrum colabora para que ocorra o claro entendimento do trabalho da Sprint.
• Após o Time de Desenvolvimento identificar os itens de Backlog do Produto que irá entregar na sprint, o Time Scrum determina a meta da sprint. A meta da sprint orienta o Time de Desenvolvimento em relação aos motivos para a construção do incremento.
• Com o objetivo da sprint e os itens do Backlog do Produto da sprint definidos, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a sprint, acompanhados do plano de entrega destes itens, compõem o Backlog da Sprint ( Sprint Backlog) .
• O Time de Desenvolvimento se auto-organiza para realizar todo o trabalho do Backlog da Sprint. Se o Time de Desenvolvimento acredita que haja excesso ou escassez de trabalho, os itens do Backlog da Sprint podem ser renegociados com o Product Owner.
• No final do planejamento da sprint, o Time de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da sprint e criar o incremento previsto.

Sprint

Sprint é um time-box de duas a quatro semanas, ou seja, limitada a um mês, no qual a equipe ou time do projeto irá produzir uma parte do produto. Recomenda-se que uma sprint deve ser empreendida por um time multidisciplinar com no máximo nove componentes.

A sprint é a unidade básica de desenvolvimento do Scrum. Sprints têm durações coerentes em todo o esforço de desenvolvimento. Uma nova sprint se inicia imediatamente após a conclusão da sprint anterior.

O conceito de sprint envolve uma entrega constante de algo de valor ao cliente, diferente dos modelos tradicionais, em que se desenvolve um produto em um longo período de tempo e, apenas no final, o produto “pronto” é entregue ao cliente. No Scrum sempre é entregue uma “parte” do produto em pequenos intervalos de tempo. À medida que o “pronto” vai ocorrendo com frequência, os critérios de qualidade se tornam mais rigorosos.

Cada sprint deve ter uma meta específica que possa ser realizada naquele time-box específico. Tudo no Scrum deve ser delimitado pelo tempo, e a sprintsempre determinará o tempo visando um produto final comprometido com o negócio.

Os eventos Scrum são time-boxed .

Por Tashatuvango / shutterstock.com.

No contexto do Scrum, o empirismo está relacionado aos sprint s . Por exemplo: o prazo de duas a quatro semanas, na maioria dos casos atribuído para cada sprint, tem demonstrado ser suficiente para a maioria dos projetos. De fato, se o período de tempo aumenta muito, acaba-se por perder a agilidade...

Schwaber e Sutherland (2016, p. 8), elencam as seguintes características de uma Sprint:

• Durante uma sprint não são feitas mudanças que possam por em perigo o seu objetivo, as metas de qualidade não diminuem  e o escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento;
• Cada sprint pode ser considerada um projeto com horizonte não maior que um mês.
• Como os projetos, as sprint s são utilizadas para realizar algo. Cada sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto;
• Sprint s são limitadas a um mês corrido. Quando o horizonte da sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer.
• Sprint s permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprint s também limitam o risco ao custo de um mês corrido.

Curiosidade  

Uma sprint pode ser cancelada?

Uma sprint pode ser cancelada antes do time-boxed da sprint terminar. Somente o Product Owner tem a autoridade para cancelar a sprint, embora ele (ou ela) possa fazer isso sob influência dos stakeholders , do Time de Desenvolvimento ou do Scrum Master.

A sprint poderá ser cancelada se o objetivo da sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem.

Geralmente a sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da sprint, raramente cancelamentos fazem sentido.

Quando a sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado.

O cancelamentos de sprints consome recursos, já que todos tem que se reagrupar em outra reunião de planejamento da sprint para iniciar outra sprint. Cancelamentos de sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.

Fonte: SCHWABER; SUTHERLAND (2016, p. 5)

Eventos Scrum

No Scrum os eventos (ou cerimônias) criam uma rotina que evita a marcação de reuniões informais. Todos os eventos do Scrum são uma ocasião oportuna para se inspecionar e adaptar algum aspecto do produto e são time-boxed , ou seja, possuem uma duração máxima.

Os eventos foram criados para permitir que haja adaptação, dentro de transparência e inspeção criteriosa. A sprint funciona como um container para os eventos. 

 Eventos do Scrum

 

Fonte: quickscrumcrm.azurewebsites.net .

 

O Scrum define quatro eventos formais, contidos dentro dos limites da sprint, quais sejam:

• Reunião de planejamento da sprint ( Sprint Planning Meeting );
• Reunião diária ( Daily Scrum Meeting );
• Reunião de revisão da sprint ( Sprint Review Meeting );
• Reunião de retrospectiva da sprint ( Sprint Retrospective Meeting ).

Dentro das regras do Scrum está implícito que a não inclusão de qualquer um dos eventos pode resultar na redução da transparência e da perda de oportunidade para inspecionar e adaptar o produto em desenvolvimento.

De acordo com Schwaber e Sutherland (2016), uma vez que uma sprint se inicie, sua duração é fixada e não pode ser nem reduzida nem aumentada. Os outros eventos, no entanto, podem terminar sempre que o seu objetivo tenha sido alcançado, sem que haja perdas na qualidade do processo.

Development Team ou Time de Desenvolvimento

O Development Team ou Time de Desenvolvimento é composto por profissionais que realizam o trabalho de entregar uma versão do produto que seja funcional e que incrementa o produto “Pronto” ao final de cada sprint. Somente quem integra o time de desenvolvimento cria incrementos. Schwaber e Sutherland (2016, p. 6) elencam as seguintes características do Time de Desenvolvimento:

• Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;
• Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, como equipe, para criar o incremento do produto;
• O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa e não há exceções para esta regra;
• Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo;
• Times de Desenvolvimento não contém subtimes dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios;
• O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da sprint;
• Menos de três integrantes no Time de Desenvolvimento diminui a interação e resulta em um menor ganho de produtividade. Times de Desenvolvimento menores podem encontrar restrições de habilidades durante a sprint, gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável;
• Havendo mais de nove integrantes é exigida muita coordenação. Times de Desenvolvimento muito grandes geram muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint.

Os membros do time devem ser competentes em sua atividade.

Por REDPIXEL.PL / shutterstock.com

Todos os membros do time devem ser competentes para sua respectiva atividade. A pergunta para o Scrum Master, então, é: Você conhece bem todos os membros da equipe? Sabe quais são suas qualidades e limitações?

Alguns talvez até contestem dizendo que a equipe não tem limitações, mas temos que admitir que mesmo o melhor profissional não consegue ser perfeito em tudo. Alguns são ótimos em especificação e não tão bons em programação, enquanto outros, opostamente, são bons em programação e com limitações em especificação.

A verdade é que o bom gestor ou líder conhece bem cada pessoa e procura extrair o melhor dos membros de sua equipe. Um time competente e afinado é essencial para que a agilidade em todas as etapas da metodologia seja mantida, e as entregas, realizadas dentro do planejado e com a qualidade desejada.

Uma situação muito comum em grandes projetos é a necessidade de se trabalhar com equipes mais numerosas. Isso pode ocorrer em consequência de vários fatores. Afinal, o frameworkScrum atende a qualquer tamanho de projeto.

Existem algumas sugestões sobre o que se considera ser o tamanho ideal de uma equipe, como um limite de nove componentes. Mas, na verdade, não pode existir tamanho predefinido, já que o Scrum é empírico, ou seja, aprendemos com ele à medida que o usamos e nos ajustamos a cada situação vivida.

No entanto, o próprio empirismo vai nos propor uma divisão da equipe em subequipes, levando o Scrum Master a preparar equipes menores e multidisciplinares. Nas reuniões poderão ocorrer alguns ajustes de forma que, ao invés de toda a equipe participar, apenas membros representantes de cada subequipe sejam convidados.

Voltamos a destacar: não há uma regra preestabelecida. Cada projeto, cada produto, cada dono do produto pode recomendar um ou outro procedimento.

Schwaber (2004) chama esta ação de “ Scrum of Scrums” e recomenda que estes times menores sejam autossuficientes, podendo entregar seus sprints de forma independente. Ele também sugere a “sprintzero”, que se refere ao caso em que uma equipe de engenheiros atuou apenas na definição inicial dos sprint s , e esta equipe técnica permitiu ao restante da equipe ter uma visão diferenciada do produto.

Malabarista

Fonte: Alexander_P / shutterstock.com

Contratando um Malabarista

Gerente de circo : Há quanto tempo você é malabarista?

Contratado : Há cerca de seis anos.

Gerente : Você pode segurar três bolas, quatro bolas e cinco bolas?

Candidato : Sim, sim, sim.

Gerente : Você trabalha com objetos em chamas?

Candidato : Certamente.

Gerente : ...facas, machados, caixas abertas e charutos, chapéus-coco?

Candidato : Eu posso fazer malabarismo com tudo.

Gerente : Você faz algum monólogo engraçado junto com o malabarismo?

Candidato : Faço e é hilariante.

Gerente : Bem, parece interessante. Eu acho que você está empregado.

Candidato : Humm.... Você não quer me ver fazendo malabarismo?

Gerente : Puxa, eu não pensei nisso...

(fonte: blogdoabu.blogspot.com.br )

Time Scrum: Dono do Produto, Scrum Master e Equipe de Desenvolvimento

Times Scrum são auto-organizáveis e multifuncionais. Times auto-organizáveis têm autonomia para escolher a melhor maneira de completarem seu trabalho, ao invés de se submeterem à direção de pessoas fora do time. Times multifuncionais reúnem todo o expertise necessário para completar o trabalho sem depender de pessoas de fora.

O modelo de time no Scrum tem características importantes, como flexibilidade e criatividade, além de serem bastante produtivos. Os times Scrum realizam entregas incrementais de produto “Pronto”, ou seja, entregam versões de forma que sempre haja um produto funcional disponível.

O Time Scrum é composto pelo Product Owner, Scrum Master e o Development Team .

Vejamos seus papéis a seguir.

Product Owner ou Dono do Projeto

Product Owner ou Dono do Projeto é a única pessoa responsável por gerenciar o Backlog do Produto. Embora ele possa delegar tarefas para o Time de Desenvolvimento, o Backlog do Produto continua sendo de sua responsabilidade. Caso alguém deseje alterar as prioridades do Backlog, primeiro deve conversar e convencer o Product Owner. De acordo com Schwaber e Sutherland (2016, p. 6), para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem. Ele sempre vai atualizar, priorizar e se preocupar em refinar o Product Backlog.

Scrum Master

O ScrumMaster tem a responsabilidade de remover os possíveis impedimentos que a equipe ou time possam ter e protege o Time de envolvimentos externos prejudiciais. Ele busca garantir o uso adequado do Scrum de forma que o Time adote as práticas e regras. Ele tem preocupação com a cultura organizacional, pois ela pode afetar o sucesso do projeto. O Scrum Master ajuda os que não pertencem ao Time Scrum a compreenderem quais são e como são as suas interações com o Time. Em seu papel de “servidor-líder”, o Scrum Master trabalha junto com o Product Owner, junto com o Time de Desenvolvimento e para a organização. 

O time Scrum.

Por OksanaAlex / shutterstock.com

 

Valores do Scrum

 

Quando os valores de comprometimento, coragem, foco, transparência e respeito são assumidos e vividos pelo Time Scrum, os pilares do Scrum de transparência, inspeção e adaptação tornam-se vivos e constroem a confiança para todos. Os membros do Time Scrum aprendem e exploram estes valores à medida que trabalham com os eventos, papéis e artefatos do Scrum.

O sucesso no uso do Scrum depende das pessoas se tornarem mais proficientes na vivência destes cinco valores. As pessoas se comprometem pessoalmente em alcançar estes objetivos do Time Scrum. O Time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis. Todos focam no trabalho da Sprint e nos objetivos do Time Scrum. O Time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a execução dos trabalhos. Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes (SCHWABER; SUTHERLAND, 2016, p. 5).

A figura apresenta o ciclo de vida do Scrum. Nela pode-se observar a interação entre os diversos elementos que compõem o framework e que estudaremos neste capítulo, quais sejam:

• Time Scrum (Product Owner, Scrum Master, Equipe de Desenvolvimento);
• Eventos Scrum (Sprint, Reunião de Planejamento da Sprint, Reunião Diária, Reunião de Revisão da Sprint, Reunião de Retrospectiva da Sprint);
• Artefatos Scrum (Product Backlog, Sprint Backlog).

Ciclo de vida Scrum.

Fonte: ned.unifenas.br .

Modelagem ágil com Scrum

Segundo seus criadores, Ken Schwaber e Jeff Sutherland, o Scrum é um framework ágil para a conclusão de projetos complexos. É um framework que permite que pessoas possam tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Mas o framework Scrum, muitas vezes, é visto como enganosamente simples. A partir deste conceito, caro aluno, vamos nos aprofundar no estudo deste método ágil de desenvolvimento de software. 

Visão geral do Scrum

O Scrum não é um processo padrão que descreve o que fazer em cada situação. Sua verdadeira eficiência é comprovada em trabalhos complexos, em que não há certeza do que irá ocorrer.

De acordo com Schwaber e Sutherland (2016, p. 3), o Scrum é:

• leve;
• simples de entender;
• extremamente difícil de dominar.

O Scrum é baseado em teorias empíricas de controle de processo, ou empirismo, cujas bases se fundamentam no fato de que o conhecimento é adquirido pela experiência e que as tomadas de decisão são baseadas no que é conhecido.

Ainda de acordo com os autores, o Scrum possui três pilares de controle de processo empírico, que sustentam sua implementação, e são assim definidas por eles:

• Adaptação : caso algum aspecto seja identificado como desvio, podendo levar o produto a algo inaceitável, o processo deve ser ajustado, e isso deve ser feito o mais rapidamente possível;
• Inspeção : os usuários devem inspecionar frequentemente os artefatos Scrum e verificar possíveis variações que comprometam seu progresso, mas este trabalho é mais adequadamente realizado se for deixado a cargo de inspetores especializados neste tipo de verificação;
• Transparência : todos os aspectos significativos dos processos devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer o uso de um padrão comum para que todos possam ter a mesma compreensão do que está sendo visto.

O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. O frameworkScrum é composto por membros do time Scrum associados a papéis, eventos, artefatos e regras. Cada um destes componentes serve a um objetivo específico e é essencial para o uso e sucesso do Scrum. As regras do Scrum integram os eventos, papéis e artefatos, administrando as relações e interações entre eles.