SISTEMA DE GESTÃO DE PROJETOS BASEADOS EM SCRUM

Transcrição

1 UNIVERSIDADE ANHEMBI MORUMBI MAGDA SHARON OKUMURA ROSA NATÁLIA MENEGHESSO NEVES AGUIAR RODRIGO MEDEIRO ALVES RODRIGO SAVAZZI ANNUNCIATO WILLIAN FRANCO DE OLIVEIRA DE LIMA SISTEMA DE GESTÃO DE PROJETOS BASEADOS EM SCRUM São Paulo 2011

2 MAGDA SHARON OKUMURA ROSA NATÁLIA MENEGHESSO NEVES AGUIAR RODRIGO MEDEIRO ALVES RODRIGO SAVAZZI ANNUNCIATO WILLIAN FRANCO DE OLIVEIRA DE LIMA SISTEMA DE GESTÃO DE PROJETOS BASEADOS EM SCRUM Trabalho de Conclusão Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas da Informação da Universidade Anhembi Morumbi. Orientador: Dr. Renato Luís de Souza Dutra São Paulo 2011

3 MAGDA SHARON OKUMURA ROSA NATÁLIA MENEGHESSO NEVES AGUIAR RODRIGO MEDEIRO ALVES RODRIGO SAVAZZI ANNUNCIATO WILLIAN FRANCO DE OLIVEIRA DE LIMA SISTEMA DE GESTÃO DE PROJETOS BASEADOS EM SCRUM Trabalho de Conclusão Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas da Informação da Universidade Anhembi Morumbi. Aprovado em Prof. Universidade Anhembi Morumbi Prof. Universidade Anhembi Morumbi Prof. Universidade Anhembi Morumbi

4 Dedicamos este trabalho aos nossos pais que nos ensinaram o valor da sabedoria e nos ajudaram a encontrar nossos caminhos.

5 AGRADECIMENTOS Aos nossos familiares e amigos, que sempre estiveram presentes nos momentos mais difíceis e sempre nos incentivaram a prosseguir para a conclusão deste curso. Ao nosso orientador, Dr. Renato Luís de Souza Dutra, por sua dedicação e conhecimento durante todas as fases deste trabalho. Aos professores que ao longo desses anos colaboraram para a nossa formação profissional.

6 "Aprender é mudar posturas" (Platão).

7 RESUMO O desenvolvimento de software é considerado uma atividade complexa e que pode ter problemas em projetos, relativos à orçamento, cronogramas não cumpridos, funcionalidades incompletas e baixa qualidade causando a insatisfação do cliente. Todos esses problemas são causados principalmente por falhas no gerenciamento de processos. Na busca para atingir melhores resultados e ter um gerenciamento eficiente, as empresas estão adotando metodologias ágeis no desenvolvimento de software, que possuam maior flexibilidade a mudanças e que ofereçam maior interação entre o cliente e o desenvolvedor. Existem diversos métodos ágeis que propõem a diminuição na burocracia do desenvolvimento de software e busca um melhor equilíbrio entre prazo, custo e qualidade durante o desenvolvimento de um projeto. Neste sentido, este trabalho apresenta o uso da metodologia Scrum, aplicada ao gerenciamento das atividades e desenvolvimento de software. Além disso foi desenvolvido uma ferramenta WEB, que implementa o Scrum, oferecendo um gerenciamento de projetos ágil e flexível. PALAVRAS CHAVE: Scrum. Desenvolvimento de Software. Gerenciamento de Projetos. Métodos Ágeis.

8 ABSTRACT The software development is considered a complex activity that may have problems in projects related to budget, timelines not fulfilled, incomplete functionalities and low quality causing unhappiness to their clients. All of these problems are caused specially by failures in the process management. In order to achieve better results and to have an efficient management, the companies are adopting agile methodologies in software development, which have higher flexibilities to changes and that offer higher interaction between the client and the developer. In the current market, there are several agile methods that offer to decrease the bureaucracy in the software development and the increase of quality not only in the software, but also in the project. This way, this work presents the use of the Scrum methodology that can be applied in the activities management and in the development of new products, besides the development of a WEB tool, which implements the Scrum, offering a flexible and agile projects management. KEY WORDS: Scrum. Software Development. Project Management. Agile Methods.

9 LISTA DE FIGURAS Figura 1: O modelo cascata Figura 2: O paradigma da prototipação Figura 3: Desenvolvimento incremental Figura 4: Modelo espiral típico Figura 5: Os modelos incremental e iterativo Figura 6: Cartoon Porco e Galinha Figura 7: Gráfico de Burndown Figura 8: Variáveis de uma estória Figura 9: Exemplo da divisão de uma estória em outras menores Figura 10: Exemplo da divisão de uma estória em tarefas Figura 11: Baralho do Planning Poker Figura 12: Quadro de Tarefas Figura 13: Fluxo do Scrum Figura 14: Diagrama de Casos de Uso Figura 15: Diagrama de Classes Figura 16: Modelo Conceitual Figura 17: Tela Novo Projeto Figura 18: Tela Login Figura 19: Tela Colaboradores Figura 20: Tela Cadastrar Colaborador Figura 21: Tela Projetos Figura 22: Tela Criar Projeto Figura 23: Tela Listar Sprints Figura 24: Tela Criar Sprint Figura 25: Tela Listar User Stories Figura 26: Tela Definir User Story Figura 27: Tela Listar Tasks Figura 28: Tela Definir Task Figura 29: Tela Listar Apontamento de Horas Figura 30: Tela Editar Apontamento Figura 31: Tela Gráficos de progresso da Sprint Figura 32: Tela Gráfico de Acompanhamento do Colaborador... 73

10 Figura 33: Tela Relatório de Métricas da Sprint Figura 34: Tela Projetos Figura 35: Tela Novo Projeto Figura 36: Tela Sprints Figura 37: Tela Criar Sprint Figura 38: Tela User Stories Figura 39: Tela Definir User Story Figura 40: Tela Tasks Figura 41: Tela Definir Tasks Figura 42: Tela Colaboradores Figura 43: Tela Novo Colaborador... 99

11 LISTA DE GRÁFICOS Gráfico 1: Chaos Report Gráfico 2: Custos de alterações como uma função do tempo em desenvolvimento. 31

12 LISTA DE TABELAS Tabela 1: Modelos Tradicionais Tabela 2: Duração dos Time-Boxes Tabela 3: Exemplo de um Product Backlog Tabela 4: Análise Comparativa de Ferramentas Tabela 5: Matriz de Rastreabilidade... 56

13 LISTA DE ABREVIATURAS E SIGLAS API Application Programming Interface (Interface de Programação de Aplicações) JavaEE Java Platform, Enterprise Edition (Java Edição Empresarial) JSP JavaServer Pages MVC Model View Controller (Modelo, Visão e Controle) OOPSLA Object-Oriented Programming, Systems, Languages & Application (Programação Orientada a Objetos, Sistemas, Linguagens e Aplicativos) PO Product Onwer (Dono do Produto) RIA Rich Internet Application (Aplicações de Internet Rica) SM ScrumMaster UML Unified Modeling Language (Linguagem de Modelagem Unificada) WEB World Wide Web (Rede de alcance mundial) XP Extreme Programming (Programação Extrema)

14 SUMÁRIO 1 INTRODUÇÃO OBJETIVO JUSTIFICATIVA ABRANGÊNCIA ESTRUTURA DO TRABALHO CONCEITOS E TECNOLOGIA CONCEITOS DE GERENCIAMENTO DE PROJETOS PROCESSO DE SOFTWARE Modelo cascata Modelo de prototipação Modelo incremental Modelo espiral Vantagens e desvantagens dos Modelos de Processos DESENVOLVIMENTO TRADICIONAL DESENVOLVIMENTO ÁGIL Manifesto Ágil Equipe Ágil PROCESSO ÁGIL DE SOFTWARE Programação Extrema (XP) SCRUM Papéis Time-Boxes Artefatos User Stories e tarefas Ferramentas e métodos Fluxo do Scrum Principais Ferramentas Disponíveis METODOLOGIA SCRUM-BOX: SISTEMA DE GESTÃO DE PROJETOS ANÁLISE DOS REQUISITOS Requisitos funcionais Requisitos não funcionais... 56

15 4.1.3 Matriz de Rastreabilidade DIAGRAMA DE CASO DE USO Descrição dos atores DIAGRAMA DE CLASSES PROJETO DE BANCO DE DADOS Modelo Conceitual DESENVOLVIMENTO TECNOLOGIAS UTILIZADAS EVOLUÇÃO DO PROJETO RESULTADO FINAL CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A CASOS DE USO APÊNDICE B WIREFRAMES ANEXO A - MANIFESTO PARA O DESENVOLVIMENTO ÁGIL ANEXO B - PRINCÍPIOS POR TRÁS DO MANIFESTO ÁGIL ANEXO C - CAMPOS ADICIONAIS DA ESTÓRIA

16 16 1 INTRODUÇÃO A cada dia que passa, o mercado fica mais competitivo e a utilização de um software está desempenhando um papel importante para ajudar a alcançar o sucesso dentro das organizações. Com a globalização, a concorrência vem aumentando cada vez mais e com isso as organizações necessitam ter um diferencial competitivo. Dentro do cenário de desenvolvimento de software, as fábricas de software, consultorias e até mesmo empresas com desenvolvimento próprio vêm enfrentando diversos problemas, como a entrega de produtos de baixa qualidade, aumento dos custos previstos e atrasos na entrega do projeto. Esses problemas são causados por falhas no gerenciamento, falta de processos bem definidos e oferecem grandes riscos para as empresas. O ambiente de desenvolvimento de software está aberto para a introdução de novas metodologias que podem trazer melhorias. Diferentes abordagens vêm sendo introduzidas nesses últimos anos e entre elas, as metodologias ágeis vêm sendo destacadas pelas respostas rápidas de acordo com as exigências e a simplificação do desenvolvimento do software com mais agilidade do que modelos tradicionais. As organizações estão tendo algumas dificuldades na implantação desses métodos de desenvolvimento. O grande problema encontrado é a dificuldade comportamental para a assimilação e aceitação das mudanças. A queda de produtividade é outra dificuldade enfrentada devido ao fato dos profissionais estarem acostumados com a mesma maneira de realizar as atividades. A metodologia deve ser totalmente assimilada por todos os envolvidos no projeto para que a mesma seja corretamente implantada e seja útil na melhoria dos processos. Além disso, mesmo que a metodologia seja totalmente compreendida pelos envolvidos no projeto, as organizações não têm conscientização da importância de ter um software que auxilie no gerenciamento de projeto baseado no Scrum. Com um software conceituado, o mesmo poderá ajudar as organizações a gerenciar e controlar tarefas do projeto, acompanhar todo o progresso do desenvolvimento dessas tarefas e oferecer relatórios, que são de extrema importância para obtenção de conclusões e tomada de decisões. A implantação do Scrum e um software de gerenciamento de projetos, baseado nessa metodologia, podem ajudar na melhoria dos processos e contribuirão

17 17 para as organizações obter bons resultados e alcançar os seus objetivos. 1.1 OBJETIVO A proposta deste trabalho é desenvolver um sistema para suportar o gerenciamento de projetos ágeis utilizando o Scrum, com foco na simplicidade e usabilidade, suprindo necessidades como apoio a equipes remotas, geração automática de gráficos, obtenção de históricos, facilitando assim a utilização do Scrum. Este sistema será utilizado pela equipe do projeto, desenvolvedores, arquitetos, designers, gerentes e clientes, assim centralizando as informações do projeto, permitindo um controle mais minucioso e possibilitando a extração de relatórios, muito valiosos para avaliação do desenvolvimento do projeto atual ou mesmo para projetos futuros. Serão estudados os conceitos de gerenciamento de projetos que são de extrema importância para o entendimento da metodologia Scrum. 1.2 JUSTIFICATIVA Dentro do cenário atual, o trabalho buscou motivação nas empresas do setor de desenvolvimento de softwares, que não utilizam qualquer ferramenta ou metodologia ágil e que utiliza metodologia tradicional para apoiar no gerenciamento do projeto. O problema da falta de padronização para controlar a equipe pode ocasionar uma descentralização de informações, o que é prejudicial para o resultado esperado pelas organizações, tendo em vista que muitas atividades estão interligadas. Esse ponto pode impactar diretamente na produtividade da equipe e o fato do escopo do projeto ter a possibilidade de alteração, isso poderá fazer com que o planejamento e o desenvolvimento sejam desperdiçados, comprometendo o orçamento do projeto e o resultado esperado. Visando atingir os melhores resultados e diminuir a ocorrência de riscos, o trabalho apresenta um software para ajudar no gerenciamento de projetos baseado na metodologia Scrum. A idéia do software é agregar mais valor ao Scrum. Será utilizado pelo Time e

18 18 pelos outros envolvidos no projeto e centralizará as informações, permitindo um controle mais detalhado e possibilitando a extração de relatórios, muito valiosos para avaliação da execução do projeto atual ou mesmo para projetos futuros. Visando a melhoria dos processos, o software desempenhará um papel essencial para ajudar a evitar os problemas relacionados a processos enfrentados pelas organizações e ajudar na diminuição dos riscos dentro do desenvolvimento do projeto. 1.3 ABRANGÊNCIA O trabalho apresenta detalhadamente os conceitos do desenvolvimento ágil. O trabalho não tem o objetivo de abordar o desenvolvimento tradicional em detalhes ou apresentar os vários métodos de processo ágil de software. Além disso, não serão descritas pesquisas para comprovar a eficácia do Scrum e outros métodos ágeis. O projeto também visa o desenvolvimento de um sistema WEB ou World Wide Web (Rede de alcance mundial) para gerenciamento de projetos, baseado na metodologia ágil Scrum. O sistema tem como finalidade projetar melhorias no processo de desenvolvimento, tais como: comunicação direta e sem falhas, interatividade, independência e transparência na tomada de decisões, análise de resultados e otimização da produção da equipe de forma sustentável. 1.4 ESTRUTURA DO TRABALHO Esse trabalho será dividido em quatro capítulos, incluindo este introdutório. Os próximos capítulos têm o objetivo de apresentar as metodologias ágeis juntamente com o trabalho desenvolvido. Capítulo 2: Conceitos e Tecnologia: Este capítulo aborda sobre os conceitos de gerenciamento de projetos, sobre a forma como os sistemas são desenvolvidos tradicionalmente, os principais problemas do desenvolvimento tradicional, uma pesquisa que mostra as falhas e sucesso nos projetos de software e as mudanças propostas pela filosofia do desenvolvimento ágil de software. Além disso, apresenta uma visão geral da Programação Extrema (Extreme Programming) e uma visão detalhada sobre o Scrum, apresentando uma análise comparativa de algumas ferramentas que utilizam essa metodologia.

19 19 Capítulo 3: Metodologia: Este capítulo aborda a forma de como o sistema será desenvolvido e detalha as tecnologias que serão utilizadas. Também apresenta as necessidades que o nosso grupo obteve para o desenvolvimento do sistema e as descrições de todas as tarefas com as suas respectivas estimativas, status e observações. Capítulo 4: SCRUM-BOX: Sistema de Gestão de Projetos: Este capítulo apresenta todo o levantamento de requisitos e a modelagem para o desenvolvimento do software para gerenciamento de projetos baseado na metodologia Scrum. Capítulo 5: Desenvolvimento: Este capítulo apresenta as tecnologias utilizadas no desenvolvimento do sistema. Conclusão: Apresenta a conclusão do trabalho juntamente com as considerações finais e as ideias sobre trabalhos futuros.

20 20 2 CONCEITOS E TECNOLOGIA Os softwares de computadores estão presentes em todos os aspectos de nosso cotidiano, mesmo sem se fazer notar. Por essa razão, a engenharia de software e suas boas práticas devem assegurar que o software tenha uma contribuição positiva em nossas vidas (PFLEEGER, 2004). Conforme aumenta a importância do software, aumentam também as tentativas de desenvolver tecnologias que tornem mais fácil, rápido e barato desenvolver e manter softwares de alta qualidade. Nas seções seguintes são discutidas estruturas que podem ser utilizadas por aqueles que desenvolvem software e os que gerenciam o desenvolvimento. 2.1 CONCEITOS DE GERENCIAMENTO DE PROJETOS O desenvolvimento de um software pode ser considerado uma atividade complexa, principalmente se envolver uma equipe grande e ter uma duração longa. Por essa razão, o gerenciamento de projetos é necessário (PRESSMAN, 2011). Gerenciamento de projeto envolve planejamento, monitoração e controle de pessoas, processos e eventos que ocorrem à medida que o software evolui desde os conceitos preliminares até a sua disponibilização, operacional e completa (PRESSMAN, 2011, p.566). O trabalho de um gerente de projeto de software é garantir que o projeto atenda às necessidades do cliente dentro do prazo e orçamento estimados. Os gerentes de software são responsáveis pelo planejamento e pelo cronograma do projeto. Além disso, os gerentes devem supervisionar todo o trabalho e monitorar o progresso do projeto, assegurando assim que ele esteja sendo realizado dentro dos padrões exigidos e no prazo estimado (SOMMERVILLE, 2007). Pressman (2011, p. 567) afirma que o Gerenciamento efetivo de desenvolvimento de software tem foco nos 4 Ps: Pessoas, produto, processo e projeto. Essa ordem não é arbitrária.

21 21 Entende-se por pessoas, as pessoas que fazem parte do projeto, como gerentes, desenvolvedores, clientes, usuários, líderes e os demais interessados no desenvolvimento do software. Para essas pessoas serem efetivas nos seus trabalhos, elas precisam ser gerenciadas. O produto possui escopo e objetivos, e para que estes sejam entendidos é preciso boa comunicação com o cliente. O escopo identifica os principais dados, funções e comportamentos que caracterizam o produto. Os objetivos identificam as metas gerais do produto. Um processo de software fornece um roteiro que permite que um plano de projeto possa ser estabelecido. É preciso escolher um modelo de processo mais apropriado para o cliente que solicitou o produto e para o pessoal que executará o trabalho. O projeto precisa ser planejado com base na estimativa do esforço e do prazo para a realização das tarefas. Uma vez criado o plano de projeto, é preciso monitorar e controlar o projeto e seus envolvidos (PRESSMAN, 2011). Um bom gerenciamento não pode garantir o sucesso de um projeto. No entanto, um mau gerenciamento geralmente resulta em falha do projeto: o software é entregue com atraso, custa mais do que foi originalmente estimado e falha ao atender seus requisitos (SOMMERVILLE, 2007, p.61). O Standish Group International, empresa de consultoria e pesquisa, publica desde 1994 um estudo intitulado Chaos Research, conhecido também como Chaos Report, que consolida informações de pesquisas sobre os resultados dos projetos de software. Neste estudo, segundo o Standish Group, os resultados podem ser definidos em (TELES, 2004): Sucesso: o projeto é finalizado dentro do prazo e orçamento e contém todas as funcionalidades especificadas. Mudaram: o projeto é finalizado, porém com prazo e orçamento fora do planejado, além de disponibilizar menos funcionalidades que o especificado. Falharam: o projeto é cancelado em algum momento durante o ciclo de desenvolvimento ou não é implementado.

22 22 Gráfico 1: Chaos Report. Fontes: CASAGRANDE; GERA (2011) (Adaptado) Ao analisar os resultados desse estudo, conforme ilustrado no Gráfico 1, observa-se que mais da metade dos projetos não atinge o grau de sucesso como era esperado. A maioria dos projetos são entregues, porém com prazos e orçamentos fora do planejado e/ou escopo reduzido. Uma minoria, porém importante, parte dos projetos falham, sendo cancelados ou não utilizados. Esse estudo demonstra a importância de um bom planejamento. Para gerenciar um projeto de software com sucesso, deve-se compreender o que pode sair errado, de modo que ações planejadas evitem tais problemas (PRESSMAN, 2011, p. 577). 2.2 PROCESSO DE SOFTWARE Um processo de software é definido como uma sequencia de atividades e feedbacks que resultam no desenvolvimento ou na evolução de um software. As atividades são necessárias para especificar, projetar e testar o software que está sendo desenvolvido. O feedback dessas atividades mostra o que é necessário para se desenvolver o software (PETERS; PEDRYCZ, 2001). São propostos vários e diferentes processos de software para a engenharia de software, porém a maioria utilizam quatro atividades básicas: especificação, desenvolvimento, validação e evolução. A especificação define as funcionalidades

23 23 e restrições do software. O desenvolvimento acontece quando o software é produzido atendendo as especificações. A validação garante que o software atende o que o cliente deseja. A evolução define que o software evolua para se adaptar às mudanças dos requisitos do cliente e do mercado (SOMMERVILLE, 2007). Um processo de software não é uma prescrição rígida de como desenvolver um software, ao contrário, é uma abordagem que pode ser adaptada, possibilitando à equipe de software selecionar e escolher o conjunto apropriado de ações e tarefas, que possibilite entregar o software dentro do prazo e com qualidade suficiente para satisfazer o cliente e o usuário final (PRESSMAN, 2011). Os processos são importantes porque imprimem consistência a estrutura a um conjunto de atividades. Essas características são úteis quando sabemos como fazer algo bem e queremos garantir que outras pessoas o façam da mesma maneira (PFLEEGER, 2004, p.37). Um modelo de processo de software representa, de forma mais simples, um processo de software. Cada modelo de processo representa um processo sob determinada perspectiva, fornecendo somente informações parciais sobre esse processo (SOMMERVILLE, 2007). A elaboração desses modelos atingiu um estágio maduro ao longo do tempo, baseado no conhecimento e na experiência adquirida após a execução de vários projetos de software em grande escala. Mesmo assim, esses modelos continuam a ser estudados intensivamente (PETERS; PEDRYCZ, 2001). Existem diversos modelos de processos que podem ser definidos e ajustados de acordo com as necessidades dos usuários, clientes e desenvolvedores (PFLEEGER, 2004). Nas próximas seções são discutidos o modelo cascata, o modelo de prototipação, o modelo incremental e o modelo espiral, que são a base para o entendimento dos modelos de processos ágeis, discutidos na seção 2.5 PROCESSO ÁGIL DE SOFTWARE.

24 Modelo cascata Também conhecido como ciclo de vida clássico, esse modelo é o mais antigo da engenharia de software. Ele sugere uma abordagem sequencial para o desenvolvimento, onde uma atividade somente iniciará depois que a atividade anterior estiver concluída sem pendências e aprovada. Segundo Sommerville (2007, p.38), Em princípio, o resultado de cada fase consiste de um ou mais documentos aprovados (assinados). Nesta abordagem, ilustrada na Figura 1, o projeto é iniciado e as funções, restrições e objetivos do sistema são definidos pelo cliente. Em seguida a fase de planejamento é iniciada e são feitas estimativas de acordo com o levantamento de requisitos. Na modelagem inicia-se o projeto, que é documentado. Na fase de construção os programas que fazem parte do software são codificados e testados respectivamente. Por fim, é feita a implantação, onde o software é liberado para utilização, treinamento e suporte contínuo em produção (PRESSMAN, 2011). Figura 1: O modelo cascata. Fonte: PRESSMAN (2011) O modelo em cascata apresenta uma visão conceitual de alto nível de como será o desenvolvimento do software e sugere aos desenvolvedores a sequencia de eventos que eles encontrarão (PFLEEGER, 2004). As vantagens desse modelo consistem na documentação produzida em cada fase e por ser aderente a outros modelos de processos. O modelo em cascata é ótimo em um cenário onde os requisitos sejam bem definidos e que não exista o risco de serem alterados (SOMMERVILLE, 2007). Muitos problemas no modelo em cascata tem sido discutidos na literatura. O maior deles é fato desse modelo não suportar possíveis mudanças durante o desenvolvimento, que são possíveis de acontecerem no cenário real de

25 25 desenvolvimento de software (PFLEEGER, 2004). Outra desvantagem desse modelo é o fato de o cliente ter de esperar até a fase de instalação e liberação para ver como o sistema funciona (PETERS; PEDRYCZ, 2001, p. 41) Modelo de prototipação A prototipação permite que todo o sistema, ou parte dele, seja construído rapidamente para que requisitos obscuros sejam esclarecidos posteriormente, garantindo assim que, desenvolvedor, usuário e cliente cheguem a um consenso comum (PFLEEGER, 2004). Conforme ilustrado na Figura 2, o modelo de prototipação inicia-se com a comunicação, onde os envolvidos reúnem-se para definir os objetivos gerais do software, identificar quais requisitos já são conhecidos e esquematizar as áreas que necessitam de uma definição mais ampla. Em seguida, uma iteração de prototipação é planejada e a modelagem é feita na forma de um projeto rápido. O projeto rápido contém aspectos visíveis para o cliente, como layout da interface. A próxima etapa é a construção de um protótipo, que atua como um mecanismo para identificar os requisitos do software. Depois de entregue, o protótipo é avaliado pelo cliente, que retorna um feedback que é usado para refinar os requisitos do software (PRESSMAN, 2011). Figura 2: O paradigma da prototipação. Fonte: PRESSMAN (2011)

26 26 Nesse modelo os usuários conseguem enxergar um software real e os desenvolvedores conseguem construir algo de imediato. Entretanto, a prototipação pode ser problemática quando o cliente e usuários enxergam o protótipo como uma versão operacional, não aceitando que o software seja reconstruído e solicitando apenas melhorias para torná-lo o produto final. Outro problema é manter escolhas inapropriadas, decididas rapidamente para o desenvolvimento do protótipo, na versão final do produto, comprometendo assim a qualidade do software (PRESSMAN, 2011) Modelo incremental O modelo incremental é um processo que utiliza elementos do modelo em cascata, onde os requisitos são analisados primeiramente, porém, as atividades de desenvolvimento são repetidas cada vez que uma nova versão do software é entregue (PETERS; PEDRYCZ, 2001). Essa abordagem foi sugerida para que o retrabalho seja reduzido no desenvolvimento do software e para proporcionar aos clientes algumas oportunidades de adiar decisões sobre seus requisitos detalhados, até que eles tenham alguma experiência com o sistema (SOMMERVILLE, 2007). O modelo incremental libera uma série de versões, chamada versões incrementais, que oferecem um produto operacional para o cliente à medida que cada incremento é entregue (PRESSMAN, 2011). Os incrementos devem ser pequenos e cuidadosamente selecionados, visando os incrementos futuros (PETERS; PEDRYCZ, 2001, p. 14). Sommerville (2007) explica que nesse modelo, inicialmente é feito um esboço dos requisitos pelos clientes, que contém as funções priorizadas que deverão ser fornecidas pelo software. O próximo passo é definir uma série de estágios de entrega, onde cada estágio contemplará um subconjunto com funcionalidades do software. As funcionalidades com maior prioridade deverão ser entregues primeiramente. Após a identificação dos incrementos, as funcionalidades que os compõem são definidas em detalhes e os incrementos são desenvolvidos. Como segue apresentado na Figura 3:

27 27 Figura 3: Desenvolvimento incremental. Fonte: SOMMERVILLE (2007) Nesse modelo os clientes não precisam esperar a entrega total do software para utilizá-lo, já no primeiro estágio é possível tirar proveito do software, mesmo como um protótipo, pois nele será entregue as funcionalidades mais importantes. Além disso, o risco de falha total é reduzido, pois como as funcionalidades prioritárias são entregues nos primeiros incrementos, e incrementos posteriores são integrados a eles, a quantidade de testes das funcionalidades prioritárias será bem maior, oferecendo mais confiabilidade a eles (SOMMERVILLE, 2007). Um problema desse modelo é que ele parte do princípio irreal que o sistema e seus requisitos não serão alterados, sendo assim, um incremento depois de entregue, não pode ser modificado. Porém, os requisitos tendem a evoluir devido à experiência que o cliente tem ao analisar uma versão operacional do sistema (PETERS; PEDRYCZ, 2001) Modelo espiral O modelo em espiral ao invés de representar o processo de software como uma sequencia de atividades com algum retorno entre elas, representa o processo como uma espiral, onde cada loop consiste em uma fase do processo de software (SOMMERVILLE, 2007). Esse modelo acopla a natureza iterativa da prototipação com aspectos sistemáticos e controlados do modelo cascata, fornecendo potencial para o rápido desenvolvimento de versões cada vez mais completas do software. Nas primeiras iterações, a versão pode consistir em um modelo ou um protótipo, tornando-se assim versões mais completas nas iterações posteriores (PRESSMAN, 2011).

28 28 O modelo espiral, conforme ilustrado na Figura 4, é dividido em um conjunto de atividades indicadas por um circuito em torno da espiral no sentido horário, começando pelo centro. Ao longo do trajeto da espiral, esse conjunto de atividades são realizadas, resultando, por exemplo, no desenvolvimento de uma especificação de produto no primeiro circuito, protótipo no segundo circuito e progressivamente em versões mais sofisticadas do software nos próximos circuitos (PRESSMAN, 2011). Figura 4: Modelo espiral típico. Fonte: PRESSMAN (2011) O modelo espiral pode ser adotado para ser aplicado por todas as atividades da engenharia de software - desde o desenvolvimento de conceitos até a manutenção do sistema no longo prazo (PRESSMAN, 2011) Vantagens e desvantagens dos Modelos de Processos Os diferentes modelos de processos podem possuir vantagens e desvantagens quando vistos de diferentes perspectivas no desenvolvimento ou na evolução de um software. A Tabela 1 apresenta uma análise das principais vantagens e desvantagens dos modelos de processos.

29 29 Tabela 1: Modelos Tradicionais Modelo Vantagens Desvantagens Cascata Prototipação Incremental Espiral Documentação produzida em cada fase e aderência a outros modelos. Protótipo serve como mecanismo a fim de definir os requisitos. Os clientes não precisam esperar a entrega total do software para utilizá-lo. Passagens subsequentes em torno da espiral podem ser usadas para desenvolver um protótipo e depois, versões mais sofisticadas do software. Fonte: OS AUTORES (2011) O modelo não suporta possíveis mudanças durante o desenvolvimento. O cliente pode querer o protótipo como produto final. Parte do princípio irreal que o sistema e seus requisitos não serão alterados, sendo assim, um incremento depois de entregue, não poderá ser modificado. Passagens pela região de planejamento resultam em ajustes ao plano do projeto, custo e cronograma são alterados com base na realimentação dada pelo cliente. 2.3 DESENVOLVIMENTO TRADICIONAL Para que se entendam os conceitos de desenvolvimento tradicional, é preciso ter em mente que o primeiro objetivo do desenvolvimento de software é a construção de sistemas da maneira mais eficaz e eficiente possível e que satisfaça às necessidades de seus usuários (AMBLER, 2004, p.21). O termo desenvolvimento tradicional é usado para descrever projetos de software que se baseiam no desenvolvimento em cascata (TELES, 2004). No desenvolvimento tradicional, a equipe constrói o software avançando gradualmente nas fases do desenvolvimento, permitindo assim, lidar com níveis de complexidade cada vez mais elevados. O determinismo nas atividades costuma estar presente a fim de diminuir erros e perdas de tempo, porém no cenário real, não há como garantir que uma atividade não seja alterada com o tempo. Além disso, a busca pela especialização, nomeando diferentes papéis aos membros da equipe, permite que os mesmos foquem apenas em suas próprias responsabilidades, perdendo assim, a visão geral do software (TELES, 2004). O principal problema deste modelo é sua inflexível divisão do projeto em fases distintas, o que dificulta possíveis alterações que são comuns no desenvolvimento de um projeto. No desenvolvimento tradicional, os custos de mudanças no projeto aumentam de forma não linear conforme o projeto avança, gerando um impacto significativo nos custos ou no tempo (PRESSMAN, 2011).

30 DESENVOLVIMENTO ÁGIL A insatisfação com o desenvolvimento tradicional levou um grupo de desenvolvedores de software na década de 1990 a propor novos processos, chamados de ágeis, que permitiam à equipe de desenvolvimento manter o foco no software, ao invés do projeto e documentação (SOMMERVILLE, 2007). Assim surgiu uma nova abordagem para o desenvolvimento de software, chamada de desenvolvimento ágil. O termo desenvolvimento ágil faz referencia ao desenvolvimento iterativo, em espiral, discutido na seção Modelo espiral. Ele recomenda que todas as fases descritas no modelo em cascata sejam executadas diversas vezes ao longo do projeto, produzindo ciclos que se repetem ao longo de todo desenvolvimento (TELES, 2004, p. 31). O resultado de cada ciclo - chamado de iteração - é um software pronto, testado e aprovado, sendo que a as primeiras iterações possuem poucas funcionalidades enquanto a última contém todas as funcionalidades do software (TELES, 2004). O desenvolvimento de software é considerado uma atividade complexa e os clientes geralmente não estão interessados em participar do processo de desenvolvimento, pois não entendem bem e preferem deixar os detalhes para a equipe (AMBLER, 2004). O desenvolvimento ágil se baseia na premissa que o cliente passa a entender sobre o software e seus detalhes à medida que é capaz de manipulá-lo, observando detalhes, compreendendo dificuldades técnicas, visualizando novas possibilidades, e assim, solicitando alterações para que o software se aproxime ao máximo de seu objetivo, que é resolver os seus problemas (TELES, 2004). No desenvolvimento de software, conforme ilustrado no Gráfico 2, os custos de mudança nos requisitos do software aumentam de forma não linear conforme o projeto avança. Mudanças que ocorrem no levantamento de requisitos são fáceis de serem efetuadas e o custo para isso é baixo. Porém, se isso ocorrer após alguns meses, em fases finais de desenvolvimento, os custos de uma mudança cresce e o cronograma do projeto será afetado. Comparado com o desenvolvimento tradicional, o desenvolvimento ágil tende a otimizar esse fator. (PRESSMAN, 2011).

31 31 Gráfico 2: Custos de alterações como uma função do tempo em desenvolvimento. Fonte: PRESSMAN (2011) No desenvolvimento ágil, a comunicação ativa e contínua entre desenvolvedores e clientes é fundamental. Além disso, é priorizada a satisfação do cliente, equipes pequenas e motivadas, métodos informais e, acima de tudo, simplicidade no desenvolvimento no geral. (PRESSMAN, 2011) Manifesto Ágil Com o objetivo de encontrar soluções para os problemas enfrentados no desenvolvimento de software, um grupo de 17 metodologistas se reuniu e formou em fevereiro de 2001 a Aliança de Desenvolvimento Ágil de Software (Agile Software Development Alliance), também conhecida como Aliança Ágil (Agile Alliance). Esse grupo definiu um manifesto chamado Manifesto para Desenvolvimento Ágil de Software (Manifesto for Agile Software Development) que encorajava melhores meios para o desenvolvimento de software (AMBLER, 2004). No Manifesto para Desenvolvimento Ágil de Software estão declarados valores comuns no desenvolvimento de software e princípios de processos ágeis. Em 2001, Fowler (2001) republicou um artigo sobre metodologias ágeis onde, nesta versão, observou o manifesto como uma publicação que agia como um ponto de partida para aqueles que compartilhavam as mesmas ideias básicas. Ambler (2004, p. 23) sugere que, Uma boa maneira de pensar sobre o manifesto é que ele define preferências, não alternativas, encorajando o enfoque de

32 32 certas áreas, mas sem eliminar outras. O manifesto é definido por quatro simples declarações de valores, que podem ser lidas na íntegra no ANEXO A. A primeira delas, afirma que indivíduos e interações valem mais do que processos e ferramentas. A segunda afirma que um software funcionando vale mais do que uma documentação extensa. A terceira afirma que a colaboração com o cliente é mais valiosa do que a negociação de um contrato. E por fim, a última declaração afirma que responder a mudanças tem mais valor do que seguir um plano. (AMBLER, 2004) Segundo Ambler (2004, p. 24), O interessante dessas declarações de valores é que todos irão concordar com elas imediatamente, mas poucos irão aderir a elas na prática. [...] as pessoas dizem uma coisa e fazem outra. Com o objetivo de ajudar na compreensão do que é o desenvolvimento ágil, os membros da Aliança Ágil refinaram as ideias do Manifesto Ágil em doze princípios (ANEXO B) citados abaixo nas palavras de Pressman (2011, p. 84): 1. A maior prioridade é satisfazer o cliente por meio de entrada adiantada e contínua de software valioso. 2. Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento. Os processos ágeis se aproveitam das mudanças com uma vantagem competitiva na relação com o cliente. 3. Entregue software em funcionamento frequentemente, de algumas semanas para alguns meses, dando preferência a intervalos mais curtos. 4. O pessoal comercial e os desenvolvedores devem trabalhar em conjunto diariamente ao longo de todo o projeto. 5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e apoio necessários e confie neles para ter o trabalho feito. 6. O método mais eficiente e efetivo de transmitir informações para e dentro de uma equipe de desenvolvimento é uma conversa aberta, de forma presencial. 7. Software em funcionamento é a principal medida de progresso. 8. Os processos ágeis promovem desenvolvimento sustentável. Os proponentes, desenvolvedores e usuários devem estar capacitados para manter um ritmo constante indefinidamente. 9. Atenção contínua para com a excelência técnica e para com bons

33 33 projetos aumenta a agilidade. 10. Simplicidade a arte de maximizar o volume de trabalho não efetuado é essencial. 11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam. 12. A intervalos regulares, a equipe se avalia para ver como torna-se mais eficiente, então sintoniza e ajusta seu comportamento de acordo. Esses princípios oferecem uma base para o sucesso no trabalho de desenvolvimento do software e, além disso, eles definem requisitos de alto nível para uma metodologia eficaz (AMBLER, 2004) Equipe Ágil A filosofia ágil enfatiza pequenas equipes de projetos altamente motivadas e que se auto-organizam, chamadas de equipes ágeis. Elas adotam muitas características das equipes de software bem-sucedidas, porém enfatizando competência individual juntamente com a colaboração em grupo (PRESSMAN, 2011). Em equipes ágeis, seus membros estão menos propensos à ociosidade social, caracterizada pela tendência das pessoas se esforçarem menos quando acham que há outras pessoas que assumirão a responsabilidade. Além disso, em uma equipe pequena, as participações e contribuições de seus membros são maiores, sendo mais visíveis e significativas, proporcionando maior satisfação aos membros da equipe (COHN, 2011). As equipes ágeis têm ciência e aceitam os erros cometidos ao longo do projeto, porém, entendem que a melhor maneira de identificar os erros é não pensar no software de maneira teórica, pelo contrário, é pensar nele de forma prática e começar a construí-lo (KNIBERG, 2007). Muitas empresas de desenvolvimento de software estão adotando equipes ágeis, que estão produzindo software com mais qualidade, que atendem melhor às necessidades do usuário, com maior rapidez e um custo menor do que equipes tradicionais (COHN, 2011).

34 PROCESSO ÁGIL DE SOFTWARE Na maioria dos projetos de software, a análise, projeto, desenvolvimento e testes não são tão previsíveis, isso acontece porque é difícil prever quanto de trabalho será necessário e também é difícil garantir quais requisitos de software irão persistir e quais irão sofrer alterações no decorrer do desenvolvimento. Um processo ágil de software é um processo adaptável, capaz de administrar essas imprevisibilidades (PRESSMAN, 2011). Os processos ágeis são chamados também de processos leves (lightweight), pois são menos prescritivos que os processos tradicionais. Prescritivo significa mais regras a seguir, enquanto adaptativo significa menos regras a seguir. Os processos ágeis são menos prescritivos e mais adaptativos (KNIBERG; SKARIN, 2009). Segundo Sommerville (2007), os processos ágeis são adequados para o desenvolvimento de software de pequenas e médias empresas. Eles não são tão adequados para o desenvolvimento em larga escala, equipes em lugares diferentes e onde possa haver iterações complexas com outros sistemas. Além disso, os processos ágeis também não devem ser usados em sistemas críticos, onde é necessária uma análise detalhada de todos os requisitos. Para ilustrar um processo ágil de forma um pouco mais detalhada, será apresentado na seção seguinte, uma visão geral sobre a Extreme Programming (Programação Extrema) e na seção 2.6 SCRUM, será apresentado detalhadamente o Scrum, que são modelos de processos ágeis que se encontram em uso no setor do desenvolvimento ágil e que estão em conformidade (em maior ou menor grau) com Manifesto Ágil e seus princípios Programação Extrema (XP) A Programação Extrema (Extreme Programming), ou XP, é um modelo de processo ágil mais conhecido e mais amplamente usado. Seu nome surgiu devido ao envolvimento do cliente em níveis extremos (SOMMERVILLE, 2007). A XP é baseado em torno de um conjunto de valores e práticas que asseguram que o cliente sempre receba um alto retorno do investimento que teve no software. É indicado para projetos com equipes pequenas que desenvolvam de forma

35 35 incremental (ou iterativo), sistemas orientados a objetos, cujos requisitos são vagos e mudam frequentemente (TELES, 2004). A XP foi baseada inicialmente em quatro valores fundamentais, sendo eles: comunicação, feedback, simplicidade e coragem. A comunicação entre a equipe e o cliente faz com que todos os detalhes do projeto sejam observados e entendidos a fim de não serem deixados para trás. O feedback é feito pelo cliente para a equipe de desenvolvimento e se resume em um conjunto de alterações nas necessidades do software, implementadas ou não, que o cliente enxerga manipulando o software no decorrer do projeto. Ele é fundamental para permitir que o cliente direcione o desenvolvimento todos os dias, garantindo que a equipe foque nas atividades que irão gerar mais valor. A simplicidade permite que a equipe implemente apenas o que supre a necessidade do cliente. E por fim, a coragem deve estar presente para que a equipe seja capaz de fazer o desenvolvimento e evolução do software com segurança e agilidade, utilizando as práticas e valores da XP (TELES, 2004). Posteriormente foi acrescentado um quinto valor, o respeito, agregado para recordar o ser humano que está envolvido no produto. O respeito entre os envolvidos tem grau de importância fundamental para que os valores como a comunicação, o feedback, a simplicidade e a coragem tenham real efetividade. Todos devem manter o respeito e aceitar as diferenças entre si, além de aceitar as responsabilidades impostas e cumpri-las, cabe aos membros da equipe confiar que cada um dará o seu melhor (BASSI FILHO, 2008). Além dos valores fundamentais, a XP se baseia em doze práticas, na qual seus projetos devem seguir: cliente presente, jogo do planejamento, stand up meeting, programação em par, desenvolvimento guiado pelos testes, refactoring, código coletivo, código padronizado, design simples, metáfora, ritmo sustentável, integração contínua e releases curtos (TELES, 2004). Segundo Fowler (2001), muitas dessas práticas são técnicas que já existem e já foram testadas e comprovadas no passado, porém muitas vezes esquecidas. A XP conseguiu ressuscitar essas técnicas e utilizá-las de maneira onde cada uma reforce as outras. A XP sugere um número de técnicas poderosas e inovadoras que possibilitam uma equipe ágil criar versões de software com frequência, oferecendo recursos e funcionalidades estabelecidos anteriormente (PRESSMAN, 2011). A XP é bastante prescritiva comparada ao Scrum, pois inclui praticamente

36 36 todos os itens que compõem o Scrum, além de boas práticas de engenharia bem específicas (KNIBERG; SKARIN, 2009). 2.6 SCRUM O Scrum foi criado por Jeff Sutherland e sua equipe de desenvolvimento no início dos anos Mais recentemente, foram realizados desenvolvimentos adicionais no Scrum por Ken Schwaber e Mike Beedle. (PRESSMAN, 2011). Sua apresentação e publicação oficial foram no OOPSLA 1995 (SCHWABER; SUTHERLAND, 2010). O termo Scrum surgiu de uma atividade que ocorre durante uma partida de rugby, onde Um grupo de jogadores faz uma formação em torno da bola e seus companheiros de equipe trabalham juntos (às vezes de forma violenta!) para avançar com a bola em direção ao fundo do campo (PRESSMAN, 2011, p. 95). Nos dez primeiros anos do Scrum, Jeff Sutherland, trabalhando com o Jeff McKenna, e Ken Schwaber com Mike Smith e Chris Martin foram as pessoas que mais contribuíram na sua consolidação. Nos anos seguintes Mike Beadle e Martine Devos fizeram contribuições significativas (SCHWABER; SUTHERLAND, 2010). Utilizando uma abordagem iterativa e incremental, ilustrado na Figura 5, o Scrum tem como objetivo otimizar prazos e controlar riscos. Seu papel é fazer transparecer a eficácia das práticas de desenvolvimento de software e prover um framework dentro do quais produtos complexos podem ser desenvolvidos (SCHWABER; SUTHERLAND, 2010). Figura 5: Os modelos incremental e iterativo. Fonte: PFLEEGER (2004)

37 37 O Scrum engloba o uso de um conjunto de padrões de processos de software, que se mostra efetivo para projetos com prazos de entrega apertados, requisitos que possam mudar no decorrer do projeto e regras de negócios complexas e difíceis de serem compreendidas (PRESSMAN, 2011) Papéis O Time Scrum é composto pelo Product Onwer (PO), ScrumMaster (SM) e pelo Time. Os membros que compõem o Time Scrum são chamados de porcos ou comprometidos. Qualquer outra pessoa que está envolvida no projeto é chamada de galinha ou envolvida. Esses termos surgiram devido a uma história ilustrada na Figura 6, que conclui que porcos são aqueles que estão comprometidos com os objetivos do projeto como um todo e galinhas são aqueles envolvidos, que não estão no dia-a-dia do projeto (SCHWABER; SUTHERLAND, 2010). Figura 6: Cartoon Porco e Galinha. Fonte: CLARK; VIZDOS (2006) O Product Owner (Dono do Produto) ou PO, responsável trazer os requisitos especificados, tem como missão elaborar o Product Backlog priorizando itens e mantendo suas atualizações em dia, deixando sempre visível para todos da equipe. O PO tem autoridade na tomada de decisões referentes ao conteúdo e priorização do Product Backlog, porém não tem autoridade sobre o Time (SCHWABER; SUTHERLAND, 2010). Um bom PO demonstra comprometimento com o projeto, estando disponível para a equipe, a fim de esclarecer dúvidas e ajudar na construção de um bom produto. É essencial que ele tenha profundo conhecimento do negócio e consiga ter

38 38 uma boa comunicação com todas as pessoas envolvidas e comprometidas no projeto. Além disso, ele deve ter autoridade para tomar e manter decisões e ser responsabilizado por elas (COHN, 2011). O ScrumMaster existe para ajudar o Time Scrum e a organização no uso adequado do Scrum, para atingir maior produtividade e a desenvolver produtos com maior qualidade. Além disso, ele ajuda a equipe a entender e utilizar os conceitos de autogerenciamento e interdisciplinaridade a fim de se tornarem uma equipe autoorganizável (SCHWABER; SUTHERLAND, 2010). Uma das funções do SM é remover impedimentos ao progresso da equipe, agindo como um líder servidor para a equipe, sem autoridade sobre ela, mas com autoridade sobre o processo. Um SM qualificado preza a responsabilidade e a informação, ao invés do poder, trabalha para manter um clima colaborativo na equipe, reconhece o valor de todos os membros da equipe, e exerce sua influencia a fim de ajudar a equipe a atingir um bom resultado (COHN, 2011). O Time, ou equipe do projeto, é responsável por executar as atividades necessárias para o desenvolvimento do projeto de forma auto-organizáveis. Os membros do Time devem possuir todo o conhecimento necessário para transformar os itens do Product Backlog em incrementos de funcionalidades entregáveis em cada Sprint. Todos na equipe contribuem, mesmo que isso exija aprender novas habilidades (SCHWABER; SUTHERLAND, 2010). As equipes Scrum são bem-sucedidas em conjunto e falham em conjunto [...] Tornar-se realmente uma equipe Scrum de alto desempenho requer um esforço conjunto em direção ao aprendizado e à melhoria contínuos (COHN, 2011, p. 223) Time-Boxes Os Time-Boxes são eventos que compõem todo o ciclo do Scrum. São eles: Release Planning Meeting, Sprint Planning Meeting, Sprint, Daily Scrum Meeting, Sprint Review Meeting e Sprint Retrospective. O Release Planning Meeting (Reunião de Planejamento da Versão para Entrega) é uma reunião que tem como foco planejar o trabalho e definir metas para a geração de uma versão funcional, com os itens de maior prioridade no Product Backlog e com data prevista de entrega. Esse plano de versão pode ser atualizado ao final de cada Sprint. Com essa reunião é possível ter uma visão futurista do

39 39 projeto e dos Sprints que farão parte do próximo Release (SCHWABER; SUTHERLAND, 2010). Para planejar cada iteração (Sprint), o Time, juntamente com o PO e SM, se reúnem e realizam o Sprint Planning Meeting (Reunião de Planejamento da Sprint), que tem como objetivo definir e estimar o grau de dificuldade e duração das atividades que serão entregues ao final do ciclo do Sprint. Além dos comprometidos, outros envolvidos podem ser convidados a participar, desde que agreguem valor à reunião e tenham seu convite aprovado pelo PO (SCHWABER; SUTHERLAND, 2010). O Sprint Planning Meeting é dividido em duas partes com mesma duração. Na primeira parte é decidido o que será feito no Sprint. O PO deverá definir a Meta do Sprint e falar para o Time sobre os itens com maior prioridade no Procuct Backlog. Além disso, o Time deverá estimar os itens em tamanhos e selecionar aqueles que teoricamente podem ser feitos durante o Sprint, elaborando assim, uma lista que recebe o nome de Selected Product Backlog. Na segunda parte da reunião, o Time deverá colher mais detalhes dos itens do Selected Product Backlog, a fim de transformá-lo em um incremento pronto e implementado, gerando assim o Sprint Backlog (SCHWABER; SUTHERLAND, 2010). Ao elaborar o Selected Product Backlog, o Time deve comprometer-se apenas com os itens que acreditam poder terminar dentro de uma Sprint. Caso um item seja grande demais para terminar em um Sprint, o Time e o PO devem quebrá-lo em pedaços menores e encaixá-los nos próximos Sprints. Se os itens tendem a ser grandes, os Sprints terão maior duração (KNIBERG; SKARIN, 2009). Essa reunião é uma das mais importantes do Scrum e oferece a equipe informação suficiente para trabalharem sem ociosidade durante o Sprint e oferece confiança suficiente ao PO para não incomodar a equipe. Porém, é uma reunião crítica e se o planejamento for mal feito, o Sprint estará comprometido (KNIBERG, 2007). Um Sprint é uma iteração com duração de 2 a 4 semanas, no qual o Time produzirá uma parte do produto solicitado pelo cliente. Eles ocorrem um após o outro, sem intervalos entre eles. No Sprint, o SM deve garantir que nenhuma alteração que afete a Meta do Sprint será feita. Além disso, ele deve barrar impedimentos e garantir uma boa aplicação do Scrum (SCHWABER; SUTHERLAND, 2010). Somente o PO pode cancelar um Sprint, porém, as partes interessadas podem

40 40 influenciá-lo a isso. Um Sprint pode ser cancelado quando perde o sentido no cenário atual. Um cancelamento raramente acontece, devido a curta duração de um Sprint (SCHWABER; SUTHERLAND, 2010). O Daily Scrum Meeting (Reunião Diária) é uma reunião que ocorre diariamente onde cada membro do Time deve informar tudo que realizou desde a última reunião diária, o que pretende fazer antes da próxima reunião diária e se ele está tendo algum impedimento em suas atividades (SCHWABER; SUTHERLAND, 2010). Essa reunião é conhecida também como Stand Up Meeting (Reunião em Pé), pois para que seja rápida e com um alto nível de energia, os membros da equipe permanecem em pé. Além disso, deve ocorrer no mesmo horário e local (KNIBERG; SKARIN, 2009). O SM deve garantir que essa reunião aconteça diariamente, pois ela tem grande importância no Time, fazendo com que a comunicação e o nível de conhecimento do projeto sejam melhorados a cada dia, eliminando outras reuniões, removendo impedimentos para o desenvolvimento e ressaltando e promovendo a tomada rápida de decisões (SCHWABER; SUTHERLAND, 2010). O Sprint Review Meeting (Reunião de Revisão) acontece quando acaba a execução do Sprint. O objetivo dessa reunião informal é o Time apresentar as funcionalidades desenvolvidas no último Sprint para o PO e convidados. O PO avalia se a Meta do Sprint foi alcançada, além disso, ele pode fazer anotações que poderão se transformar em novos itens para o Product Backlog (SCHWABER; SUTHERLAND, 2010). Essa reunião, quando bem feita, traz crédito à equipe, fazendo os integrantes se sentirem satisfeitos pelo trabalho realizado. Além disso, todos da equipe podem ver o que foi desenvolvido. Mesmo o Sprint não atingindo um grau de sucesso, a reunião deverá ser feita, pois será um aprendizado para o próximo Sprint, onde o Time tentará se superar para entregar mais funcionalidades e realizar uma reunião mais agradável (KNIBERG, 2007). A Sprint Retrospective (Retrospectiva da Sprint) é a última reunião do fluxo do Scrum, onde nela participa inicialmente o Time, porém, caso seja de acordo com todos os seus integrantes, o PO também pode participar (SCHWABER; SUTHERLAND, 2010). Nessa reunião o SM encoraja o Time a identificar e priorizar os principais itens

41 41 que correram bem ou mal no último Sprint, de forma a torná-lo mais eficaz e gratificante. Ao final da reunião o Time deve ter identificado as medidas de melhorias para os itens negativos que ocorreram no último Sprint e que serão implementados no próximo Sprint (SCHWABER; SUTHERLAND, 2010). A duração dos Time-Boxes pode variar de acordo com a duração do Sprint, geralmente entre 2 a 4 semanas, definida pela organização. Conforme exibido na Tabela 2, para Sprints com duração de 4 semanas, o Sprint Planning Meeting deve durar 8 horas e o Sprint Review Meeting 4 horas. Já em Sprints com tempo menor, ambos devem durar até 5% do tempo total do Sprint. As outras reuniões possuem duração fixa, sendo o Release Planning Meeting com duração entre 15 à 20% do tempo de uma reunião de plano de entrega tradicional, o Daily Scrum Meeting com duração de 15 minutos e Sprint Retrospective com duração de 3 horas (SCHWABER; SUTHERLAND, 2010). Tabela 2: Duração dos Time-Boxes Evento Duração Sprint de X tempo Sprint de 4 semanas Release Planning Meeting 15 à 20% de um plano tradicional Sprint Planning Meeting 5% de X 8 horas Sprint 2 a 4 semanas Daily Scrum Meeting 15 minutos Sprint Review Meeting Até 5% de X 4 horas Sprint Retrospective 3 horas Fonte: OS AUTORES (2011) Artefatos O Scrum utiliza artefatos que inclui o Product Backlog, o Sprint Backlog e o Burndown. Cada um desses itens é discutido nos parágrafos seguintes. O Product Backlog lista todos os requisitos necessários para o desenvolvimento, como as características, as melhorias, as funções e as correções de erros. Inicialmente, são selecionados apenas os requisitos conhecidos e com melhor compreensão. Conforme o desenvolvimento evolui, o Product Backlog, que é dinâmico, evolui também (SCHWABER; SUTHERLAND, 2010).

42 42 Em um processo de desenvolvimento sequencial, existe uma longa fase inicial que coleta e detalha os requisitos até que o produto seja totalmente especificado. O Scrum não utiliza essa abordagem, suas descrições dos requisitos podem ser coletadas no início, mas são refinadas à medida que o projeto avança (COHN, 2011). Os requisitos, também chamados de User Stories (Estórias de Usuário), do Product Backlog contém atributos de descrição, estimativa e prioridade, conforme exibido na Tabela 3. O ID é usado como identificação única e incremental para que não se perca o controle das User Stories caso o seu nome seja alterado. O nome, que deve ter entre 2 a 10 palavras, descreve a estória de forma clara tanto para os desenvolvedores quanto para o PO. A importância mostra qual o grau de prioridade da estória para o PO, de forma crescente. A estimativa inicial é o tempo necessário pela equipe para implementar a estória. Uma descrição de alto nível sobre a estória é descrita no campo como demonstrar. No campo notas pode ser adicionada qualquer outra informação, esclarecimento ou referencias a outras fontes de informação (KNIBERG, 2007). Em ANEXO C - CAMPOS ADICIONAIS DA ESTÓRIA são discutidos alguns campos que podem ser adicionados ao Product Backlog. Tabela 3: Exemplo de um Product Backlog Fonte: KNIBERG (2007) A ordenação do Product Backlog é por prioridade e quanto mais alta a prioridade maior o nível de detalhe e maior a urgência para o desenvolvimento da atividade. O PO é responsável por manter a listagem do Product Backlog com suas prioridades atualizadas e visíveis à equipe (SCHWABER; SUTHERLAND, 2010). O Sprint Backlog é constituído pelas as atividades que o Time deve executar

43 43 para transformar os itens do Product Backlog em uma funcionalidade ou incremento do produto e alcançar a Meta da Sprint. O Sprint Backlog é modificado e atualizado pelo Time durante o Sprint (SCHWABER; SUTHERLAND, 2010). Somente deverá entrar no Sprint Backlog itens que podem ser concluídos na Sprint. Quando uma User Storie for muito longa, podendo durar muitos Sprints, ela devera ser dividida em partes bem menores para que cada uma possa ser concluída dentro de uma Sprint (COHN, 2011). O Time identifica se cada tarefa individual será necessária e o tempo que cada uma poderá levar para ser desenvolvida. Somente o Time pode atualizar o conteúdo do Sprint Backlog e atualizar as suas estimativas (SCHWABER; SUTHERLAND, 2010). O Burndown Chart, ilustrado na Figura 7, é um gráfico que representa o progresso de toda a equipe ao longo do tempo, exibindo em qualquer ponto a quantidade restante de trabalho com o progresso da equipe na redução do trabalho da mesma. O registro do trabalho executado dentro do gráfico é feito através da quantidade de tarefas e pontos de complexidade das mesmas (SCHWABER; SUTHERLAND, 2010). Figura 7: Gráfico de Burndown. Fonte: KNIBERG (2007) Esse gráfico é usado como uma das principais ferramentas para acompanhar o andamento do Sprint, observar facilmente se o Time está acompanhando o cronograma e se conseguirá entregar o Sprint no prazo (KNIBERG; SKARIN, 2009). O Burndown Chart pode ser usado em nível de Release, seguindo o mesmo formato, porém, exibindo quantos pontos da User Storie restam no Product Backlog ao final de cada Sprint (KNIBERG; SKARIN, 2009).

44 User Stories e tarefas User Stories (Estórias de Usuários) são trabalhos que podem ser entregues ao final de um Sprint e que o são importantes para o PO. Uma estória contém três variáveis, ilustradas na Figura 8, que dependem umas das outras. São elas: escopo, importância e estimativa. O escopo e a importância são definidos pelo PO, enquanto que a estimativa é definida pelo Time (KNIBERG, 2007). Figura 8: Variáveis de uma estória. Fonte: KNIBERG (2007) Algumas vezes os PO não quer ou não pode participar do Sprint Planning Meeting e justifica isso dizendo que já listou os requisitos que deseja no Product Backlog. Esse é um problema grave, pois o Time e o PO devem selecionar as estórias juntos e refinar essas três variáveis em cada estória selecionada (KNIBERG, 2007). As estórias não devem ser muito grandes (em termos de estimativas), pois sendo grandes demais, haverá o risco de não serem entregues concluídas ao final do Sprint. Caso isso possa acontecer, ela deve ser quebrada em estórias menores, conforme ilustrado na Figura 9 (KNIBERG, 2007). Figura 9: Exemplo da divisão de uma estória em outras menores. Fonte: KNIBERG (2007)

45 45 Cada estória do Product Backlog pode ser quebrada em tarefas, ilustradas na Figura 10, que são atividades que juntas formam a estória, porém que para o PO não tem importância e valor ao final do Sprint (KNIBERG, 2007). Figura 10: Exemplo da divisão de uma estória em tarefas. Fonte: KNIBERG (2007) Existem atividades que precisam ser realizadas, mas que não fazem parte das entregas do Sprint, não estão relacionadas à nenhuma User Storie e não agregam valor para o PO. Elas são chamadas de estória técnicas, ou itens não funcionais. Podemos citar como exemplo de estória técnicas, a instalação de um servidor de build, upgrades de softwares, entre outros (KNIBERG, 2007). Essas estórias podem fazer parte do Product Backlog, porém, dificilmente o PO irá priorizá-las como deveria, justamente pelo fato de não entender o grau de importância delas. Nesses casos, é interessante incluir as atividades que compõem as estória técnicas dentro de outras estórias ou transformar a estória técnica em uma estória normal, que agregue valor ao PO (KNIBERG, 2007) Ferramentas e métodos Existem algumas ferramentas e métodos que são usados para auxiliar e agregar mais valor ao uso do Scrum. São eles: Scrum Board e Planning Poker e serão discutidas nos parágrafos seguintes. O Planning Poker é um método usado pelo Time para estimar o tempo de desenvolvimento de cada User Storie. O baralho é composto por 13 cartas,

46 46 conforme ilustrado na Figura 11, com uma escala de valores 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 e 100, além dos símbolos de interrogação e xícara de café. Cada valor numérico, exceto o zero, representa uma estimativa de tempo em pontos para a estória. O zero representa que a estória é tão pequena que leva somente alguns minutos ou, que a estória já foi feita. A interrogação significa que o participante não entendeu o escopo da estória e a xícara de café significa que o participante está cansado, sem foco e sugere uma pausa no Sprint Planning Meeting (KNIBERG, 2007). Figura 11: Baralho do Planning Poker. Fonte: KNIBERG (2007) Ao estimar uma estória, cada integrante do Time escolhe uma carta e coloca-a sobre a mesa, virada para baixo. Quando todos do Time tiverem jogado sua carta, as cartas são reveladas. Dessa forma, nenhum integrante é influenciado pela estimativa do outro, pois somente no final da jogada, as cartas são reveladas (KNIBERG, 2007). Quando não há consenso entre as estimativas, é feita uma discussão entre os participantes para obter uma visão comum para a estória e uma nova jogada é feita. Esse processo é repetido até que as estimativas cheguem em valores próximos (KNIBERG, 2007). Para que seja possível estimar as estórias, o Time precisa entender do que se trata a estória. Além disso, todos os integrantes que participarão do desenvolvimento

47 47 da estória (arquiteto de informação, designer, programadores, testes, etc.) devem estimá-la. Com isso haverá certeza que o Time por completo entendeu o escopo da estória e poderão se ajudar no decorrer do desenvolvimento (KNIBERG, 2007). O Scrum Board (Quadro de Tarefas), ilustrado na Figura 12, é uma ferramenta que tem como objetivo exibir o progresso do Sprint com as atribuições e responsabilidades de todos do Time. O quadro é dividido em colunas, onde as tarefas das estórias são inicialmente coladas na coluna de tarefas não iniciadas. Conforme as tarefas vão sendo feitas, elas são transportadas para as colunas respectivas ao seu status desenvolvimento. No quadro também pode ser traçado o gráfico de Burndown além de adicionados tarefas não planejadas, como bugs em produção e tarefas que podem entrar no Sprint, caso ele tenha sido finalizado antes do prazo (KNIBERG, 2007). Figura 12: Quadro de Tarefas. Fonte: KNIBERG (2007) Mais de uma atividade pode ser iniciada, não existe uma regra para isso, porém, a maioria dos Times aprende que na prática não é uma boa ideia iniciar muitas atividades ao mesmo tempo, e criam uma cultura de tentar finalizar uma atividade antes de iniciar a outra (KNIBERG; SKARIN, 2009). O quadro de tarefas pode ser atualizado antes ou durante o Sprint Daily Meeting (KNIBERG, 2007). Ao final do Sprint, o quadro é limpo: todos os itens são retirados, proporcionando à equipe a sensação de realização e fechamento de uma etapa do projeto (KNIBERG; SKARIN, 2009).

48 Fluxo do Scrum O ciclo de desenvolvimento do Scrum, conforme ilustrado na Figura 13, inicia com o levantamento de requisitos do produto que será desenvolvido, compondo o Product Backlog. Após o Product Backlog ser elaborado, pode-se fazer o Release Planning Meeting, caso exista o interesse de agendar uma versão funcional do software. Antes do início de cada Sprint, a equipe se reúne com o PO para fazer o Sprint Planning Meeting e selecionar as tarefas que serão desenvolvidas na Sprint e priorizar cada uma delas, elaborando a Sprint Backlog. Os projetos são desenvolvidos em uma série de Sprints de 2 à 4 semanas, onde diariamente ocorre o Daily Scrum Meeting. Ao final da Sprint é realizado a Sprint Review Meeting e a Sprint Retrospective Meeting. Figura 13: Fluxo do Scrum. Fonte: PRESSMAN (2011) (Adaptado) Principais Ferramentas Disponíveis Dentre as ferramentas existentes que auxiliam na manutenção de projetos que utilizam o Scrum, é difícil encontrar uma que aproveite todo o potencial desse framework. Dentre as disponíveis no mercado, foi analisado 4 ferramentas: ScrumHalf, PangoScrum, FireScrum e GreenHopper. As principais características dessas ferramentas estão descritas nos parágrafos a seguir. ScrumHalf é disponibilizado em versão gratuita e paga. Algumas funcionalidades só estão disponíveis na versão paga. A ferramenta permite o arquivamento de projetos finalizados, fornecendo um importante histórico do qual é

49 49 possível retirar métricas e estimativas. Permite o planejamento de releases do produto que está sendo desenvolvido e gera automaticamente os gráficos de Burndown de acordo com dados inseridos no sistema. Ela também permite a pontuação das estórias, assim como a criação de estórias para bugs (GPE, 2011). O PangoScrum conta com um Kanban, que oferece suporte ao quadro físico. O quadro, segundo os criadores do PangoScrum, não pode ser incluído no sistema, pois dificultaria sua visualização e a manutenção da evolução das tarefas. A ferramenta possui um calendário onde todas as reuniões podem ser agendadas e o sistema se encarrega de notificar os envolvidos do compromisso. Também permite facilmente estimar e priorizar o Product Backlog e o Sprint. Permite também a geração de gráficos e estatísticas para acompanhamento do projeto e do desempenho do Time (PANGOSCRUM, 2011). O FireScrum foi desenvolvido utilizando os moldes da WEB 2.0 e Rich Internet Application (Aplicações de Internet Rica), também conhecidas como RIA. A ferramenta expõe uma API (Interface de Programação de Aplicações) para integração com outros módulos e sistemas. Além de possuir as funcionalidades básicas de uma ferramenta de gerenciamento baseada em Scrum, como criação de Backlog, pontuação, métricas etc., ela apresenta diversas funcionalidades na parte de testes, como criação de casos e plano de testes e um módulo de Bug Tracking onde os bugs podem ser cadastrados, analisados e acompanhados até a sua solução. Os casos de teste podem ser associados ao Backlog do projeto e é possível extrair relatórios dos resultados dos testes feitos. A ferramenta conta com um chat para a comunicação do Time e um Planning Poker para pontuar as tarefas e estórias. Além disso, possui uma versão desktop, não tão completa como a versão WEB, mas que contém suas principais funcionalidades para facilitar e tornar mais rápido o acesso a ferramenta (FIRESCRUM, 2011). O GreenHopper é um módulo do JIRA, ferramenta de gerenciamento de projetos, voltado para a utilização do Scrum. A ferramenta conta com um quadro de planejamento que permite priorizar e agendar tarefas, que são representadas com cartões, codificada por cores de acordo com o tipo da tarefa (por exemplo estória, bug, refatoração, etc.). O ScrumMaster e o Product Owner podem adicionar novas tarefas no quadro também. A partir deste são retiradas as funcionalidades que serão entregues no Sprint, ou seja, as tarefas que irão para o quadro podem ter seus status atualizados com o decorrer do desenvolvimento. Na ferramenta também é

50 50 possível visualizar os gráficos de Burndown, assim como outros gráficos para acompanhar o andamento do projeto. Ela tem um módulo de Bug Tracking, que permite que os casos de bug possam ser associados diretamente com as tarefas do Sprint (JIRA, 2011). Tabela 4: Análise Comparativa de Ferramentas Funcionalidades disponíveis ScrumHalf PangoScrum FireScrum GreenHopper API de WEB Services - - Bug Tracking - Cliente Desktop - - Daily Meeting Geração de Release - Gerenciamento de Impedimentos Gerenciamento do Product Backlog Gerenciamento de Projetos Gerenciamento de Teste - - Gerenciamento de Usuários Gerenciamento do Sprint Gráfico Burndown Planning Poker Pontuação de Estórias Quadro de Tarefas Relatórios e Estatísticas Sprint Retrospective - - Sprint Review - - Versão Gratuita Fonte: OS AUTORES (2011) Na análise comparativa todos os softwares, conforme Tabela 4, contam as mesmas funcionalidades básicas para utilizar o Scrum (exceto o PangoScrum que não conta com o quadro). O GreenHopper por ser um plugin do Jira, conta com mais funcionalidades que

51 51 os demais, é uma ferramenta mais robusta. Porém peca na questão de fácil usabilidade por tentar atender em diversos requisitos. O PangoScrum é o mais simples de todos, funcionando como uma ferramenta que não pretende atender a todos requisitos do Scrum, porém se mostra muito ágil e versátil na gestão de projetos. O FireScum não possui os recursos mais avançados que a nova onda de componentes da RIA oferece, e não tem uma interface tão limpa como o PangoScrum ou o ScrumHalf, porém, tem os recursos que uma ferramenta que implementa o Scrum precisa ter. O ScrumHalf é a ferramenta com a melhor combinação funcionalidades e usabilidade, com um layout bem caprichado, e recursos bem intuitivos, não demandando muito tempo de aprendizado, o software consegue gerenciar todo o fluxo do Scrum. Por fim, o Scrum-Box que é a ferramenta do projeto que não está listada no quadro que analisa e compara todas as ferramentas, tem como diferencial todas as funcionalidades descrita acima e a funcionalidade que gera relatório de métricas da Sprint diferentemente dos demais.

52 52 3 METODOLOGIA Para atingir os objetivos conceituais e práticos desde trabalho, foram realizadas pesquisas e uma breve revisão bibliográfica de áreas específicas da Engenharia de Software, discutindo os tópicos relacionados nas visões de diferentes autores. A partir desse estudo, foi possível entender os principais conceitos e aplicabilidade, de forma a ajudar na inclusão dos materiais selecionados para construção do software. Com o objetivo de complementar a parte conceitual, foram analisados diferentes softwares que auxiliam no gerenciamento de projetos que utilizam a abordagem proposta pelo Scrum. Essa análise foi realizada para conhecer todos os recursos oferecidos pelo Scrum e auxiliar no levantamento de requisitos para o desenvolvimento de um novo software, que tem como objetivo agregar mais valor ao Scrum e oferecer ao usuário recursos que os softwares analisados não oferecem, tais como Métricas e Gráficos que estão detalhados na sessão 4 SCRUM-BOX: SISTEMA DE GESTÃO DE PROJETOS. No levantamento de requisitos, foram estudados todos os requisitos necessários para a conclusão deste trabalho e, após essa etapa, foram utilizados alguns diagramas da UML. A UML ou Linguagem de Modelagem Unificada (Unified Modeling Language) é um padrão de mercado utilizado para especificar, visualizar e construir os artefatos de sistemas de software, usando conceitos orientados a objetos (LARMAN, 2000). Os diagramas existentes na UML apresentam características do sistema, sua evolução e como o sistema responde à requisições (MELO, 2004). Foram utilizados os seguintes diagramas para a modelagem do sistema: Diagrama de Casos de Uso (Use Case Diagram): apresenta os casos de uso, atores e seus relacionamentos que expressam a funcionalidade de um sistema. Diagrama de Classes (Class Diagram): apresenta elementos conectados por relacionamentos, como entidades. O Diagrama de Caso de Uso foi desenvolvido na ferramenta de modelagem visual, Rational Rose Enterprise. Já o Diagrama de Classes foi gerado com a ferramenta Enterprise Architect. Além dos diagramas, foi utilizado o Modelo Conceitual para representar os

53 53 conceitos do domínio do sistema, gerado com a ferramenta brmodelo. A especificação de Caso de Uso é um artefato que contém detalhes das características do caso de uso. Todos os Casos de Uso identificados no sistema foram especificados, detalhando cenários e comportamentos do sistema. Um wireframe é uma estrutura gráfica que representa a interação e os diferentes níveis de navegação de um sistema, eles simulam casos de uso, mas de forma gráfica (WAISMAN, 2006). Para viabilizar o desenvolvimento do sistema, foram desenhados alguns wireframes a fim de proporcionar uma visualização da interface dos principais módulos do sistema, considerando conceitos de usabilidade e arquitetura de informação. Os wireframes foram construídos utilizando a ferramenta Axure RP. Na etapa de definição de arquitetura e desenvolvimento do software realizou-se um levantamento sobre padrões de desenvolvimento, ferramentas e linguagens de programação viáveis para o projeto. Após esse levantamento, foi definida a utilização da arquitetura de sistemas em camadas, também chamada de padrão MVC (Model View Controller). O padrão de projeto MVC foi originalmente criado por Trygve Reenskaug em 1979 (NUNES, 2005). Está dividido em três camadas: Primeira camada: identificada como apresentação, abrange as classes que são responsáveis pela interação dos usuários com o próprio sistema (MELO, 2004). Nesta camada de apresentação foi utilizado os frameworks Struts e o JSP, juntamente com HTML/CSS e TILES para os componentes visuais. Segunda camada: identificada como camada de negócios, controla as regras de negócio do sistema (MELO, 2004). Nesta camada foi utilizado o framework Spring para gerenciar as entidades de domínio como beans. Terceira camada: identificada como camada de persistência, controla a persistência dos dados do sistema (MELO, 2004). Nesta camada foi utilizando o framework Hibernate para mapeamento objeto entidade. Para o armazenamento de dados do software foi utilizado o banco de dados relacional MySql. Para desenvolvimento do sistema foi utilizada a IDE Springsource Tool Suite com a linguagem de programação Java. O desenvolvimento de software é um processo que envolve diversas atividades que, mesmo implementando as melhores práticas, podem ocasionar erros no software final. Por esse motivo existe a atividade de teste, que consiste na análise

54 54 dinâmica do software a fim de verificar a presença de defeitos e garantir a qualidade do software (DELLA CORTE, 2006). Na fase de atividade de testes do sistema Scrum-Box, as funcionalidades foram executadas sob ponto de vista de seu usuário final, investigando falhas em relação aos objetivos propostos. Os testes foram executados de forma manual, em condições similares aos que os usuários finais utilizarão.

55 55 4 SCRUM-BOX: SISTEMA DE GESTÃO DE PROJETOS A modelagem de sistemas é um elemento importante na Engenharia de Software, pois ela fornece modelos que definem os processos e visões abrangentes e detalhadas do software (PRESSMAN, 2011). 4.1 ANÁLISE DOS REQUISITOS Os requisitos são descrições das necessidades de um produto. O objetivo da análise de requisitos é identificar e documentar o que é necessário de forma clara, para que clientes e integrantes da equipe de desenvolvimento possam entender (LARMAN, 2000). Seguindo toda parte conceitual abordada no Capítulo 2 deste trabalho, foram levantados os requisitos funcionais e não funcionais necessários para o desenvolvimento do software Requisitos funcionais Os requisitos funcionais referem-se a ações que o sistema deve ser capaz de realizar. Eles especificam o comportamento de entrada e saída do sistema (PFLEEGER, 2004). Os requisitos funcionais identificados no sistema são: RF01: O sistema deve gerenciar o acesso de usuários ao sistema. RF02: O sistema deve permitir o cadastro e consulta de colaborador. RF03: O sistema deve permitir o cadastro e consulta de projeto. RF04: O sistema deve permitir a associação de colaborador e projeto. RF05: O sistema deve permitir o cadastro de Sprint. RF06: O sistema deve permitir o cadastro de User Story. RF07: O sistema deve permitir o cadastro de Task. RF08: O sistema deve permitir o cadastro de apontamento de horas trabalhadas por Task. RF09: O sistema deve permitir a geração do gráfico de Burndown e de progresso da Sprint.

56 56 RF10: O sistema deve permitir a geração do gráfico de estimativa para visualização de horas por projeto, horas por Sprint e horas por User Story. RF11: O sistema deve permitir a geração do relatório de progresso de Sprint Requisitos não funcionais Os requisitos não funcionais descrevem apenas atributos do sistema ou atributos do ambiente do sistema (PFLEEGER, 2004). Os requisitos não funcionais identificados no sistema são: RNF01: A interface do sistema deve ser WEB. RNF02: O sistema deve possuir uma interface de fácil usabilidade. RNF03: O sistema deve utilizar o banco de dados MySql. RNF04: O sistema deve ser desenvolvido na linguagem Java. RNF05: O tempo de resposta do sistema deve ser de até 30 segundos Matriz de Rastreabilidade Matriz de Rastreabilidade é uma forma de apresentar o relacionamento entre os requisitos de software. A sua utilização ajuda no gerenciamento de como as informações levantadas sobre requisitos são convertidas em características e funcionalidades do sistema. A Tabela 5 apresenta a Matriz de Rastreabilidade do relacionamento dos requisitos funcionais com os casos de uso. Tabela 5: Matriz de Rastreabilidade Nº Caso de Uso Requisito 01 UC01 Login RF01 02 UC02 - Cadastrar Colaborador RF02 03 UC03 - Cadastrar Projeto RF03 04 UC02 - Cadastrar Colaborador RF04 05 UC04 - Cadastrar Sprint RF05 Fonte: OS AUTORES (2011)

57 57 Tabela 5: Matriz de Rastreabilidade (continuação) Nº Caso de Uso Requisito 06 UC05 - Cadastrar User Story RF06 07 UC06 - Cadastrar Task (SM) RF07 08 UC06 - Cadastrar Task (Colaborador) RF08 09 UC07 - Gerar Gráficos de progresso da Sprint RF09 10 UC08 - Gerar Gráficos de Acompanhamento do Colaborador RF10 11 UC09 - Gerar Relatório de Métricas da Sprint RF11 Fonte: OS AUTORES (2011) 4.2 DIAGRAMA DE CASO DE USO A modelagem de casos de uso relata as funcionalidades propostas que são observadas do sistema. Cada caso faz uma representação de uma parte funcional do sistema. O grupo de casos de uso apresenta as funcionalidades totais do sistema em níveis de detalhes, assim como, cada ator especifica um usuário ou objeto para o sistema poder realizar um comportamento (RUMBAUGH, 2006). Os casos de uso identificados no sistema são: UC01 Login: Este caso de uso descreve a interação do Colaborador e do ScrumMaster com a funcionalidade que identifica e permite o seu acesso no sistema. UC02 - Cadastrar Colaborador: Este caso de uso descreve a interação do Colaborador e do ScrumMaster com a funcionalidade que cadastra e identifica os colaboradores existentes. UC03 - Cadastrar Projeto: Este caso de uso descreve a interação do ScrumMaster com a funcionalidade que cadastra e identifica os projetos existentes. UC04 - Cadastrar Sprint: Este caso de uso descreve a interação do ScrumMaster com a funcionalidade que cadastra e identifica as Sprints existentes. UC05 - Cadastrar User Story: Este caso de uso descreve a interação do

58 58 ScrumMaster com a funcionalidade que cadastra e identifica as User Stories existentes. UC06 - Cadastrar Task: Este caso de uso descreve a interação do Colaborador e do ScrumMaster com a funcionalidade que cadastra e identifica os Tasks existentes e realiza o apontamento de horas. UC07 - Gerar Gráficos de progresso da Sprint: Este caso de uso descreve a interação do Colaborador e do ScrumMaster com a funcionalidade que gera os gráficos de Burndown e de progresso da Sprint. UC08 - Gerar Gráficos de Acompanhamento do Colaborador: Este caso de uso descreve a interação do Colaborador e do ScrumMaster com a funcionalidade que gera o gráfico de Estimativa de horas por projeto, de horas por Sprint e de horas por User Story. UC09 - Gerar Relatório de Métricas da Sprint: Este caso de uso descreve a interação do Colaborador e do ScrumMaster com a funcionalidade que gera o relatório de Progresso da Sprint. Os Casos de Uso detalhados encontram-se na seção APÊNDICE A deste documento. A Figura 14 ilustra o Diagrama de Casos de Uso do sistema: Figura 14: Diagrama de Casos de Uso. Fonte: OS AUTORES (2011)

59 Descrição dos atores Ator é uma entidade do mundo real que interage com o sistema. Ele representa um elemento externo do sistema onde pode ser pessoa, sistema, máquina ou dispositivo (WAZLAWICK, 2004). Os atores identificados no sistema são: Colaborador: O ator colaborador possui a permissão de acessar o sistema e consultar e cadastrar colaboradores, realizar o apontamento de horas trabalhadas, gerar gráfico de Burndown, gerar gráfico de Estimativa e visualizar o relatório de progresso da Sprint. ScrumMaster: O ator ScrumMaster possui permissão de acessar todas as funcionalidades do sistema. 4.3 DIAGRAMA DE CLASSES O Diagrama de Classes é um elemento da modelagem de análise que permite a visualização de um conjunto de classes relacionadas entre si. Ela fornece uma visão estática do software (PRESSMAN, 2011). A Figura 15 ilustra o Diagrama de Classes do sistema. Figura 15: Diagrama de Classes. Fonte: OS AUTORES (2011)

60 PROJETO DE BANCO DE DADOS Em projeto de banco de dados passamos por três períodos que são compostos por modelagem conceitual, projeto lógico e projeto físico para a construção de um recente banco de dados (HEUSER, 2011) Modelo Conceitual O Modelo Conceitual é um modelo abstrato que descreve o banco de dados de maneira autônoma de um sistema de gerenciamento de banco de dados, registrando as informações que podem ser visualizadas pelo banco de dados, mas não mostra como as informações estarão armazenadas (HEUSER, 2011). A Figura 16 ilustra o Modelo Conceitual do sistema. Figura 16: Modelo Conceitual. Fonte: OS AUTORES (2011)

61 61 5 DESENVOLVIMENTO Os objetivos propostos por este trabalho são o estudo do Scrum e o desenvolvimento de um sistema para gerenciamento de projetos Scrum que auxilie todos os envolvidos e comprometidos com os projetos na sua organização, agregando mais valor ao Scrum. Devido a necessidade do acesso dos usuários do sistema ser em diferentes localidades, definiu-se o desenvolvimento de um sistema que execute na plataforma WEB. Nas próximas seções são apresentadas as tecnologias utilizadas para o desenvolvimento do sistema, bem como seu funcionamento. 5.1 TECNOLOGIAS UTILIZADAS Para a implementação de um sistema, é necessário definir as tecnologias que serão utilizadas desde o processo de desenvolvimento até a disponibilização do sistema no ambiente onde o usuário final terá acesso. A definição desses itens depende de diversos fatores, como investimento, prazo, domínio e suporte. Para este projeto foram escolhidas tecnologias open-source, ou seja, tecnologias com licenças de uso gratuitas. São elas: Spring Framework: utilizado para injeção de dependências e inversão de controle, o Spring oferece flexibilidade e benefícios significativos para muitos projetos, aumentando a produtividade de desenvolvimento e desempenho de execução, melhorando a cobertura de teste e qualidade de aplicação (SPRING, 2011). Struts: framework WEB é uma solução projetada para ajudar os desenvolvedores a criar aplicações WEB que utilizam uma arquitetura MVC (STRUTS, 2011). JSP (JavaServer Pages): tecnologia que oferece uma maneira simplificada e rápida de criar conteúdo WEB dinâmico (JSP, 2011). Tiles: framework de templating construído para simplificar o desenvolvimento de interfaces WEB. Com ele é possível definir fragmentos de páginas para reaproveitamento de código (TILES, 2011).

62 62 Hibernate: framework que visa oferecer melhores capacidades de persistência, simplificando a complexidade. Este framework cuida do mapeamento de classes Java para tabelas de banco de dados e de tipos de dados Java para tipos de dados SQL. Além disso, fornece dados de consulta e facilidades de recuperação que reduzem significativamente o tempo de desenvolvimento (HIBERNATE, 2011). MySQL: banco de dados que o conjunto mais abrangente de recursos avançados e ferramentas de gestão para alcançar os mais altos níveis de escalabilidade, segurança, confiabilidade (MYSQL, 2011). Maven: ferramenta que pode ser usada para construir e gerenciar qualquer projeto baseado em Java, bem como suas dependências, facilitando o dia-a-dia dos desenvolvedores (MAVEN, 2011). Tomcat: servidor que suporta algumas funcionalidades especificadas pelo JavaEE, como JSP e Servlets. É indicado para aplicações WEB de médio porte (TOMCAT, 2011). JFreeChart: biblioteca usada para exibir gráficos de qualidade profissional em aplicações Java (JFREECHART, 2011). 5.2 EVOLUÇÃO DO PROJETO Antes de iniciar o desenvolvimento do sistema, foram desenhados wireframes de algumas páginas de cadastro e listagem para sugerir a estrutura dessas páginas e seus relacionamentos com outras páginas. A Figura 17 mostra a tela de cadastro de projeto e apresenta uma ideia geral do layout e organização das informações no sistema.

63 63 Figura 17: Tela Novo Projeto. Fonte: OS AUTORES (2011) Os demais wireframes encontram-se na seção APÊNDICE B - WIREFRAMES desde documento. 5.3 RESULTADO FINAL Esta sessão tem como objetivo descrever as principais funcionalidades oferecidas pelo o sistema de gestão de projetos Scrum-Box e ilustrar suas principais interfaces. A abrangência e aplicação do sistema visam garantir o atendimento aos requisitos listados no item 4.1 ANÁLISE DOS REQUISITOS. As funcionalidades do Sistema Scrum-Box estão descritas a seguir: Login: O usuário cadastrado acessa o sistema através de seu Login e senha criados pelo administrador do sistema e tem a opção de se manter conectado, conforme Figura 18.

64 64 Figura 18: Tela Login. Fonte: OS AUTORES (2011) Gerenciar Colaborador: São listados todos os colaboradores cadastrados e o usuário tem a opção de criar e editar colaboradores, conforme a Figura 19. Figura 19: Tela Colaboradores. Fonte: OS AUTORES (2011) Para criar um colaborador, o usuário informa o nome, o login, as iniciais do nome, o , o telefone e a senha. A opção invisível inativa o colaborador a fim de manter um histórico no sistema. Através da escolha de uma permissão, o colaborador é relacionado a um ou mais projetos. Para finalizar o cadastro, o usuário confirma a operação. Se o usuário não preencher os campos obrigatórios ou informar dados inválidos, o sistema exibe uma mensagem de alerta, caso contrário o colaborador é criado com sucesso, conforme a Figura 20.

65 65 Figura 20: Tela Cadastrar Colaborador. Fonte: OS AUTORES (2011) Gerenciar Projeto: São listados todos os projetos cadastrados relacionados a um determinado usuário e o usuário tem a opção de criar, editar e excluir projetos, conforme a Figura 21. Figura 21: Tela Projetos. Fonte: OS AUTORES (2011) Para criar um projeto, o usuário informa o nome e a descrição. A opção invisível inativa o projeto a fim de manter um histórico no sistema. Além disso, existe a opção de configurar o envio de alertas por para os desenvolvedores envolvidos no projeto que estão com atraso no apontamento de horas. O link da wiki

66 66 do projeto tem por finalidade documentar o projeto. Para finalizar o cadastro, o usuário confirma a operação. Se o usuário não preencher os campos obrigatórios ou informar dados inválidos, o sistema exibe uma mensagem de alerta, caso contrário o projeto é criado com sucesso, conforme a Figura 22. Figura 22: Tela Criar Projeto. Fonte: OS AUTORES (2011) Gerenciar Sprint: São listadas todas as Sprints cadastradas de um determinado projeto e o usuário tem a opção de criar, editar e excluir Sprints, conforme a Figura 23. Figura 23: Tela Listar Sprints. Fonte: OS AUTORES (2011)

67 67 Para criar uma Sprint, o usuário informa o nome, a data inicial, a data final e a descrição. Para finalizar o cadastro, o usuário confirma a operação. Se o usuário não preencher os campos obrigatórios ou informar dados inválidos, o sistema exibe uma mensagem de alerta, caso contrário a Sprint é criada com sucesso, conforme a Figura 24. Figura 24: Tela Criar Sprint. Fonte: OS AUTORES (2011) Gerenciar User Story: São listadas todas as User Stories cadastradas de uma determinada Sprint e o usuário tem a opção de criar, editar e excluir User Stories. Para finalizar uma User Story, o usuário seleciona a opção Fechar. Para visualizar todas as tarefas existentes, o usuário seleciona a opção Todas as Tasks, conforme a Figura 25.

68 68 Figura 25: Tela Listar User Stories. Fonte: OS AUTORES (2011) Para criar uma User Story, o usuário informa o nome, o tipo, o cliente, o tracker, o status, a prioridade, a ordem, as horas estimadas e a descrição. Para finalizar o cadastro, o usuário confirma a operação. Se o usuário não preencher os campos obrigatórios ou informar dados inválidos, o sistema exibe uma mensagem de alerta, caso contrário a User Story é criada com sucesso, conforme a Figura 26.

69 69 Figura 26: Tela Definir User Story. Fonte: OS AUTORES (2011) Gerenciar Task: São listadas todas as Tasks cadastradas e o usuário tem a opção de criar, editar e excluir Tasks, conforme a Figura 27.

70 70 Figura 27: Tela Listar Tasks. Fonte: OS AUTORES (2011) Para criar uma Task, o usuário informa o nome, o tipo, a situação, o revisor, as horas estimadas e a descrição. Para finalizar o cadastro, o usuário confirma a operação. Se o usuário não preencher os campos obrigatórios ou informar dados inválidos, o sistema exibe uma mensagem de alerta, caso contrário a Task é criada com sucesso, conforme a Figura 28.

71 71 Figura 28: Tela Definir Task. Fonte: OS AUTORES (2011) Gerenciar Apontamento de Horas: São listados todos os apontamentos de horas cadastrados e o usuário tem a opção de editar e excluir apontamentos, conforme a Figura 29. Figura 29: Tela Listar Apontamento de Horas. Fonte: OS AUTORES (2011)

72 72 Para realizar um apontamento, o usuário informa o colaborador, a descrição, a data e hora inicial e final ou a quantidade de horas restantes para o término da atividade, conforme as horas estimadas. Para finalizar o cadastro, o usuário confirma a operação. Se o usuário não preencher os campos obrigatórios ou informar dados inválidos, o sistema exibe uma mensagem de alerta, caso contrário o apontamento é realizado com sucesso, conforme a Figura 30. Figura 30: Tela Editar Apontamento. Fonte: OS AUTORES (2011) Gerar Gráficos de progresso da Sprint: O usuário visualiza os gráficos de Burndown e de progresso da Sprint, conforme a Figura 31. Figura 31: Tela Gráficos de progresso da Sprint. Fonte: OS AUTORES (2011)