UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO OBJETO DE APRENDIZAGEM DE TESTES ÁGEIS NO CONTEXTO DO SCRUM por Maira Stella da Silva Itajaí (SC), junho de 2013

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO OBJETO DE APRENDIZAGEM DE TESTES ÁGEIS NO CONTEXTO DO SCRUM Área de Engenharia de Software por Maira Stella da Silva Relatório apresentado à Banca Examinadora do Trabalho Técnicocientífico de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador(a): Fabiane Barreto Vavassori Benitti, Dra. Itajaí (SC), junho de 2013

3 Dedico esse trabalho em especial aos meus pais Genésio Fabrício da Silva Filho e Maria Aparecida Bittencourt da Silva, pelo apoio nas minhas decisões, pelos conselhos sábios e pela motivação a trilhar um caminho com honestidade e braveza.

4 AGRADECIMENTOS Agradeço meus pais pelo apoio nos momentos difíceis, pelos conselhos sábios, pelos valores ensinados, pelos abraços de felicidade, e por me fazer acreditar que com esforço e dedicação alcançamos nossos sonhos. Agradeço ao meu irmão, por representar o verdadeiro significado de companheirismo. Um agradecimento especial ao meu namorado, por me apoiar durante o desenvolvimento do projeto e por ser me trazer segurança, apoio e motivação para a conclusão desse projeto. Agradeço aos meus colegas de graduação, pelos momentos de descontração e ajuda nos estudos. Agradeço também a todos os professores do curso de Ciência da Computação que contribuíram de forma direta ou indiretamente para a minha formação acadêmica. Agradeço em especial a Fabiane Barreto Vavassori Benitti, pela paciência e dedicação na orientação desse projeto.

5 Muitos são os obstinados que se empenham no caminho que escolheram, poucos os que se empenham no objetivo. Friedrich Nietzsche

6 RESUMO SILVA, Maira Stella. Objeto de Aprendizagem de Testes Ágeis no Contexto do Scrum. Itajaí, Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, As empresas se preocupam cada vez mais com a satisfação de seus clientes. E com o objetivo de melhorar a qualidade do produto, diminuindo os incidentes de defeitos, cumprindo com os prazos de entrega, e principalmente, desenvolvendo o que o cliente realmente espera no sistema, as empresas buscam maneiras de tornar o processo de desenvolvimento mais eficaz. Com as metodologias ágeis é possível melhorar o desempenho das atividades de desenvolvimento de software. Nesse projeto foi desenvolvido um objeto de aprendizagem para simular uma empresa que utiliza a metodologia ágil Scrum. O aluno conhece os conceitos da metodologia, participa de reuniões para elaboração das tarefas do sistema a ser desenvolvido, e cria testes de aceitação para as tarefas. Quando as funcionalidades estão desenvolvidas, o aluno inicia os testes baseado nos critérios de aceitação, com a finalidade de identificar defeitos. Propositalmente existem erros inseridos no sistema a ser testado, e o aluno deverá identificá-los. Caso os defeitos sejam encontrados, a tarefa retorna para o desenvolvimento para que seja corrigida, e caso não sejam encontrados defeitos, o Product Owner, na reunião final reprova as tarefas. O aluno é avaliado conforme o seu desempenho, dependendo da quantidade de erros encontrados. Palavras-chave: Metodologia Scrum. Testes Ágeis. Teste de Aceitação.

7 ABSTRACT Companies are increasingly concerned with the satisfaction of their customers. To improve product quality, reducing defects occurrence, compliance with delivery times, and most importantly, developing what customers really expect the system, companies seek ways to make the development process more efficient. Agile methodologies can improve the performance of software development process. This project presents a learning object that simulates a company that uses the Scrum agile methodology. The student learns the concepts of the methodology, participates in meetings to prepare the tasks of the system being developed, and create acceptance tests for tasks. When the features are developed, the student begins the tests based on the acceptance criteria, in order to identify defects. Purposely inserted errors exist in the system to be tested, and the student must identify them. If defects are found, the task returns to the development to be corrected, and if not found, the Product Owner disapproves tasks. The student is rated according to their performance, depending on the number of errors found. Keywords: Scrum Methodology. Agile Testing. Acceptance Test.

8 LISTA DE FIGURAS Figura 1. Ciclo de vida da metodologia Scrum Figura 2 - Exemplo de User Story Figura 3 - Relação entre níveis, tipos e técnicas de testes Figura 4 - Exemplo de User Story com testes de aceitação Figura 5 - Processo ADDIE Figura 6 - Matriz de design instrucional Figura 7 - Tela exibida após a simulação de uma falha Figura 8 - Tela da primeira fase do jogo Figura 9 - Tela do objeto virtual de aprendizagem Figura 10 - Interface do jogo Figura 11 - Tela de instruções sobre o teste de caixa preta Figura 12 - Tela inicial do sistema Light Views Figura 13 - Diagrama de atividades do objeto de aprendizagem Figura 14 - Diagrama de entidade e relacionamento Figura 15 Tela inicial do objeto de aprendizagem Figura 16 Tela de cadastro de aluno Figura 17 - Tela sobre a metodologia Scrum Figura 18 - Apresentação do Scrum Team Figura 19 - Papel do aluno no Team e Product Backlog Figura 20 - Tela do Product Backlog Figura 21 - Tela de cadastro de veículos Após visualizar o Product Backlog, o Scrum Master informa que iniciará uma reunião de Sprint Planning, para a definição das estórias que serão desenvolvidas. Nessa tela os termos Sprint, Sprint Planning e Sprint Backlog são links, e se o aluno clicar será exibida uma explicação sobre cada termo (Figura 22). Figura 22 Tela com os termos Sprint, Sprint Planning e Sprint Backlog Figura 23 Tela exibindo a explicação sobre Sprint Figura 24 - Reunião de Sprint Planning - Cadastro de Clientes Figura 25 - Reunião para definir horas de desenvolvimento - Cadastro de Cliente.. 59 Figura 26 - User Story com tarefas definidas Figura 27 - Iniciar a criação de testes de aceitação Figura 28 - Tela para criar os testes de aceitação para a estória de cadastro de clientes Figura 29 - Conclusão da criação dos testes de aceitação Então inicia-se uma nova reunião com o Product Owner, para a definição de restrições e levantamento de tarefas da estória de locação de veículos (Figura 30). Figura 30 - Sprint Planning Locação de Veículos Figura 31 - Reunião para definir horas de desenvolvimento Locação de Veículos 62 Figura 32 User Story Locação de Veículos Figura 33 Cadastro de estes de aceitação para locação de veículos Figura 34 - Quadro Kanban... 64

9 Figura 35 Dica antes de iniciar os testes no cadastro de cliente Figura 36 - Tela para testes de cadastro de clientes Figura 37 - Comparação entre casos de testes e testes de aceitação Figura 38 - Tarefa retorna para "Em andamento" quando algum erro é identificado 67 Figura 39 - Quadro Kanban tarefa de cadastro de cliente concluída Figura 40 - Iniciar testes na funcionalidade de locação de veículos Figura 41 - Tela de teste da funcionalidade de locação de veículos Figura 42 Tarefas de locação de veículos reprovadas e retornaram para Em Andamento Figura 43 Tarefas de locação de veículos aprovadas Figura 44 - Reunião de Sprint Review Figura 45 Cenário Figura 46 - Cenário Figura 47 - Cenário Figura 48 - Cenário Figura 49 Questionário de Avaliação Figura 50 Gráfico de quantidade de erros identificados Figura 51 Gráfico de quantidade de erros identificados Figura 52 - Tela inicial do objeto de aprendizagem Figura 53 - Tela sobre a metodologia Scrum Figura 54 - Apresentação do Scrum Team Figura 55 - Papel do aluno no Team e Product Backlog Figura 56 - Tela do Product Backlog Figura 57 - Tela de cadastro de veículos Figura 58 - Explicação dos termos "Sprint", "Sprint Planning" e "Sprint Backlog Figura 59 - Reunião de Sprint Planning - Cadastro de Clientes Figura 60 - User Story com tarefas definidas Figura 61 - Iniciar a criação de testes de aceitação Figura 62 - Tela para criar os testes de aceitação para a estória de cadastro de clientes Figura 63 - Conclusão da criação dos testes de aceitação Figura 64 - Sprint Planning para a estória de locação de veículos Figura 65 - User Story sobre locação de veículos Figura 66 - Testes de aceitação para locação de veículos Figura 67 - Sprint Planning para estimativa de tempo necessário para desenvolver as tarefas Figura 68 - Quadro Kanban Figura 69 - Quadro Kanban - Tarefas "Em andamento Figura 70 - Quadro Kanban - Tarefas "Em Teste Figura 71 - Iniciar testes no cadastro de cliente Figura 72 - Tela para testes de cadastro de clientes Figura 73 - Comparação entre casos de testes e testes de aceitação Figura 74 - Tarefa retorna para "Em andamento" quando algum erro é identificado 97 Figura 75 - Quadro Kanban - tarefa concluída... 98

10 Figura 76 - Iniciar testes na funcionalidade de locação de veículos Figura 77 - Tela de teste da funcionalidade de locação de veículos Figura 78 - Reunião de Sprint Review Figura 79 Cenário Figura 80 - Cenário Figura 81 - Cenário

11 LISTA DE TABELAS Tabela 1. Protocolo de Busca Tabela 2. Trabalhos Correlatos Tabela 3. Comparativo dos trabalhos correlatos Tabela 4. Tabela de design instrucional para o objeto de aprendizagem Tabela 5. Dicionário de dados da entidade USER Tabela 6. Dicionário de dados da entidade RODADAS Tabela 7. Dicionário de dados da entidade CADASTROTESTEACEITACAO Tabela 8. Dicionário de dados da entidade CADASTROCLIENTE Tabela 9. Dicionário de dados da entidade LOCACAO Tabela 10. Dicionário de dados da entidade VEICULO Tabela 11. Dicionário de dados da entidade ASSOCIATESTECLIENTE Tabela 12. Dicionário de dados da entidade ASSOCIATESTELOCACAO Tabela 13. Tabela de diálogo Sprint Planning - Cadastro de Cliente Tabela 14. Tabela de Diálogo de Estimativa de Tempo - Cadastro de Cliente Tabela 15. Tabela de diálogo Sprint Planning Locação de Veículos Tabela 16. Tabela de Diálogo de Estimativa de Tempo Locação de Veículos Tabela 17. Tabela de Diálogo da Reunião de Sprint Review

12 LISTA DE ABREVIATURAS E SIGLAS ADDIE ATDD RIVED TDD TTC UNIVALI Analysis, Design, Development e Evaluation Acceptance Test Driven Development Rede Interativa Virtual de Educação Test Driven Development Trabalho Técnico-científico de Conclusão de Curso Universidade do Vale do Itajaí

13 SUMÁRIO 1 INTRODUÇÃO PROBLEMATIZAÇÃO FORMULAÇÃO DO PROBLEMA Solução Proposta Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA SCRUM Papéis Artefatos Eventos TESTE DE SOFTWARE Técnicas de Teste de Software Níveis de Teste de Software Tipos de Teste de Software TESTES NO CONTEXTO ÁGIL OBJETOS DE APRENDIZAGEM TRABALHOS CORRELATOS DESENVOLVIMENTO PLANEJAMENTO IMPLEMENTAÇÃO DO OBJETO DE APRENDIZAGEM Diagrama de Atividades Diagrama de Entidade Relacionamento DEMONSTRAÇÃO E OPERACIONALIDADE AVALIAÇÃO CONCLUSÕES TRABALHOS FUTUROS...80 APENDICE A. TELAS DO PROTÓTIPO DO OBJETO DE APRENDIZAGEM...84 APENDICE B. DICIONÁRIO DO BANCO DE DADOS APENDICE C. QUESTIONÁRIO DE AVALIAÇÃO APENDICE D. DIÁLOGOS DA TELA DE REUNIÕES...110

14 15 1 INTRODUÇÃO À medida em que as organizações tornam-se cada vez mais dependentes da indústria de software, os problemas relacionados ao processo de desenvolvimento de sistemas ficam mais evidentes. Alto custo, alta complexidade, dificuldade de manutenção e uma disparidade entre as necessidades dos usuários e o produto desenvolvido são exemplos dos problemas enfrentados (SOMMERVILLE, 2003). Partindo do princípio que o processo utilizado no desenvolvimento é um dos motivos para a ocorrência desses problemas, um segmento crescente da engenharia de software vem defendendo a adoção de processos e metodologias mais simplificados, conhecidos como métodos ágeis, que visam a desburocratização das atividades associadas ao desenvolvimento (FOWLER, 2001). Métodos, práticas e técnicas para o desenvolvimento ágil de projetos prometem aumentar a satisfação do cliente (BOEHM, 2003), produzindo alto nível de qualidade de software e acelerando os prazos de entrega dos projetos (ANDERSON, 2003). Entre os métodos, práticas e técnicas, surgiu o Scrum. O Scrum é um framework estrutural que é utilizado para gerenciar o desenvolvimento de produtos complexos desde o início de Scrum não é um processo ou uma técnica para construir produtos, mas um framework dentro do qual pode-se empregar vários processos ou técnicas (SCHWABER; BEEDLE, 2011). Resumindo, é uma metodologia ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível, permitindo a rápida e contínua inspeção do software em produção (COHN, 2009). No contexto de metodologias ágeis existem os testes ágeis, que são atividades da etapa de testes num processo de desenvolvimento de software que adotam conceitos ágeis (FOWLER; HIGHSMITH, 2001). Conforme Graham (2008) define, o teste de software é um processo, ou uma série de processos, executado para validar se o código de computador faz o que foi projetado para fazer e não faz algo fora do esperado. Os testes podem ter diferentes objetivos como encontrar defeitos, aumentar o nível de confiança, aumentar o nível de qualidade do software e até mesmo a prevenção de defeitos. Os testes ágeis, além de possuírem os mesmos objetivos dos testes em metodologias tradicionais, são implementados em todo o

15 16 ciclo de vida de desenvolvimento de software e não apenas quando o software está concluído. Este conceito é importante, pois segundo a regra 10 de Meyers, o custo da correção dos defeitos tende a subir quanto mais tarde eles forem encontrados e corrigidos (BASTOS et al., 2007). Ao se utilizar alguma metodologia de desenvolvimento ágil, é desejável que todos os integrantes da equipe reconheçam a importância dos testes, desde o nível de unidade a níveis mais altos, como de funcionalidade e aceitação, direcionando o desenvolvimento do código, ajudando a equipe a entender como a aplicação deve funcionar e servindo como feedback das tarefas ou estórias definidas (CRISPIN; GREGORY, 2009). Considerando a importância da aplicação de testes, e a consequente necessidade de treinamento/ensino de suas técnicas, é possível verificar algumas iniciativas já desenvolvidas, como por exemplo, o Bug Hunt que é um tutorial web para envolver os alunos na aprendizagem de estratégias de testes de software através de desafios e exercícios (ELBAUM; PERSON; DOKULIL, 2007). Outra aplicação interessante é o itest Learning, desenvolvido com o objetivo de apoiar o ensino de testes de software na fase de planejamento. É um jogo educacional, que simula um ambiente para o planejamento de teste de software através de uma breve descrição de um projeto hipotético (FARIAS et al., 2012). Outro jogo desenvolvido para o ensino de testes de software é O Jogo das 7 Falhas, permitindo o jogador a assumir o papel de testador, com a finalidade de encontrar os 7 defeitos existentes em cada funcionalidade testada. (DINIZ; DAZZI, 2011). Uma alternativa que surge para o ensino de testes ágeis é o desenvolvimento de objetos de aprendizagem. Os objetos de aprendizagem podem ser definidos como qualquer recurso digital que pode ser reusado para assistir a aprendizagem (WILEY 2001), e podem ser encarados como materiais importantes no processo de ensino e aprendizagem, pois fornecem a capacidade de simular e animar fenômenos, entre outras características, assim como, reutilizá-los em vários outros ambientes de aprendizagem. (SANTOS; FLORES; TAROUCO, 2007). Scarpa (2011) diz que: "o caminho mais indicado para identificar os saberes dos estudantes é propor situações-problema, desafios que os obriguem a mobilizar o conhecimento que possuem para resolver determinada tarefa". Baseando-se nessa

16 17 descrição, é possível utilizar o objeto de aprendizagem com o propósito de ilustrar determinadas situações, como por exemplo matérias de cursos à distância, cursos sobre programação de software, e até mesmo a simular práticas do desenvolvimento de sistemas, com o intuito de oferecer aos alunos, experiências mais próximas da realidade.

17 PROBLEMATIZAÇÃO 1.2 FORMULAÇÃO DO PROBLEMA Conforme as organizações tornam-se cada vez mais dependentes de softwares, ficam mais evidentes os problemas que ocorrem no processo de desenvolvimento de sistemas: alto custo, alta complexidade, disparidade entre as necessidades do cliente e o produto final e a dificuldade de manutenção no sistema (SOMMERVILLE, 2003). Considerando que o processo utilizado é um dos principais motivos para a ocorrência dos incidentes citados anteriormente, um segmento da engenharia de software defende a adoção de processos mais simplificados, conhecidos como métodos ágeis (FOWLER, 2001). As metodologias ágeis têm evoluído cada vez mais, o número de adeptos está crescendo e, consequentemente, está se tornando cada vez mais comum no desenvolvimento de software. No contexto de testes de software, as metodologias são consideradas vitais para garantir que erros de implementação não sejam identificados apenas pelos usuários, quando o software está totalmente desenvolvido (LEAL, 2009). Segundo Herschmann (2010), não há dúvidas que nos próximos anos profissionais de teste e organizações que desenvolvem software como um todo, sofrerão aumento de pressão para conseguirem testar melhor e mais rápido. A utilização de processos ágeis é uma tentativa de conseguir isso. A aplicação das metodologias ágeis não é tão fácil quanto explicada nos livros e nem tão difícil quanto pregam alguns adeptos das metodologias tradicionais. Para uma empresa aplicar um processo ágil, é necessário fazer diversas modificações no processo de desenvolvimento e na cultura da empresa (HABIB, 2012). Entretanto, conforme a pesquisa realizada e descrita na seção de trabalhos similares, não foi identificado objetos de aprendizagem que sejam focados especificamente em testes de software no contexto de metodologias ágeis. Por isso, o trabalho apresenta uma solução para o ensino de testes de software através de um objeto de aprendizagem.

18 Solução Proposta Com o objetivo de contribuir para a solução dos problemas expostos na seção anterior, foi proposto neste projeto a utilização de um objeto de aprendizagem para o ensino de teste de aceitação em um ambiente que utiliza a metodologia ágil Scrum. Existem muitos fatores que favorecem o uso dos objetos de aprendizagem na área educacional como: flexibilidade, customização, fácil e rápida atualização de dados e conteúdos, interoperabilidade e o aumento do valor de um conhecimento (LONGMIRE, 2001). O objeto de aprendizagem desenvolvido nesse projeto oferece ao aluno a experiência de trabalhar em uma equipe ágil, contribuindo para o aprendizado do aluno no sentido de conhecer os conceitos, as boas práticas e o ambiente de uma organização que utiliza o Scrum. Além de obter o conhecimento sobre a metodologia ágil, o aluno aprende técnicas sobre a aplicação de testes de aceitação Objetivo Geral Desenvolver um objeto de aprendizagem para simular os testes de software com ênfase em testes de aceitação, em um ambiente que utiliza a metodologia ágil Scrum Objetivos Específicos Os objetivos específicos são: 1. Estudar e identificar conceitos da metodologia Scrum; 2. Estudar conceitos e práticas relacionadas a teste de software em metodologias ágeis; 3. Estudar os conceitos sobre objetos de aprendizagem; 4. Analisar iniciativas para apoio ao ensino de teste de software; 5. Elaborar a especificação do objeto de aprendizagem; 6. Realizar a produção do objeto de aprendizagem de acordo com a modelagem e especificação desenvolvida; 7. Testar e validar o objeto de aprendizagem; e 8. Realizar uma avaliação do objeto de aprendizagem com alunos.

19 METODOLOGIA A metodologia usada para o desenvolvimento deste trabalho é composta das seguintes etapas: Primeria Etapa: 1) Pesquisa bibliográfica: para proporcionar uma sólida base para o desenvolvimento do projeto e para atender aos objetivos específicos 1, 2 e 3 foi realizada uma pesquisa bibliográfica relacionados aos temas Scrum, testes de software e objetos de aprendizagem, em livros de engenharia de software, livros direcionados apenas a testes de software ou metodologias ágeis, e livros sobre objetos de aprendizagem, assim como publicações científicas. 2) Trabalhos correlatos: Realizou-se uma pesquisa respeitando um protocolo de busca definido especificamente para a busca de projetos e ferramentas que ensinam testes de software. Após, foi realizado um mapeamento para identificar e analisar os trabalhos correlatos e compará-los com o objeto de aprendizado proposto nesse projeto. 3) Planejar o objeto de aprendizagem: Após a fundamentação teórica e a pesquisa dos trabalhos correlatos foi necessário fazer um planejamento adequado para o desenvolvimento do objeto de aprendizagem. Esta etapa contemplou as seguintes atividades: a) Definição e elaboração dos conteúdos que são abordados no objeto de aprendizagem, com base nas etapas anteriores de fundamentação teórica; b) Elaboração do design instrucional dos objetos de aprendizagem baseado no padrão de matriz instrucional proposta por Filatro (2008); e c) Criação da prototipação das telas, com o conteúdo abordado no objeto de aprendizagem. Além do protótipo, o diagrama de atividades, descrevendo o fluxo das telas e o diagrama de entidade e relacionamento.

20 21 Segunda Etapa: 1) Produção: Desenvolvimento do objeto de aprendizagem, completando o objetivo específico 6. a) Desenvolvimento do objeto de aprendizagem levando em consideração o planejamento elaborado conforme a matriz de design instrucional, os protótipos das telas, os diagramas de atividades e entidade-relacionamento, propostos na primeira etapa desse projeto; e b) Execução de testes no objeto de aprendizagem, aplicando as técnicas de testes conhecidas, com o objetivo de encontrar defeitos e melhorar a qualidade do objeto desenvolvido. 2) Avaliação do objeto de aprendizagem: Avaliar o objeto de aprendizagem através de um questionário, atendendo ao objetivo específico 7. Esta etapa contou com a execução das seguintes atividades: a) Disponibilização do objeto de aprendizagem para a execução de testes e avaliação, a ser realizado por profissionais de TI ou alunos de computação, que possuam conhecimento básico sobre testes de software. b) As respostas obtidas através do questionário foram analisadas e transferidas para gráficos, com a finalidade de facilitar a visualização e o acompanhamento dos resultados. 1.4 ESTRUTURA DO TRABALHO Este trabalho está estruturado em quatro capítulos, sendo que o Capítulo 1 apresenta uma introdução aos testes de software em metodologias ágeis. O Capítulo 2 apresenta toda a fundamentação teórica necessária para o entendimento e contextualização do trabalho. No Capítulo 3, são apresentados trabalhos correlatos, e um quadro com o resultado das comparações das ferramentas pesquisadas. No quarto capítulo é apresentado o planejamento para o desenvolvimento do objeto de aprendizagem. Para o planejamento de conteúdos foi

21 22 utilizada a matriz de design instrucional, e foi criado o diagrama de atividades. Também nesse capítulo é informada a linguagem de programação utilizada, o banco de dados, o diagrama de entidade-relacionamento, e por fim a descrição de todas as telas criadas para simular o aluno atuando em uma empresa que utiliza a metodologia Scrum. O capítulo 5 refere-se a avaliação do questionário aplicado com alunos de computação ou profissionais de TI, e os resultados obtidos através dessa pesquisa. Por fim, o sexto capítulo apresenta uma conclusão sobre o desenvolvimento e resultados obtidos em relação ao projeto.

22 23 2 FUNDAMENTAÇÃO TEÓRICA 2.1 SCRUM O nome Scrum vem do jogo de rugby, esporte semelhante ao futebol, com bola oval e jogado com as mãos. No rugby, o Scrum é utilizado para a reposição da bola, após alguma falta ou penalidade. Oito jogadores de cada equipe posicionamse frente à frente, formando um círculo, e então um jogador da equipe que não cometeu a infração lança a bola no espaço entre os jogadores alinhados que tentam, com os pés, ganhar a bola, e para isso, o grupo deve trabalhar em conjunto, por isso o nome da metodologia (SCHWABER, 2009). Scrum é uma metodologia ágil de gerenciamento de projetos, que permite respostas rápidas em relação às mudanças, reduzindo o impacto das alterações nos projetos, permitindo inclusive mudanças tardias nos requisitos ou no escopo do projeto, diminuindo o impacto que essas alterações poderiam causar (SCHWABER, 2009). O Scrum pode ser utilizado sempre que um grupo de pessoas precise trabalhar em conjunto para atingir um objetivo comum, desde o gerenciamento de projetos de software até tarefas do cotidiano, como organizar uma festa. Uma grande vantagem do Scrum, é a entrega constante de funcionalidades, melhorando a satisfação do cliente, e o tornando mais participativo no projeto, permitindo que o cliente traga seu conhecimento sobre o próprio negócio. As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade. Entre duas a quatro semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um Sprint (COHN, 2009). Na Figura 1 pode-se observar o ciclo de vida da metodologia. A figura ilustra as atividades realizadas entre os papéis, os artefatos e os eventos da metodologia Scrum.

23 24 Figura 1. Ciclo de vida da metodologia Scrum Fonte: Agile for All, Nos processos é fundamental que os papéis, artefatos e as atividades sejam bem definidas. Portanto, nas próximas seções são descritas as principais características dos papéis, artefatos e atividades, contextualizando a utilização, aplicação e geração desses itens na metodologia Scrum Papéis Os papéis no Scrum são Product Owner, Scrum Master e Scrum Team. O Product Owner é responsável pelo gerenciamento do Backlog do produto, e por garantir o valor do trabalho realizado pelo Team. É o Product Owner que mantém o Backlog do produto, garantindo que esteja visível e acessível a todos os envolvidos no projeto. Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões, e ninguém tem a permissão de dizer ao Team para trabalhar em um outro conjunto de prioridades. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do produto. Essa visibilidade

24 25 requer que o Product Owner faça seu melhor, e quem desempenha esse papel no projeto deve ser exigente e recompensador ao mesmo tempo (SCHWABER, 2009). O Scrum Master é o responsável por garantir que o Team Scrum esteja seguindo corretamente as práticas e regras da metodologia Scrum, auxiliando na organização, educação e no treinamento do Team, para que a equipe seja mais produtiva ao desenvolver os produtos, agregando mais valor e qualidade no resultado final. O Scrum Master ajuda o Team Scrum a entender e usar o autogerenciamento e a interdisciplinaridade, portanto, o papel do Scrum Master não é gerenciar a equipe, porque o Team Scrum é auto-organizável (SCHWABER, 2009). O Team, também chamado de equipe, é composto por um conjunto de pessoas que possui a responsabilidade de desenvolver e entregar os Sprints. Deve possuir as seguintes características: disciplina, autogerenciamento e comprometimento com um objetivo comum. Geralmente a equipe é formada por um número pequeno de pessoas (MARÇAL; PEREIRA; TORREÃO, 2008) Artefatos Os artefatos definidos para o Scrum são projetados com o objetivo de maximizar a transparência das informações necessárias para assegurar que o Scrum Team tenha sucesso na entrega de um Sprint (SCHWABER, SUTHERLAND, 2011). O Product Backlog é uma lista que contém todas as funcionalidades estabelecidas para um determinado produto, e o conteúdo dessa lista é definido pelo Product Owner. Os itens do Product Backlog podem ser adicionados ou alterados conforme a necessidade e a evolução do projeto, ou seja, podem ser incrementadas novas funcionalidades à medida que se tem melhor conhecimento do produto, suas aplicações e as expectativas dos interessados pelo projeto (SCHWABER; SUTHERLAND, 2011).

25 26 Outros artefatos do Scrum são as User Stories, para a descrição e definição dos requisitos do sistema. As descrições podem ser extensas e detalhadas, ou apenas conter o que é mais relevante para a implementação (SUTHERLAND, 2011). Normalmente contém informações suficientes para que os desenvolvedores possam produzir uma estimativa razoável do esforço necessário para o desenvolvimento da estória (AMBLER, 2012). O foco de uma User Story é fornecer, para a equipe de desenvolvimento, informações pertinentes ao projeto de maneira simples e objetiva. A Figura 2 representa um cartão de User Story, contendo informações como o título, breve descrição, prioridade, estimativa de tempo para sua implementação e a listagem de tarefas necessárias para o desenvolvimento da estória. (NAUMOVICH, 2007). Figura 2 - Exemplo de User Story Fonte: BENITTI (2011). O Sprint Backlog é um conjunto de itens do Product Backlog selecionados para a Sprint. É uma previsão da equipe de desenvolvimento sobre quais funcionalidades estarão no próximo incremento e do trabalho necessário para entregar essas funcionalidades. Resumidamente, no Sprint Backlog constam as