O FRAMEWORK SCRUM NA VISÃO DE FÁBIO CRUZ

[tab: Introdução]

O Scrum é um framework para desenvolver e manter produtos complexos que também pode ser utilizado no gerenciamento ágil de projetos que se destinam também a criação de produtos. O Scrum apesar de muito difundido e utilizado na área de desenvolvimento de software, pode muito bem ser utilizado no desenvolvimento de qualquer produto complexo, principalmente pela sua característica de ser um framework iterativo e incremental.

Nas últimas décadas o Scrum vem sendo extensivamente utilizado no mundo inteiro para:

• Pesquisar e identificar mercados viáveis, tecnologias e funcionalidades de produtos
• Desenvolver produtos e suas melhorias e evoluções constantes
• Liberar produtos e suas melhorias com alta frequência, podendo chegar a várias liberações diárias
• Desenvolver e sustentar a Nuvem, além de outros ambientes operacionais para o uso de produtos
• Sustentar e renovar produtos

O que reforça a flexibilidade e possibilidade de uso do Scrum são os inúmeros casos de utilizar do framework para desenvolver software, hardware, software embarcado, redes de funções iterativas, veículos autônomos, escolas, governo, marketing, gerenciar operações, e quase tudo que usamos no nosso dia-a-dia nas nossas empresas e nas nossas vidas.

O Scrum é muito efetivo na transferência de conhecimento de forma iterativa e incremental, por isso esta cada vez mais sendo utilizado para produtos, serviços e no gerenciamento da própria empresa.

A ideia principal do Scrum é que um pequeno time de pessoas pode tratar e resolver problemas complexos e adaptativos, enquanto entregam produtos de forma produtiva e criativa. O Scrum é fundamentado no controle de processos empíricos, mantendo o foco na entrega de valor de um negócio no menor tempo possível através do aperfeiçoamento da previsibilidade e do controle de riscos.

Uma das características mais conhecidas do Scrum é a que mostra que os trabalhos de desenvolvimento são divididos em ciclos repetitivos (iterações) e curtos (períodos de até 1 mês), permitindo que o produto possa ser modificado e adaptado corrigindo desvios encontrados (incrementos) mais rapidamente e com menor impacto.

O framework Scrum é simples de entender, e para ajudar você a compreendê-lo eu separei abaixo alguns tópicos que resumem o Scrum.

A ORIGEM DO SCRUM

Scrum é o nome de uma das jogadas do esporte conhecido como Rugby, tendo como principal característica a formação que pode ser visualizada na imagem acima, destacando o trabalho em equipe e o foco do time em um único objetivo.

É uma das jogadas mais conhecidas do Rugby, onde os jogadores disputam a reposição de bola, e onde é necessária a participação de todos os jogadores do time atuando em conjunto no mesmo objetivo, sendo que se um deles falhar, todos falham. Este trabalho em equipe é bem caracterizado no framework do Scrum, por isso o seu nome vem daí.

INTRODUÇÃO AO SCRUM

De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland, o Scrum vem sendo utilizado no desenvolvimento de produtos complexos desde os anos 90.

Scrum não é um processo ou uma técnica, mas sim um framework dentro do qual pode ser empregado diversos processos ou técnicas, tendo como papel fazer transparecer a eficácia relativa das práticas de desenvolvimento de produtos para que seja possível melhorá-las, enquanto provê um framework dentro do qual possa ser desenvolvido produtos.

FRAMEWORK

Já que o Scrum é um framework, e se fala muito nesta palavra hoje em dia, vamos conceituar seu significado para que todos tenham o mesmo entendimento.

Framework conceitual, ou arcabouço, é um conjunto de conceitos usado para resolver um problema de um domínio específico, sendo que existem dois tipos:

• Frameworks verticais, ou também conhecidos como especialistas, são confeccionados através da experiência obtida em um determinado contexto específico, tentando resolver problemas de um determinado domínio de aplicação.
• Frameworks horizontais não dependem do domínio de aplicação e podem ser usados em diferentes domínios.

Agora fica mais fácil ouvir a palavra framework e contextualizar o seu significado.

TEORIA

Scrum é fundamentado no controle de processos empíricos, empregando uma abordagem iterativa e incremental para otimizar a previsibilidade e o controle a riscos. Para se implementar qualquer controle a processos empíricos, são necessários os seguintes pilares de sustentação:

• Transparência

Este garante que os aspectos do processo que afetam o resultado devem ser visíveis e conhecidos aos que controlam o resultado, ou seja, quando alguém inspeciona o resultado e dá como pronto, isso deve ser equivalente a definição de pronto utilizada.

• Inspeção

Os artefatos e processos devem ser totalmente inspecionados com uma frequência suficiente para que as variações possam ser detectadas, considerando que o processo e artefatos podem ser modificados pelo próprio ato de inspecionar.

• Adaptação

Se durante a inspeção for determinada uma variação fora dos limites aceitáveis em um ou mais aspectos do processo, e que o produto resultante será inaceitável, o processo ou material produzido deve ser ajustado o mais rápido possível para que os desvios futuros sejam minimizados.

O Scrum prescreve 4 eventos formais para inspeção e adaptação:

• Planejamento da Sprint
• Reunião Diária
• Revisão da Sprint
• Retrospectiva da Sprint

CONTEÚDO

O framework Scrum consiste em um conjunto formado por papéis, eventos, artefatos e regras que são associados a times pequenos.

Os Times Scrum possuem papéis e responsabilidades associadas aos integrantes do time, que juntos realizam eventos específicos com uma duração fixa e objetivos pré-determinados.

Para realizarem estes eventos, o Time Scrum, usa como apoio artefatos específicos e aplicam regras que unem os eventos, os papéis e os artefatos.

Para saber mais do Scrum, entender melhor o seu conteúdo e saber como aplicá-lo, continue lendo os tópicos distribuídos nesta área exclusiva sobre Scrum clicando nas abas na parte superior desta página ou nos links a seguir:

• Papéis e responsabilidades
• Artefatos Scrum
• Planejamento da Versão de Entrega
• Sprint
• Planejamento da Sprint
• Estimativas
• Reunião Diária – Daily Meeting
• Revisão da Sprint – Review
• Retrospectiva da Sprint
• Manifesto Ágil

[tab: Papéis]

O Time Scrum é composto apenas por 3 (três) papéis, que são conhecidos como Product Owner, Time de Desenvolvimento e o ScrumMaster. O Time Scrum é auto-organizável e multifuncional.

Um time auto-organizável é aquela que escolhe qual é a melhor forma para completar o seu próprio trabalho, em vez de serem dirigidos por outros de fora do time, como um gestor.

Um time multifuncional é aquele que possui todas as competências necessárias para completar o trabalho do próprio time sem depender de outros que não fazem parte da equipe.

Vamos conhecer um pouco mais sobre cada um dos papéis e responsabilidades do Time Scrum:

PRODUCT OWNER

O Product Owner (Dono do Produto) também é conhecido como PO. O PO é o principal responsável pelo gerenciamento do Backlog do produto e por garantir o valor do trabalho realizado pelo Time, além de manter o Backlog do produto e garantir que este esteja visível para todos.

O Product Owner deve ser uma pessoa e não um comitê, e cada produto deve ter apenas 1 (um) PO, e este deverá ser o responsável por priorizar os itens do Backlog, e a organização deve respeitar suas decisões em relação ao backlog do produto.

Em outras palavras o Product Owner é o responsável por entender o negócio do produto, expressando claramente os itens de Backlog do Produto, além de refiná-lo, ordená-lo e garantir que seja visível, transparente, claro para todos, e que o time de desenvolvimento entenda o trabalho e realize-o entregando valor ao cliente.

Todos estes trabalhos podem ser feitos diretamente pelo PO, ou delegado ao Time de Desenvolvimento pelo próprio PO, no entanto o PO será sempre o responsável pelo trabalho ser realizado.

Dica: O Product Owner pode ser a nova função de um analista de negócio, analista de produto, gerente de produto, ou um membro do Time de Desenvolvimento, porém esta última função poderá reduzir a sua capacidade de lidar com as partes interessadas. O Product Owner nunca deve ser o ScrumMaster.

TIME DE DESENVOLVIMENTO

É um time de profissionais técnicos responsáveis por transformar o Product Backlog em incrementos de produto que possam ser entregues ao cliente. São chamados de desenvolvedores porque o Time de Desenvolvimento deve ser composto por todos os profissionais necessários para desenvolver um produto e completar todo o trabalho necessário para entregá-lo.

O Time de Desenvolvimento deve ser multidisciplinar, e todo o conhecimento interdisciplinar necessário para criar um incremento no trabalho deve estar distribuído entre os integrantes do Time de Desenvolvimento. Somente os integrantes do Time de Desenvolvimento criam incrementos.

Os integrantes do Time de Desenvolvimento podem possuir conhecimentos especializados, mas a responsabilidade pelos trabalhos realizados é todo o time, independente do trabalho ser especializado ou não. A mais importante das habilidades é a de trabalhar em equipe e transformar o item de backlog do produto um produto utilizável, por isso não há títulos no Time de Desenvolvimento e todos são conhecidos como Desenvolvedores, e não há exceção a esta regra.

O Time também não deve ser subdividido em “sub-times”, com o objetivo de realizar atividades específicas, e por serem auto-organizáveis, ninguém, nem mesmo o Scrummaster deve dizer ao Time como transformar o Backlog do produto em funcionalidades prontas para entrega. O Time precisa descobrir isso por si só.

O tamanho ótimo, ou ideal, para um Time de Desenvolvimento é de três a nove pessoas. Menos de três pessoas diminuem a interação e resultam em menor produtividade e muitas vezes faz com que o Time de Desenvolvimento não encontre todas as habilidades que precisa em seus integrantes. Mais de nove pessoas exige muita coordenação e gera muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e Scrummaster não são incluídos nesta conta, a menos que também executem trabalhos como parte integrante do Time de Desenvolvimento.

SCRUMMASTER

O Scrummaster, ou SM, é o responsável por garantir que o Scrum seja entendido e aplicado, promovendo e suportando o Scrum de forma a garantir que o Time Scrum esteja aderindo à teoria, práticas e regras do Scrum. O SM ajuda o Time Scrum e a organização a entenderem e adotarem o Scrum como um todo, e também capacita o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade.

O SM serve o Time Scrum ajudando-os a entender e usar a autoorganização e a interdisciplinaridade, a criar produtos de alto valor, além de facilitar os eventos necessários e remover impedimentos que possam impactar no progresso do Time de Desenvolvimento. Apesar desta ajuda o Scrummaster não deve gerenciar o Time Scrum, pois o Time Scrum deve ser auto-organizável.

O SM ainda é um Coach do Time de Desenvolvimento em ambientes onde o Scrum não é completamente entendido e adotado.

O SM serve o Product Owner ajudando-o a entender e praticar a agilidade, encontrar técnicas para o gerenciamento efetivo do Backlog do Produto, compreender a longo-prazo o planejamento do Produto no ambiente empírico, e a comunicar claramente a visão, objetivo e itens do Backlog do Produto para o Time de Desenvolvimento.

O SM serve a organização através da liderança e treinamento na adoção do Scrum, planejando implementações de Scrum e ajudando a todos, incluindo os Stakeholders a compreender e aplicar o Scrum e o desenvolvimento empírico de produto. O SM é o principal agente de mudança no aumento de performance dos Times Scrum e do trabalho com outros Scrummasters para aumentar a eficiência da aplicação do Scrum na organização.

Dica: O Scrummaster pode ser um membro do Time Scrum, porém isso frequentemente leva a conflitos quando o Scrummaster precisa escolher entre remover um impedimento e realizar uma tarefa. O Scrummaster nunca deve ser o Product Owner.

___________________________________________________________________________

Dica: A composição do Time pode mudar, porém, após cada mudança, a produtividade adquirida através da auto-organização é reduzida, portanto, deve-se tomar cuidado ao mudar a composição do Time.

[tab: Valores]

Sempre que falamos na prática sobre a aplicação do Scrum e sobre como exercitar os pilares de transparência, inspeção e adaptação do Scrum defendemos e promovemos atitudes e comportamentos que não só trariam eficiência e agilidade como também desenvolvimento dos times, colaboração e melhores resultados.

Diversos profissionais especialistas defendem a bastante tempo que a Agilidade é muito mais ligada a comportamento e pessoas, do que a processos e ferramentas e que por isso as mudanças de Mindset são mais importantes para a implantação e manutenção de ambientes ágeis do que adoção simples de práticas, técnicas e ferramentas tidas como ágeis.

Diante disso o Scrum reforça este entendimento através dos 5 (cinco) Valores do Scrum, que geralmente são conhecidos e praticados por muitos times de alta performance, mesmo sem utilizar Scrum ou explicitar a origem destes valores.

OS VALORES DO SCRUM SAO:

• Coragem: O Time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis. Um time ágil precisa ser corajoso para praticar a transparência ao falar e tratar de problemas difíceis, assim como traçar estratégias e resolver todos os seus maiores problemas.
• Foco: Todos focam no trabalho da Sprint e nos objetivos do Time Scrum. Todos os integrantes de um time ágil precisam focar mais nos trabalhos do time, do que em trabalhos individuais, e não devem perder o foco em trabalhos que não vão em direção ao objetivo da Sprint do time.
• Comprometimento: As pessoas se comprometem pessoalmente em alcançar os objetivos do Time Scrum. Para um time atingir seu objetivo coletivo, é preciso que cada um dentro do time se comprometa individualmente o máximo possível na direção do objetivo coletivo.
• Respeito: Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes. Integrantes de um time ágil respeitam uns aos outros praticando escuta ativa, empatia e contribuindo para o aperfeiçoamento e aprendizado de todos.
• Abertura: O Time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a execução dos trabalhos. As mudanças acontecem o tempo todo, e um time ágil precisa estar aberto a tratar estas mudanças assim que aparecerem de maneira a serem flexíveis e adaptativos.

O Guia do Scrum trás dois parágrafos que tratam dos Valores do Scrum, o primeiro deles é o seguinte:

Quando os valores de comprometimento, coragem, foco, abertura e respeito são encorporados 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 (2017, Guia do Scrum 2017, p.5)

Deste modo é possível notar que os autores afirmam que a partir do momento que os times realizam os eventos e seguindo os papéis e artefatos do Scrum, estes passam a desenvolver e praticar os Valores do Scrum uns com os outros, e que por serem valores altamente positivos e que proporcionam grande colaboração inter e entre times, há um desenvolvimento natural dos times em direção a agilidade e eficiência.

Outro ponto importante é que através deste mesmo desenvolvimento e comportamentos ágeis baseados nos Valores do Scrum os Times Scrum passam a fortalecer e evidenciar os pilares do Scrum de transparência, inspeção e adaptação promovendo um ganho fundamental para que os times evoluam ainda mais no futuro próximo: A Confiança.

O segundo parágrafo que trata dos Valores do Scrum é o seguinte:

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 os 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.

Este conteúdo foi utilizado para a representação gráfica dos Valores do Scrum que pode ser encontrada na página oficial da Scrum.org e que está contida neste artigo.

Além disso também reforça que o sucesso da agilidade e da eficiência do Scrum depende das pessoas e de seus comportamentos, e o quanto mais estas pessoas buscarem aplicar e desenvolver proficiência nos Valores do Scrum mais sucesso terão no próprio Scrum, na conquista da Agilidade e na obtenção de seus resultados.

Baixe estes valores, imprima-os e cole-os do lado do seu Taskboard, Burndown ou Kanban, e lembre-se todos os dias de que é preciso viver estes Valores tempo integral, caso contrário todos os seus esforços e tentativas de uso de ferramentas, rituais e regras irão por água a baixo.

[tab: Artefatos]

Os artefatos do Scrum incluem o Backlog e Incremento.

Muitas referências sobre o Scrum não começam detalhando os artefatos, eu preferi assim para que logo no início se entenda a importância destes elementos, e as suas funções dentro do Scrum.

Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos maximizam a transparência de informações chave para que todos tenham o mesmo entendimento sobre os trabalhos e os próprios artefatos.

BACKLOG

O Backlog é nada mais nada menos do que as necessidades do produto que precisa ser entregue, bem como todo o entendimento necessáriopara se atender a estas necessidades, produzir funcionalidades e por fim entregar um produto.

Em resumo é uma lista de todas as características, funções, tecnologias, melhorias e correções que constituem a versão futura do produto.

O responsável pelo Backlog é o Product Owner (PO). O PO é o responsável por manter o Backlog do produto, principalmente por que este é um documento vivo, e nunca estará completo, pois o Backlog evolui à medida que o produto e o ambiente que ele será usado evoluem.

É preciso ter em mente que o Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser mais apropriado, competitivo e útil, e lembre-se: Enquanto existirum produto, o Backlog deste produto também existirá e estará em contante evolução e mudança.

Dica: O Backlog é fruto do entendimento do produto e do negócio do cliente, análises de negócio são muito bem vindas para a obtenção de um Backlog completo, e documentos auxiliares que podem compor o Backlog são: Histórias, Protótipos, Especificações de regras de negócio e outros documentos complementares quando necessário.

O Backlog é dividido em duas partes, o Backlog do produto (Product Backlog) e o Backlog da Sprint (Sprint Backlog). Vamos saber como identificar cada um deles:

PRODUCT BACKLOG

É o conjunto de requisitos e necessidades de todo o produto, ou seja, o Backlog do produto representa tudo que é necessário para desenvolver e lançar um produto completo, e suas versões, e representa o produto final que será entregue ao longo de seu ciclo de vida de produto.

O Product Backlog geralmente é separado em itens de backlog. Os itens de Backlog devem ter seu tamanho estimado, frequentemente definidos como Story Points, e estas estimativas devem ser realizadas pelo Time de Desenvolvimento.

Os itens do Backlog do Produto também precisam ser priorizados, tendo em mente que os mais prioritáriosdevem ser os itens que mais agregam valor ao produto do cliente. Esta priorização deve ser realizada pelo Product Owner, e deve estar clara e visível para todos do Time, considerando que os itens mais prioritários devem estar mais claros e mais detalhados que os itens menos prioritários.

 SPRINT BACKLOG

É o conjunto de itens de backlog contidos no objetivo de uma Sprint, ou seja, o Backlog da Sprint representa tudo que é necessário para desenvolver e/ou entregar uma parte do produto, definido como objetivo da Sprint e que corresponde a entrega mais próxima que o Time Scrum fará. Todo o conteúdo do Backlog da Sprint deve estar contido dentro do Backlog do Produto, e as primeiras Sprints devem conter sempre os itens do Backlog mais prioritários e críticos para o sucesso do produto e entrega de valor ao seu cliente.

Somente os itens do Backlog da Sprint são decompostos em tarefas menores, para que possam ser realizados dentro da Sprint, e recebem uma estimativa de conclusão em horas. O ideal é que estas tarefas tenham um tamanho de no máximo 8 horas, para que possam ser realizadas dentro de 1 (um) dia contido na Sprint. Não ter tarefas maiores contribui para um melhor monitoramento do progresso em direção ao objetivo da Sprint.

MONITORAMENTO DO BACKLOG

Tanto o Backlog da Sprint quanto o Backlog do Produto podem ser monitorados em qualquer momento com a finalidade de avaliar o progresso em direção de completar o trabalho previsto. Uma das formas que o Scrum sugere é acompanhar a soma do total do trabalho restante para alcançar o objetivo. Este acompanhamento pode ser realizado através de gráficos de Burndown ou Burnup.

Para o Backlog do Produto o PO realiza um acompanhamento pelo menos a cada Reunião de Revisão da Sprint, e para o Backlog da Sprint, o Time de Desenvolvimento monitora o total de trabalho restante pelo menos a cada Reunião Diária.

Dica: Tanto o Product Backlog quanto o Sprint Backlog são geralmente representados como Histórias do Usuário, ou User Stories.

INCREMENTO

Segundo o Guia do Scrum (2016), o incremento é a soma de todos os itens do backlog do produto completados durante a Sprint. Ao final da Sprint um novo incremento deve estar “Pronto”.

DEFINIÇÃO DE “PRONTO”

Esta é a definição de pronto para o Time Scrum e é usado para assegurar que todo o trabalho esta completado no incremento do produto que o Time havia planejado. A definição de pronto orienta o Time de Desenvolvimento no conhecimento de quantos itens do backlog do produto pode ser selecionados para a Sprint, e ao longo dos trabalhos permite que o Time saiba quanto trabalho ainda resta para atingir ao objetivo da Sprint.

Caso a organização tenha um padrão, convenção ou diretriz para a definição de pronto de desenvolvimento, todos os Times Scrum devem segui-la como um mínimo, podendo completá-la com necessidades específicas. Caso a organização não tenha nenhuma convenção, então cada Time Scrum pode ter a sua própria definição de pronto. A única regra então é que todos os integrantes do Time Scrum devem ter o mesmo entendimento da definição de pronto de seu Time.

Quando múltiplos Times Scrum trabalham em um mesmo produto ou entrega, todos devem ter a mesma definição de pronto. Isto garante que cada incremento adicionado funcionará corretamente no produto e entrega como um todo.

TRANSPARÊNCIA DO ARTEFATO

O Scrum depende da transparência, e a medida que a transparência é total as decisões são sólidas e mais seguras. Quando não há transparência, as decisões tendem a ser falhas, os valores diminuídos e os riscos aumentados. O Scrummaster deve trabalhar com o PO, Time de Desenvolvimento e outros envolvidos para entender se os artefatos estão totalmente transparentes, e ajudar todos a aplicar as melhores práticas para identificar artefatos não transparentes e atuar para mantê-los completamente transparentes.

HISTÓRIAS

A História não é prescrita pelo Scrum, mas a sua utilização pode representar o Product Backlog Item (PBI) que é um artefato prescrito pelo Scrum.

É uma descrição resumida, porém clara e objetiva, de alguma funcionalidade que deverá ser fornecida pelo produto a ser entregue, sempre do ponto de vista do usuário finaldo produto.

Uma história não se trata de uma especificação completa de uma funcionalidade, mas sim uma promessa de se discutir uma funcionalidade, ou simplesmente um lembrete de que a discussão já aconteceu.

As histórias devem ser curtas e objetivas, para que caibam em um post it como estes ilustrados acima. Um modelo simples de como escrever uma história seria:

“Como um <tipo de usuário>, eu quero <um objetivo> para que <atenda uma necessidade>.”

Exemplos:

• “Como um comprador, eu quero consultar livros para que eu possa escolher qual comprar.”
• “Como um vendedor, eu quero cadastrar livros para que eu possa vendê-los.”

Dica: Escreva as histórias com uma linguagem do cliente, e não técnica. Como complemento ao entendimento das histórias o Product Owner pode produzir especificações de regras de negócio ou protótipos.

BURNDOWN

O gráfico de Burndown representa visualmente a soma das estimativas dos esforços restantes do Backlog, permitindo também uma comparação com os atuais trabalhos realizados.

Assim como o Backlog, o gráfico de Burndown também possui outras visualizações, o Burndown da versão de entrega, ou Burndown do produto, e o Burndown da Sprint são alguns exemplos mais utilizados.

Vamos entender as suas diferenças abaixo:

___________________________________________________________________________
a. Burndown do Produto

É o gráfico que registra a soma dos esforços restantes do Backlog do Produto ao longo do tempo. O esforço estimado pode estar em qualquer unidade de medida que o Time entenda, mas geralmente para o Burndown do Produto a unidade de medida são Sprints.

Dica: Tanto o Backlog do Produto quanto o Burndown do Produto devem ser mantidos pelo Product Owner e publicados o tempo todo. Uma linha de tendência e de trabalhos realizados pode ser traçada baseada na mudança do trabalho restante.

___________________________________________________________________________
b. Burndown da Sprint

É o gráfico que representa a quantidade restante de trabalho do Backlog da Sprint, ao longo dos dias de duração da Sprint. O esforço estimado pode estar em qualquer unidade de medida que o Time entenda, mas geralmente para o Burndown da Sprint a unidade de medida são dias.

Para montar este gráfico, determine quanto trabalho resta somando as estimativas dos itens de Backlog a cada dia da Sprint, e a quantidade de trabalho restante para uma Sprint é a soma do trabalho restante para tudo do Backlog da Sprint.

Dica: Acompanhe essas somas diariamente e utilize-as para criar um gráfico que mostre a evolução dos trabalhos de forma simples, e o trabalho restante ao longo do tempo. O Time de Desenvolvimento pode marcar estas somas diárias no gráfico e traçar uma linha através dos pontos, acompanhando seu progresso na Sprint.

TASKBOARD

O Taskboard, ou Quadro de Tarefas, não aparece originalmente como artefato no Guia do Scrum, mas é sem dúvida uma ferramenta fundamental ao lado do Backlog e do Burndown.

O Taskboard nada mais é do que é um quadro, ou uma parede mesmo, onde o Time coloca as tarefas do Backlog, em post its, de uma forma organizada e ordenada. O objetivo é para que visualmente se entenda rapidamente e claramente como o trabalho está sendo completado.

Geralmente as divisões são feitas em 4 (quatro) colunas: Histórias, A Fazer, Fazendo e Feito, nesta mesma ordem.

Na primeira coluna devem estar as Histórias identificadas no Backlog da Sprint, e nas demais a sua direita, as tarefas contidas dentro de cada história, e que foram decompostas pelo Time de Desenvolvimento durante a Reunião de Planejamento da Sprint. As tarefas que não estão sendo trabalhadas devem estar na coluna “A Fazer“, quando alguém estiver trabalhando em uma tarefa, esta deve estar na coluna “Fazendo“, e quando a mesma tarefa estiver pronta, deverá ir para a coluna “Feito“.

É super simples não é? É simples mesmo e muito eficiente. O efeito visual gera impactos em todos que acompanham o quadro, além de deixar claro para todos quais tarefas estão sendo trabalhadas, e até quantas pessoas estão trabalhando.

Além do modelo mostrado, o Quadro de Tarefas pode conter outras colunas de acordo com o entendimento, necessidade e auto-organização do Time de Desenvolvimento. Não se prenda a padrões, experimente e descubra o que é melhor para o seu Time.

Dica: Coloque acima dos títulos das colunas a capacidade do Time que está realizando as tarefas do Taskboard, com isso será possível saber quem está trabalhando e quem está parado só de olhar os post its e a capacidade do Time.

Dica: Utilize cores diferentes para as Histórias, para as tarefas normais, para correções/bugs e para as tarefas não previstas. Isso ajudará muito na identificação de impedimentos ou desvios.

___________________________________________________________________________
Super Dica

Não se preocupe agora em assimilar totalmente, e entender perfeitamente como funcionam todos os artefatos acima. Não se preocupe também neste momento em aplicá-los imediatamente.

Ao longo dos próximos tópicos e quando estivermos falando do ciclo e do fluxo Scrum, você entenderá bem melhor qual o papel de cada ferramenta e como cada uma funciona, e ai sim poderá aplicá-las em seus projetos e produtos.

[tab: Entregas]

[tab:Sprint]

Os eventos prescritos pelo Scrum são usados para criar uma cadência e minimizar a necessidade de outras reuniões não definidas. Todos os eventos são Time-Boxed, que significa que possuem uma duração de tempo máxima. O principal evento do Scrum é a Sprint, que também é um container para os outros eventos prescritos pelo Scrum.

SPRINT

Como o próprio Guia do Scrum afirma, a Sprint é o coração do Scrum. Uma iteração com duração fixa de até um mês, no qual um incremento “Pronto”, funcional e possível de ser entregue ao cliente é criado.

A Sprint é um Time-Boxed que não deve ser maior que um mês, e a sua duração deve ser coerente com todo o esforço de desenvolvimento que será realizado durante a Sprint.

Uma Sprint deve possuir uma meta estabelecida com objetivos claros. O Scrummaster é o responsável por garantir que não será feita nenhuma mudança que possa afetar a meta da Sprint.

Parac melhor aproveitamento da Sprint a composição do Time, o objetivo da Sprint e as metas de qualidade devem permanecer constantes durante toda a Sprint.

As Sprints contêm e consistem as reuniões de planejamento da Sprint, o trabalho de desenvolvimento, a revisão da Sprint e a retrospectiva da Sprint. Devendo ocorrer uma após a outra, sem intervalos.

Cada Sprint pode ser considerada um projeto, e como os projetos a Sprint possui um objetivo que precisa ser completado em um horizonte, não maior que 1 mês corrido. Quando o horizonte é muito longo, o objetivo do projeto pode mudar ou os riscos se tornarem grandes demais. Desta forma as Sprints não devem ter um horizonte maior que o período de um mês, evitando que um horizonte maior se torne arriscado demais, considerando que já há complexidade suficiente.

A ideia é que a previsibilidade do desenvolvimento seja controlada a cada um mês no máximo, e o risco de que o produto saia de controle, ou se torne imprevisível, é contido em um intervalo menor.

O Time Scrum precisa monitorar sua Sprint de modo que seus objetivos sejam alcançados, e evitar que mudanças sejam feitas e coloquem em perigo o objetivo da Sprint, considerando inclusive que as metas de qualidade não devem diminuir, pois quando isso acontece o próprio objetivo da Sprint é colocado em risco, ou em dúvida em relação a qualidade e funcionamento futuro.

Quando for necessário, o escopo  da Sprint pode ser refinado ou renegociado entre PO e Time de Desenvolvimento, podendo acontecer sempre que novos aprendizados forem obtidos.

Dica: Quando um Time começa com Scrum, é mais interessante que as Sprints tenham no máximo duas semanas, para que o Time aprenda sem se afundar nas incertezas.

Lembre-se que a Sprint é um Time-Boxed é deve ter uma duração fixa e um trabalho pré-determinado pelo objetivo da Sprint. No caso específico da Sprint, o Time-Boxed é fixo e a Sprint não deve terminar antes ou depois do período definido, ou seja, uma Sprint de 5 dias, deve durar exatos 5 dias, nem 1 a mais, nem 1 a menos.

Dica: Caso o Time sinta que se comprometeu com mais itens do Backlog do que podia trabalhar, pode solicitar ao Product Owner que remova ou troque itens. Uma solicitação para adicionar itens do Backlog à Sprint, podem ser realizados caso o Time sinta que sobrará tempo na Sprint.

CANCELAMENTO DA SPRINT

As Sprints podem ser canceladas antes do término do seu Time-Boxed, mas somente o Product Owner tem autoridade para realizar este cancelamento.

Este cancelamento poderá vir através da solicitação de Stakeholders, Time de Desenvolvimento e Scrummaster, mas somente o PO realizará o cancelamento. A Sprint poderá ser cancelada quando o objetivo da Sprint se tornar obsoleto ou perder o sentido, mas é difícil isso acontecer devido a curta duração da Sprint.

Quando ocorrer este cancelamento, todos os itens do Backlog que estejam “Prontos” devem ser revisados. O PO poderá aceitá-los caso representem um incremento funcional do produto. Todos os outros itens que não atendem a definição de “Pronto” são reestimados e voltam ao Backlog do Produto.

Caso o cancelamento ocorra, o Time Scrum deverá se reagrupar e realizar imediatamente outra reunião de planejamento da Sprint para iniciar outra Sprint.

Dica: Apesar de serem incomuns, evite o cancelamento de Sprint, estes consomem recursos e podem ser traumáticos para o Time.

[tab:Planning]

A reunião de planejamento da Sprint é o momento onde todo o Time Scrum de forma colaborativa planeja o trabalho a ser realizado na Sprint. A Sprint Planning é uma Time-Boxed de no máximo 8 horas para uma Sprint de um mês de duração, sendo usualmente menor para Sprints mais curtas.

O Scrummaster garante que o evento ocorra e que os participantes entendam o seu propósito, além de ensinar o Time Scrum a se manter dentro dos limites do Time-Boxed.

A Sprint Planning é um evento para os participantes responderem as seguintes perguntas:

O QUE PODE SER PRONTO NESTA SPRINT?

Todo o Time de Desenvolvimento colabora para o entendimento do trabalho da Sprint e na estimativa do trabalho que poderá ser desenvolvimento durante a Sprint. Para isso realizam um debate com o Product Owner a respeito do objetivo da Sprint e dos itens do backlog do produto que precisam ser completados para atingir a este objetivo.

Para que a reunião seja mais produtiva e gere um resultado eficiente de planejamento, os participantes devem utilizar como entrada para a reunião o Backlog do Produto, o último incremento produzido, a capacidade projetada para o Time de Desenvolvimento durante a Sprint e a última performance do Time do Desenvolvimento.

O único trabalho do Time de Desenvolvimento durante a Sprint são os itens selecionados na Sprint Planning, e somente o próprio Time de Desenvolvimento pode avaliar os itens que podem ser completados durante a Sprint.

Após o Time de Desenvolvimento prever os itens que irá entregar na Sprint, o Time Scrum determina o Objetivo da Sprint. O Objetivo da Sprint é o propósito que irá orientar o Time de Desenvolvimento sobre o porque dele estar construindo o incremento do produto, sendo que este objetivo será conhecido durante a própria Sprint conforme o incremento é completado.

Dica: O Objetivo da Sprint deve ser um subconjunto da Meta da versão para entrega, já definida anteriormente na reunião de planejamento da versão de entrega. Conforme o Time trabalha ele mantém a sua meta em mente, e para satisfazer o objetivo da Sprint ele implementa as funcionalidades através dos itens do Backlog selecionados para a Sprint.

COMO O TRABALHO SELECIONADO SERÁ PRONTO?

O Time de Desenvolvimento decide como irá completar o trabalho da Sprint e construir um incremento de produto “Pronto” durante a Sprint. Os itens do Backlog do Produto selecionados para serem completados na Sprint são conhecidos como Backlog da Sprint.

O Time de Desenvolvimento entende o trabalho necessário para converter o Backlog da Sprint em um incremental funcional do produto, decompondo os itens até o final desta reunião, de modo que o Time de Desenvolvimento tenha o entendimento necessário e suficiente se auto-organizar e realizar todo o trabalho necessário dentro dos limites de Time-Boxed da Sprint.

Frequentemente os itens do backlog da Sprint são decompostos em unidades de até um dia de duração ou menos. Geralmente os trabalhos dos primeiros dias da Sprint são decompostos até o final da Sprint, e o restante pode ser detalhado durante a própria Sprint, desde que o Time de Desenvolvimento planeje e estime este trabalho, considerando que o objetivo da Sprint será atingido.

Dica: Para não estender a Sprint Planning além de seu Time-Boxed, uma sugestão é detalhar até 70% do total do Backlog da Sprint durante a reunião de planejamento da Sprint. O restante é deixado para ser detalhado mais tarde, ou são dadas estimativas grandes que serão decompostas mais a frente durante a própria Sprint.

O Product Owner pode ajudar a clarificar os itens do Backlog da Sprint e também nas decisões de troca para melhor acomodação do Backlog do Produto e do objetivo da Sprint. Trabalhos em excesso ou falta de trabalho podem ser renegociados entre Time de Desenvolvimento e PO. Outras pessoas podem ser convidadas para esta reunião pelo Time de Desenvolvimento.

Dica: O Time de Desenvolvimento pode convidar outros especialistas de domínios específicos para dar opiniões técnicas e contribuir com as estimativas ou decomposição dos itens do backlog da Sprint.

Dica: Com a Sprint Planning completada se tem insumo para a montagem do taskboard e burndown da Sprint, incluindo estimativas e tarefas.

[tab:Estimativas]

Antes de falar de estimativas é preciso reforçar a importância dos itens à estimar, ou seja, antes mesmo de determinar o esforço referente aos futuros trabalhos do Time, é preciso saber em que o Time deve trabalhar primeiro.

IMPORTÂNCIA E PRIORIDADE

No Scrum é decisivo definir as prioridades, ou importâncias, dos itens de Backlog que serão implementados. Porque? Bom, é fácil entender, o Scrum defende que se deve investir mais detalhamento, mais análise e mais esforço aos itens mais importantes do Backlog, onde devemos entender o termo importância como: O que agrega mais valor ao cliente que utilizará o produto.

Mesmo assim, porque trabalhar primeiro com os mais importantes? Por que são estes itens que realmente farão diferença ao cliente na entrega que ele espera receber, então estes itens geralmente são os maiores, ou os mais complexos, e por consequência são os itens que sofrerão mais com os riscos e mudanças. Então se os maiores riscos geralmente estão nos mais importantes, é melhor tratá-los o quanto antes porque é no início que o Time terá tempo de recuperação através da inspeção e adaptação.

Dica: Não pense no que é mais importante para você, ou para a sua visão de importância para o projeto. Pense navisão do cliente, pergunte a ele, converse com os stakeholders e entenda com eles o que é realmente mais importante para o projeto e o que entregará maior valor.

DEFININDO A IMPORTÂNCIA E VALOR

Os itens mais importantes devem ser aqueles que entregam, ou agregam, maior valor para o cliente e usuário final do produto, mas o que é valor?

Valor não está diretamente relacionado a retorno financeiro, mas sim a um grande problema resolvido, ou até mesmo, uma experiência percebida pelo cliente como importante e relevante para o seu negócio.

Para simplificar, no Scrum e no Agile, utilizamos a priorização através de números atribuídos a cada item de backlog do produto, onde quanto maior for o número, maior é a sua importância e valor. Em outras palavras, um item de backlog do produto que recebe a importância de 70 tem mais valor agregado e é mais importante que um item de backlog do produto que tem a importância de 50.

Dica: Deixe sempre intervalos entre uma importância e outra e não utilize números sequenciais próximos, por exemplo, de preferência para sequências de 5 em 5 números, ao invés de 1 em 1, como 15, 20 e 25, e não 1, 2, 3 e 4. O primeiro exemplo de sequência com intervalos de 5 em 5 permite que itens sejam incluídos entre uma importância e outra, sem a necessidade de reordenar todos os números.

Esta é maneira mais fácil de determinar uma ordem de importância para todos os itens de Backlog, permitindo também definir uma importância distinta para cada item de Backlog, não sendo necessário repetir prioridades ou refazer a priorização por falta de números.

Dica: Procure dar uma importância distinta para cada item, isso realmente vai ajudar no futuro a saber rapidamente qual item é mais importante que um outro. Tenha em mente que em um momento de decisãosempre haverá algo mais importante.

SUPER DICA

Para saber o que é mais importante, use também a técnica MoSCoW.

Separe primeiro suas Histórias de acordo com a indicação MoSCoW, sendo que os itens “Tem que ter para funcionar” (Must have) e “Deve ter para estar completo” (Should have) devem ser os primeiros da sua lista, e o “Pode ter para ficar mais legal” (Could have) e o “Não terá por não ser mais importante” (Won’t have) ficam no final da lista, inclusive o último pode compor uma lista futura, ou até mesmo ser definitivamente descartado.

É uma ótima técnica para ser exercitada pelo Product Owner em conjunto com o cliente, pois facilita o entendimento do que realmente é importante e entrega valor para o projeto.

ESTIMANDO HISTÓRIAS E TAREFAS

Com o Backlog da Sprint selecionado, priorizado de acordo com as importâncias de valor e apresentado ao Time de Desenvolvimento, chega a hora de estimar as Histórias e as tarefas para que seja possível confirmar os trabalhos que serão completados durante a Sprint.

1. Planning Poker Cards

O Planning Poker é uma técnica que auxilia na estimativa de histórias e tarefas baseada no consenso de todo o Time, onde é utilizado um conjunto de cartas com valores específicos que podem representar Story Points (Pontos por história).

O seu uso é simples, o Product Owner apresenta a história ou tarefa ao Time, e, após uma breve discussão, cada um escolhe uma carta e a coloca virada sobre a mesa onde o Time de Desenvolvimento está reunido para entender o trabalho a ser completado.

Quando todos colocarem as suas cartas, elas são desviradas e mostradas a todos, caso não haja consenso entre as cartas escolhidas as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja convergência e consenso entre todo o Time de Desenvolvimento.

Dica: As discussões devem ser breves e objetivas, caso contrário as histórias ou tarefas não estão preparadas para serem estimadas e consequentemente trabalhadas, e devem ser mais refinadas antes de uma nova estimativa.

O Planning Poker é praticamente um jogo de planejamento e tem suas regras, vamos conhecer um pouco mais algumas delas.

• As cartas numeradas são doze: 0 (zero), 1/2 ou 0,5 (meio), 1, 2, 3, 5, 8, 13, 20, 40, 100.
• As cartas com símbolos são duas: ? (interrogação) e a com um desenho de uma Xicará de Café.

Para entender o uso destas cartas em uma estimativa, o primeiro passo é entender as cartas especiais, que são:

• 0 (zero): Representa uma história ou tarefa já concluída, ou com um tempo muito curto para conclusão, que não vale a pena ser mensurado, como por exemplo alguns poucos minutos.
• 100 (cem): Representa que uma história ou tarefa está muito grande, e o ideal é que seja quebrada em mais histórias ou tarefas, pois inclusive, o risco de estimar errado se torna alto em histórias ou tarefas muito grandes.
• ? (interrogação): Representa que a história ou tarefa está indefinida, e que além de não ser possível entender o seu tamanho, não se consegue nem dizer se é muito pequena ou muito grande.
• “desenho da xicará de café“: Representa que o integrante do Time está sugerindo uma pausa para um café, uma água, ou simples descanso, devido ao tempo da reunião estar muito longa e estar gerando cansaço.

Bom, agora é jogar, ou melhor estimar. O formato apresentado aqui é apenas um estilo de estimar com o Planning Poker, mas é uma sugestão de uso que funciona bem.

Outras Dicas: Algumas outras dicas são interessantes quando se usa o Planning Poker Card.

1. Caso as cartas “?” ou 100 (cem) ganharem uma estimativa, significa que o Time deve devolver a história ou tarefa ao Product Owner, para novo detalhamento, divisão ou entendimento.
2. Caso o Time não chegue em um acordo sobre a estimativa de uma história ou tarefa, mais de uma rodada deve ser realizada, sempre havendo breves discussões entre uma rodada e outra. Porém, o número de rodadas deve ser limitado, e caso o limite seja atingido sem o acordo, o Time deve optar pela estimativa mais alta.
3. Geralmente se limita o número de rodadas para estimativa em no máximo quatro por item.
4. Em um Time, a velocidade do mais lento deve ser considerada a velocidade do Time todo. Por isso quando o Time não chega em um acordo, a estimativa mais alta deve ser considerada como a melhor para o caso.

Encerramento da estimativa: A cada item estimado, o Time deve pegar a próxima história ou tarefa pela importância, e continuar neste processo até os itens terminarem, ou até o tempo da reunião acabar.

Dica: O Planning Poker é sugerido quando o Time é novo no Scrum, e quando os integrantes ainda são muito influenciáveis pelas opiniões dos outros

2. Story Points ou Pontos por História

Story Points são uma forma relativa de medir o tempo necessário, ou o esforço, para se implementar uma História.

Destina-se a ser uma forma de se estimar a dificuldade sem se comprometer com uma duração de tempo específico, de modo que as variações no tamanho da equipe não afete as estimativas.

Os valores 1, 2, 3, 5, 8, 13, 20, 40 e 100 contidos nas cartas do Planning Poker representam o formato mais utilizado de pontuação em Story Points. O significado dos valores é relativo, onde uma história de pontuação 8 demanda aproximadamente quatro vezes mais esforço que uma história de pontuação 2.

Para começar a estimar, o Time pega a história que julga ser a de menor esforço e atribui a pontuação 2. As demais histórias deverão seguir uma pontuação relativa a essa primeira, chamada de referência.

Dica: Story Points é geralmente a referência de medida de esforço mais utilizada no Planning Poker.

4. Tamanho P, M ou G

Uma outra forma de estimar as Histórias é o tamanho P, M ou G. Neste caso geralmente é utilizado apenas para as histórias ou até itens maiores como épicos, não para as tarefas.

Neste caso o Time pega a história que julga ser a de menor tamanho, ou de menor esforço, e atribui o tamanho P. Esta história será conhecida pelo Time como referência, e deve ser utilizada como base ao Time para determinar o tamanho das demais histórias.

Dica: Esta é uma estimativa Análoga, e apesar de não ser o propósito, pode ser associado uma média de horas, ou pontos por história a cada tamanho P, M ou G utilizado, tornando mais fácil associar o tamanho ao que se pretende fazer. Este tipo de estimativa geralmente é utilizada nos momentos iniciais do desenvolvimento, especialmente aqueles que é preciso projetar estimativas futuras sem conhecer detalhes, como por exemplo, quando é necessário realizar estimativas para precificar ou vender um desenvolvimento.

[tab: Daily Scrum]

Esta cerimônia é uma das características mais marcantes do Scrum, e que contribui muito para a mudança de pensamentos, e principalmente as ações dos times que trabalham com práticas ágeis.

DAILY SCRUM

Os Times devem se encontrar diariamente para uma reunião de 15 minutos no máximo, também conhecida como reunião diária. A reunião diária é um evento Time-Boxed de 15 minutos para o Time de Desenvolvimento sincronizar atividades e planejar as próximas 24 horas.

A Daily Scrum é mantida no mesmo horário e local todos os dias, reduzindo a complexidade da sua realização e promovendo a geração de um hábito saudável para o Time Scrum.

A reunião diária é feita para o Time de Desenvolvimento inspecionar o trabalho desde a última reunião diária e prever o trabalho que poderá ser completado até a próxima reunião diária. Para isso o Time de Desenvolvimento explica:

• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a Meta da Sprint?
• O que eu farei hoje que ajudará o Time de Desenvolvimento a atender a Meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim, ou ao Time de Desenvolvimento, no atendimento da Meta da Sprint?

O Time de Desenvolvimento é o responsável por conduzir a Reunião Diária, e deve utilizá-la para inspecionar o progresso em direção ao objetivo da Sprint e inspecionar se o trabalho completado versus o trabalho restante tende a completar o trabalho do Backlog da Sprint.

O foco das perguntas e de suas respostas não deve ser um status dos itens, mas sim aumentar a probabilidade  do Time de Desenvolvimento atingir ao objetivo da Sprint. O compartilhamento das realizações e dos impedimentos deve ser levado muito a sério durante Daily Scrum, pois estes podem interferir seriamente no atingimento do objetivo da Sprint e por isso devem ser evitados ou removidos o mais rápido possível.

A reunião diária deve promover a comunicação, a eliminação de outras reuniões e a identificação de impedimentos para o desenvolvimento fluir sem barreiras. Estas ações promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos a cerca do projeto.

A reunião diária também é uma inspeção do progresso na direção da meta da Sprint, mas não pode ser realizada para resolver problemas, o que ela pode é provocar outras reuniões subsequentes para realizar discussões detalhadas, re-planejar ou adaptar o trabalho restante da Sprint.

Dica: O ScrumMaster deve garantir que o Time realize a reunião diária, ensinando-os a mantê-la dentro do Time-Boxed, mantendo as regras, as discussões breves e a participação somente do Time de Desenvolvimento da Daily Scrum.

STAND UP MEETING

Um formato muito utilizado para as reuniões diárias, é o Stand Up Meeting, que significa reunião em pé.

É isso mesmo, o conceito é simples. Reúna o Time para aDaily Scrum, de forma com que todos fiquem de pé, e de preferência em um círculo pequeno para que todos possam se olhar e se ouvir. Isso força com que todos sejam objetivos, diretos e breves em suas discussões e explicações. Afinal, ninguém quer ficar horas de pé, não é!?

Dica: Geralmente quando se pensa em reunião, se visualiza uma sala reservada para o encontro da equipe e com portas fechadas. Porém, quando se trabalha com Scrum e Agile, não é preciso se trancar em uma sala. Basta o Time se levantar e conversar perto de suas mesas mesmo, e de preferência de frente para o Quadro de Tarefas ou Kanban.

O CANTO DO DESIGN

O Canto do Design é outra dica bem interessante para o local de realização da reunião diária. Basta colocar o Time todo em pé em um canto da sala, e quando dizemos canto, é canto mesmo, onde duas paredes se encontram.

Em uma delas podemos ter um quadro branco, com rabiscos ou rascunhos de design, modelos ou esboços de design, como gráficos, fluxos, diagramas ou protótipos. Na outra podemos ter o Taskboard e o Burndown Chart.

Isto realmente pode ser útil, pois não há forma melhor de ter uma visão geral do sistema e da Sprint, do que ficar no Canto do Design e dar uma espiada no que tem nas duas paredes.

Referência: Esta dica foi retirada do livro “Scrum e XP direto das Trincheiras – Como nós fazemos o Scrum”, de Henrik Kniberg. Que pode ser encontrado na versão em português, traduzido e disponibilizado pela InfoQ através do seguinte endereço http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches

ATUALIZAÇÃO DO QUADRO DE TAREFA E DO GRÁFICO DE BURNDOWN

A reunião diária também é o momento de atualizar o Quadro de Tarefas e o Gráfico de Burndown.

Dois momentos são sugeridos para a atualização do quadro de tarefas, um é no início da reunião diária, onde antes de cada membro da equipe apresentar suas realizações e obstáculos, um dos membros, ou o Scrummaster, atualiza todas as tarefas no Quadro.

A segunda sugestão que funciona bem é cada membro do Time, no momento que estiver apresentando suas realizações, atualizar suas próprias tarefas no Quadro.

Independente do momento, a atualização deve conter as previsões das tarefas a serem completadas, a mudança da situação das tarefas e as novas tarefas identificadas e não planejadas, quando for o caso.

Por fim, ao final da reunião diária e após a atualização de todo o Taskboard, um membro do Time ou o Scrummaster, deve totalizar as estimativas de prazo, considerando os itens prontos, e marcar um novo pontono Burndown Chart.

Dica: O Time não deve sair da Reunião Diária sem atualizar o Quadro de Tarefas e o Gráfico de Burndown, pois isto é essencial para que a gestão a vista seja bem sucedida.

[tab:Revisão da Sprint]

REUNIÃO DE REVISÃO DA SPRINT – REVIEW

A Sprint Review é um evento Time-Boxed de 4 horas de duração para uma Sprint de 1 mês, sendo usualmente menor para Sprints mais curtas. A reunião de revisão da Sprint é mantida no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário.

Durante a Review o Time Scrum e os Stakeholders entendem de forma colaborativa o que foi completado e atendeu a definição de Pronto na Sprint. Com base nos itens completados e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes da Review colaborativamente entendem quais são os próximos trabalhos que entregarão, agregarão ou otimizarão valor nas próximas Sprints.

O objetivo maior desta reunião é a revisão dos itens concluídospelo Product Owner, ou pelo cliente. A melhor maneira de fazer isso é justamente realizar uma apresentação de todos os itens concluídos aos Stakeholders, de modo a obter feedback e colaboração favorável.

Para que a revisão ocorra da forma mais objetiva e produtiva, defina claramente antes da reunião qual era o objetivo da Sprint, e qual é a meta da Review.

O Scrummaster garante que o evento ocorra e que todos entendam seu propósito. O Scrummaster ensina a todos a manterem a Review dentro do Time-Boxed.

Dica: A Review não é um momento para testar os itens entregues, mas sim de apresentação dos incrementos Prontos e a conferência dos itens de acordo com a definição de pronto de cada um.

A Revisão da Sprint inclui os seguintes elementos:

• Os participantes incluem o Time Scrum e Stakeholders Chave convidados pelo PO
• O PO explica quais itens do backlog do Produto estão Prontos e quais não estão
• O Time de Desenvolvimento explica o que correu bem durante a Sprint, quais problemas ocorreram e como foram resolvidos
• O Time de Desenvolvimento apresenta o incremento “Prontos” e responde dúvidas a respeito
• O PO discute o Backlog do Produto, considerando os itens completados, aprendizados adquiridos e mudanças no backlog ou no mercado, e projeta as prováveis datas de conclusão baseado no progresso até o momento
• O grupo todo colabora sobre o que fazer nas próximas Sprints, e deste modo a Review contribui com entradas valiosas para a Reunião de Planejamento da próxima Sprint
• O grupo colaborativamente realiza uma análise da linha do tempo, orçamento, potencial capacidades, e mercado para a próxima versão esperada pelo produto.

IMPORTÂNCIA DA REVIEW

Muitos ainda podem pensar e se perguntar: “Para que gastarmos tempo com uma revisão ou apresentação?“. Bom, a primeira coisa a se mudar nesta questão, é que ao seguir as regras do Scrum não se “gasta” tempo, mas se investe tempo na geração de valor ao realizar eventos como este. Vamos entender porque.

Uma coisa muito comum em desenvolvimento de sistemas, é o acumulo de tarefas “quase” prontas, e o empilhamento de funcionalidades com 99% de conclusão. Quem nunca ouviu a frase: “Tá praticamente pronto!“.

Geralmente não se tem nada pronto em 100%, mas tudo no quase. No entanto, quando se tem uma apresentação com o objetivo de demonstrar e revisar os trabalhos completados, todo o time se empenha em realmente ter as tarefas prontas, porque o próprio Time, o Product Owner e até outros Stakeholders vão participar da Apresentação do Objetivo completado na Sprint e esperam ver um Produto “Pronto”.

O que geralmente se vê em Times novos no Scrum, é a negligência ou falta de importância às primeiras Reviews. Com isso acabam caindo no “vício” do “praticamente pronto”, e o que se vê muito é o aparecimento de vários erros, e até a impossibilidade de apresentações completas de incremento devido a falhas. Isso com certeza vai machucar, gerar desconforto e frustração para o próprio Time, e então a mudança começa.

O próprio Time vai preferir melhorar a sua apresentação na próxima Revisão de Sprint, e naturalmente vai preferir terminar em 100% menos itens, do que ter mais itens “quase” prontos. Desta forma será mais precisa a avaliação de velocidade e capacidade do Time, e do que está sendo entregue realmente.

Quando o Time começa a melhorar a qualidade de suas entregues nas Reviews, a auto-estima melhora, a confiança do Time em si mesmo aumenta, e as previsões começam a ser cumpridas e a positividade começa a tomar conta do Time, fazendo com que a sua melhoria torne-se cada vez mais contínua e percebida.

Dica: Não gaste tempo montando uma apresentação do seu produto ou dos incrementos prontos, utilize o próprio produto e incremento para apresentar os itens concluídos e o objetivo atingido.

Dica: Ao final da Review pode-se ter alterações e mudanças no Backlog do Produto, gerando com isso entradasmuito importantes para as futuras reuniões de planejamento de Sprint.

[tab:Retrospectiva ]

Este é o último evento da Sprint do Scrum, após a reunião de revisão e antes da reunião de planejamento da próxima Sprint, deve ocorrer a reunião de retrospectiva. Vamos conhecê-la.

REUNIÃO DE RETROSPECTIVA

A Retrospectiva é a oportunidade para o Time Scrum inspecionar a si mesmo e criar um plano para melhorias serem aplicadas na próxima Sprint. Este é um evento Time-Boxed de 3 horas para uma Sprint de um mês, sendo usualmente menor para Sprints mais curtas.

O Scrum Master garante que o evento aconteça e que seus participantes entendam seu propósito, além de ensinar todos a se manterem dentro do Time-Boxed. O SM também participa da retrospectiva como membro do Time responsável pelo processo Scrum.

Melhorar continuamente é fundamental para uma boa saúde do Time, Stakeholders, Clientes e Produtos, e para que isso seja possível as reuniões de retrospectiva devem sempre acontecer. Frequentemente as equipes acreditam que não seja necessário realizar as retrospectivas, e sem o estímulo correto seguem para a próxima Sprint sem realizar este evento.

Algumas bibliografias dizem que este evento é o segundo mais importante no Scrum, pois é a melhor oportunidade para melhorar. Sendo que o primeiro evento mais importante é considerado a reunião de planejamento da Sprint.

É o momento mais indicado para o Time voltar no tempo e inspecionar como ocorreu a última Sprint, levando em consideração as pessoas, as relações entre elas, os processos e as ferramentas utilizadas.

O propósito da Reunião de Retrospectiva é:

• Inspecionar como a última Sprint foi em relação às pessoas, relacionamentos, processos e ferramentas.
• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias.
• Criar um plano de ação para implementar as melhorias e influenciar positivamente o modo com que o Time Scrum faz seu trabalho.

Dica: Pode ser que existam muitos itens de melhorias identificados e o tempo não seja suficiente para tratar todos dentro de uma única retrospectiva. Não rompa a regra da Time-Boxed, priorize todos os itens, e trate apenas os principais e mais importantes, e guarde alguns para as próximas Retrospectivas e suas Sprints.

O Scrummaster encoraja o Time Scrum a melhorar, dentro do processo do Framework Scrum, no processo de desenvolvimento e nas práticas para ser mais efetivo e agradável na próxima Sprint.

No final da reunião de retrospectiva, o Time deve sair com uma identificação de melhoria necessárias e factíveis, bem como seus respectivos planos de ação que serão implementadas a partir da próxima Sprint.

Dica: Sem as retrospectivas, o Time descobrirá, a duras penas, que continuará a cometer os mesmos errosrepetidamente.

___________________________________________________________________________
Participantes e Local Apropriado

Na retrospectiva é importante que participem todos, ou seja, o ScrumMaster, o Product Owner, e o Time de desenvolvimento, Stakeholders e Clientes.

Para esta reunião, o ideal é ir para uma sala fechada, confortável e sem interrupções. Geralmente não é feito esta reunião no mesmo espaço de trabalho, pois as pessoas tendem a perder a atenção. A foto ao lado não é a toa, são as salas de reunião da Google, da área Guerra nas Estrelas, e ao mesmo tempo são autênticos iglus utilizados em missões científicas na Antártida.

Dica: O tema mais utilizado para dar rumo a retrospectiva é: “O que nós podemos fazer melhor na próxima Sprint?“.

Pode iniciar pelo ScrumMaster mostrando o Sprint Backlog e resumindo os resultados atingidos pela Sprint com a ajuda do Time. Depois, é realizado “rodadas” onde cada membro do Time fala sem interrupção, o que foi bom, o que eles melhorariam, e o que eles fariam de forma diferente na próxima Sprint.

Dica: Não seja ambicioso, e não queira melhorar tudo de uma vez, foque em algumas melhorias por Sprint.

[tab:Manifesto Ágil]

Todo este movimento que toma força a cada dia em pró da Agilidade, surgiu a partir de um Manifesto Ágil, que veio com algumas quebras de conceitos, que podiam parecer irreais para muitos a alguns anos, mas hoje já se mostra muito forte e funcional para vários tipos de projetos. Vamos conhecer este manifesto.

___________________________________________________________________________
Manifesto Ágil

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

• Indivíduos e interações entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Importante: É importante ressaltar e evidenciar que todos os processos realizados fora do gerenciamento ágil, são importantes dentro do ágil, porém na medida certa e em menor valor e importância do que os destacados no Manifesto Ágil, vamos entender melhor:

• Alguns dizem que o gerenciamento ágil não tem documentação, isso não é verdade. O que é dito, é que é melhor ter o software funcionando, do que uma documentação extensa, ou seja, devemos fazer apenas a documentação necessária para se ter o software funcionando, tendo em mente de que o produto final é mais importante do que uma pilha de documentos.
• As pessoas envolvidas com o projeto, seja o time interno, ou seja o time externo (cliente ou parceiros), são mais importantes do que os processos e as ferramentas, ou seja, as pessoas são mais importantes e devem ser melhor tratadas do que as máquinas e programas. Lembre-se sempre, quem faz a máquina funcionar e desenvolve o sistema são as pessoas, e não o contrário.
• É preciso ter um contrato firmado com regras claras, porém negociar é muito mais importante e valioso do que brigar judicialmente com o seu cliente, então negocie sempre, seja transparente, seja claro, seja honestoe converse francamente com o seu cliente.
• A mudança continua sendo a única certeza existente em um projeto, então não adianta lutarmos contra elas, elas vão aparecer e precisam ser tratadas. Então lembre-se que é mais importante responder rápido e corretamente a uma mudança, do que seguir um plano que foi feito antes da mudança, e pode inclusive perder o seu sentido se a mudança não for tratada.

Com isso, é fácil perceber que itens do gerenciamento convencional, como documentação, contratos e plano de projeto, continuam existindo no gerenciamento ágil, e na verdade devem continuar existindo, porém não devem ser mais importantes do que, respectivamente, fazer o sistema funcionar, negociar com o cliente e se adaptar as mudanças.

___________________________________________________________________________
Princípios por trás do Manifesto Ágil

Nós seguimos os seguintes princípios:

• Nossa maior prioridade é satisfazer o cliente, através da entrega adianta e contínua de software de valor;
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas;
• Entregar software funcionando com frequencia, na escala de semanas até meses, com preferência aos períodos mais curtos;
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto diariamente, durante todo o curso do projeto;
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão o seu trabalho;
• O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara;
• Software funcionando é a medida primária de progresso;
• Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes;
• Contínua atenção à excelência técnica e bom design, aumenta a agilidade;
• Simplicidade: A arte de maximizar a quantidade de trabalho que não precisou ser feito;
• As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis;
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Estes 12 princípios ágeis juntos fornecem a base de apoio ao Manifesto Ágil, e para se entitular um gerenciamento ágil de projetos, é preciso que todos estes princípios sejam aplicados e seguidos.

Dica: Para quem ainda não sabia, foi a partir destes 12 princípios e do próprio manifesto que surgiu o framework do Scrum, e outras práticas ágeis.