Estudo sobre Desenvolvimento de Software
Utilizando o Framework Ágil Scrum
Andre Scarmagnani1 , Fabricio C. Mota1 , Isaac da Silva1 , Matheus de C. Madalozzo1 ,
Regis S. Onishi1 , Luciano S. Cardoso1
1
UDC ANGLO – Faculdade Anglo Americano (FAA)
Av. Paraná, 5661, CEP: 85868-030 – Foz do Iguaçu – PR – Brasil
{andre-scar, caceres.mota, shindionishi}@hotmail.com, [email protected],
[email protected], [email protected]
Abstract. Agile development methodologies has been outstanding every day, but
these are still not widespread in academia. The purpose of this article, as well
as disseminating this issue and provide support for future research is to demonstrate a simple and objective way, operation, features, vocabulary and application of the scrum framework in a work environment.
Resumo. As metodologias de desenvolvimento ágil vem se destacando a cada
dia, porém essas ainda são pouco difundidas no meio acadêmico. O objetivo
deste artigo, além de difundir esse assunto e servir de apoio para futuras pesquisas, é demonstrar de maneira simples e objetiva, o funcionamento, as caracterı́sticas, o vocabulário e a aplicação do framework scrum em um ambiente de
trabalho.
1. Introdução
Atualmente, os negócios atuam em um ambiente sujeito a mudanças constantes, como
novas oportunidades de mercados, diferentes condições econômicas e o surgimento de
produtos e serviços concorrentes. Para quase todas as operações de negócios é essencial
que um novo software seja desenvolvido e, para maior competitividade, deve ser em curto
prazo. O desenvolvimento ágil muitas vezes é requisito fundamental para a criação de
softwares a fim de que consigam atender mais prontamente as demandas do cliente.
Segundo [Sommerville 2006], os processos de desenvolvimento ágil de software
são projetados para criar softwares úteis rapidamente. Geralmente, são processos iterativos nos quais a especificação, o projeto, o desenvolvimento e o teste são intercalados.
O software não é desenvolvido e disponibilizado integralmente, mas em uma série de
incrementos, onde cada incremento inclui uma nova funcionalidade do sistema.
Na engenharia de software existem modelos que trabalham de forma ágil nos processos, com semelhanças entre as abordagens filosóficas e práticas. Dentro dessa abordagem surgiu o manifesto para o desenvolvimento ágil de software, cujo o objetivo era
descobrir melhores maneiras de desenvolver software [Beck et al. 2001]. Uma das maneiras encontradas foi a utilização do framework Scrum que foi desenvolvido por Jeff
Sutherland na década de 90.
2. Conceitos de Scrum
O framework Scrum utilizado para gestão de desenvolvimento de software complexos.
Essa ferramenta não é um processo para construir produto, mas sim um framework no
qual pode ser empregado vários processos ou técnicas, tendo uma eficácia relativa das
práticas de gerenciamento e desenvolvimento de softwares.
O Scrum é formado pelos times do Scrum, associados a papeis, eventos, artefatos
e regras. Cada uma dessas associações dentro do framework servem a um proposito e é
importante para o sucesso do Scrum.
O framework tem sua fundamentação nas boas práticas que foram adquiridas
através da realização de vários projetos e que tiveram seus processos de maior sucesso
documentados, empregando uma abordagem iterativa e incremental para aperfeiçoar a
previsão e o controle de riscos. Três pilares apoiam a implementação de controle de processo empı́rico:
• Transparência – Aspectos significativos do processo devem estar visı́veis aos responsáveis pelos resultados.
• Inspeção – Os usuários Scrum devem, frequentemente, inspecionar os artefatos
Scrum e o progresso em direção a detectar variações.
• Adaptação – Se um inspetor identifica que um processo se desviou para fora dos
limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o
material sendo produzido deve ser ajustado o mais breve possı́vel.
O Scrum possui quatro eventos formais, contidos dentro dos limites da Sprint1 ,
para inspeção e adaptação, conforme mostra na figura 1 [Sutherland and Schwaber 2011]
Figura 1. Ciclo da sprint. (Fonte: Adaptada de [Schwaber and Beedle 2002]).
3. O Time
O time Scrum é composto pelo product owner, o time de desenvolvimento e o scrum
master, os integrantes do time Scrum são auto-organizáveis, ou seja, escolhem qual a
melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de
fora do time. São multifuncionais pois possuem todas as competências necessárias para
completar o trabalho sem depender de outros de fora da equipe. O modelo de time no
Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.
A Entrega dos produtos é feita de forma iterativa e incremental, o que resulta em
mais oportunidades de realimentação [Sutherland and Schwaber 2011].
1
Abordado na seção 5.1
3.1. Product Owner
O Product Owner (PO), ou dono do produto é 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[Sutherland and Schwaber 2011]. O PO está ligado à visão
de negócio do projeto, ele representa o interesse das pessoas que investem no desenvolvimento do produto[Neto 2012].
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;
• Aceitar ou rejeitar os resultados dos trabalhos;
• Decidir o momento de liberação do produto ou de suas versões funcionais para o
cliente.
3.2. Time de Desenvolvimento
O time de desenvolvimento consiste de profissionais que transformam o Product Backlog
em um produto funcional. É esse time que desenvolve as versões incrementais do produto
”pronto”que são entregues ao final de cada Sprint.
O tamanho ideal do time é pequeno o suficiente para se manter ágil e
grande o suficiente para ser capaz de completar uma parcela significativa do trabalho
[Sutherland and Schwaber 2011].
Também espera-se que time possua um caráter auto-gerenciável, com o comprometimento e uma postura multifuncional dos membros representando um fator crucial
para o sucesso do projeto.
3.3. Scrum Master
O scrum master é o gerente do projeto, o responsavel por garantir que a equipe siga de
maneira adequada as práticas da scrum e também responsável por eliminar os obstáculos
que impedem o bom funcionamento do Scrum.
4. Eventos Scrum
O Scrum utiliza os eventos prescritos parar criar uma rotina e minimizar a necessidade
de reuniões não definidas no Scrum. Os eventos podem terminar quando o propósito for
alcançado, ou seja, disponibiliza o tempo adequado aos processos e evita possı́veis perdas
[Sutherland and Schwaber 2011].
4.1. Sprint
A parte fundamental do Scrum é a Sprint, no qual uma versão incremental potencialmente utilizável do produto é criada. Suas durações são coerentes em todo o esforço de
desenvolvimento e iniciam uma após a outra, com intervalos não maiores que um mês.
Durante a Sprint não são feitas mudanças que possam colocar em perigo o objetivo
da Sprint. As metas de qualidade não diminuem e o escopo pode ser renegociado entre o
Product Owner e o Time de Desenvolvimento de acordo com o que foi aprendido.
Cada Sprint tem a definição do que é para ser construı́do, um plano projetado e
flexı́vel que irá guiar a construção, o trabalho e o resultado do produto. O intervalo entre
uma Sprint e outra for muito longo, aumentam os riscos de erros e prejuı́zos. Sprints
rápidas permitem uma previsão que garante a correção e adaptação do progresso em
direção ao objetivo, pelo menos a cada mês.
O objetivo da Sprint é satisfeito através da implementação do Backlog do produto,
que por sua vez, fornece ao time de desenvolvimento o porquê de estar construindo o
incremento, criado durante a reunião de planejamento da Sprint. O time de desenvolvimento implementa a funcionalidade e tecnologia no intuito de satisfazer o objetivo da
Sprint, se o trabalho for finalizado por ser diferente do esperado pelo time de desenvolvimento, então eles contam com o Product Owner para negociar o escopo do backlog
[Sutherland and Schwaber 2011].
4.2. Reunião de Planejamento da Sprint
Em [Schwaber and Beedle 2002], o trabalho a ser realizado na Sprint é planejado na
reunião de planejamento. Este plano é criado com o trabalho colaborativo de todo o
time Scrum.
O Scrum Master garante que o evento ocorra e que os participantes entendam seu
propósito, ensinando o time Scrum a manter-se dentro dos limites do time-box. A reunião
de planejamento da Sprint responde as seguintes questões:
• O que pode ser entregue como resultado do incremento da próxima Sprint?
• Como o trabalho necessário para entregar o incremento será realizado?
4.3. Reunião Diária
As reuniões diárias do scrum são realizadas para que o time de desenvolvimento, possa
inspecionar o trabalho das reuniões posteriores, e prever o próximo trabalho que deverá
ser feito. De acordo com [Sutherland and Schwaber 2011], durante a reunião os desenvolvedores esclarecem:
• O que eu fiz ontem que ajudou o time de desenvolvimento a atender a meta da
Sprint?
• O que eu farei hoje para ajudar o time de desenvolvimento atender a meta da
Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o time de desenvolvimento no
atendimento da meta da Sprint?
O time de desenvolvimento utiliza as reuniões para inspecionar o processo em
direção ao objetivo. O Scrum Master assegura que a equipe de desenvolvimento tenha a
reunião, porém a equipe é responsável por conduzi-la.
As reuniões diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas
tomadas de decisão, e melhoram o nı́vel de conhecimento do time de desenvolvimento.
4.4. Revisão da Sprint
A revisão é executada no final, para inspecionar o incremento e adaptar o Backlog do
produto se necessário. Qualquer mudança no Backlog do produto durante a Sprint, os
participantes colaboram nas próximas coisas que podem ser feitas para otimizar. Esta é
uma reunião informal, não uma reunião de status, e a apresentação do incremento destinase a motivar e obter comentários e promover a colaboração.
O resultado da reunião de revisão da Sprint é um Backlog do produto revisado, que define o provável Backlog do produto para a próxima Sprint. O Backlog
do produto pode também ser ajustado completamente para atender novas oportunidades
[Sutherland and Schwaber 2011].
4.5. Retrospectiva da Sprint
Segundo [Sutherland and Schwaber 2011], a retrospectiva da Sprint serve para que o time
Scrum inspecione a si próprio e crie formas de melhorias que são aplicadas na próxima
Sprint. Esta retrospectiva ocorre antes da reunião de planejamento e depois da revisão
da Sprint. A Retrospectiva da Sprint consiste em inspecionar como a última Sprint foi,
identificar suas melhorias e melhorar no modo que o Time Scrum faz seu trabalho.
5. Artefatos 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. São especificamente projetados para
maximizar a transparência das informações chave de modo que todos tenham o mesmo
entendimento dos artefatos [Sutherland and Schwaber 2011].
5.1. Backlog do Produto
O Backlog do Produto é uma lista ordenada por prioridade de tudo que deve ser necessário
no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no
produto, sendo de responsabilidade do Product Owner.
O Product Owner deve influenciar o time, ajudando no entendimento e nas decisões, porém o time de Desenvolvimento é responsável por todas as estimativas, assim
as pessoas que irão realizar o trabalho fazem a estimativa final.
O Product Owner acompanha o trabalho restante pelo menos a cada reunião
de revisão da Sprint, para isso, compara com trabalho que restava quando ocorreu a
reunião de revisão anterior, para avaliar o progresso do trabalho previsto e finalizar no
prazo previsto. Esta informação deve ser transparente para todas as partes interessadas
[Sutherland and Schwaber 2011].
5.2. Backlog da Sprint
O Backlog da Sprint é um conjunto de itens da Backlog do Produto selecionados para a
Sprint, juntamente com o plano de entrega do incremento do produto.
Ele torna mais visı́vel o trabalho que o time de Desenvolvimento identifica como
necessário para atingir o objetivo da Sprint.
O Backlog da Sprint serve como um plano que contém detalhes suficientes para
que as mudanças no progresso sejam entendidas durante a Reunião Diária. O time de
desenvolvimento modifica o Backlog ao longo de toda a Sprint, e o Backlog vai surgindo
durante a Sprint. Este surgimento ocorre quando o time de desenvolvimento trabalha
segundo o plano e aprende mais sobre o trabalho necessário para alcançar o objetivo da
Sprint [Sutherland and Schwaber 2011].
5.3. Incremento
O incremento é a soma de todos os itens do Backlog do produto completados durante
a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um
novo incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável
e atender a definição de “Pronto” do time Scrum, independente do Product Owner decidir
por liberá-lo realmente ou não [Schwaber and Beedle 2002].
6. Transparência do Artefato
Decisões para otimizar o valor e controlar os riscos são feitos com base no estado dos artefatos. Na medida em que a transparência é plena, estas decisões tem uma base sólida. Na
medida em que os artefatos não são completamente transparentes, estas decisões podem
conter falhas, valores podem diminuir e riscos podem aumentar.
O trabalho do Scrum Master é trabalhar com o time Scrum para aumentar a
transparência dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e mudança. Transparência não ocorre de um dia para o outro, mas é um caminho
[Sutherland and Schwaber 2011].
6.1. Definição de “Pronto”
Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa. Embora, isso varie significativamente
para cada time Scrum, os integrantes devem ter um entendimento compartilhado do que
significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de
Pronto” para o time Scrum e é usado para assegurar quando o trabalho de incremento do
produto está completo.
A mesma definição orienta o time de desenvolvimento no conhecimento de quantos itens do Backlog do produto podem ser selecionados durante a reunião de planejamento da Sprint. O propósito de cada Sprint é entregar incrementos de funcionalidades
potencialmente utilizáveis que aderem à definição atual de “Pronto” do time Scrum.
O time de desenvolvimento entrega um incremento de funcionalidade do produto a
cada Sprint. Este incremento é utilizável, assim o Product Owner pode escolher liberá-lo
imediatamente. Se a definição de “Pronto” para um incremento é parte das convenções,
padrões ou diretrizes de desenvolvimento da organização, todos os times Scrum devem
segui-la. Se “Pronto” para um incremento não é uma convenção de desenvolvimento
da organização, o time de desenvolvimento do time Scrum deve criar uma definição
de “Pronto” apropriada para o produto. Se há múltiplos times Scrum trabalhando no
lançamento do sistema ou produto, os times de desenvolvimento de todos os times Scrum
devem mutuamente acordar uma definição de “Pronto”.
Cada incremento é adicionado a todos os incrementos anteriores e completamente
testado, garantindo que todos os incrementos funcionem juntos.
Com um time Scrum maduro, é esperado que a sua definição de
“Pronto” seja expandida para incluir critérios mais rigorosos de alta qualidade
[Sutherland and Schwaber 2011].
7. Conclusão
O Scrum é geralmente voltado ao desenvolvimento de software mas pode ser aplicado em
qualquer área.
É um framework simples, criado para tornar ágil a realização de projetos complexos, tal como os que necessitam de mudanças rápidas durante o desenvolvimento, e
mesmo assim, proporcionando a entrega de resultados de alta qualidade. Sendo assim,
dentro do gerenciamento ágil de projetos, o Scrum é um dos que mais se destaca.
Existem alguns benefı́cios obtidos com o uso do framework scrum, tais como:
Diminuição dos riscos, maior integração entre os membros das equipe, rápida solução de
problemas, progresso medido continuamente, os clientes se tornam parte da equipe de
desenvolvimento, entregas frequentes de funcionalidades funcionando, discussões diárias
de status com a equipe, os profissionais de negócios e tecnologias trabalham juntos. Com
todo esse entrosamento entre a equipe de desenvolvimento e com a participação ativa
dos clientes o rendimento do projeto aumenta e os requisitos e solicitação de alteração
passa a ser entendido mais rapidamente, devido ao explı́cito entrosamento de todos os
participantes do desenvolvimento.
Referências
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C.,
Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Manifesto for agile
software development. http://www.agilemanifesto.org. Acessado em: 22 maio de
2014.
Neto, C. (2012). Conhecendo o scrum. http://www.devmedia.com.br/conhecendo-oscrum/25744. Acessado em: 26 maio de 2014.
Schwaber, K. and Beedle, M. (2002). Agile software development with scrum. Prentice
Hall, 1th edition.
Sommerville, I. (2006). Engenharia de Software. Pearson, 8th edition.
Sutherland, J. and Schwaber, K. (2011). The scrum guide. Retrieved from www.scrum.org.