Afinal, o que é scrum?
Vamos iniciar uma série de artigos sobre o Framework Ágil Scrum com o intuito de verificar a possibilidade de inserir os conceitos de agilidade no dia a dia das consultorias e empresas de um modo geral, que atuam com modelos de gerenciamento tradicional ou ainda, sem modelo algum.
Todo mundo que atua com tecnologia já ouviu falar em Scrum em algum momento. É um assunto que desperta interesse em muita gente. Quando falamos em “agile”, costumamos relacionar o termo a esse “Framework” (Scrum), embora haja uma série de outros métodos que aplicam os conceitos de agilidade definidos no manifesto ágil (falarei um pouco mais à frente).
Um dos criadores do Scrum, Jeff Sutherland, foi autor de um livro chamado “Scrum, a arte de fazer o dobro do trabalho na metade do tempo”. Título muito interessante, afinal, quem não deseja entregar seus projetos mais rápido? Em um próximo artigo comentarei sobre algumas ideias do livro.
Para começar, vamos entender os principais elementos e ideias que compõem o Scrum.
Scrum Guide
O Scrum Guide é um guia criado pelos autores do Scrum, Ken Shweber e Jeff Sutherland. Trata-se de um guia bem curto, cerca de 20 páginas, que contém todas as principais características do Scrum. Ele não fala quase nada a respeito de ferramentas.
O foco do guia não é dizer muitos detalhes de implementação, pois o Scrum não é um livro de boas práticas, como o ITIL ou PMBOK, nem tampouco é uma metodologia.
O Scrum é um Framework, ou seja, um molde, uma estrutura para criar produtos e projetos ágeis. Ele permite agregar ferramentas, métricas e técnicas, porém, não permite que a estrutura básica seja alterada.
Nesse post irei falar dessa estrutura do Framework Scrum. Para ver o conteúdo do Scrum Guide na íntegra, basta baixar no site da Scrum.org.
Manifesto Ágil
Na década de 1990, alguns “agilistas” começaram a utilizar técnicas ágeis em projetos de software. Muitos dos conceitos vieram do exemplo de empresas como a Toyota que utilizava uma metodologia chamada Lean Manufacture, que tinha como principal objetivo evitar desperdícios e se adaptar rapidamente a mudanças, sempre com foco em qualidade.
A ideia de gerenciar projetos utilizando ciclos curtos, incluindo técnicas de qualidade de software, era algo novo. Esses agilistas consideravam que o modelo tradicional de gestão “Waterfall”, originado na engenharia, não fazia sentido para desenvolver softwares.
Porém, não havia consenso entre esses “gerentes de projeto” com relação às técnicas e diretrizes utilizadas. Por isso, no ano de 2001 houve uma reunião desses famosos agilistas para consolidar essas ideias.
Dessa reunião surgiu o Manifesto Ágil, que une os princípios básicos do conceito agile. Abaixo, seguem as principais frases contidas no manifesto que consolidam as ideias do Scrum e outros Frameworks e Métodos Ágeis:
• 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
Para ver o Manifesto Ágil na íntegra, clique aqui.
Princípios do Scrum
O Scrum possui os seguintes pilares: Clareza, Inspeção e Adaptação. Conta ainda, com cerimônias e ferramentas para demonstrar o avanço do projeto. Ele é iterativo e incremental. Isso significa que os projetos são divididos em fases curtas, que chamamos de Sprint e, ao final de cada interação, teremos uma parte do produto pronto para ser demonstrado ao cliente e até mesmo liberado para uso.
O Scrum possui cerimônias para garantir a comunicação dentro e fora do time do Scrum. Dessa forma, o andamento do projeto se torna explícito e claro para todos. Isso demonstra a Clareza e Inspeção.
Mudanças de escopo são esperadas em qualquer projeto, porém, costumam ser tratadas como um risco.
Caso surja uma nova tarefa durante o projeto, ela será analisada para verificar o quanto será útil para o cliente. Caso agregue mais valor que as tarefas previstas, ela deve ser realizada com antecedência, independentemente do escopo original. O foco é sempre agregar valor ao cliente. Essa forma do Scrum tratar as mudanças faz parte de sua característica de adaptação.
Artefatos do Scrum
Product Backlog: é uma lista de tarefas que o Product Owner gerencia. Ela contém o escopo do projeto ou produto. Essa lista é ordenada de acordo com as tarefas que agregarão maior valor ao cliente.
Cabe ao Product Owner entender as necessidades do cliente e manter essa lista sempre ordenada. Mais à frente falaremos das atribuições de um Product Owner.
Sprint Backlog: é a lista de tarefas que o Time de Desenvolvimento escolheu para executar durante uma Sprint. As tarefas desta lista devem ser concluídas ao final de cada Sprint.
Ciclo de vida do Scrum
O Scrum possui fases que são repetidas até o projeto ser finalizado ou até enquanto durar um produto.
Essas fases compõem o ciclo de vida do Scrum. Podemos dividi-las em:
• Planejamento da Sprint (Sprint Planning)
• Sprint
• Reunião diária (Daily Scrum)
• Revisão (Sprint Review)
• Retrospectiva (Sprint Retrospective)
A imagem abaixo demonstra esse fluxo:
Sprint: é uma etapa de um projeto ou produto que pode durar de 1 até 30 dias, e que se repete até que o projeto esteja concluído, ou até que o produto faça sentido.
É nessa etapa que o produto é desenvolvido. Nesse momento, o Time de Desenvolvimento está focado na entrega das funcionalidades que agregarão valor ao cliente.
Um projeto pode ser composto por inúmeras Sprints, que podem durar, no máximo, um mês. O mais comum é ter Sprints de duas semanas.
O ideal é que todas as Sprints tenham um tamanho fixo. Também é importante que o resultado da Sprint seja um incremento de software que faça sentido para o cliente. Esse incremento deve estar PRONTO, ou seja, testado e funcionando.
Sprint Planning: é a reunião de planejamento da Sprint. Durante essa cerimônia, o Time do Scrum trabalha no entendimento e na estimativa das tarefas do Product Backlog que possuem maior prioridade.
Daily Scrum: é uma reunião diária que pode durar, no máximo, 15 minutos. É uma excelente forma de inspecionar o trabalho realizado até o momento. Nessa reunião, todos devem estar de pé para garantir que ela não se prolongue.
Cada integrante do time deve responder às seguintes questões:
- O que eu fiz ontem?
- O que farei até à próxima reunião?
- Há algum impedimento para realizar essa atividade?
Essa reunião promove a comunicação e faz com que o time se ajude a resolver os problemas.
Sprint Review: é a reunião de revisão da Sprint. Ela ocorre sempre ao final de cada Sprint com o objetivo de demonstrar o trabalho realizado durante a Sprint.
Ela tem duração de, no máximo, 3 horas. Mas há casos de Sprints mais longas que podem durar até 30 dias. O Time de Desenvolvimento irá apresentar o resultado. O cliente pode participar da reunião para inspecionar as features que estão sendo entregues. O Product Owner irá dizer se o que está sendo entregue foi aprovado ou não. Caso tenha sido aprovado, irá liberar a entrega para o cliente. Caso não tenha sido aprovado, os itens retornarão ao Backlog do Produto para ser reavaliado.
Sprint Retrospective: após a revisão, o time irá se reunir novamente, dessa vez sem o cliente, para avaliar os pontos positivos e negativos dessa Sprint que terminou. O objetivo é aprender com os erros cometidos. Após essa reunião, uma nova Sprint se inicia, voltando ao planejamento.
Papéis
O Time Scrum é composto por três papéis: Scrum Master, Product Owner e Time de Desenvolvimento (note que chamamos de papéis, e não de cargo ou profissão).
Um indivíduo pode ter o cargo de gerente de uma determinada área e, mesmo assim, compor o Time de Desenvolvimento.
Também não há uma hierarquia no Scrum. Ninguém está acima de ninguém. O que importa é o todo.
Veja abaixo as atribuições de cada papel.
Time de Desenvolvimento
São as pessoas que fazem acontecer durante as Sprints. Possui a característica de ser autogerenciável e multifuncional. Embora o nome seja Time de Desenvolvimento, não confunda com programadores.
Esse time é multifuncional. Pode ser composto por consultores de negócios, programadores, designers, QA (Quality Assurance ou Testers), UX (User Experience), engenheiros, DBA, gerentes etc. Tudo depende da estrutura do produto ou do projeto.
Todos os integrantes do time são responsáveis pela entrega. Então, cada um deve estar comprometido com o todo. Se for necessário, o DBA irá sim, realizar testes.
O tamanho ideal para esse time é de 3 a 9 pessoas. Times com mais de 9 integrantes tendem a não conseguir se autogerenciar.
É o time que decide quantos itens serão entregues durante uma Sprint. Durante o planejamento da Sprint (Sprint Planning), o time se reúne com o Product Owner para entender os itens de maior prioridade. A partir daí, os integrantes realizam uma estimativa para definir a complexidade de cada item e verificam se cabe em uma Sprint.
Segundo o Scrum, o time não pode ser alterado e nem receber intervenções externas durante uma Sprint.
Productos Owner (Dono do Produto)
É o papel responsável por entender as necessidades do cliente e traduzir para o Time de Desenvolvimento. Ele prioriza as tarefas do Backlog do produto. Os itens que serão entregues são os itens que irão agregar mais valor ao cliente.
Ao final de cada Sprint, o Product Owner avalia a entrega do time durante a reunião de revisão.
Embora tenha esse título de “owner”, ele não é um chefe. Inclusive, ele sequer pode interferir nas decisões do Time de Desenvolvimento.
Scrum Master
As principais responsabilidades do Scrum Master são: retirar os impedimentos do time de desenvolvimento e divulgar as melhores práticas do Scrum para o time e para o resto da organização.
O Scrum Master protege o time impedindo que ele seja afetado por elementos externos. Ou seja, se alguém de fora do Time de Desenvolvimento, inclusive o Product Owner, solicitar alguma atividade que não tenha relação com os itens comprometidos para a Sprint, o Scrum Master tem a obrigação de barrar e procurar uma alternativa.
Caso o time encontre algum problema que impeça o andamento adequado para a Sprint, como a falta de algum insumo, o Scrum Master atua na retirada desse impedimento.
Outra característica importante é que ele não toma decisões para o time nem se envolve nas decisões do Time de Desenvolvimento. Ele atua como um servo-líder, ensinando boas práticas e auxiliando no que for necessário. Muitas vezes, atua como um mentor, potencializando as habilidades do time e evitando conflitos.
Resumo
O Scrum é um Framework ágil, usado principalmente em projetos de software, mas pode ser utilizado em vários tipos de projetos.
Seu principal foco é entregar valor ao cliente de forma interativa e incremental. Para isso, divide o desenvolvimento em ciclos curtos (Sprints). As atividades desenhadas na Sprint são as que irão agregar mais valor ao negócio.
Há apenas três papéis no Scrum:
O Product Owner é quem representa o cliente. Ele irá priorizar as atividades no Backlog do Produto.
O Time de Desenvolvimento é composto pelas pessoas que irão entregar parte do projeto a cada Sprint. É uma equipe multidisciplinar e autogerenciável.
O Scrum Master é responsável por tirar os impedimentos para que o Time de Desenvolvimento não encontre desvios.
Algumas cerimônias são necessárias para garantir a Inspeção e Adaptação: Planejamento da Sprint, Daily Meeting, Revisão da Sprint e Retrospectiva da Sprint.
Esse artigo busca trazer os conceitos do Scrum. Em breve, postaremos novos artigos ensinando a colocar em prática, inclusive utilizando ferramentas e técnicas.
Por: Fernando Silva – Especialista GRA Actionsys
