Trabalhando com Scrum - Introdução

Hoje vou iniciar uma série de posts para falar sobre o Scrum. Sei que já existem diversas fontes de informação, mas sigo vendo várias pessoas entrando no mercado de trabalho que têm dúvidas a respeito do framework. Como o Scrum é amplamente utilizado e sempre existem oportunidades para trabalhar com ele, acredito que será útil mais um material explicando o seu funcionamento. Além disso, pretendo falar sobre a minha experiência, mostrando como facilito cada uma das cerimônias e o que deu certo e o que deu errado em cada escolha que fiz.

Os posts serão publicados toda segunda-feira e a série será composta por:

• Trabalhando com o Scrum - Introdução
• Trabalhando com o Scrum - Papéis
• Trabalhando com o Scrum - Cerimônias
• Trabalhando com o Scrum - Artefatos
• Trabalhando com o Scrum - Exemplo de uma Sprint

Para quem é essa série?

Quando iniciei a minha carreira como desenvolvedora, não dava muita bola para o formato de trabalho. O que me interessava era receber uma demanda, desenvolver, aguardar o teste e seguir para a próxima. Como trabalhei durante muito tempo como desenvolvedora em times de sustentação, isso fazia muito sentido, já que todas as demandas eram controladas por tickets de problema. Mas quando estava trabalhando em projetos de novos produtos, sempre notava a diferença no acompanhamento do trabalho com os gerentes de projeto. Então, não era incomum trabalhar em times que faziam reuniões diárias pela manhã e o resto do dia seguia normal, assim como era na sustentação. Também não era incomum problemas nas entregas, como atrasos e diferenças no entendimento do que deveria ser desenvolvido.

Ao iniciar como analista de sistemas, fui designada como Scrum Master de um time. Inicialmente, pensei que saberia conduzir corretamente, pois como eu sempre tive dailies e conseguia entregar os projetos como desenvolvedora, seria bem fácil acompanhar o time como Scrum Master. Seria só ler o Scrum Guide e eu estaria pronta. Foi aí que eu me enganei. O Scrum Guide possui toda a definição do Scrum, mas nem tudo é explicado com aplicações práticas e essa realmente não é a proposta do documento. Então, além de descobrir que Scrum não é só daily, eu também deveria saber como fazer aquela cerimônia que estava sendo descrita na prática. Já falei no post inicial do blog que não tinha jeito para lidar com as pessoas e assumir o protagonismo nas reuniões. Então fiquei realmente apavorada ao descobrir tudo o que teria que fazer se realmente quisesse ser uma Scrum Master de verdade. Felizmente deu tudo certo, sigo aprendendo e tentando melhorar, mas já tenho a experiência na prática que me dá a segurança de dizer que consigo desempenhar o papel de um Scrum Master.

Então, para quem é essa série? Essa série é para quem já sabe sobre Scrum e gosta de ler a respeito; é para quem nunca participou de um projeto Scrum e quer saber o que acontece na prática; ou, até mesmo, para quem acabou de ouvir falar e quer descobrir o que é. Gosto muito de compartilhar conhecimento, então se você é alguém que está tentando entrar no mercado de trabalho, espero que essa série te ajude a entender o funcionamento do Scrum e quem sabe até ajude a escolher uma carreira. Posso estar sendo ambiciosa demais, mas nada me deixa mais feliz do que saber que pude fazer a diferença para alguém, nem que seja ajudando a decidir que trabalhar com o Scrum não é o que está buscando. Sendo assim, posso dizer que esta série também é para mim.

O que tem nessa série?

A intenção é passar pelos itens do Scrum Guide, comentando a respeito do que é descrito e falando das experiências profissionais que tive trabalhando com o framework. Por isso, boa parte desse material será uma tradução parcial do Scrum Guide.

Vou incluir definições e tentar contextualizar quem não tem experiência sempre que possível. A ideia é que faça sentido a aplicação do Scrum, independente do ambiente. Para isso, pretendo exemplificar os processos com um time no dia a dia. A minha experiência é toda baseada no desenvolvimento de produtos de software. Sendo assim, apesar de ser possível aplicar o Scrum em diversas áreas, os posts vão focar muito na aplicação para a construção de software.

Alguns termos foram traduzidos do inglês e outros não. Deixei o texto assim para que ele fique o mais próximo possível do que é dito em um ambiente rodando o Scrum com pessoas que falam português. Esse é o meu contexto atual e acredito que seja o de muitas pessoas. Caso necessite saber o termo em inglês, sugiro consultar o Scrum Guide ou até mesmo perguntar nos comentários, já que alguma coisa pode acabar passando batido.

Como sempre, fique à vontade para comentar sobre os pontos levantados e trazer sugestões para os exemplos citados.

Contextualização

Como mencionado, vou focar os exemplos no âmbito do desenvolvimento de software. Então, vamos iniciar entendendo em qual contexto o Scrum é aplicado. Imagine que existe um projeto para o desenvolvimento de um sistema de cadastro de clientes, este sistema é o nosso produto. Para a execução desse projeto, é necessária a aplicação de um processo de desenvolvimento de software, que por sua vez é definido por um framework.

Framework: estabelece o alicerce para um processo de engenharia de software completo por meio da identificação de um pequeno número de atividades metodológicas aplicáveis a todos os projetos de software, independentemente de tamanho ou complexidade. ^[1]

Portanto, vamos desenvolver este produto baseado em um processo que define quais atividades devem ser executadas para atingir esse objetivo. No nosso caso, o framework que estabelece este processo é o Scrum.

Manifesto ágil

Em fevereiro de 2001, um grupo de 17 pessoas autodenominado “Agile Alliance” se reuniu e discutiram a respeito de alternativas para o desenvolvimento de software desgastante e altamente voltado à documentação. Desta reunião, surgiu o Manifesto Ágil:

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

Indivíduos e interações 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.

Representantes do Scrum assinaram este manifesto e você pode saber mais detalhes aqui. Mas o importante é ter em mente que o Scrum está alinhado com o Manifesto Ágil e com os Princípios da Agilidade.

Princípios da agilidade

Estes são os princípios por trás do Manifesto Ágil:

• Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado;
• Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente;
• Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo;
• Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
• Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho;
• O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face;
• Software funcionando é a medida primária de progresso;
• Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
• Contínua atenção à excelência técnica e bom design aumenta a agilidade;
• Simplicidade (a arte de maximizar a quantidade de trabalho não realizado) é essencial;
• As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;
• Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Desenvolvimento ágil

Conhecendo o Manifesto Ágil e os Princípios da Agilidade, também conhecemos o desenvolvimento ágil e o Scrum está alinhado com essa metodologia de desenvolvimento. Recomendo que você leia ambos com atenção e avalie se estão alinhados com as suas expectativas. Se você não tem experiência, certamente vai achar interessante, mas, por outro lado, fica difícil de se entender como cada um dos itens será atingido no dia a dia. No caso de ter uma certa experiência, acredito que a dúvida é como mudar o pensamento das pessoas que trabalham com métodos tradicionais há tanto tempo. Não faltam exemplos de projetos onde a intenção é colher os frutos da agilidade, sem praticar os princípios dela.

Sendo assim, o Scrum é um framework para o desenvolvimento de produtos que está alinhado com o desenvolvimento ágil. Acredito que com essas definições você está pronto para ler e compreender o que vai ser exposto no resto da série.

O que é o Scrum

Segundo o Scrum Guide, o Scrum é um framework que possui a definição dos times, cerimônias, artefatos e regras para desenvolver, entregar e sustentar produtos complexos. É descrito como leve, simples de entender e difícil de dominar e, por ser um framework, ele pode ser aplicado utilizando-se de diversos processos e técnicas.

Por mais que se diga em diversos projetos que o Scrum é o framework utilizado, o Scrum Guide define que somente quando todas as partes descritas nele são implementadas é que o Scrum existe de verdade. No dia a dia vemos como a definição “difícil de dominar” é real, porque realmente é bem difícil conseguir seguir tudo conforme o guia. Eu mesma vou fazer algumas observações que vão fugir da definição, então já deixo avisado para evitar possíveis decepções.

Em resumo, o Scrum nos dá os insumos necessários para desenvolver e manter um produto, explicando as regras de funcionamento e como cada parte se relaciona e cabe ao responsável pela implementação do Scrum definir as técnicas que serão aplicadas para rodar o framework.

Apesar de ser mais conhecido dentro da área de tecnologia da informação, diversos tipos de projetos podem se beneficiar com o uso do Scrum. Temos exemplos de uso em pequenas e grandes empresas, desenvolvendo sistemas de grande complexidade ou até mesmo para o lançamento de um livro ou projetos pessoais. Se você pesquisar, rapidamente vai encontrar diversos cases de sucesso e entender o porquê de ser tão famoso.

Teoria do Scrum

O Scrum se baseia no empirismo, o que significa que o conhecimento vem da experiência e a tomada de decisão deve ser baseada no que é conhecido. Visando previsibilidade e controle de riscos, o Scrum utiliza uma abordagem iterativa e incremental. Essa definição é sustentada por três pilares:

1. Transparência: todos os aspectos importantes do processo devem ser visíveis para os responsáveis pelo resultado. Todos devem ter o mesmo entendimento do que está sendo trabalhado;
2. Inspeção: os artefatos do Scrum e o progresso rumo ao objetivo da Sprint devem ser frequentemente inspecionados para detectar variações indesejadas. Mas isso deve ser feito de forma que a inspeção não atrapalhe o trabalho do time;
3. Adaptação: se no momento da inspeção for detectada uma variação indesejada, que afeta o resultado final, o processo ou os insumos do processo devem ser ajustados. Esta adaptação deve ser feita rápida o suficiente para minimizar os impactos.

Você já trabalhou em algum projeto onde não tinha certeza se compreendia tudo o que estava sendo dito? Onde ouvia diversas siglas que não sabia o significado? Ou era informado de datas sem saber o que elas representavam? Então você deve valorizar a transparência. Um processo transparente permite que todos os envolvidos consigam entender as decisões, as entregas que estão sendo feitas e porquê elas estão sendo feitas. A priorização e o valor para o cliente final também deve ser perceptível. Independente do seu papel no Scrum, você não deve ficar limitado a saber somente o que tem relação com o seu trabalho, mas sim o processo como um todo. Isso não significa que você vai entender todas as partes em detalhe, mas vai entender como o que você entrega se encaixa na entrega do seu time ou na entrega de um time que trabalha em conjunto com o seu.

Por muitas vezes focamos nos impedimentos que aparecem sem dar a devida atenção ao objetivo da Sprint. Isso não é bom, mas também não posso dizer que é algo raro. Diversas vezes problemas surgem e ficamos tão focados em resolvê-los que não nos damos conta que estamos arriscando o objetivo da Sprint por algo que nem havia sido planejado. Por isso, é importante dedicar momentos para inspecionar e adaptar as entregas, sem deixar que isso tome conta do dia de trabalho do time. Sendo assim, o Scrum prevê quatro cerimônias de inspeção e adaptação: Planning, Daily, Review e Retrospectiva.

Ponto importante: não podemos nos perder inspecionando sem dedicar tempo suficiente adaptando.

Aqui já apareceram algumas palavras do framework que ainda não foram apresentadas, como “Sprint”, por exemplo. Mas não se preocupe, todas as definições serão detalhadas mais adiante.

Valores do Scrum

O Scrum tem como valores comprometimento, coragem, foco, abertura e respeito. Quando esses valores são percebidos pelo time, atingimos os 3 pilares descritos anteriormente, além de construir a confiança como time.

As cerimônias do Scrum permitem que esses valores sejam cultivados. Isso é possível em ambientes seguros, onde as opiniões de todos são levadas em consideração; onde existe confiança no trabalho que está sendo desenvolvido por cada membro do time; e, principalmente, onde as pessoas são valorizadas. Perceba novamente o quanto os valores do Scrum estão alinhados com os Princípios da Agilidade.

A confiança do time não será construída em uma Sprint, talvez nem em 10. Mas, conforme rodamos o Scrum, temos a oportunidade de construir essa confiança e ajustar qualquer coisa que esteja impedindo que essa relação de confiança seja estabelecida. A partir do momento que se atinge um nível de confiança com o time, é possível perceber as pessoas comprometidas com os objetivos, focadas nas entregas e colaborando para que o framework funcione, pois nesses casos os benefícios são perceptíveis para todos. Já trabalhei em times maduros que possuíam um nível de confiança elevado e, em todos os casos, foi uma ótima experiência.

Esta foi a primeira parte da série a respeito do Scrum. Com este conteúdo, você tem a base necessária para entender o desenvolvimento ágil e para saber se a proposta do Scrum vai de encontro ao que você almeja no seu trabalho. No próximo post, sigo falando sobre algumas definições, mas focada na organização de um time Scrum e qual é o papel de cada pessoa que compõe este time.

Como sempre, os comentários estão abertos aguardando sugestões e feedbacks.

Até a próxima!

Copiar link