Estudo sobre Desenvolvimento de Software

Utilizando o Framework Agil

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. Parana, 5661, CEP: 85868-030 Foz do Iguacu PR Brasil
{andre-scar, caceres.mota, shindionishi}@hotmail.com, isaac.s@outlook.com,
matheus.madalozzo@gmail.com, lucianoscardoso@gmail.com

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 a gil vem se destacando a cada
dia, porem essas ainda sao pouco difundidas no meio academico. O objetivo
deste artigo, alem de difundir esse assunto e servir de apoio para futuras pesquisas, e demonstrar de maneira simples e objetiva, o funcionamento, as caractersticas, o vocabulario e a aplicaca o do framework scrum em um ambiente de
trabalho.

1. Introduca o
Atualmente, os negocios atuam em um ambiente sujeito a mudancas constantes, como
novas oportunidades de mercados, diferentes condico es economicas e o surgimento de
produtos e servicos concorrentes. Para quase todas as operaco es de negocios e essencial
que um novo software seja desenvolvido e, para maior competitividade, deve ser em curto
prazo. O desenvolvimento a gil muitas vezes e requisito fundamental para a criaca o de
softwares a fim de que consigam atender mais prontamente as demandas do cliente.
Segundo [Sommerville 2006], os processos de desenvolvimento a gil de software
sao projetados para criar softwares u teis rapidamente. Geralmente, sao processos iterativos nos quais a especificaca o, o projeto, o desenvolvimento e o teste sao intercalados.
O software nao e desenvolvido e disponibilizado integralmente, mas em uma serie de
incrementos, onde cada incremento inclui uma nova funcionalidade do sistema.
Na engenharia de software existem modelos que trabalham de forma a gil nos processos, com semelhancas entre as abordagens filosoficas e praticas. Dentro dessa abordagem surgiu o manifesto para o desenvolvimento a gil de software, cujo o objetivo era
descobrir melhores maneiras de desenvolver software [Beck et al. 2001]. Uma das maneiras encontradas foi a utilizaca o do framework Scrum que foi desenvolvido por Jeff
Sutherland na decada de 90.

2. Conceitos de Scrum
O framework Scrum utilizado para gestao de desenvolvimento de software complexos.
Essa ferramenta nao e um processo para construir produto, mas sim um framework no
qual pode ser empregado varios processos ou tecnicas, tendo uma eficacia relativa das
praticas de gerenciamento e desenvolvimento de softwares.
O Scrum e formado pelos times do Scrum, associados a papeis, eventos, artefatos
e regras. Cada uma dessas associaco es dentro do framework servem a um proposito e e
importante para o sucesso do Scrum.
O framework tem sua fundamentaca o nas boas praticas que foram adquiridas
atraves da realizaca o de varios projetos e que tiveram seus processos de maior sucesso
documentados, empregando uma abordagem iterativa e incremental para aperfeicoar a
previsao e o controle de riscos. Tres pilares apoiam a implementaca o de controle de processo emprico:
Transparencia Aspectos significativos do processo devem estar visveis aos responsaveis pelos resultados.
Inspeca o Os usuarios Scrum devem, frequentemente, inspecionar os artefatos
Scrum e o progresso em direca o a detectar variaco es.
Adaptaca o Se um inspetor identifica que um processo se desviou para fora dos
limites aceitaveis, e que o produto resultado sera inaceitavel, o processo ou o
material sendo produzido deve ser ajustado o mais breve possvel.
O Scrum possui quatro eventos formais, contidos dentro dos limites da Sprint1 ,
para inspeca o e adaptaca 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 e composto pelo product owner, o time de desenvolvimento e o scrum
master, os integrantes do time Scrum sao auto-organizaveis, ou seja, escolhem qual a
melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de
fora do time. Sao multifuncionais pois possuem todas as competencias necessarias para
completar o trabalho sem depender de outros de fora da equipe. O modelo de time no
Scrum e projetado para aperfeicoar a flexibilidade, criatividade e produtividade.
A Entrega dos produtos e feita de forma iterativa e incremental, o que resulta em
mais oportunidades de realimentaca o [Sutherland and Schwaber 2011].
1

Abordado na seca o 5.1

3.1. Product Owner

O Product Owner (PO), ou dono do produto e o responsavel por maximizar o valor do
produto e do trabalho da equipe de Desenvolvimento e e a u nica pessoa responsavel por
gerenciar o Product Backlog[Sutherland and Schwaber 2011]. O PO esta ligado a` visao
de negocio do projeto, ele representa o interesse das pessoas que investem no desenvolvimento do produto[Neto 2012].
Sua maior responsabilidade e gerenciar o Product Backlog que inclui:
Ordenar os itens do Product Backlog de acordo com a visao de prioridade do
cliente;
Garantir a transparencia do Product Backlog;
Aceitar ou rejeitar os resultados dos trabalhos;
Decidir o momento de liberaca o do produto ou de suas versoes 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. E esse time que desenvolve as versoes incrementais do produto
prontoque sao entregues ao final de cada Sprint.
O tamanho ideal do time e pequeno o suficiente para se manter a gil e
grande o suficiente para ser capaz de completar uma parcela significativa do trabalho
[Sutherland and Schwaber 2011].
Tambem espera-se que time possua um carater auto-gerenciavel, 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 e o gerente do projeto, o responsavel por garantir que a equipe siga de
maneira adequada as praticas da scrum e tambem responsavel por eliminar os obstaculos
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 reunioes nao definidas no Scrum. Os eventos podem terminar quando o proposito for
alcancado, ou seja, disponibiliza o tempo adequado aos processos e evita possveis perdas
[Sutherland and Schwaber 2011].
4.1. Sprint
A parte fundamental do Scrum e a Sprint, no qual uma versao incremental potencialmente utilizavel do produto e criada. Suas duraco es sao coerentes em todo o esforco de
desenvolvimento e iniciam uma apos a outra, com intervalos nao maiores que um mes.
Durante a Sprint nao sao feitas mudancas que possam colocar em perigo o objetivo
da Sprint. As metas de qualidade nao 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 definica o do que e para ser construdo, um plano projetado e
flexvel que ira guiar a construca o, o trabalho e o resultado do produto. O intervalo entre
uma Sprint e outra for muito longo, aumentam os riscos de erros e prejuzos. Sprints
rapidas permitem uma previsao que garante a correca o e adaptaca o do progresso em
direca o ao objetivo, pelo menos a cada mes.
O objetivo da Sprint e satisfeito atraves da implementaca o do Backlog do produto,
que por sua vez, fornece ao time de desenvolvimento o porque de estar construindo o
incremento, criado durante a reuniao 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, entao eles contam com o Product Owner para negociar o escopo do backlog
[Sutherland and Schwaber 2011].
4.2. Reuniao de Planejamento da Sprint
Em [Schwaber and Beedle 2002], o trabalho a ser realizado na Sprint e planejado na
reuniao de planejamento. Este plano e criado com o trabalho colaborativo de todo o
time Scrum.
O Scrum Master garante que o evento ocorra e que os participantes entendam seu
proposito, ensinando o time Scrum a manter-se dentro dos limites do time-box. A reuniao
de planejamento da Sprint responde as seguintes questoes:
O que pode ser entregue como resultado do incremento da proxima Sprint?
Como o trabalho necessario para entregar o incremento sera realizado?
4.3. Reuniao Diaria
As reunioes diarias do scrum sao realizadas para que o time de desenvolvimento, possa
inspecionar o trabalho das reunioes posteriores, e prever o proximo trabalho que devera
ser feito. De acordo com [Sutherland and Schwaber 2011], durante a reuniao 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 obstaculo que impeca a mim ou o time de desenvolvimento no
atendimento da meta da Sprint?
O time de desenvolvimento utiliza as reunioes para inspecionar o processo em
direca o ao objetivo. O Scrum Master assegura que a equipe de desenvolvimento tenha a
reuniao, porem a equipe e responsavel por conduzi-la.
As reunioes diarias melhoram as comunicaco es, eliminam outras reunioes, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rapidas
tomadas de decisao, e melhoram o nvel de conhecimento do time de desenvolvimento.
4.4. Revisao da Sprint
A revisao e executada no final, para inspecionar o incremento e adaptar o Backlog do
produto se necessario. Qualquer mudanca no Backlog do produto durante a Sprint, os

participantes colaboram nas proximas coisas que podem ser feitas para otimizar. Esta e
uma reuniao informal, nao uma reuniao de status, e a apresentaca o do incremento destinase a motivar e obter comentarios e promover a colaboraca o.
O resultado da reuniao de revisao da Sprint e um Backlog do produto revisado, que define o provavel Backlog do produto para a proxima Sprint. O Backlog
do produto pode tambem 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 proprio e crie formas de melhorias que sao aplicadas na proxima
Sprint. Esta retrospectiva ocorre antes da reuniao de planejamento e depois da revisao
da Sprint. A Retrospectiva da Sprint consiste em inspecionar como a u 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 transparencia e oportunidades para inspeca o e adaptaca o. Sao especificamente projetados para
maximizar a transparencia das informaco 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 e uma lista ordenada por prioridade de tudo que deve ser necessario
no produto, e e uma origem u nica dos requisitos para qualquer mudanca a ser feita no
produto, sendo de responsabilidade do Product Owner.
O Product Owner deve influenciar o time, ajudando no entendimento e nas decisoes, porem o time de Desenvolvimento e responsavel por todas as estimativas, assim
as pessoas que irao realizar o trabalho fazem a estimativa final.
O Product Owner acompanha o trabalho restante pelo menos a cada reuniao
de revisao da Sprint, para isso, compara com trabalho que restava quando ocorreu a
reuniao de revisao anterior, para avaliar o progresso do trabalho previsto e finalizar no
prazo previsto. Esta informaca o deve ser transparente para todas as partes interessadas
[Sutherland and Schwaber 2011].
5.2. Backlog da Sprint
O Backlog da Sprint e 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 visvel o trabalho que o time de Desenvolvimento identifica como
necessario para atingir o objetivo da Sprint.
O Backlog da Sprint serve como um plano que contem detalhes suficientes para
que as mudancas no progresso sejam entendidas durante a Reuniao Diaria. 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 necessario para alcancar o objetivo da
Sprint [Sutherland and Schwaber 2011].

5.3. Incremento
O incremento e 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 condica o utilizavel
e atender a definica o de Pronto do time Scrum, independente do Product Owner decidir
por libera-lo realmente ou nao [Schwaber and Beedle 2002].

6. Transparencia do Artefato
Decisoes para otimizar o valor e controlar os riscos sao feitos com base no estado dos artefatos. Na medida em que a transparencia e plena, estas decisoes tem uma base solida. Na
medida em que os artefatos nao sao completamente transparentes, estas decisoes podem
conter falhas, valores podem diminuir e riscos podem aumentar.
O trabalho do Scrum Master e trabalhar com o time Scrum para aumentar a
transparencia dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e mudanca. Transparencia nao ocorre de um dia para o outro, mas e um caminho
[Sutherland and Schwaber 2011].
6.1. Definica o de Pronto
Quando o item do Backlog do Produto ou um incremento e 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 transparencia. Esta e a Definica o de
Pronto para o time Scrum e e usado para assegurar quando o trabalho de incremento do
produto esta completo.
A mesma definica o orienta o time de desenvolvimento no conhecimento de quantos itens do Backlog do produto podem ser selecionados durante a reuniao de planejamento da Sprint. O proposito de cada Sprint e entregar incrementos de funcionalidades
potencialmente utilizaveis que aderem a` definica o atual de Pronto do time Scrum.
O time de desenvolvimento entrega um incremento de funcionalidade do produto a
cada Sprint. Este incremento e utilizavel, assim o Product Owner pode escolher libera-lo
imediatamente. Se a definica o de Pronto para um incremento e parte das convenco es,
padroes ou diretrizes de desenvolvimento da organizaca o, todos os times Scrum devem
segui-la. Se Pronto para um incremento nao e uma convenca o de desenvolvimento
da organizaca o, o time de desenvolvimento do time Scrum deve criar uma definica o
de Pronto apropriada para o produto. Se ha multiplos times Scrum trabalhando no
lancamento do sistema ou produto, os times de desenvolvimento de todos os times Scrum
devem mutuamente acordar uma definica o de Pronto.
Cada incremento e adicionado a todos os incrementos anteriores e completamente
testado, garantindo que todos os incrementos funcionem juntos.
Com um time Scrum maduro, e esperado que a sua definica o de
Pronto seja expandida para incluir criterios mais rigorosos de alta qualidade
[Sutherland and Schwaber 2011].

7. Conclusao
O Scrum e geralmente voltado ao desenvolvimento de software mas pode ser aplicado em
qualquer a rea.
E um framework simples, criado para tornar a gil a realizaca o de projetos complexos, tal como os que necessitam de mudancas rapidas durante o desenvolvimento, e
mesmo assim, proporcionando a entrega de resultados de alta qualidade. Sendo assim,
dentro do gerenciamento a gil de projetos, o Scrum e um dos que mais se destaca.
Existem alguns benefcios obtidos com o uso do framework scrum, tais como:
Diminuica o dos riscos, maior integraca o entre os membros das equipe, rapida soluca o de
problemas, progresso medido continuamente, os clientes se tornam parte da equipe de
desenvolvimento, entregas frequentes de funcionalidades funcionando, discussoes diarias
de status com a equipe, os profissionais de negocios e tecnologias trabalham juntos. Com
todo esse entrosamento entre a equipe de desenvolvimento e com a participaca o ativa
dos clientes o rendimento do projeto aumenta e os requisitos e solicitaca o de alteraca o
passa a ser entendido mais rapidamente, devido ao explcito entrosamento de todos os
participantes do desenvolvimento.

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