Scrum é uma estrutural processual (framework) para suportar o desenvolvimento e manutenção de produtos complexos. O termo framework é muito usado nos ambientes de TI, principalmente naqueles onde o foco é o desenvolvimento de sistemas.
Concebe-se o termo framework em desenvolvimento de software, como sendo um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação. Por definição o Scrum não se insere na descrição acima, pois não se trata de um software executável.
Embora ele seja descrito por muitos como um framework, percebe-se que essa descrição está relacionada não ao fato dele possuir um conjunto de códigos de software que pode ser reutilizado em diversos projetos, mas sim por se tratar de um arcabouço de conceitos e práticas que podem ser aplicadas no desenvolvimento de alguma atividade, como por exemplo, no desenvolvimento de software, que aqui será abordado.
Dessa forma, o Scrum pode ser definido como um framework, porém o mais adequado seria o uso do termo “Framework Conceitual” por ele não oferecer códigos de software aos seus usuários. Metodologia, também é uma definição atribuída por muitos ao Scrum, já que a ele estão associados um conjunto de regras, papéis, atividades e artefatos que são propostos em sua execução.
O Scrum é uma proposta ágil para o gerenciamento de projetos complexos. Apresenta recursos que visam manter estável o controle do desenvolvimento mesmo em ambientes instáveis, onde predominam constantes mudanças no escopo de requisitos, por exemplo, e torna-se uma alternativa às propostas tradicionais existentes no mercado de desenvolvimento de software voltados para essa mesma finalidade, como o Rational Unified Process (RUP).
Saiba mais: Curso de Scrum: Conhecendo o Product Owner
Características do Scrum
Um Scrum Team, como é chamada a equipe que executa o Scrum no gerenciamento de seus projetos, trabalha sobre três pilares do controle de processo empírico, no qual se fundamenta o Scrum, que são transparência, inspeção e adaptação.
Transparência diz respeito a ter um processo visível para todos os responsáveis por os resultados, de forma que o Scrum Team compartilhe o entendimento do que está sendo feito. A inspeção deve garantir a correta execução do Scrum em direção ao objetivo a fim de que as indesejáveis variações dentro do projeto sejam corrigidas, mas tendo o cuidado para que as inspeções nunca cheguem a atrapalhar o bom desenvolvimento das tarefas. A adaptação é uma aliada da inspeção, já que esta informa tudo aquilo dentro do processo que teve seu caminho desviado, necessitando assim que adaptações sejam feitas a fim de que os resultados esperados sejam logrados. A adaptação acontece de forma que o Scrum Team possa acompanhar sem prejuízo as mudanças que podem acontecer no ambiente do projeto. No Scrum, são prescritas quatro oportunidades de se manter a transparência, inspeção e adaptação constantes: Scrum Planning Meeting, Daily Scrum Meeting , Sprint Review, Sprint Retrospective. Todos esses termos serão vistos com mais detalhes adiante.
O framework Scrum propõe uma abordagem iterativa e incremental onde o trabalho é dividido e desenvolvido em quantos Sprints forem necessários para a conclusão do projeto. Uma Sprint representa o espaço de tempo em que é desenvolvida uma parte de todo o trabalho estimado. Ao fim de uma Sprint espera-se obter uma versão incremental utilizável do produto, a qual recebe a denominação de “Pronto”. A definição de “Pronto” pode variar de acordo com cada Scrum Team, mas deve ser uma informação compartilhada por todos que fazem parte deste.
A parcela funcional do sistema concluída ao fim de uma Sprint é o resultado do desenvolvimento de uma lista de necessidades para o software, que representa parte daquilo que é necessário para o produto final. Essa lista recebe o nome de Sprint Backlog, que é por sua vez retirada do Product Backlog que consiste em uma lista ordenada de tudo que é necessário para o produto final.
Papéis do Scrum
O Scrum Team é composto por três papeis, que são o Product Owner, o Development Team e o Scrum Master.
O Product Owner (PO) é o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento e é a única pessoa responsável por gerenciar o Product Backlog. O PO está ligado à visão de negócio do projeto, ele representa o interesse das pessoas que investem no desenvolvimento do produto.
Sua maior responsabilidade é gerenciar o Product Backlog que inclui:
- Ordenar os itens do Product Backlog de acordo com a visão de prioridade do cliente;
- Garantir a transparência do Product Backlog; além de:
- Aceitar ou rejeitar os resultados dos trabalhos;
- Decidir o momento de liberação do produto ou de suas versões funcionais para o cliente.
O Development Team (DT) é a equipe de profissionais responsável por transformar o Product Backlog em um produto funcional. São eles que desenvolvem as versões incrementais do produto “Pronto” que são entregues ao final de cada Sprint.
Um DT de um Scrum Team tem como característica ser auto-organizável e multifuncional. Dessa forma ele consegue decidir qual a melhor forma de se chegar às metas estabelecidas, sem precisar de um “Gerente de projeto” delegando responsabilidades ao logo do tempo. E por ser também multifuncional todos os integrantes de um DT devem ser capazes de desenvolver diversas atividades dentro do projeto, não sendo apropriado possuir profissionais que sejam apenas especialistas. Todos que fazem parte de um Development Team no Scrum recebem a classificação de desenvolvedores.
O tamanho ideal do DT é pequeno o suficiente para se manter ágil e grande o suficiente para ser capaz de completar uma parcela significativa do trabalho.
É interessante que o Development Team não possua menos que três integrastes nem mais que 9. Com poucas pessoas trabalhando no desenvolvimento corre-se o risco de o potencial de desenvolvimento não ser o suficiente para entregar um produto funcional ao final de uma Sprint. Já com equipes muito grandes o Scrum pode se tornar muito complexo e difícil de ser gerenciado.
O Scrum Master (SM) é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Scrum Team adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Scrum Team, e não somente um gerente, está sempre em contato com o Product Owner.
O SM está sempre à disposição para prestar esclarecimentos sobre o que se deve fazer a qualquer momento no decorrer do projeto. Sempre eliminando os obstáculos que impedem o bom funcionamento do Scum.
Eventos do Scrum
O objetivo de se ter eventos no Scrum é proporcionar um maior controle sobre o processo adquirindo uma rotina de trabalho e aumentar a transparência ao decorrer do desenvolvimento. Os eventos Scrum são time boxed, ou seja, possuem uma duração máxima definida. Não se pode garantir o sucesso de um projeto com o uso do Scrum deixando de incluir qualquer um dos seus eventos que são, a Sprint, a Sprint Planning Meeting, a Daily Scrum Meeting, a Sprint Review e a Sprint Retrospective.
Sprint
Uma Sprint consiste em um espaço de tempo de no máximo quatro semanas. Onde é desenvolvido por o Development Team um produto potencialmente utilizável.
O tempo de duração de uma Sprint pode variar entre duas a quatro semanas, essa é uma decisão compartilhada por o Scrum Team. Ter no máximo um mês de duração proporciona um maior controle sobre o objetivo da Sprint, diminuindo os riscos do desenvolvimento adquirir muita complexibilidade. Cada Sprint deve ter um objetivo a ser alcançado pelo Development Team. Esse objetivo resulta no incremento do produto final.
Em uma Sprint acontecem quatro eventos do Scrum, a Sprint Planning Meeting , Daily Scrum Meeting , Sprint Review e Sprint Retrospective.
Sprint Planning Meeting
O Sprint Planning Meeting é a reunião de planejamento que ocorre antes do início de uma Sprint como resultado de um trabalho colaborativo do Scrum Team. Deve ter um time box de oito horas de duração para Sprints de quatro semanas. Ao fim de uma Sprint Planning Meeting o Development Team deve saber responder ao Scrum Master e ao Product Owner o que será entregue como resultado do próximo incremento e como o trabalho será desenvolvido para chegar ao resultado esperado.
O PO apresenta para o Scrum Team o Product Backlog, que consiste em uma lista ordenada de tudo que é necessário para o produto final, para que o Development Team escolha quantos itens será capaz de desenvolver na próxima Sprint. Essa é uma decisão que deve ser tomada apenas pelo o Development Team, pois é este quem vai desenvolver o produto que representará o resultado da Sprint. O PO tem a responsabilidade de definir a prioridade dos itens do Product Backlog, mas quem sabe quantos itens serão desenvolvidos é o DT. Após a criação do Sprint Backlog que representa a seleção dos itens do Product Backlog que serão desenvolvidos na Sprint o Scrum Team define o objetivo da Sprint que é a meta para qual todos devem trabalhar até o término da Sprint.
Como dito antes o Scrum Team tem como característica ser auto-organizável e multifuncional. Seguindo esse pensamento o Development Team deve ser capaz de decidir a melhor forma de alcançar os objetivos da Sprint. Usando de seu conhecimento para transformar o Sprint Backlog em um produto utilizável. O Scrum não prescreve praticas da engenharia de software a serem usadas dentro do desenvolvimento do sistema. Essa é uma decisão do Development Team.
Daily Scrum Meeting
A Daily Scrum Meeting é uma reunião diária time box geralmente de 15 minutos. O seu objetivo principal é fazer o Development Team refletir a respeito das seguintes questões: “O que foi completado desde a última reunião?”, “O que será feito até a próxima reunião e quais os obstáculos que estão no caminho?”.
Essa reunião assegura que o DT está seguindo a direção correta em relação ao objetivo da Sprint. Como regra do Scrum somente os integrantes do Development Team devem participar da Daily Scrum Meeting.
A reunião diária melhora a comunicação, identifica e remove impedimentos para o desenvolvimento e melhora o nível de conhecimento da Equipe de Desenvolvimento.
Sprint Review
A Sprint Review acontece ao final de cada Sprint e tem como objetivo avaliar o que foi produzido pelo Development Team. É uma reunião time box com duração de 4 horas para Sprints de um mês.
Na Sprint Review o Product Owner se encarrega de verificar se o incremento desenvolvido realmente atende a expectativa de “Pronto”. Nesse momento o PO se encarrega de atualizar o Product Backlog e através disso torna-se capaz projetar possíveis conclusões.
A Sprint Review chega a fornece informações importantes que serão usadas na Sprint Planning Meeting da próxima Sprint.
Sprint Retrospective
Esta é uma reunião time box de duração de três horas para uma Sprint de um mês. E tem como objetivo avaliar o desempenho do Development Team, criando melhorias a esse respeito para a próxima Sprint. Deve ocorrer ao final da Sprint Review e serve como uma forma de inspeção e adaptação em que o Scrum Team enxerga melhores formas de trabalhar a fim de otimizar o seu desempenho na Sprint posterior.
Conclusão
O Scrum pode contribuir para a obtenção dos resultados esperados nos projetos executados em ambientes onde a agilidade possa ser empregada, mas como dito antes, a correta execução de seus eventos deve acontecer para que o êxito seja logrado. Deve-se obter o correto entendimento do propósito de suas práticas, papéis e eventos a fim de que o Scrum Team consiga em encontrar a lógica na execução dos pilares do Scrum que são transparência, inspeção e adaptação.
Referências
- SCHMIDT, D. C.; Gokhale, A.; NATARAJAN, B. Leveraging Application Frameworks. ACM Queue, v.2,5 jul./ago. 2004, p.66-75.
- font-size: 14px SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum, 2011. Disponível aqui.
