Estudo sobre Desenvolvimento de SoftwareUtilizando o Framework Agil Scrum

Andre Scarmagnani1, Fabricio C. Mota1, Isaac da Silva1, Matheus de C. Madalozzo1,Regis S. Onishi1, Luciano S. Cardoso1

1UDC 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, butthese are still not widespread in academia. The purpose of this article, as wellas disseminating this issue and provide support for future research is to demons-trate a simple and objective way, operation, features, vocabulary and applica-tion of the scrum framework in a work environment.

Resumo. As metodologias de desenvolvimento agil vem se destacando a cadadia, porem essas ainda sao pouco difundidas no meio academico. O objetivodeste artigo, alem de difundir esse assunto e servir de apoio para futuras pes-quisas, e demonstrar de maneira simples e objetiva, o funcionamento, as carac-tersticas, o vocabulario e a aplicacao do framework scrum em um ambiente detrabalho.

1. Introducao

Atualmente, os negocios atuam em um ambiente sujeito a mudancas constantes, comonovas oportunidades de mercados, diferentes condicoes economicas e o surgimento deprodutos e servicos concorrentes. Para quase todas as operacoes de negocios e essencialque um novo software seja desenvolvido e, para maior competitividade, deve ser em curtoprazo. O desenvolvimento agil muitas vezes e requisito fundamental para a criacao desoftwares a fim de que consigam atender mais prontamente as demandas do cliente.

Segundo [Sommerville 2006], os processos de desenvolvimento agil de softwaresao projetados para criar softwares uteis rapidamente. Geralmente, sao processos itera-tivos nos quais a especificacao, o projeto, o desenvolvimento e o teste sao intercalados.O software nao e desenvolvido e disponibilizado integralmente, mas em uma serie deincrementos, onde cada incremento inclui uma nova funcionalidade do sistema.

Na engenharia de software existem modelos que trabalham de forma agil nos pro-cessos, com semelhancas entre as abordagens filosoficas e praticas. Dentro dessa abor-dagem surgiu o manifesto para o desenvolvimento agil de software, cujo o objetivo eradescobrir melhores maneiras de desenvolver software [Beck et al. 2001]. Uma das ma-neiras encontradas foi a utilizacao do framework Scrum que foi desenvolvido por JeffSutherland na decada de 90.

2. Conceitos de ScrumO framework Scrum utilizado para gestao de desenvolvimento de software complexos.Essa ferramenta nao e um processo para construir produto, mas sim um framework noqual pode ser empregado varios processos ou tecnicas, tendo uma eficacia relativa daspraticas de gerenciamento e desenvolvimento de softwares.

O Scrum e formado pelos times do Scrum, associados a papeis, eventos, artefatose regras. Cada uma dessas associacoes dentro do framework servem a um proposito e eimportante para o sucesso do Scrum.

O framework tem sua fundamentacao nas boas praticas que foram adquiridasatraves da realizacao de varios projetos e que tiveram seus processos de maior sucessodocumentados, empregando uma abordagem iterativa e incremental para aperfeicoar aprevisao e o controle de riscos. Tres pilares apoiam a implementacao de controle de pro-cesso emprico:

Transparencia Aspectos significativos do processo devem estar visveis aos res-ponsaveis pelos resultados. Inspecao Os usuarios Scrum devem, frequentemente, inspecionar os artefatos

Scrum e o progresso em direcao a detectar variacoes. Adaptacao Se um inspetor identifica que um processo se desviou para fora dos

limites aceitaveis, e que o produto resultado sera inaceitavel, o processo ou omaterial sendo produzido deve ser ajustado o mais breve possvel.

O Scrum possui quatro eventos formais, contidos dentro dos limites da Sprint1,para inspecao e adaptacao, conforme mostra na figura 1 [Sutherland and Schwaber 2011]

Figura 1. Ciclo da sprint. (Fonte: Adaptada de [Schwaber and Beedle 2002]).

3. O TimeO time Scrum e composto pelo product owner, o time de desenvolvimento e o scrummaster, os integrantes do time Scrum sao auto-organizaveis, ou seja, escolhem qual amelhor forma para completarem seu trabalho, em vez de serem dirigidos por outros defora do time. Sao multifuncionais pois possuem todas as competencias necessarias paracompletar o trabalho sem depender de outros de fora da equipe. O modelo de time noScrum e projetado para aperfeicoar a flexibilidade, criatividade e produtividade.

A Entrega dos produtos e feita de forma iterativa e incremental, o que resulta emmais oportunidades de realimentacao [Sutherland and Schwaber 2011].

1Abordado na secao 5.1

3.1. Product Owner

O Product Owner (PO), ou dono do produto e o responsavel por maximizar o valor doproduto e do trabalho da equipe de Desenvolvimento e e a unica pessoa responsavel porgerenciar o Product Backlog[Sutherland and Schwaber 2011]. O PO esta ligado a` visaode negocio do projeto, ele representa o interesse das pessoas que investem no desenvolvi-mento 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 docliente; Garantir a transparencia do Product Backlog; Aceitar ou rejeitar os resultados dos trabalhos; Decidir o momento de liberacao 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 Backlogem um produto funcional. E esse time que desenvolve as versoes incrementais do produtoprontoque sao entregues ao final de cada Sprint.

O tamanho ideal do time e pequeno o suficiente para se manter agil egrande 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 compro-metimento e uma postura multifuncional dos membros representando um fator crucialpara o sucesso do projeto.

3.3. Scrum Master

O scrum master e o gerente do projeto, o responsavel por garantir que a equipe siga demaneira adequada as praticas da scrum e tambem responsavel por eliminar os obstaculosque impedem o bom funcionamento do Scrum.

4. Eventos ScrumO Scrum utiliza os eventos prescritos parar criar uma rotina e minimizar a necessidadede reunioes nao definidas no Scrum. Os eventos podem terminar quando o proposito foralcancado, 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 potencial-mente utilizavel do produto e criada. Suas duracoes sao coerentes em todo o esforco dedesenvolvimento 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 objetivoda Sprint. As metas de qualidade nao diminuem e o escopo pode ser renegociado entre oProduct Owner e o Time de Desenvolvimento de acordo com o que foi aprendido.

Cada Sprint tem a definicao do que e para ser construdo, um plano projetado eflexvel que ira guiar a construcao, o trabalho e o resultado do produto. O intervalo entreuma Sprint e outra for muito longo, aumentam os riscos de erros e prejuzos. Sprintsrapidas permitem uma previsao que garante a correcao e adaptacao do progresso emdirecao ao objetivo, pelo menos a cada mes.

O objetivo da Sprint e satisfeito atraves da implementacao do Backlog do produto,que por sua vez, fornece ao time de desenvolvimento o porque de estar construindo oincremento, criado durante a reuniao de planejamento da Sprint. O time de desenvol-vimento implementa a funcionalidade e tecnologia no intuito de satisfazer o objetivo daSprint, se o trabalho for finalizado por ser diferente do esperado pelo time de desenvol-vimento, entao eles contam com o Product Owner para negociar o escopo do backlog[Sutherland and Schwaber 2011].

4.2. Reuniao de Planejamento da SprintEm [Schwaber and Beedle 2002], o trabalho a ser realizado na Sprint e planejado nareuniao de planejamento. Este plano e criado com o trabalho colaborativo de todo otime Scrum.

O Scrum Master garante que o evento ocorra e que os participantes entendam seuproposito, ensinando o time Scrum a manter-se dentro dos limites do time-box. A reuniaode 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 DiariaAs reunioes diarias do scrum sao realizadas para que o time de desenvolvimento, possainspecionar o trabalho das reunioes posteriores, e prever o proximo trabalho que deveraser feito. De acordo com [Sutherland and Schwaber 2011], durante a reuniao os desen-volvedores esclarecem:

O que eu fiz ontem que ajudou o time de desenvolvimento a atender a meta daSprint? 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 emdirecao ao objetivo. O Scrum Master assegura que a equipe de desenvolvimento tenha areuniao, porem a equipe e responsavel por conduzi-la.

As reunioes diarias melhoram as comunicacoes, eliminam outras reunioes, identi-ficam e removem impedimentos para o desenvolvimento, destacam e promovem rapidastomadas de decisao, e melhoram o nvel de conhecimento do time de desenvolvimento.

4.4. Revisao da SprintA revisao e executada no final, para inspecionar o incremento e adaptar o Backlog doproduto se necessario. Qualquer mudanca no Backlog do produto durante a Sprint, os

participantes colaboram nas proximas coisas que podem ser feitas para otimizar. Esta euma reuniao informal, nao uma reuniao de status, e a apresentacao do incremento destina-se a motivar e obter comentarios e promover a colaboracao.

O resultado da reuniao de revisao da Sprint e um Backlog do produto revi-sado, que define o provavel Backlog do produto para a proxima Sprint. O Backlogdo produto pode tambem ser ajustado completamente para atender novas oportunidades[Sutherland and Schwaber 2011].

4.5. Retrospectiva da SprintSegundo [Sutherland and Schwaber 2011], a retrospectiva da Sprint serve para que o timeScrum inspecione a si proprio e crie formas de melhorias que sao aplicadas na proximaSprint. Esta retrospectiva ocorre antes da reuniao de planejamento e depois da revisaoda Sprint. A Retrospectiva da Sprint consiste em inspecionar como a ultima Sprint foi,identificar suas melhorias e melhorar no modo que o Time Scrum faz seu trabalho.

5. Artefatos do ScrumOs artefatos do Scrum representam o trabalho ou o valor para o fornecimento de trans-parencia e oportunidades para inspecao e adaptacao. Sao especificamente projetados paramaximizar a transparencia das informacoes chave de modo que todos tenham o mesmoentendimento dos artefatos [Sutherland and Schwaber 2011].

5.1. Backlog do ProdutoO Backlog do Produto e uma lista ordenada por prioridade de tudo que deve ser necessariono produto, e e uma origem unica dos requisitos para qualquer mudanca a ser feita noproduto, sendo de responsabilidade do Product Owner.

O Product Owner deve influenciar o time, ajudando no entendimento e nas de-cisoes, porem o time de Desenvolvimento e responsavel por todas as estimativas, assimas pessoas que irao realizar o trabalho fazem a estimativa final.

O Product Owner acompanha o trabalho restante pelo menos a cada reuniaode revisao da Sprint, para isso, compara com trabalho que restava quando ocorreu areuniao de revisao anterior, para avaliar o progresso do trabalho previsto e finalizar noprazo previsto. Esta informacao deve ser transparente para todas as partes interessadas[Sutherland and Schwaber 2011].

5.2. Backlog da SprintO Backlog da Sprint e um conjunto de itens da Backlog do Produto selecionados para aSprint, juntamente com o plano de entrega do incremento do produto.

Ele torna mais visvel o trabalho que o time de Desenvolvimento identifica comonecessario para atingir o objetivo da Sprint.

O Backlog da Sprint serve como um plano que contem detalhes suficientes paraque as mudancas no progresso sejam entendidas durante a Reuniao Diaria. O time dedesenvolvimento modifica o Backlog ao longo de toda a Sprint, e o Backlog vai surgindodurante a Sprint. Este surgimento ocorre quando o time de desenvolvimento trabalhasegundo o plano e aprende mais sobre o trabalho necessario para alcancar o objetivo daSprint [Sutherland and Schwaber 2011].

5.3. Incremento

O incremento e a soma de todos os itens do Backlog do produto completados durantea Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint umnovo incremento deve estar Pronto, o que significa que deve estar na condicao utilizavele atender a definicao de Pronto do time Scrum, independente do Product Owner decidirpor 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 arte-fatos. Na medida em que a transparencia e plena, estas decisoes tem uma base solida. Namedida em que os artefatos nao sao completamente transparentes, estas decisoes podemconter falhas, valores podem diminuir e riscos podem aumentar.

O trabalho do Scrum Master e trabalhar com o time Scrum para aumentar atransparencia dos artefatos. Este trabalho geralmente envolve aprendizagem, convenci-mento e mudanca. Transparencia nao ocorre de um dia para o outro, mas e um caminho[Sutherland and Schwaber 2011].

6.1. Definicao de Pronto

Quando o item do Backlog do Produto ou um incremento e descrito como Pronto, to-dos devem entender o que o Pronto significa. Embora, isso varie significativamentepara cada time Scrum, os integrantes devem ter um entendimento compartilhado do quesignifica o trabalho estar completo, assegurando a transparencia. Esta e a Definicao dePronto para o time Scrum e e usado para assegurar quando o trabalho de incremento doproduto esta completo.

A mesma definicao orienta o time de desenvolvimento no conhecimento de quan-tos itens do Backlog do produto podem ser selecionados durante a reuniao de planeja-mento da Sprint. O proposito de cada Sprint e entregar incrementos de funcionalidadespotencialmente utilizaveis que aderem a` definicao atual de Pronto do time Scrum.

O time de desenvolvimento entrega um incremento de funcionalidade do produto acada Sprint. Este incremento e utilizavel, assim o Product Owner pode escolher libera-loimediatamente. Se a definicao de Pronto para um incremento e parte das convencoes,padroes ou diretrizes de desenvolvimento da organizacao, todos os times Scrum devemsegui-la. Se Pronto para um incremento nao e uma convencao de desenvolvimentoda organizacao, o time de desenvolvimento do time Scrum deve criar uma definicaode Pronto apropriada para o produto. Se ha multiplos times Scrum trabalhando nolancamento do sistema ou produto, os times de desenvolvimento de todos os times Scrumdevem mutuamente acordar uma definicao de Pronto.

Cada incremento e adicionado a todos os incrementos anteriores e completamentetestado, garantindo que todos os incrementos funcionem juntos.

Com um time Scrum maduro, e esperado que a sua definicao dePronto seja expandida para incluir criterios mais rigorosos de alta qualidade[Sutherland and Schwaber 2011].

7. ConclusaoO Scrum e geralmente voltado ao desenvolvimento de software mas pode ser aplicado emqualquer area.

E um framework simples, criado para tornar agil a realizacao de projetos com-plexos, tal como os que necessitam de mudancas rapidas durante o desenvolvimento, emesmo assim, proporcionando a entrega de resultados de alta qualidade. Sendo assim,dentro do gerenciamento agil de projetos, o Scrum e um dos que mais se destaca.

Existem alguns benefcios obtidos com o uso do framework scrum, tais como:Diminuicao dos riscos, maior integracao entre os membros das equipe, rapida solucao deproblemas, progresso medido continuamente, os clientes se tornam parte da equipe dedesenvolvimento, entregas frequentes de funcionalidades funcionando, discussoes diariasde status com a equipe, os profissionais de negocios e tecnologias trabalham juntos. Comtodo esse entrosamento entre a equipe de desenvolvimento e com a participacao ativados clientes o rendimento do projeto aumenta e os requisitos e solicitacao de alteracaopassa a ser entendido mais rapidamente, devido ao explcito entrosamento de todos osparticipantes do desenvolvimento.

ReferenciasBeck, 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 agilesoftware development. http://www.agilemanifesto.org. Acessado em: 22 maio de2014.

Neto, C. (2012). Conhecendo o scrum. http://www.devmedia.com.br/conhecendo-o-scrum/25744. Acessado em: 26 maio de 2014.

Schwaber, K. and Beedle, M. (2002). Agile software development with scrum. PrenticeHall, 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.