ARTIGO 11 - MÉTODOS ÁGEIS SCRUM

SAVE OFFLINE

COM

Pró-Reitoria de Graduação Tecnologia em Análise e Desenvolvimento de Sistemas Trabalho de Conclusão de Curso

Método Ágil SCRUM

Autor: Alan Santos Maciel Orientador: José Gonçalo dos Santos

Brasília - DF 2013

Alan Santos Maciel

Método Ágil SCRUM

Artigo Apresentado ao Curso de Graduação em (Tecnologia em Análise e Desenvolvimento de Sistemas), da Universidade Católica de Brasília com obtenção parcial para o curso de (Tecnólogo) em Tecnologia Da Informação. Orientador:Prof° Dr. José Gonçalo dos Santos Co-Orientador: Nome do Co-orientador com titulo.

Brasília 2013

Artigo de autoria de (Alan Santos Maciel), Intitulado “Desenvolvimento de Software com foco no Método Ágil (SCRUM)” apresentado como requisito parcial para obtenção do grau de (Tecnólogo) em (Tecnologia em Análise e Desenvolvimento de Sistemas) da Universidade Católica de Brasília em ( / / ) definido e aprovado pela banca examinador abaixo assinado:

Orientador: Prof. Dr. José Gonçalo dos Santos. Tecnologia em Análise e Desenvolvimento de Sistemas – UCB

Professor (titulação). (Membro da Banca) Orientador (Curso/Programa) (UCB)

Professor (titulação). (Membro da Banca) Orientador (Curso/Programa) (UCB)

Brasília 2013

Métodos Desenvolvimento de Software com foco no Método Ágil “SCRUM” Método Ágil SCRUM

Alan Santos Maciel Resumo: (Em Português). Este artigo foi produzido com intuito de demonstrar a evolução das metodologias de desenvolvimento projetos e softwares. Serão abordados os seguintes modelos, Cascata, Modelo Interativo/Incremental, Processo Unificado (RUP) e Métodos de desenvolvimento ágil com a abordagem principal no SCRUM. Após pesquisas realizadas ficou constatado que as empresas que adotam esse o procedimento citado na intenção de dar agilidade ao desenvolvimento de softwares, tem 52% de todos os processos de criação ágeis adotados estão baseados neste modo de trabalho. Serão demonstrados como resultado do artigo os pontos fracos e positivos em se adotar o método de desenvolvimento Scrum.

Palavras Chave: Métodos de Desenvolvimento de Software, Método Ágil e Scrum.

1

SÚMARIO 1. Introdução......................................................................................................................pag 3 1.1Contextualizaçõe............................................................................................................pag3 1.2 Justificativas..................................................................................................................pag4 1.3 Objetivo Geral ..............................................................................................................pag4 1.4 Métodos..........................................................................................................................pag5 1.5 Estruturas do trabalho.................................................................................................pag6 2. Fundamentação Teorica.................................................................................................pag6 2.1 Evoluções dos métodos desenvolvimento do software...............................................pag6 2.2Modelos Cascata............................................................................................................pag7 2.3 Modelos Interativo/Incremental..................................................................................pag9 2.3.1 Esquema do Modelo Interativo/Incremental..........................................................pag9 2.4 Processos de Desenvolvimento RUP..........................................................................pag10 2.5 Métodos Ágeis.............................................................................................................pag12 3.Scrum .............................................................................................................................pag14 3.1 Papeis no Scrum .........................................................................................................pag16 3.1.1 O Product Owner ....................................................................................................pag16 3.1.2 Equipe ......................................................................................................................pag17 3.1.3 O Scrum Máster ......................................................................................................pag18 3.2 Times Box ...................................................................................................................pag19 3.2.1 Realise Planning Meeting .......................................................................................pag19 3.2.2 Sprint.........................................................................................................................pag20 3.2.3 Sprint Review ..........................................................................................................pag21

2

3.2.4Sprint Retrospective ...............................................................................................pag22 3.2.5 Daily Scrum Meeting...............................................................................................pag22 3.3 Artefato Scrum ...........................................................................................................pag23 3.3.1Product Backlog e Release Burndown....................................................................pag24 3.3.2 Sprint backlog e Sprint Burndown........................................................................pag26 4.Scrum nas Empresa.......................................................................................................pag28 5.Aceitação do Scrum nas Empresa................................................................................pag29 6. Beneficios e Crinticas ao Scrum..................................................................................pag30 7. Resultado.......................................................................................................................pag31 8. Discussão........................................................................................................................pag31 9. Conclusão.......................................................................................................................pag32

3

1. Introdução 1.1 – Contextualização

Desde o período da 1° Guerra Mundial o mundo vem passando por mudanças tecnológicas desde grandes volumes de dados, à criação de computadores comerciais. Daí começou surgir problemas para a construção de software para que esses computadores pudessem automatizar processos manuais e avaliar situações complexas que são parte integrante do cotidiano das organizações (UCHÔA, 2006). A partir desse, foi possível criar modelos de desenvolvimento de software que atendessem determinadas necessidades. Por que construir software sem utilizar métodos de desenvolvimento pode causar perda de renda e até um prejuízo inestimável para a organização O planejamento do processo de desenvolvimento de software é importantíssimo em se tratando de construção de sistemas robustos.

Metodologia de desenvolvimento de Software ou simplesmente Processo de Software é um conjunto de atividades e resultados associados que auxiliam na produção de software. Existem várias modelos de desenvolvimento de software, o modelo CASCATA, que é também chamado de Clássico ou Linear, caracteriza-se por possuir uma tendência na progressão seqüencial entre uma fase e a seguinte (SANTOS, 2007). Existe também um processo de desenvolvimento de software que é o principal representante da abordagem de desenvolvimento incremental e iterativo. Conhecido

como RUP - Rational

Unified

Process (Processo Unificado Racional). E foi patenteado pela empresa Rational, onde trabalham os famosos três amigos (Jacobson, Booch e Rumbaugh) (BOOCH 2000).

E por último temos os modelos Ágeis que surgiu dado a necessidade de melhorarmos a forma como está se desenvolvendo SW e o foco principal é satisfazer o cliente. Isso ocorreu devido as crescentes pressões do mercado por inovação, produtividade (prazos cada vez mais curtos), flexibilidade e melhoria no desempenho/qualidade dos projetos de desenvolvimento de SW, houve o surgimento dos métodos ágeis(STEFFEN ,2012). Nos últimos anos métodos ágeis como SCRUM entre outros passaram a ser utilizados por grandes empresas como GOOGLE, YAHOO, MYCROSFT entre outras universidades instituto de pesquisa e agências governamentais. Nesse Artigo Abordaremos o método de

4

desenvolvimento ágil veremos como se dá sua implantação no processo de desenvolvimento de software (RADAR CITi(2010)). O método SCRUM e um modelo ágil e é o modelo mais utilizado pelas empresas na intenção de dar agilidade ao desenvolvimento de softwares. Estima-se que 52% de todos os processos de criação ágeis adotados estão baseados neste modo de trabalho. Apesar dos benefícios das metodologias ágeis, como o Scrum, há limitações à sua adoção. A maior é a resistência cultural dentro das organizações. Em pesquisa realizada por Leandro Cruz Gerente de Projetos, mais da metade das empresas consultadas indicaram incapacidade de mudança na cultura organizacional da empresa como a maior barreira na aplicação de métodos como o Scrum. Essa pesquisa tem como Objetivo mostrar os benefícios que a método Scrum pode trazer, ele pode ser aplicado em empresas de qualquer porte e setor. “Essa pesquisa Poderá também trazer conhecimentos para pessoas que atuam em outras áreas por que o método de desenvolvimento ágil SCRUM, não é um método restrito à área de TI”, afirma Leandro Cruz Gerente de Projetos. É possível fazer um paralelo entre softwares e o desenvolvimento de novos produtos, por exemplo, (CRUZ, 2009).

1.2 Justificativa A evolução dos métodos de se desenvolver software o evidencia quanto era difícil desenvolver software no seu inicio, mas esses métodos foram passando por grandes avanços tecnológicos e a cada método que surgiu veio para melhorar os métodos antigos (iterativos), Em suma, a escolha deste tema justifica-se plenamente para mostrar as melhorias que os métodos

ágeis principalmente o Scrum traz para o desenvolvimento não só de software, mas para outros produtos. Ele visa refinar as metodologias iterativas, tirando o foco do processo em si e dando mais ênfase à contribuição das pessoas, dos integrantes do projeto.

1.3 Objetivos Gerais O objetivo de esse artigo é mostrar que os métodos ágeis principalmente o Scrum podem solucionar vários problemas que se tinha e têm para desenvolver software, por exemplo, processo muito longo, muito retrabalha e clientes insatisfeitos. Mostra o a quebra do paradigma de que esses métodos são aplicados apenas em desenvolvimento de softwarwe,

5

eles também podem ser aplicador em empresa de qualquer área e ou setor por que na verdade ele não é um só método de desenvolvimento, mas sim conjuntos de diretrizes para se chegar a um bom resultado final. Exemplo Projeto de Hardware, Projeto de Infra-estrutura, Projeto de Publicidade/ Marketing, Sul América Seguros/ Saúde etc. E também mostrar a aceitação do Scrum nas empresas.

1.4 Método O método é um conjunto de regras básicas para desenvolver uma experiência a fim de produzir novo conhecimento, bem como corrigir e integrar conhecimentos pré-existentes. Entende-se também por metodologia, como a maneira – forma – de se utilizar um conjunto coerente e coordenado de métodos para atingir um objetivo, de modo que se evite, tanto quanto possível, a subjetividade na execução do trabalho. Fornecendo um roteiro, um processo dinâmico e interativo para desenvolvimento estruturado de projetos, sistemas ou software, visando à qualidade e produtividade dos projetos (FARIAS,2010). Segundo (STEFFEN, 2012). É objetivo de uma metodologia definir de forma clara “quem” faz “o que”, “quando”, “como”, e até mesmo “onde”, para todos os que estejam envolvidos diretamente ou não com o desenvolvimento de software. Deve definir também qual o papel dos técnicos, dos usuários, e o da administração da empresa no processo de desenvolvimento. Com isso, evita-se a situação a qual o conhecimento sobre o sistema é de poucos, comumente apelidados, de “os donos do sistema”. Além disso, deve instruir um conjunto de padrões preestabelecidos, de modo a ser evitar a subjetividade na abordagem, a fim de garantir fácil integração entre os sistemas desenvolvidos O Foco de estudo desse artigo é o método ágil “SCRUM”.

A pesquisa será desenvolvida tomando como base textos, artigos e blogs retirados da internet, conceitos do livro “guia do usuário” de BOOCH, G.; RUMBAUGH, J. JACOBSON e conceitos da apostila do curso de Tópicos Avançados de Engenharia de Software da católica virtual ministrado pelo Professor EDGARD DEVANIR AMOROSO. Além da base teórica já citada faremos uso também de relatos da empresa GAO (Governament Accountability Office) e Rafael Amaro Diretor Administrativo da Ice Interative, para mostrar que Scrum pode ser adotado em empresas de outros setor que não seja

6

TI, dados de uma pesquisa realizada pela empresa VersionOne com onde 52% das empresas que utilizam métodos ágeis utilizam o Scrum.

1.5 Estruturas do trabalho Nesta seção foram apresentado a contextualização, ás justificativas, os objetivos e um breve conceito do que é método e metodologia. Na segunda seção será apresentada a Fundamentação teórica onde será demonstrada a evolução que teve o método em que se desenvolve software.

2. Fundamentação Teórica “Nesta Seção é apresentada a fundamentação teórica onde serão mostrados breves conceitos dos Modelos Cascata, Modelo Iterativo / Incremental, Processo de desenvolvimento RUP Rational Unified Process (Processo Unificado Racional),Métodos Ágeis com o foco no Scrum.

2.1 Evoluções dos Métodos Desenvolvimento de Software. Em meados da primeira guerra mundial tivemos uma evolução significativa no segmento corporativo. Nesta época o mundo passava por intensas transformações e isto provocou drásticas mudanças no ciclo produtivo das empresas e percebeu-se a necessidade de controlar o seu processo de trabalho. Baseado nestas transformações houve a necessidade de se aplicar o conceito de dinamização de processos e daí surgiu à necessidade de se administrar grandes volumes de dados em organizações de todas as esferas. Com a criação dos computadores comerciais após a segunda guerra mundial tivemos um aumento significativo na dinamização da indústria de computadores e, conseqüentemente, o processo de construção de softwares, para que os mesmos automatizassem processos manuais e pudessem avaliar situações complexas que são parte integrante do cotidiano das organizações (ESPING, 2008).

Mal o homem começou a produzir software, já se deparou com uma série de problemas de qualidade e com uma demanda maior que a capacidade produtiva. A solução foi introduzir

7

conceitos de Engenharia de Software que com a introdução de metodologias e ferramentas, proporcionou condições para a melhoria qualidade do produto. Pela primeira vez falou-se em um processo de desenvolvimento de software. (UCHÔA, 2006) Hoje em dia nos deparamos com várias metodologias para o desenvolvimento de um software, mas temos os modelos de desenvolvimento, que falando em um modo de herança seriam os país das metodologias. Existem alguns modelos de desenvolvimento de software, os principais são o desenvolvimento em Cascata, Iterativo, Incremental e Métodos Ágeis. O desenvolvimento em cascata é o mais tradicional dos três, por parecer ser mais simples e organizado, porém durante o desenvolvimento do projeto pode ocorrer inúmeras falhas decorrentes desse modelo Cascata, por isso veio os métodos Iterativo / Incremental, com a idéia de substituir o modelo Cascata e acabar com as suas falhas, o desenvolvimento incremental têm o propósito desenvolver todo o sistema com uma integração única e o Interativo é uma estratégia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido. Mas como nada é perfeito eles também teve as suas falhas, e por ultimo os métodos ágeis que veio para acabar com o retrabalho e a grande quantidade de documentação e com o grande números de insucesso onde só 16% dos projetos obtinham sucesso. Seu foco é desenvolvimento rápido de software e satisfazer o cliente (RENATO JOSÉ GROFFE,2012).

2.2Modelos CASCATA O modelo CASCATA é ainda hoje o mais utilizado, também conhecido como modelo clássico, por ser um dos mais antigos (Surgiu na década de 70). Até meados da década de 1980 foi o único modelo com aceitação geral. Neles as atividades do processo do desenvolvimento são estruturadas numa cascata onde a saída de uma e a entrada da próxima (C. LEITE 2007). Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo. Basicamente um modelo de desenvolvimento em cascata resume-se em um modelo sequencial de desenvolvimento, com fases bem definidas, sendo comuns as fases de: análise, projeto, codificação, teste e manutenção. Existem várias etapas que são desenvolvidas de forma sistemática e seqüencial: 

Levantamento de Requisitos

8



Análise de Requisitos



Projeto



Implementação



Testes



Implantação

Figura 1  Neste modelo existem pontos específicos para entrega dos artefatos, pois cada fase depende da anterior.  Ela é bastante simples e por conta disso acaba sendo bastante fácil de planejar Contudo, existe iteração entre cada uma das fases, ou seja, uma alteração em qualquer das fases pode alterar qualquer uma das outras, ou seja, por mais que se busquem fases independentes, elas acabam se relacionando, não tendo, começo e fim definidos e definitivos antes do final de todo o projeto.

O modelo CASCATA tem muitas qualidades, mas nem sempre são possíveis de aplicar na integra. A maioria dos seus problemas está ligada aos requisitos do software que se vai construir. Segundo PRESSMAN (1995), as principais criticam a esse modelo são: Desvantagens 

O modelo cascata exige que o cliente estabeleça todos os requisitos no inicio do projeto.



Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores;



Qualquer erro ou mal entendido, se não for detectado até que o software seja revisado, pode ser desastroso.

9



Se ocorrer um atraso todo o processo é afetado;



Demora muito para ser entregue o software;

2.3Modelos Iterativo / Incremental Desenvolvimento Iterativo e Incremental é o cerne de um processo cíclico do desenvolvimento de software desenvolvido em resposta ás fragilidades do modelo em CASCATA. Um processo de desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Essa característica contrasta com a abordagem clássica, na qual as fases de análise, projeto, implementação e testes são realizadas uma única vez ( BEZERRA 2002). O princípio subjacente ao processo incremental e iterativo é que a equipa envolvida possa refinar e alargar pouco-a-pouco a qualidade, detalhe e âmbito do sistema envolvido.Ou seja, a principal conseqüência da aproximação iterativa é que os produtos finais de todo o processo vão sendo amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um conjunto de produtos finais. Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo ciclo, outro subconjunto dos requisitos é considerado para ser desenvolvido, o que produz um novo incremento do sistema que contém extensões e refinamentos sobre o incremento anterior. Assim, o desenvolvimento evolui em versões, através da construção incremental e iterativa de novas funcionalidades até que o sistema completo esteja construído (PRESSMAN 2010). Note que apenas uma parte dos requisitos é considerada em cada ciclo de desenvolvimento.

2.3.1 Esquema do Modelo Iterativo e Incremental.

10

Figura 2: Modelo Incremental. Fonte: PRESSMAN (2010). Na verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvimento em incrementos e cada incremento é desenvolvido em cascata.

Existe também um processo de desenvolvimento de software que é o principal representante da abordagem de desenvolvimento incremental e iterativo. Conhecido como RUP - Rational Unified Process (Processo Unificado Racional). E foi patenteado pela empresa Rational, onde trabalham os famosos três amigos (Jacobson, Booch e Rumbaugh).

2.4Processos de desenvolvimento RUP - Rational Unified Process (Processo Unificado Racional). É um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, então o RUP ganhou o nome de IRUP IBM Rational Unified Software (porém o nome mais conhecido ainda é RUP), Fornece técnicas às equipes de desenvolvimento de software

objetivando

o

aumento

seguindo uma abordagem prescritiva (normatização)( DIAS,2008);

da

produtividade

11

O RUP se baseia no paradigma de Orientação a Objetos e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos sem ação MARTINEZ,2010. O RUP surgiu com a intenção de acabar com um grande problema nos processos, cada vez mais os sistemas são complexos e precisam estar prontos em menos tempo. Mais do que isso, as necessidades mudam ao longo do tempo e a especificação de um sistema provavelmente será alterada durante seu desenvolvimento. Tentando amenizar esses problemas o RUP tem as seguintes premissas:  Uso de iterações para evitar o impacto de mudanças no projeto,  Gerenciamento de mudanças e  Abordagens dos pontos de maior risco o mais cedo possível (CAVERNA DO SOFTWARE 2010).

Figura 3 ( MARTINEZ ,2010) A metodologia RUP identifica cada ciclo de desenvolvimento do projeto em quatro fases, cada uma com respectivos marcos de finalização definidos Os Miles tones são os indicadores de progresso do projeto, e são usados como base para decisões para continuar, abortar, ou mudar o rumo do projeto LUIZ, R. (2005). As fases do RUP são:

1. Início (Inception): determinação do escopo do desenvolvimento, sendo levantado

12

uma visão do produto final a partir de um caso de uso (básico) definido.

2. Elaboração (Elaboration): planejamento de atividades e recursos necessários, onde são definidas funcionalidades e a arquitetura a ser desenvolvida.

3. Construção (Construction): implementação do software, contrução do código. Em projetos grandes esta fase pode ser segmentada em várias iterações, visando à divisão em partes menores e mais facilmente gerenciadas.

4. Transição (TRansition): o produto é passado aos usuários. Nesta fase ocorre treinamento dos usuários (e possíveis mantenedores) e a avaliação do produto (“beta-testing”) (MARTINEZ, 2010).

2.5 METODOS ÁGEIS Conforme (STEFFEN, 2012). Os Métodos Ágeis surgiram como alternativa para os problemas corriqueiros que se apresentam durante a elaboração de um software usando os métodos de desenvolvimento orientado a planos. Devido às crescentes pressões do mercado por inovação, produtividade (prazos casa vez mais curtos), flexibilidade e melhoria no desempenho/qualidade dos projetos de desenvolvimento de Software, houve o surgimento dos métodos ágeis. O ágil surgiu dado à necessidade de melhorar a forma como desenvolve Software e o foco principal é satisfazer o cliente .Nos modelos tradicionais, o foco é maior na análise de requisitos do software e projeto do que no desenvolvimento e testes. Sendo assim, em um cenário de um sistema de pequeno ou médio porte, a mudança repentina de requisitos causa mudança na especificação e no projeto, fazendo que voltem a “estaca zero”, ou seja, um grande retrabalho (CHRISTOPHER AUGUSTO, 2012). O termo “Metodologias Ágeis” tornou-se popular em 2001 quando um grupo de dezessete especialistas em processos de desenvolvimento de software decidiu se reunir nos EUA, para discutir maneiras de melhorar o desempenho de seus projetos (KIOSKEA. NET (2013)). Ambler (2004) declara que o Manifesto Ágil é composto por quatro simples declarações de valores, onde o importante é entender que ao mesmo tempo em que você deve valorizar

13

conceitos, são definidas preferências, não alternativas, dando enfoque em certas áreas, sem, contudo eliminar outras. Os valores do Manifesto Ágil são: * Indivíduos e interações valem mais que processos e ferramentas * Um software funcionando vale mais que documentação extensa * A colaboração do cliente vale mais do que a negociação do contrato * Responder a mudanças vale mais do que seguir um plano

É muito importante entender que os conceitos do manifesto ágil definem preferências e não alternativas no desenvolvimento de software, encorajando a focar a atenção em certos conceitos sem eliminar outros. Assim para seguir os conceitos ágeis devem-se valorizar mais a certas coisas do que a outras. Segundo (VINICIUS A.C(2007)) Premissas comuns aos métodos ágeis: 

Times pequenos, auto-organizados, menos hierarquia e mais autonomia;



Foco em valor, saber o que realmente faz a diferença para o negócio e pessoas;



Ciclos curtos, iterativo-incrementais, na escala de horas, dias e semanas;



Busca pela qualidade consciente, ter orgulho do que se faz, sem desperdícios;



Liberdade com responsabilidade coletiva deveu ter orgulho de toda a equipe;



Gestão visual, realismo e transparência, tomando decisões diariamente;



Usar uma linguagem comum junto a todos os envolvidos no projeto ou sistema.

É importante não confundir Agilidade com rapidez: um projeto ágil procura entregar ao cliente, a cada iteração, um produto executável, que se integra gradualmente à solução final, para progressivamente formar o produto completo a ser homologado e implantado. Assim o cliente acompanha a construção evolutiva e contínua do produto, tendo a transparência do trabalho realizado, implicando na geração mútua de confiança. Tal situação propicia uma redução do risco de insucesso do projeto. As metodologias ágeis é uma tentativa de refinar as metodologias iterativas, tirando o foco do processo em si e dando mais ênfase à contribuição das pessoas, dos integrantes do projeto. Trazem alguns conceitos que as diferenciam radicalmente das metodologias antecessoras,

14

como deixar o cliente participar mais próximo ao processo, iterações extremamente curtas e grande ênfase em testes automatizados. Por outro lado, pesquisadores e mesmo defensores dessas práticas não recomendam times muito grandes para um projeto (e alguns propõem dividir o projeto em subprojetos e trabalhar com equipes menores). Os métodos mais conhecidos nesta categoria são: XP Clientes escrevem as user stories. Scrum Definição do Product Backlog. FDD Geração de artefatos para a documentação dos requisitos Observação: Todos os seus autores com exceção do autor de LD e OpenSource participaram do Manifesto Ágil e portanto possuem princípios em comum. Nessa seção será apresentada uma das mais conhecidas e mais aceitas Metodologias Ágeis para Desenvolvimento de Scrum. Conceituando e Mostrando a maneira como funcionam os Papeis Reuniões e Artefatos.

3. Scrum De acordo com (JAMES MOREIRA (2011)) o Scrum nasceu a partir de um Gerenciamento de Projeto de uma fábrica de automóveis, onde se constatou que a utilização de equipes pequenas e multidisciplinares produzia melhores resultados. Em analogia a essas equipes, associou-se a formação do Scrum a de um jogo de Rugby. A partir de 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.

15

Figura. 4 (NASCIMENTO, 2010)

Scrum é um processo de gerenciamento de projetos ágeis, adaptado para a área de desenvolvimento de software, porém teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projeto de pesquisa cientifica o lançamento de um novo produto (INOVATIVIDADE MJV (2003)).

Martin Fowler, um dos maiores estudiosos em desenvolvimento de software, comenta em seu artigo A Nova Metodologia que: “Nos últimos anos, vem crescendo rapidamente o interesse em metodologias ágeis (ou "leves"). Também caracterizadas como um antídoto contra a burocracia ou uma licença para "hackear". Estas metodologias despertaram os interesses em toda a extensão da indústria do software”. Dentre as técnicas de utilização do Scrum, há a

16

entrega de produtos em períodos de tempo pré-estabelecidos, nunca inferiores a uma semana ou superiores a trinta dias.

3.1 Papeis no Scrum 3.1.1 O Product Owner O Product Owner é responsável por maximizar o valor do produto e o trabalho da equipa de desenvolvimento. Ele tem o papel de maior responsabilidade e visibilidade no método Scrum, representa o cliente e é responsável pelas decisões de qual trabalho da equipe maximizará o valor do produto e agregará mais aos envolvidos, define metas, prioriza e aprova a qualidade, sempre buscando garantir o maior retorno ao investimento (FARIA .2011). O Product Owner é o único responsável por gerir, define os itens que compõem o Product Backlog e os prioriza. Algumas de suas principais ‘  Ordenar os itens para melhor atingiras metas e missões  Garantir que o trabalho a realizar pela equipa é o que traz maior valor  Criar as fronteiras (boundaries) que protegem o Time (Tempo, Orçamento, Visão, Padrões, etc.)  Garantir que o Product Backlog é visível, transparente e claro a todos, e que mostra o trabalho em que a equipa Scrum terá de trabalhar a seguir;  Garantir que a equipa de desenvolvimento compreendem, no nível do necessário, os itens no Product Backlog  Ser a interface de comunicação com os Stakeholders , e outros clientes internos e externos. O Product Owner pode fazer o trabalho acima ou delegar à equipa de desenvolvimento. No entanto, estas tarefas continuam a ser imputáveis e da responsabilidade do Product Owner.O Product Owner é um indivíduo e não um comité. O Product Owner poderá representar os requisitos de um comitê no seu Product Backlog, mas qualquer alteração à prioridade dos intensos Product Backlog deverá ser decidida pelo Product Owner (BUZON,2009).

17

Para que o Product Owner tenha sucesso na sua atividade, toda a organização deve respeitar as suas decisões. As decisões do Product Owner são visíveis e óbvias pela forma como os itens estão ordenados no Product Backlog e pelo seu conteúdo. Ninguém está autorizado a indicar a equipa de desenvolvimento um conjunto de requisitos diferentes daqueles definidos pelo Product Owner, do mesmo modo que a equipa de desenvolvimento não está autorizada a agir noutra direção senão a dada pelo Product Owner (SCHWABER E SUTHERLAND 2011).

3.1.2 Equipe (Time) Segundo (SCHWABER E SUTHERLAND (2011)) O Time Scrum é composto pelo Product Owner, a Equipe de Desenvolvimento e o Scrum Master. Times Scrum são autoorganizáveis e multifuncionais/ multidisciplinar (terá muito mais facilidade para agregar valor ao produto, com rápida adaptação à mudança de requisitos). Equipes auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de equipe no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. O tamanho ótimo para um time é de cinco a nove pessoas. Menos que isso gera menor interação e conseqüentemente menor ganho de produtividade. E mais que isso poderá encontrar limitações de conhecimento e há a necessidade de muita coordenação. Equipes de desenvolvimento Scrum estão autorizadas para definir e organizar a melhor maneira de concluir as tarefas definidas no Sprint, ninguém além do time tem autorização para definir quem ou como serão trabalhadas as tarefas definidas no Sprint( F.PEREIRA,2011). Com todas essas qualidades a Equipe de desenvolvimento é uma equipe que consegue agregar mais valor ao produto devido à dinâmica de trabalho. Ela realiza esse trabalho fazendo sua própria organização e planejamento, do mesmo modo que na reunião de Planning 1 é dito pelo P.O o que deve ser feito, na reunião de Planning 2 a equipe diz como vai ser feito. Isso tudo sem deixar a responsabilidade e o comprometimento com o produto, e foca em Produzir o resultado. que é o se espera de Equipe de desenvolvimento Scrum. Ilustração de Como funciona o Trabalho da Equipe Scrum:

18

Schaub.2010 Figura 5.

3.1.3 O Scrum Master O Scrum Master é responsável por garantir que o Scrum é compreendido e divulgado. Os ScrumMasters conseguem isto ao garantir que a equipa Scrum adere à teoria subjacente ao Scrum, às suas práticas e regras. O Scrum Master é o servo-líder da equipa Scrum. Ele garante que todas as práticas do processo serão seguidas, usando para isto as reuniões (Daily Scrum, Sprint Planning, etc…) e artefatos (Product Backlog, Gráfico de Burndown, etc..) ( F.PEREIRA,2011). O Scrum Master deve observar o andamento do sprint com o intuito de manter a todos focados no objetivo do sprint e o prazo de entrega, ele deve tornar a equipe mais produtiva e entregando a cada iteração software com maior qualidade. Scrum.Master é um líder facilitador ou também chamado de líder servidor, pois este sempre esta a serviço dos interessados, visando facilitar e remover impedimentos que possam comprometer a entrega com sucesso das estórias previstas no Sprint.( RIVOLELA(2012)). De acordo com o blog de EDUARDO ROLIM as principais Funções do Scrum Master:  Facilitador do processo

19

 Proteger a equipe de interferências externas que impeçam o funcionamento do Scrum  Evitar que a equipe fique com otimismo exagerado, sempre alertando para possíveis mudanças  Resolver os problemas identificados nas Reuniões diárias  Manter o backlog do Sprint  Manter um gráfico Top/Dowm onde deve ser comparado o total de pontos das tarefas do Sprint com o tempo de horas restante

Um ponto importante é que o Scrum Master não tem que ter autoridade sobre a equipe, isto é, qualquer integrante da equipe de desenvolvimento de software pode ser o Scrum Master e até mesmo fazer um rodízio desta responsabilidade. A troca de Scrum Master entre as pessoas da equipe deve ser realizada com cautela, nunca a cada sprint (fase, ciclo ou iteração) de desenvolvimento e sim por projeto ou por versões (releases) do sistema

afirma (HORÁCIO

,2013).

3.2 Times Box Time Box Traduzindo significa "caixa de tempo". É ter períodos de tempo bem definidos, ter prazo bem definido e imutável para cada iteração. No Scrum o conceito de “Time Box” é aplicado a: Sprints e Reuniões. Como a duração é fixa, os prazos desses eventos não são prorrogados, mesmo que existam pendências ou tarefas a concluir Cada um dos eventos Scrum possui uma finalidade específica, agenda de execução e participantes claramente definidos.

3.2.1 Release Planning Meeting (Reunião de Planejamento)

De acordo com o Scrum guide de SCHWABER E SUTHERLAND (2011) O propósito do planejamento da release é o de estabelecer um plano de metas que a Equipe Scrum e o resto da organização possam entender e comunicar . Geralmente visa Responde as seguintes Questões: 

Como podemos transformar a visão em um produto da melhor maneira possível?

20



Como podemos alcançar ou exceder a satisfação do cliente?



Como podemos alcançar o ROI (Retorno Sobre Investimento)?

Estabelece as metas da release e as maiores prioridades do Product Backlog , os principais riscos e as características gerais e funcionalidades que estarão contidas

na

release.

Estabelece também uma data de entrega e custo prováveis que devem se mantiver se nada mudar. Muitas organizações já tem um processo de Planejamento de Release, e na maior parte desses processos o planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo.Esse planejamento geralmente não requer mais do que15-20% do tempo que uma organização costumava utilizar para produzir um plano de release tradicional.

Figura 6. URS ENZLER (2011) 3.2.2 Sprint Na metodologia Scrum, o processo de desenvolvimento é dividido em ciclos regulares ao longo do tempo. Sprint é cada um destes ciclos. A Sprint “Representa um ciclo de trabalho no Scrum. Esse ciclo pode ser de 2 semanas, 3 ou 4 semanas, onde um conjunto de tarefas deverá ser executado, incrementando o produto de maneira que algo possa ser entregue, ou seja, ser testado e utilizado. Um fator importante no processo é entender que nem sempre a meta será cumprida e algumas tarefas poderão ser realocadas em outro Sprint, além disso o

21

cliente pode mudar de idéia ou algum outro fator externo pode modificar todo o conceito planejado(IGOR,2012) Sprint consiste em tudo que se faz necessário para construção de um determinado Sprint Backlog, ou seja, um Sprint completo contém: 

Sprint Planning (reunião de planejamento)



Sprint (tempo determinado de trabalho)



DailyMeeting (reuniões diárias)



Sprint Review (reuniões de revisão)



Sprint Retrospective (reuniões de retrospectiva)

Figura 7. (HORÁCIO ,2013).

3.2.3 Sprint Review (Reunião de Revisão da Sprint)

22

A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. O objetivo desta reunião é apresentar ao Product Owner (PO) todos os Produtos/ projetos entregáveis que foram produzidos pelo time Scrum e ela conta com a participação do time, do Scrum Master (SM), do PO e de qualquer outro interessado no projeto. Durante essa reunião, o time tem a responsabilidade de mostrar ao PO o trabalho que foi feito, o SM tem a responsabilidade de evitar que a reunião saia do seu propósito inicial não deve se tornar uma distração ou desvio significativo para a equipe, mas sim, deve ser um resultado natural do sprint. e o PO tem a responsabilidade de aprovar, ou não, as novas funcionalidades mostradas (NASCIMENTO,2012). Logo em seguida eles ouvem o que deu errado e o que deu certo levam uma correção de onde eles realmente são em sua viagem de construção do produto e do sistema. Depois de tudo isso, eles são capazes de tomar uma decisão informada sobre o que fazer a seguir. Em outras palavras, eles determinam o melhor caminho a tomar para chegar ao destino pretendido. 3.2.4 Sprint Retrospective (Retrospectiva da Sprint) De acordo com o artigo “A Retrospectiva do Sprint” de JULIANA JENNY A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês. Proporcionalmente um tempo menor é alocado para Sprints menores. O propósito da Retrospectiva da Sprint é:  Inspecionar como a última Sprint foi em relação às pessoas, relações, processos e ferramentas;  Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,  Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho; Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si própria. A Retrospectiva da Sprint fornece um evento dedicado e focado na inspeção e adaptação, no entanto, as melhorias podem ser adotadas a qualquer momento SCHWABER E SUTHERLAND (2011). 3.2.5

Daily Scrum Meeting(Reuniões Diárias)

23

Daily Scrum Meeting são reuniões, elas tem como objetivo disseminar conhecimentos sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.Essas reuniões são normalmente realizadas no mesmo local e ao mesmo tempo cada dia,são rápidas,duram em torno de 15 minutos apenas, e o objetivo é que os integrantes do time respondam a três perguntas: 

O que fiz ontem?



O que farei hoje?



Possuo impedimento? Se sim, o que está me impedindo?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na quais membros da equipe assumem compromissos perante os demais (Mountain Goat). Sátira para mostrar a diferença dos papeeis dos envolvidos no Scrum

Figura8. COELHO 2010.

A brincadeira serve para apontar a diferença entre aqueles que estão empenhados em um projeto e aqueles que só estão envolvidos. Scrum permite estatuto especial para aqueles que estão comprometidos, e muitas equipes impor uma regra em que somente aqueles que estão comprometidos estão autorizados a falar durante a reunião diária do Scrum(Mountain Goat).

3.3 Artefatos do Scrum De acordo com Scrum Guide de SCHWABER E SUTHERLAND (2011) os artefatos do Scrum representam o trabalho ou o valor das várias maneiras que são úteis no fornecimento

24

de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave necessários para assegurar que o Time Scrum tenha sucesso na entrega do incremento “Pronto”. 3.3.1 Product Backlog e Release Burndown O Product Backlog é uma lista contendo tudo aquilo que constará no projeto no inicio não há um grande esforço que demande gastar muito tempo, sendo suficiente para a primeira Sprinte.Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.O Product Backlog é dinâmico; muda constantemente de forma a identificar o que o produto precisa para ser adequado, competitivo e útil. Enquanto um produto existe, o Product Backlog também existe(VINÍCIUS,2007). De acordo com Scrum Guide de SCHWABER E SUTHERLAND(2011) O Product Backlog é muitas vezes ordenado pelo seu valor, risco, prioridade e necessidade. Os itens no top da lista necessitam de atividade de desenvolvimento imediata. Quanto maior a ordem (topo da lista) de um item, mais este tem sido considerado e maior é o consenso existente sobre si e sobre o seu valor. Itens do Product Backlog podem ser tarefas técnicas (“Refatorar a classe Login para disparar uma exceção”) ou mais focadas no usuário ("Permitir voltar na tela de instalação"). O Product Backlog pode ser mantido em uma planilha Excel. Essa planilha Excel mostra cada item do Product Backlog com uma priorização genérica (Muito Alta, Alta, etc.) feita pelo Product Owner. Planilha Excel mostrando o Product Backlog

25

Figura 10. LIBERATO, 2011 Na Release Burndown o time acompanha seu progresso comparado ao planejamento da Release, atualizando um Release Burndown Chart (gráfico) ao final de cada Sprint. O eixo horizontal representa os Sprints; o eixo vertical apresenta o total de trabalho restante no início de cada Sprint. O trabalho restante pode ser representado com qualquer unidade, da preferência do time Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser detalhados. As estimativas dos itens de Sprint Backlog são inicialmente calculadas durante o Planejamento da Versão para entrega e, posteriormente, à medida que forem sendo criados. Durante a

26

preparação do documento, os itens são revistos e revisados. No entanto, podem ser atualizados a qualquer momento. O time é responsável por todas estimativas. O Product Owner pode auxiliar o time além de manter o Sprint Backlog e o Burndown do Backlog da Versão sempre atualizados e publicados todo o tempo (SCHWABER; SUTHERLAND, 2011). Exemplo de Grafico Release Borndown

Figura 11. COHN, 2008 3.3.2 Sprint Backlog e Sprint Burndown

O Sprint Backlog representa tudo o que deverá ser feito durante a próxima Sprint do seu projeto. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades. Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los (NASCIMENTO,2012).. Á medida que novo trabalho surge, o Time o adiciona no Sprint Backlog. E à medida que se trabalha nas tarefas ou que elas são finalizadas as horas estimadas de trabalho restante para

27

cada tarefa são atualizadas. Tarefas desnecessárias são removidas. Somente o time pode modificar o Sprint Backlog bem como seu conteúdo e estimativas. É um retrato em tempo real altamente visível do trabalho que o time planeja efetuar durante a Sprint SCHWABER E SUTHERLAND (2011). A maioria dos itens que estão no Product Backlog serão implementados um dia, mas para serem considerados para fazer parte do Sprint Backlog eles devem estar preparados, estimados e priorizados, segundo a definição de preparado estabelecida no início do projeto. O Sprint Burndown Geralmente é utilizado em forma de gráfico para acompanhar o desenvolvimento e utilizado pelas equipes Scrum para representar diariamente o progresso do trabalho. 

Eixo X para exibir dias úteis



Eixo Y para exibir esforço restante



Esforço Ideal como uma diretriz



O progresso real de esforço

As empresas usam diferentes atributos no eixo Y. Todos eles têm vantagens e desvantagens. Exemplo do Gráfico Burndown.

Figura 12. Fonte: Castro 2009

28

Segundo SCHWABER (2011) o Scrum não é um processo previsível, ele não define o que fazer em toda circunstância. Ele é usado em trabalhos complexos nos quais não é prever tudo o que irá ocorrer e oferece um framework e um conjunto de práticas que torna tudo visível. O conhecimento das práticas do Scrum permite a aplicação delas de forma variadas e este é um dos aspectos positivos do Scrum a adaptabilidade. Sendo assim o Scrum pode ser aplicado em contexto (empresas de qualquer porte e setor.) onde pessoas precisem trabalhar juntas para atingir um objetivo comum. Nessa seção serão mostrado exemplos de empresas tanto no ramo de desenvolvimento de Software quanto fora do ramo de software que adotam o Scrum. 4.Scrum nas Empresa O Scrum oferece ferramentas e práticas que permitem maior visibilidade do projeto, de forma a facilitar os ajustes e manter o foco sempre na direção da meta desejada. Sendo Assim o Scrum não necessariamente precisa ser adotado por empresas de desenvolvimentos de software (“mas na maioria das vezes é”) exemplo disso é a Government Accountability Office (GAO) empresa Norte Americana responsável pela Auditoria, Avaliações e Investigações do Congresso dos Estados Unidos. Que aderiram ao Scrum, antes o projeto já havia consumido mais de US$ 1bi em mais de uma década de tentativa de desenvolvimento, passando pelas mãos de duas empresas. A Government Accountability Office(GAO) no Brasil, seria um órgão com objetivos similares ao da Controladoria Geral da União. Em outro exemplo Rafael Amaro Diretor Administrativo da empresa ICE Interactive fala em seu blog “Métodos Ágeis na rotina da empresa” que além de ser utilizado para gerenciar o desenvolvimento de um projeto, que na maioria das vezes, é de software. Ele também pode ser inserido no dia-dia da empresa que foi o caso da ICE. Por a empresa ter pouco pessoal eles dividem o tempo no desenvolvimento de projetos e no gerenciamento administrativo. E como eles tinham que dividir o tempo em desenvolviemnto e tarefas como: uma visita técnica, ter uma reunião com um cliente, ou mesmo ir ao banco, não era possível estimar o tempo de desenvolvimento sem levar essas outras tarefas “externas” em consideração. Então eles inseriram o Scrum tanto no dia - a-dia da empresa quantos gerenciamentos dos projetos isso Até mesmo para saber como está o andamento de uma negociação com um determinado cliente, e quem é o responsável por ela, por exemplo, fica muito mais fácil.

29

De Acordo com Artigo “Empresas que utilizam Scrum” de Rafael Ramos serão listadas algumas das empresas que aderiram o Scrum.  Microsoft;  Yahoo;  Google;  Philips;  Siemens;  Nokia;  Time Warner;  Projeta de Hardware,  Projeto de Infra-estrutura,  Projeto de Publicidade/ Marketing,  Sul América Seguros/ Saúde etc.  Government Accountability Office (GAO)

Nesta seção será Abordado uma pesquisa feita pela VersionOne mostrando a aceitação do Scrum dentro todos métodos de desenvolvimento ágil.

5. Aceitação do Scrum nas Empresas

Em uma pesquisa realizada em 2011 pela VersionOne, empresa pioneira no mercado de ferramentas de gestão ágil 60 % dos entrevistados afirmaram que mais de 50% dos projetos realizados em suas respectivas empresas já utilizaram métodos ágeis Scrum é o método ágil mais utilizado pelas empresas, sendo utilizado por 52% das empresas respondentes.

30

Scrum 52% XP 14% Kaban 9% Don't know 8% FDD 5% Outros 12%

Figura 13 VersionOne, 2011 Isso demonstra que o Scrum rompeu a barreira para sua adoção é a remoção dos obstáculos organizacionais (cultura) e está tendo uma aceitação maior dentre as empresas que Utilizam o Método de Desenvolvimento Ágil.

6. Benefícios e Criticas Apesar de bem aceito na indústria de software e projetos, o Scrum também sofre grandes críticas e é questionado quanto ao seu domínio de aplicação. Eles censuram a substituição de relatórios e documentos pelo post-it.Contrariando a crença de que, em algum nível, projetos e trabalhos precisam ser documentados. Outra critica e relativo à ausência de hierarquia, o que prejudicaria os interessados em alcançar postos de gestores, em progredir na carreira.

Se bem adotado o Scrum, permite à organização começar a ter uma métrica da capacidade que tem em converter demandas funcionais em produtos prontos, o que permite que se possa melhorar a predictibilidade de entregas de produto O SCRUM tem como meta também agilizar o processo de desenvolvimento, sugerindo a quebra do projeto em pequenas partes para facilitar o cumprimento de objetivos de curto prazo. O SCRUM propõe a quebra de um paradigma que pode ser observado no método em cascata: a falta de flexibilidade do escopo do projeto. Tal questão se revela como uma dificuldade para

31

que resultados eficazes possam ser atingidos. Ou seja, garantir que os objetivos reais do cliente com a solução criada serão integralmente atendidos. Outro paradigma gerencial quebrado pelo método SCRUM refere-se às relações hierárquicas claramente definidas entre os membros da equipe KEN SCHWABER E JEFF SUTHERLAND (2011).

7. Resultado Pude compreender bem os benefícios de mostrar que os métodos ágeis e Principalmente o Scrum trabalha com a preocupação em Satisfazer o cliente, dar resultados em rápidos tempos, Softwares e Produtos com os maiores números de sucesso e sempre dando feedback para o cliente , essa pesquisa também mostrou os fundamentos dos princípios "ágeis" dispostos no manifesto que são uma filosofia de vida, pela valorização das pessoas, respeito a sua função desenvolvida, senso de urgência e valor, evitarem o desperdício, espírito de equipe, colaboração, sustentabilidade, um longo caminho para cada um, envolvido no projeto, mas também que traz benefícios para todos a cada passo.Não seja projetos estressantes as equipes possam se motivar quando eles podem usar sua criatividade para resolver problemas e quando eles podem decidir organizar o seu trabalho.

8. Discussões Como a intenção desse artigo era mostrar a evolução dos métodos de desenvolvimento de software e focar nos Scrum, mostrar os benefícios, mostrar os fundamentos dos princípios "ágeis" dispostos no manifesto que são uma filosofia de vida, pela valorização das pessoas, respeito a sua função desenvolvida e também pode ser aplicadas e outras empresas de de outros setores , então eu conseguir alcançar o que foi proposto o que me surpreendeu e superou minhas expectativas . Porque quando decidir fazer o curso de Tecnologia em Análise e Desenvolvimento de Sistemas queria apenas programar, aprender fazer um banco fazer a conexão, criar paginas para WEB. E essa pesquisa que eu realizei, me proporcionou a oportunidade de aprofundar no assunto Gerencia de Projetos que sempre foi um assunto que eu não gostava muito e tinha dificuldade e acabei percebendo que esse aprendizado não foi só para a vida profissional mas para a vida toda a valorização da pessoa, o respeito.

32

9. Conclusão Com o presente Artigo demonstrou-se que ocorreu uma grande evolução durantes esses anos todos no modo em que se desenvolve software, Devido às crescentes pressões do mercado por inovação, produtividade (prazos casa vez mais curtos), qualidade dos projetos de desenvolvimento de Software os métodos ágeis principalmente o Scrum pode solucionar muitos desses problemas por ter há a entrega de produtos em períodos de tempo préestabelecidos, nunca inferiores a uma semana ou superiores a trinta dias, oferece ferramentas e práticas que permitem maior visibilidade do projeto,e tem um feedback constante do que é feito.Isso culminou em uma aceitação muito grande entre as empresas onde 52% das empresas que aderiram aos métodos ágeis utilizam o Scrum. O Scrum quebrou o paradigma de que é utilizado para desenvolver software ele também pode ser utilizados para o gerenciamento de outros projetos de áreas e ou setor e até nos dia-a-dia das empresas por permitir manter o foco na entrega e no menor tempo possível e a rápida e continua inspeção e com feedback constantes. E com esses sucessos a tendência e o Scrum ganhar cada vez, mas espaço dentre as empresas.

33

Methods Software Development with focus on Agile Method "SCRUM" Agile Method SCRUM Alan Santos Maciel

Abstract: (In English). This article was produced in order to show the evolution of development methodologies and software projects. Will consider the following models, Waterfall, Interactive Model / Incremental, Unified Process (RUP) and agile development methods with the main approach in SCRUM. After research conducted it was found that companies that adopt this procedure cited in the intention to streamline the software development, has 52% of all creative processes are based agile adopted this way of working. Will be demonstrated as a result of Article weaknesses and positive in adopting the Scrum development method.

Keywords: Development Methods Software, Agile Method and Scrum.

34

Referência AdaptWorks Emphasys Group“Caso de sucesso utilizando Scrum”(2012) Documento online disponível em: http://www.adaptworks.com.br/blog/2012/08/ ALESSANDRO F.PEREIRA “Equipe Scrum” (2011) Documento online disponível em: http://www.cova.com.br/afp/node/17

ANDRÉ NASCIMENTO “O que é Scrum”(2010) Documento online disponível em: http://blog.anascimento.net/2010/02/25/o-que-e-scrum/ ANDRÉ FARIA “Mas o que faz um Product Owner?” (2011) Documento online disponível em: http://blog.andrefaria.com/mas-o-que-faz-um-product-owner

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML, guia do usuário. Rio de Janeiro: Campus, 2000

CAVERNA DO SOFTWARE “Fábrica de Software-Definir processo de desenvolvimento RUP” (2010) Documento online disponível em: (http://voat.com.br/rdal/?p=91) CHRISTOPHER AUGUSTO “Introdução a Métodos Ágeis” Documento online disponível em: http://www.devmedia.com.br/introducao-a-metodos-ageis/24526

EDEM COELHO “A CLASSICA Historia porco e Frango” (2010) Documento online disponível em: http://penseagil.wordpress.com/2010/04/20/23/ EDUARDO BEZERRA. Princípio de Análise e Projeto de Sistemas com UML . . : Campus, 2002.

ELLIANDO DIAS “Processo Unificado (RUP)” (2008) Documento online disponível em: (http://www.slideshare.net/adorepump/processo-unificadorup-presentation)

35

FLÁVIO FUTADO DE FARIAS “Metodologia X Método” (2011) Documento online disponível em: (http://materialemetodos.blogspot.com.br/2011/06/metodologia-x-metodo.html) Flavio Steffens de Castro “Gráfico Burndown – Sugestão de uso” (2009) Documento online disponível em: http://www.agileway.com.br/2009/08/18/grafico-burndown-sugestao-de-uso/ IGOR ARAÚJO “O QUE É SPRINT” (2012) Documento online disponível em: http://blog.myscrumhalf.com/2012/02/o-que-e-sprint-%E2%80%93-faq-scrum/

INOVATIVIDADE MJV “Scrum? O que é? Como funciona?” (2003) Documento online disponível em: http://www.inovatividade.com/metodologias/scrum-o-que-e-como-funciona

JAIR C. LEITE “O Modelo Cascata” (2007) Documento online disponível em: (http://engenhariadesoftware.blogspot.com.br/2007/03/o-modelo-cascata.html)

JAMES MOREIRA “Scrum” (2011) Documento online disponível em: http://www.slideshare.net/nyubai/scrum-prof-james-moreira-jr JORGE HORÁCIO AUDY “O QUE FAZ ESSE TAL DE SCRUM MASTER”(2013) Documento online disponível em: http://www.baguete.com.br/colunistas/colunas/1173/jorgehoracio-audy/21/01/2013/o-que-faz-esse-tal-de-scrum-master JULIANA PRADO UCHÔA "Evolução da metodologia do desenvolvimento de sistemas” Documento on-line Disponível em: https://www.google.com.br/search?q=referencia&aq=f&oq=referencia&aqs=chrome.0.57j0l3j 62l2.1622j0&sourceid=chrome&ie=UTF-8

JULIANA PRADO UCHÔA “Evolução da metodologia do desenvolvimento de sistemas” Documento online disponível em: (http://www.linhadecodigo.com.br/artigo/2108/evolucaoda-metodologia-do-desenvolvimento-de-sistemas.aspx) JULIANA BEROSSA STEFFEN "O que são essas tais de metodologias Ágeis " (2012). Documento on-line. Diponível em:

36

(https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_que_s_c 3_a3o_essas_tais_de_metodologias

c3_a1geis?lang=en)

JULIANA JENNY “A Retrospectiva do Sprint” (2012) Documento online disponível em: http://julianakolb.com/2012/01/28/a-retrospectiva-do-sprint/ KEN SCHWABER E JEFF SUTHERLAND “Guia do SCRUM” (2011) Documento online disponível em: http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20%20Port uguese%20BR.pdf#zoom=100 KIOSKEA.NET “Métodos ágeis (RAD, XP)”(2013) Documento online disponível em: (http://pt.kioskea.net/contents/229-metodos-ageis-rad-xp) MARCELO LIBERATO “Case Projeto Automação BPM: PMBOK e o Manifesto Ágio, mistura possível?” (2011) Documento online disponível em: http://marceloliberato.wordpress.com/tag/product-backlog/ MARINA

MARTINEZ

“RUP”

(2010)

Documento

online

disponível

em:

(http://www.infoescola.com/engenharia-de-software/rup/) MARTIN FOWLER “A Nova Metodologia” (2003) Documento online disponível em: http://www.p3software.com.br/home/index.php?option=com_content&view=article&id=6:anova-metodologia&catid=35:tecnicos&Itemid=69

MIKE COHN “Melhoria na liberação gráfica Burndown tradicionais ”(2008) Documento online disponível em: http://www.mountaingoatsoftware.com/blog/improving-on-traditionalrelease-burndown-charts MOUNTAIN GOAT “ O Scrum Meeting Diário” Documento online disponível em: http://www.mountaingoatsoftware.com/scrum/daily-scrum/

LUCIENE MARTINZ “O Scrum no apoio à Gestão de Pessoas” Documento online diponivel em: (http://www.lg.com.br/canais/mais-ti/artigos/o-scrum-no-apoio-a-gestao-de-pessoas)

37

Luiz, R.(2005) “Obtendo Qualidade de software com o RUP”,TCC,Universidade de Uberaba. PAULA NASCIMENTO “O que é reunião de revisão” (2012) Documento online disponível em: http://blog.myscrumhalf.com/2012/03/o-que-e-reuniao-de-revisao-faq-scrum/ PAULO ANDRÉ MOREIRA CRUZ “SCRUM” (2009) Documento online diponivel em: (http://www.slideshare.net/pauloandrejpa/scrum-2628994)

PRESSMAN, Roger S. Engenharia de Software, Sexta Edição. Editora MCGrawHill: , 2010. (RADAR CITi).” SCRUM – Gestão Ágil de Projetos ”(2010)Documento online diponivel em:(http://www.citi.org.br/blog/2010/12/22/scrum-gestao-agil-de-projetos/) RAFAEL BUZON “Escalando o papel do Product Owner” (2009) Documento online disponível em: http://blog.kudoos.com.br/agile/escalando-o-papel-do-product-owner/ Rafael Ramos “Empresas que utilizam SCRUM”(2013) Documento online disponível em : http://www.gestaoetc.com.br/150/empresas-que-utilizam-scrum/ RENATO JOSÉ GROFFE “Desenvolvimento ágil com Scrum: uma visão geral” Documento online disponível em: (http://www.devmedia.com.br/desenvolvimento-agil-comscrum-uma-visao-geral/26343) RENATO DAVIS RUIZ BATISTA “SCRUM NA PRATICA” (2012) Documento online disponível

em:

http://scrum10.blogspot.com.br/2012/05/reuniao-de-planejamento-da-

sprint.html RIVOLELA “Quem é o Scrum Master” (2012) Documento online disponível em: http://blog.roma.srv.br/quem-e-o-scrum-master/

38

ROBSON SILVA ESPING “A Evolução dos Processos de Desenvolvimento de Software” (2008) Documento online disponível em: HTTP://www.slideshare.net/espig/a-evoluo-dosprocessos-de-desenvolvimento-de-software ROBSOM RAMOS “Uma comparação entre os modelos ágil e cascata de desenvolvimento de software” (2010) Documento online disponível em: (http://brainstormdeti.wordpress.com/2010/05/25/uma-comparacao-entremodelo-agil-ecascata/)

SERGIO ANTONIO DOS SANTOS "Sucesso no desenvolvimento de software usando uma metodologia de desenvolvimento" (2012). Documento on-line. Disponível em: (http://imasters.com.br/artigo/6566/software/sucesso-no-desenvolvimento-de-softwareusando-uma-metodologia-de-desenvolvimento/) URS ENZLER “Scrum em bbv Software Services AG” (2011) Documento online disponível em: http://www.planetgeek.ch/2011/01/27/presentation-scrum-at-bbv-software-services-ag/

VINÍCIUS MANHÃS TELE "PRODUCT BACKLOG" (2007) Documento online disponível em: http://improveit.com.br/scrum/product_backlog Rafael Amaro “Métodos Ágeis na rotina da empresa” (2012) Documento online disponível em: http://blog.myscrumhalf.com/2012/06/metodo-agil-na-rotina-da-empresa/

VINICIUS A.C “Software e Empreendedorismos-Valores, princípios e praticas”(2007) Documento online disponível em: http://devagil.wordpress.com/2007/07/07/introducao-aodesenvolvimento-agil/ Willy-P.Schaub “Basics of Scrum” (2010) Documento online disponível em: http://blogs.msdn.com/b/willy-peter_schaub/archive/2010/04/30/basics-of-scrum-part-3-whatare-the-scrum-artefacts-and-how-will-the-rangers-use-them.aspx