UNIVERSIDADE DO SUL DE SANTA CATARINA DIEGO SALOMÃO
MARIA LUIZA DA SILVA
UM ESTUDO DE CASO UTILIZANDO FRAMEWORK SCRUM COM ARTEFATOS UML PARA APOIO AO DESENVOLVIMENTO DE SOFTWARE
Florianópolis/SC 2016
DIEGO SALOMÃO MARIA LUIZA DA SILVA
UM ESTUDO DE CASO UTILIZANDO FRAMEWORK SCRUM COM ARTEFATOS UML PARA APOIO AO DESENVOLVIMENTO DE SOFTWARE
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina.
Orientador: Maurício Botelho, MEng.
Florianópolis/SC 2016
DIEGO SALOMÃO MARIA LUIZA DA SILVA
UM ESTUDO DE CASO UTILIZANDO FRAMEWORK SCRUM COM ARTEFATOS UML PARA APOIO AO DESENVOLVIMENTO DE SOFTWARE
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de informação de Informação da Universidade do Sul de Santa Catarina.
Florianópolis, 15 de junho de 2016.
______________________________________________________ Professor e orientador Maurício Botelho, MEng.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Edson Lessa, Esp.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Flávio Ceci, Dr.
Dedicamos esta monografia aos nossos pais e irmãos que sempre nos apoiaram, ao nosso orientador Prof. Maurício Botelho que sempre muito prestativo, contribuiu muito para que este trabalho fosse concluído e, ainda, a todos os professores do nosso curso.
AGRADECIMENTOS
Diego Salomão agradece a:
A Deus por permitir e dar forças para que este sonho pudesse ser alcançado.
Aos meus pais e irmão que me apoiaram em todos os momentos e, que mesmo distantes, me deram força, conselhos e incentivos para a realização deste sonho.
Ao nosso orientador Prof. Maurício Botelho, pela atenção, apoio e recomendações para a execução do trabalho.
A Prof.ª Maria Inés Castiñeira, que nos conduziu na elaboração deste trabalho.
As instituições UNIUBE e UNISUL onde pude ter o contato com os mestres e os colegas de curso que tiveram grande participação nesta jornada.
A Ana Marta, que nos permitiu utilizar a sua empresa como parte fundamental para a realização deste trabalho e disponibilidade em nos receber.
A minha parceira deste trabalho, Maria Luiza da Silva, pelo último ano em que passamos juntos para a realização deste trabalho, pela dedicação e paciência.
E a todos que participaram direta ou indiretamente deste momento, muito obrigado.
Maria Luiza da Silva agradece a:
Meu pai, por sua confiança e investimento em mim, sem os quais não poderia ter concluído esse curso. Também gostaria de agradecer a minha mãe, por seu apoio inabalável e confiança em mim.
Ao nosso orientador Prof. Maurício Botelho, por sua orientação sempre presente, sua disposição em nos ajudar e tirar dúvidas em qualquer momento que fosse necessário.
A Prof.ª Maria Inés Castiñeira, por seu apoio em momentos de insegurança e por seus conselhos.
A proprietária da cantina, Ana Marta, que nos permitiu utilizar o seu negócio como case para realizar a implementação do sistema e que sempre esteve disponível para marcar encontros e tirar dúvidas.
A todos os meus familiares e amigos que me apoiaram e encorajaram para a conclusão desse trabalho.
Ao Clayton Boneli, por me ensinar a programação na prática e compartilhar muitos dos seus conhecimentos comigo que foram muito importantes para a implementação do sistema realizado neste trabalho.
Por fim, não poderia deixar de agradecer ao meu parceiro desse trabalho, Diego Salomão, por ter passado esses dois semestres comigo realizando esse trabalho e por dar o seu melhor em tudo o que faz.
“O sucesso nasce do querer, da determinação e persistência em se chegar a um objetivo. Mesmo não atingindo o alvo, quem busca e vence obstáculos, no mínimo fará coisas admiráveis.” (José de Alencar).
RESUMO
A engenharia de software apresenta diferentes modelos de processos de desenvolvimento de software, dentre estes, estão os modelos tradicionais e os modelos ágeis. Os modelos tradicionais apresentam uma forma mais incisiva em documentação de software e abordam a utilização da Unified Modeling Language (UML) para elaboração de diferentes diagramas para proporcionar diferentes visões do sistema. Os modelos ágeis defendem que a interação entre as pessoas são mais importantes que a documentação, mas não restringe que seja documentado. Alguns dos principais motivos apresentados pelos autores que defendem as metodologias ágeis, são a dificuldade em manter uma documentação atualizada devido à mudanças que frequentemente ocorrem durante a fase de desenvolvimento de sistemas e também que as pessoas são mais importantes que os processos. Este trabalho apresenta uma pesquisa aplicada que busca documentar e conduzir o desenvolvimento de um software utilizando o framework Scrum com seus respectivos artefatos (histórias de usuário e critérios de aceite) apoiado a alguns dos diagramas da UML, sendo eles o de casos de uso, o de classes e o de sequências. A junção de alguns diagramas da UML em um processo de desenvolvimento que utiliza o Scrum pode agregar muito para que mesmo sendo um projeto que utiliza princípios ágeis, possa conter o mínimo de uma documentação que de fato tenha sentido para o desenvolvimento e que agregue valor ao processo, porém, sem perder o foco ágil. Para testar o objetivo deste trabalho, foi realizado o desenvolvimento de um software de gestão para uma cantina escolar com funcionalidades simples, seguindo o Scrum. Foram elaborados os respectivos diagramas da UML e os artefatos previstos do Scrum, ao final, o software foi desenvolvido dentro do prazo e os critérios de aceitação foram atendidos, o que demonstra um resultado positivo da metodologia utilizada em relação ao cenário.
Palavras chaves: Metodologias de Desenvolvimento. Metodologias Ágeis. Scrum. Scrum com UML.
ABSTRACT
Software Engineering applies different methods of software development processes. We can list among them the classic or waterfall model and the agile model: the classic model is strict when it comes to software documentation and makes use of the Unified Modeling Language (UML) for the preparation of different diagrams which provides different views of the system. The agile model priorizes the interaction with people even more than documentation, what doesn´t mean that documentation is not important. Actually, it is really difficult to maintain a up to date documentation in this method due to the several changes during the system development phase. Besides that, user’s involvment is imperative. It is over the processes. This paper presents an applied research that documents and conduces the development of a software which makes use of the Scrum Framework as its characteristics (computer's users stories and acceptance criterias). Also it presents some UML diagrams as the use case diagram, the class diagram and the sequence diagram in a case study. The addition of some UML diagrams in a development process using Scrum can add up a lot even though its a project using agile principles. It helps the project in a way it contains the minimum documentation necessary to develop and it also values the process. All of that without losing the agile focus . To test the objective of this work was carried out a development of a management software for a school canteen with its simple functionalities, following the Scrum. Their UML diagrams and expected characteristics of Scrum were prepared at the end. The software was developed on time and the acceptance criterias have been met, which shows a positive result of the methodology used in the scenary.
Keywords: Development Methodologies. Agile Methodologies. Scrum. Scrum with UML.
LISTA DE ILUSTRAÇÕES
Figura 1 – Camadas da engenharia de software ... 23
Figura 2 – O modelo em Cascata ... 25
Figura 3 – O processo de desenvolvimento de software na realidade ... 26
Figura 4 – O modelo em Espiral ... 27
Figura 5 – Framework e utilização do RUP ... 29
Figura 6 – O ciclo de vida de desenvolvimento de um software ... 30
Figura 7 – Processo XP ... 35
Figura 8 – Planejamento da Sprint ... 36
Figura 9 – Três exemplos de formatos de Product Backlog ... 39
Figura 10 – Exemplo de História de Usuário ... 40
Figura 11 – Sprint Backlog ... 41
Figura 12 – Ciclo de vida do Scrum ... 42
Figura 13 – Representação esquemática de uma Sprint ... 43
Figura 14 – Exemplo simples de definição de preparado ... 44
Figura 15 – Gráfico de Burndown ... 46
Figura 16 – Exemplo simples de um acordo de definição de pronto ... 47
Figura 17 – O ciclo de vida de desenvolvimento de um software ... 50
Figura 18 – Representação da classe ... 54
Figura 19 – Notação de generalização ... 55
Figura 20 – Agregação ... 56
Figura 21 – Composição ... 56
Figura 22 – Diagrama de Classes ... 56
Figura 23 – Exemplos de atores ... 58
Figura 24 – Documentação do caso de uso de abertura de conta ... 58
Figura 25 – Diagrama de caso de uso - include ... 59
Figura 26 – Diagrama de caso de uso - extend ... 60
Figura 27 – Diagrama de caso de uso - generalização ... 60
Figura 28 – Diagrama de caso de uso – atores x casos de uso ... 61
Figura 29 – Tipos de mensagens ... 63
Figura 30 – Diagrama de sequência ... 63
Figura 31 – Etapa metodológica ... 67
Figura 32 – Arquitetura da solução ... 68
Figura 33 – Diagrama de Caso de Uso e Atores ... 77
Figura 34 – Diagrama de Classes – Cantina Escolar ... 95
Figura 35 – Diagrama de Sequência – Incluir Venda ... 96
Figura 36 – Diagrama de Sequência – Alterar Venda ... 97
Figura 37 – Diagrama de Sequência – Consultar Venda ... 98
Figura 38 – Diagrama de Sequência – Excluir Venda ... 98
Figura 39 – Tarefas da Sprint 4 ... 102
Figura 40 – Gráfico de Burndown – Sprint 4 ... 104
Figura 41 – Ferramentas Utilizadas ... 108
Figura 42 – Interface da tela que permite inserir créditos ... 116
Figura 43 – Interface da tela que permite a realização de vendas ... 117
Figura 44 – Interface da tela que permite a finalização de vendas ... 118
LISTA DE QUADROS
Quadro 1 – Atributos essenciais de um bom software. ... 22
Quadro 2 – Princípios dos métodos ágeis ... 32
Quadro 3 – Divisão de tarefas nos papéis do Scrum. ... 38
Quadro 4 – Exemplo de Critérios de Aceitação ... 40
Quadro 5 – Exemplos de multiplicidade ... 55
Quadro 6 – Descrição dos Requisitos Funcionais ... 73
Quadro 7 – Descrição dos Requisitos Não Funcionais ... 74
Quadro 8 – Descrição das Regras de Negócio ... 74
Quadro 9 – Documentação do caso de uso “Cadastrar Produtos” ... 77
Quadro 10 – Documentação do caso de uso “Cadastrar Clientes” ... 79
Quadro 11 – Documentação do caso de uso “Cadastrar Fornecedores”... 81
Quadro 12 – Documentação do caso de uso “Recarregar Saldo em Cartão” ... 84
Quadro 13 – Documentação do caso de uso “Registrar compras” ... 84
Quadro 14 – Documentação do caso de uso “Realizar Venda de Produtos” ... 86
Quadro 15 – História de usuário – “Cadastro de Clientes” ... 90
Quadro 16 – História de usuário – “Cadastro de Fornecedores” ... 91
Quadro 17 – História de usuário – “Cadastro de Produtos” ... 91
Quadro 18 – História de usuário – “Recarga de Saldo em Cartão” ... 92
Quadro 19 – História de usuário – “Compra de Produtos” ... 92
Quadro 20 – História de usuário – “Venda de Produtos” ... 93
Quadro 21 – Time Scrum ... 99
Quadro 22 – Planejamento das Sprints ... 100
Quadro 23 – Estimativa das tarefas da história “Venda de Produtos” ... 103
SUMÁRIO 1 INTRODUÇÃO ... 14 1.1 PROBLEMA ...17 1.2 OBJETIVOS ...18 1.2.1 Objetivo Geral ...19 1.2.2 Objetivos Específicos ...19 1.3 JUSTIFICATIVA ...19 1.4 ESTRUTURA DA MONOGRAFIA ...20 2 ENGENHARIA DE SOFTWARE ... 22
2.1 MODELOS DE DESENVOLVIMENTO DE SOFTWARE ...24
2.1.1 Modelos Tradicionais...24
2.1.1.1 Modelo em Cascata ... 25
2.1.1.2 Modelo em Espiral ... 26
2.1.2 Rational Unified Process (RUP) ...28
2.1.3 Modelos Ágeis ...31
2.1.3.1 Extreme Programming (XP) ... 33
2.1.3.2 Scrum ... 35
2.1.3.2.1 Papéis do Scrum ...37
2.1.3.2.2 Product Backlog ...38
2.1.3.2.2.1 HISTÓRIAS DE USUÁRIO (USER STORIES) ... 39
2.1.3.2.2.2 CRITÉRIOS DE ACEITAÇÃO ... 40
2.1.3.2.3 Sprint Backlog ...41
2.1.3.2.4 Sprint ...41
2.1.3.2.5 Reunião de Planejamento da Sprint (Sprint Planning) ...43
2.1.3.2.6 Scrum Diárias (Daily Scrum) ...45
2.1.3.2.6.1 GRÁFICO BURNDOWN ... 45
2.1.3.2.7 Revisão da Sprint (SPRINT REVIEW) ...46
2.1.3.2.8 Retrospectiva da Sprint (Sprint Retrospective) ...48
2.2 DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A UNIFIED MODELING LANGUAGE (UML) ...48
2.2.1 Requisitos ...51
2.2.1.1.1 Requisitos Funcionais ...51
2.2.1.1.2 Requisitos Não funcionais...52
2.2.1.1.3 Regras de Negócio ...53
2.2.2 Diagrama de Classes ...53
2.2.3 Diagrama de Casos de Uso ...57
2.2.4 Diagrama de Sequência ...62
2.3 SCRUM COM UML ...64
3 MÉTODO ... 65
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...65
3.2 ETAPAS DE EXECUÇÃO DO PROJETO ...66
3.3 ARQUITETURA DA SOLUÇÃO...68
3.4 DELIMITAÇÕES ...69
4 MODELAGEM ... 70
4.1 O CASE UTILIZADO PARA APLICAR A PROPOSTA ...70
4.1.1 Etapa de Levantamento de Requisitos ...71
4.1.2 Etapa de Desenvolvimento da Proposta ...72
4.1.2.2 Product Backlog ... 89 4.1.2.2.1 Histórias de Usuário ...89 4.1.2.3 Time do SCRUM ... 99 4.1.2.4 SPRINT ... 100 4.1.2.5 SPRINT Planning ... 100 4.1.2.6 SPRINT Backlog ... 101 4.1.2.7 Tarefas ... 101 4.1.2.8 Reunião Diária... 103 4.1.2.9 Revisão da SPRINT ... 105 4.1.2.10 Retrospectiva da SPRINT ... 105 5 DESENVOLVIMENTO DA PROPOSTA ... 108 5.1 FERRAMENTAS E TECNOLOGIA ...108 5.1.1 Java ...109
5.1.2 Enterprise Architect (EA) ...109
5.1.3 Trello ...109 5.1.4 Maven ...110 5.1.5 JSF ...110 5.1.6 Primefaces ...110 5.1.7 Eclipse ...111 5.1.8 Mysql ...111 5.1.9 Tomcat ...111 5.1.10 Balsamiq ...112
5.2 PROCESSOS DE DESENVOLVIMENTO (HISTÓRIA) ...112
5.3 APRESENTAÇÃO DO SISTEMA ...116
5.4 CONSIDERAÇÕES FINAIS ...119
6 CONCLUSÕES E TRABALHOS FUTUROS ... 121
6.1 CONCLUSÂO ...121
6.2 TRABALHOS FUTUROS ...123
REFERÊNCIAS ... 124
APÊNDICES ... 127
1 INTRODUÇÃO
O processo de desenvolvimento de software sempre foi um assunto bastante discutido. Tais processos visam dar suporte aos quesitos produtividade e qualidade que atendam as expectativas do cliente e que sejam viáveis para o negócio.
Quando se iniciava a década de 1980, uma reportagem de primeira página da revista Business Week trazia a seguinte manchete: “Software: A Nova Força Propulsora”. O software amadurecera – tornara-se um tema de preocupação administrativa. Em meados da década de 1989, uma reportagem de capa de Fortune lamentava “Uma Crescente Defasagem de Software” e, ao final da década, a Business Week avisava os gerentes sobre a “Armadilha do Software – Automatizar ou não”. No começo da década de 1990, uma reportagem especial da Newsweek perguntava: “Podemos Confiar em Nosso Software:” enquanto o Wall Street Journal relacionava as “dores de parto” de uma grande empresa de software com um artigo de primeira página intitulado “Criar Software Novo: Era uma Tarefa Agonizante...”. Essas manchetes, e muitas outras iguais a elas, eram o anúncio de uma nova compreensão da importância do software de computador – as oportunidades que ele oferece e os perigos que apresenta. (PRESSMAN, 1995, p. 3).
Com a exploração do potencial de softwares para melhor posicionamento de mercado das empresas foi preciso oferecer soluções que de fato atendessem as necessidades das organizações e que agregassem valor ao negócio.
O objetivo principal de um software é dar suporte aos usuários; logo, para o software ter sucesso, ele deverá atender às expectativas e necessidades dos usuários que o utilizarão. Neste contexto, a palavra usuário não se refere apenas a pessoas, ela pode designar também outros sistemas que tenham que interagir com o software em questão. (MARTINS, 2006, p. 138).
Conforme abordado por Hirama (2011), em busca de atingir os objetivos do software, com o tempo foram propostos alguns processos para conduzir o desenvolvimento de software. Um dos processos de desenvolvimento bastante utilizado nas décadas de 1970 e 1980 foi o modelo Cascata. Como o próprio nome já sugere, este processo é composto por etapas que são dependentes uma da outra. Comumente é utilizado quando os requisitos estão bem definidos e possuem uma boa estabilidade (PRESSMAN, 2011). Uma das desvantagens deste modelo, é que pode acarretar em problemas caso houver a necessidade de alteração de requisitos, visto que o respectivo modelo não permite alterações no meio do processo, pois
prevê que uma funcionalidade apenas poderá ser alterada após ter sido concluída (SANTANA, 2013).
O processo Cascata define um desenvolvimento linear e sequencial do software. Da maneira como é proposto, ele não se adapta facilmente às novas exigências de mercado. Enquanto o processo Cascata é focado na entrega de um sistema completo no fim do seu processo, os processos Evolutivos são iterativos: o software é desenvolvido evolutivamente em direção ao produto final cada vez mais completo. (HIRAMA, 2011, p. 31).
De forma geral, Hirama (2011) apresentou que o modelo Cascata possui algumas limitações que podem comprometer o projeto caso os requisitos não estejam estáveis. Para solucionar alguns pontos negativos do modelo Cascata, foram apresentados alguns processos do tipo “Evolutivo”. A diferença básica entre estes processos é que o processo Evolutivo suporta alterações de requisitos durante o desenvolvimento do software, o que proporciona melhor controle e gestão de riscos do projeto.
Um modelo Evolutivo que foi apresentado é o Espiral, Pressman (2011, p. 65), afirma que este “é um modelo de software evolucionário que acopla a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo cascata”, o que potencializa o desenvolvimento de versões mais completas do software.
Dos modelos de desenvolvimento tradicionais apresentados até então, segundo Medeiros (2004), eles dão uma visão única do processo, e com a necessidade de se obter uma visão do projeto como um todo, Ivar Jacobson apresentou uma nova forma de se ver o processo de desenvolvimento, este com foco na arquitetura. Este processo é o Rational Unified Process (RUP).
De acordo com Mendes (2014), O RUP é um processo de desenvolvimento de software criado pela Rational Software Corporation e em 2003 foi adquirida pela IBM. O RUP consiste em várias etapas de entregas de forma a agregar mais valor ao produto e diminuir os riscos de projeto. Ao utilizar o RUP, ocorrem validações e verificações do que foi produzido, permitindo um melhor gerenciamento. A linguagem utilizada para apoiar o RUP é a Unified Modeling
Language (UML), que de maneira geral, é destinada a visualizar, especificar,
Matos et al. (2014), cita que as necessidades de mercado como a rápida evolução tecnológica, pressão para que o sistema seja entregue rapidamente e mudanças frequentes no ambiente de negócio do cliente, trouxeram novos desafios para a engenharia de requisitos. As Metodologias Ágeis (MA) surgiram com o objetivo de atender a esta demanda, com foco principal em garantir a entrega de um software em menor tempo, com qualidade e que atenda as necessidades do cliente.
Visando customizar o processo de desenvolvimento de software, Sutherland (2014) começou a pesquisar novas formas de melhorar o modo de trabalho, o que mais tarde ficou conhecido como Scrum. O Scrum é um framework de MA que vem sendo adotado por várias empresas, pois busca realizar uma melhoria contínua no processo, onde ao final do processo de desenvolvimento, é realizada uma retrospectiva de alinhamento que permite verificar o que pode ser melhorado. O Scrum busca uma nova forma de trabalho, que propõe maior foco na produtividade por meio da interação dos próprios desenvolvedores e clientes.
Scrum é um framework para gerenciamento de projetos ágeis muito utilizado na área de desenvolvimento de software. Uma das principais características do Scrum é permitir o desenvolvimento de produtos complexos de uma forma incremental e iterativa, contribuindo para decompor um grande produto complexo, em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem desenvolvidos e entregues. No Scrum estas iterações são chamadas de Sprints, e uma característica marcante de sua estrutura e aplicação é o controle sobre os trabalhos realizados, e a possibilidade de correção e adaptação rápida, permitindo que a equipe altere sua forma de agir ou de pensar o mais breve possível, evitando que problemas ou erros causem danos maiores ao projeto. (MARIOTTI, 2012, p. 7).
Santana (2014) apresenta um comparativo entre os processos de desenvolvimento RUP e Scrum, onde de um lado o RUP apresenta uma proposta de metodologia bem estruturada e que é aceita com sucesso no mercado de desenvolvimento de software, porém requer grande número de documentos em seu modelo, o que leva a ser considerado como uma abordagem pesada e muito burocrática. Por outro lado, o Scrum apresenta uma abordagem que valoriza mais a interação com o cliente para diminuir a necessidade de documentação, o que propõe que seja apresentado resultados mais rápidos, uma vez que há o acompanhamento mais próximo do cliente junto ao desenvolvimento.
Com base nos cenários expostos do RUP e MA, este trabalho propõe o uso do framework Scrum apoiado a alguns diagramas da UML para auxiliar na elicitação das funcionalidades de sistema, tendo como estudo de caso um cenário
que possibilite testar a utilização dos artefatos a serem levantados. Ao final, espera-se obter um sistema com qualidade, consumindo menor recurso de tempo e que principalmente, atenda as necessidades de negócio.
1.1 PROBLEMA
Os processos de desenvolvimento de software estão sempre evoluindo para satisfazer as necessidades de mercado. Para Machado (2011, p. 19), “a evolução das técnicas para processos de desenvolvimento de software é uma constante na busca da construção de sistemas mais confiáveis, dentro de prazos razoáveis, e com qualidade que satisfaça as necessidades do cliente final”.
De um lado o Scrum propõe uma forma interativa do time de desenvolvimento e cliente (SUTHERLAND, 2014), e de outro, diversos autores da literatura de engenharia de software apresentam a importância de se documentar software (PRESSMAN, 2011; BOOCH et al., 2000).
Aproveitando a necessidade de uma cantina escolar, localizada no município de São José – SC, de controlar o movimento de vendas, este trabalho utiliza este cenário como um case para testar a utilização de uma forma de desenvolvimento que possa resultar em um software para a cantina. Busca-se uma forma que o cliente possa participar do projeto de forma efetiva, que o software seja entregue em menor tempo, que seja previsto a possibilidade de alteração de requisitos durante o desenvolvimento e que satisfaça as necessidades da proprietária da cantina.
Conforme uma prévia apresentada na introdução deste trabalho, os modelos em cascata e espiral, não seriam uma boa escolha para atingir o objetivo do trabalho visto que o modelo cascata apresenta restrições à mudança de requisitos durante o processo de desenvolvimento (HIRAMA, 2011), e o modelo espiral apesar de possibilitar a alteração de requisitos, segundo Sommerville (2007) exige uma série de avaliações para gerenciamento de riscos que podem comprometer o tempo de entrega para o cliente.
O RUP seria uma opção para este trabalho, porém, dentre algumas desvantagens que ele apresenta, uma bastante relevante que o levou não ser escolhido neste projeto, foi o fato de que exige um grande número de documentos (SANTANA, 2014), o que pode ser muito burocrático para o cenário exposto da cantina.
Por último, o método ágil Scrum parece ser uma boa alternativa para se utilizar neste cenário, visto que conforme apresentado por Santana (2014), apresenta uma abordagem que valoriza muito a interação com o cliente para diminuir a documentação. Havendo a necessidade de se utilizar uma documentação mais técnica para apoiar o desenvolvimento, a utilização da UML é uma boa alternativa, pois conforme um experimento que Silva (2012, p. 16), realizou utilizando a UML em um projeto Scrum, ele compartilha a conclusão de que “qualquer projeto pode seguir práticas ágeis e utilizar artefatos UML que se encaixem no seu processo de desenvolvimento”, e finaliza enfatizando que o Scrum não limita utilizar a UML em seu ciclo de vida.
O desenvolvimento de software utilizando apenas o Scrum pode deixar a desejar de uma documentação básica que auxilia tanto a elicitação das necessidades do cliente quanto os desenvolvedores a construir algo que de fato o cliente espera.
1.2 OBJETIVOS
Apresentam-se os objetivos a serem alcançados através de um estudo de caso.
1.2.1 OBJETIVO GERAL
Utilizar o framework Scrum em conjunto com diagramas da UML para analisar a eficácia destas abordagens no decorrer das etapas de análise e desenvolvimento de software.
1.2.2 OBJETIVOS ESPECÍFICOS
Os objetivos específicos deste trabalho são:
Realizar pesquisa bibliográfica para levantar informações que embasam a produção deste trabalho;
Elaborar modelagem e documentação utilizando Scrum e diagramas da UML para o desenvolvimento de software utilizando um cenário para estudo de caso;
Desenvolver um software testando os artefatos de análise produzidos;
Apresentar os resultados obtidos do teste de desenvolvimento com os artefatos produzidos.
1.3 JUSTIFICATIVA
Considerando que o principal produto de um time de desenvolvimento seja um software que atenda as expectativas e necessidades dos usuários e seus respectivos negócios (BOOCH et al., 2000), é importante que o processo de desenvolvimento seja ajustado para que possa atender a estes princípios.
Em determinados projetos de desenvolvimento de software, pode ser que uma proposta de documentar o projeto inteiro seguindo modelagens tradicionais
torne-se exaustivo e não traga um custo/benefício que o justifique como sendo um pré-requisito indispensável a ser adotado para documentar as necessidades a serem atendidas do cliente.
Há a hipótese de se utilizar o Scrum apoiado a alguns diagramas da UML para conduzir um processo de desenvolvimento de software orientado às metodologias ágeis. Para Silva (2012 p. 16), “qualquer projeto pode seguir práticas ágeis e utilizar artefatos UML que se encaixem no seu processo de desenvolvimento”.
Considerando então que não há restrições nas metodologias ágeis para se utilizar a UML como ferramenta de apoio para documentação, este trabalho busca desenvolver um software utilizando o Scrum de forma a minimizar custos com mudanças e propor maior flexibilidade para caso houver alterações de requisitos. Procura-se verificar se é possível elaborar uma documentação para desenvolvimento de software que possua qualidade, que atenda as necessidades do cliente, porém prezando a documentar apenas o essencial e, aproveitar ao máximo os princípios das metodologias ágeis (interação entre as pessoas).
1.4 ESTRUTURA DA MONOGRAFIA
O trabalho está organizado em 6 capítulos. O Capítulo 1 apresenta a introdução, o problema, os objetivos gerais e específicos e a justificativa que motivou a realização do trabalho.
O Capítulo 2 apresenta os conceitos básicos sobre engenharia de software, modelos de desenvolvimento tradicionais e ágeis. Ao final, apresenta-se um fechamento abordando de forma conjunta como a UML pode ser introduzida no desenvolvimento de software que utiliza o framework Scrum.
O Capítulo 3 apresenta o método científico e a proposta de solução para a obtenção de um documento para o desenvolvimento de software utilizando o Scrum com apoio de diagramas da UML, além das delimitações a que este trabalho se propõe.
O Capítulo 4 apresenta a modelagem do trabalho, desde o levantamento de requisitos, passando pelo planejamento previsto pelo Scrum, como a UML foi utilizada para apoiar o desenvolvimento, até o fechamento do ciclo da sprint.
O Capítulo 5 apresenta as ferramentas utilizadas para o desenvolvimento deste trabalho, bem como o sistema que foi produzido como case para testar a aplicabilidade deste trabalho.
O Capítulo 6 apresenta as conclusões, considerações finais e trabalho futuros.
2 ENGENHARIA DE SOFTWARE
Para dar início ao tema principal deste trabalho, bem como abordar os assuntos que embasam todo o contexto, é importante apresentar o tema de engenharia de software, pois assim será possível obter informações para uma melhor compreensão das abordagens que serão utilizadas neste trabalho.
O software se tornou essencial para o mundo moderno, uma espécie de combustível, pois propicia diversos mecanismos de controle baseados em infraestrutura que dispõem de sistemas de computador, por exemplo, a maioria dos produtos elétricos possuem um computador e um software para controlá-lo. (KRUCHTEN, 2003; SOMMERVILLE, 2007).
Para Sommerville (2007), não existem limitações físicas no potencial de software e isso simplifica a engenharia de software. Porém essa falta de restrições pode ser perigosa, pois este software pode se tornar difícil de ser compreendido se ficar muito complexo. Diante disso, Sommerville destaca os atributos indispensáveis para um software, conforme demonstra o quadro 1.
Quadro 1 – Atributos essenciais de um bom software.
Características do produto Descrição
Facilidade de manutenção
O software deve ser escrito de modo que possa evoluir para atender às necessidades de mudança dos clientes. É um atributo fundamental, pois a mudança de software é uma consequência inevitável de um ambiente de negócios em constante mutação.
Confiança
O nível de confiança do software tem uma série de características, incluindo confiabilidade, proteção e segurança. Um software confiável não deve causar danos físicos ou econômicos no caso de falha no sistema.
Eficiência
O software não deve desperdiçar os recursos do sistema, como memória e ciclos do processador. Portanto, a eficiência inclui tempo de resposta, tempo de processamento, utilização de memória etc.
Usabilidade
O software deve ser usável, sem esforço excessivo, pelo tipo de usuário para o qual ele foi projetado. Isso significa que ele deve apresentar uma interface com o usuário e documentação adequadas
Fonte: SOMMERVILLE (2007, p. 9).
Diante dos atributos essenciais de um bom software apresentado por Sommerville (2007) representados no quadro 1, Martins (2006) e Kruchten (2003)
por outro lado, apresentam causas que podem levar projetos de desenvolvimento de software ao fracasso. Alguns dos itens mencionados por estes autores são: o gerenciamento informal dos requisitos, a não compreensão das necessidades do cliente, falta de flexibilidade para gerenciar a mudança de requisitos, falta de experiência para prever possíveis falhas de projeto, falta de organização e comunicação com a equipe envolvida no projeto, testes insuficientes, dentre outros.
Com o conceito de software bem definido, fica mais fácil o entendimento do que é Engenharia de Software, para Pressman (2011, p. 39) “a engenharia de software é um ramo da engenharia cujo foco é o desenvolvimento dentro de custos adequados de sistemas de software de alta qualidade [...]”.
Qualquer abordagem de engenharia precisa estar fundamentada e comprometida com a qualidade, desta forma, os engenheiros e demais pessoas envolvidas precisam estar aptas a aplicarem métodos e ferramentas que atendam as necessidades apoiados por processos, conforme esboço demonstrado na figura 1 (PRESSMAN, 2011; SOMMERVILLE, 2007).
Figura 1 – Camadas da engenharia de software
Fonte: PRESMAN (2011, p. 39).
De acordo com a figura 1, observa-se que as camadas da engenharia de software têm como base o foco na qualidade.
Nos últimos 50 anos diferentes grupos, especialistas e pesquisadores da área de TI, vêm disponibilizando diversas metodologias para apoiar essa difícil tarefa de desenvolvimento de software, tais como: modelo cascata, espiral, RAD, RUP, Crystal, Scrum, XP, PFF, Lean, DSDM entre outros (MARIOTTI, 2012, pág. 6).
Existem diversas abordagens para desenvolver um software. Para Sommerville (2007, p. 4) “[...] noções fundamentais de processo e de organização de
sistemas constituem a base de todas essas técnicas que constituem a essência da engenharia de software”.
2.1 MODELOS DE DESENVOLVIMENTO DE SOFTWARE
Na engenharia de software existem diversos modelos de processo de desenvolvimento, e muitos foram propostos ao logo dos anos (PFLEEGER, 2004).
Segundo Pfleenger (2004, p. 38) “todo processo de desenvolvimento de software tem como entrada os requisitos do sistema e como saída um produto fornecido”.
Os modelos tradicionais geralmente são desenvolvidos em sequencia em que as etapas de planejamento, análise, design, codificação, testes e documentação são feitas uma única vez e em sequência. Já os modelos ágeis, geralmente são utilizados ciclos curtos com duração de poucas semanas, o que facilita mudanças, pois proporciona um feedback constante (GOMES, 2013). A seguir são abordados os modelos tradicionais e ágeis.
2.1.1 MODELOS TRADICIONAIS
Os modelos de tradicionais de desenvolvimento de software permitem maior controle do andamento do projeto, visto que as atividades precisam ser executadas em ordem para que o processo funcione como um todo (MATOS et al., 2014).
“Em contra partida, os processos tradicionais ou em cascata, que eram amplamente utilizados do mercado antes dos métodos ágeis, assumem que o desenvolvimento de software pode ser realizado através de uma sequência de atividades facilmente identificadas, previsíveis e repetíveis, mas diferente de outras engenharias, desenvolvimento de software requer criatividade, e geralmente envolve um ato.” (GOMES, 2013, pág. 9).
Dos modelos tradicionais de desenvolvimento de software, serão apresentados alguns dos mais populares, sendo eles: Modelo Cascata e Modelo em Espiral. Em seguida, será apresentado o RUP, uma unificação dos processos tradicionais. Apesar de não ser o foco principal deste trabalho, os respectivos modelos tradicionais serão apresentados de forma sucinta para criar um embasamento de forma a levar a um melhor entendimento do porque da utilização do Scrum com apoio da UML que será abordado posteriormente.
2.1.1.1 MODELO EM CASCATA
No modelo em Cascata existe um encadeamento de uma fase com a outra, no qual o desenvolvimento deve terminar antes do próximo começar. Inicia-se quando todos os requisitos estiverem enunciados pelo cliente de forma completa, analisadas as consistências destes requisitos e tiverem sido documentadas em uma especificação de requisitos. A partir de então, o time de desenvolvimento pode realizar as atividades de projeto do sistema. É possível entender bem este modelo observando a figura 2 (PFLEEGER, 2004; SOMMERVILLE, 2007).
Figura 2 – O modelo em Cascata
Sommerville (2007) destaca que as vantagens deste modelo são que em cada fase existe uma documentação e sua aderência a outros modelos de processo de engenharia. E a grande desvantagem é a dificuldade de alterações de requisitos do usuário, por isso é sugerido que este modelo seja usado quando os requisitos forem bem definidos e a probabilidade de mudança for muito pouca.
A figura 3 mostra o quanto pode ser difícil seguir o modelo em Cascata, considerando um cenário que necessite de alterações de requisitos ou que algo faça com que seja necessário realizar uma tarefa anterior.
Figura 3 – O processo de desenvolvimento de software na realidade
Fonte: PFLEEGER (2004, p. 40).
O modelo Cascata passou a ser questionado na década de 1990 devido às exigências de produtividade e qualidade, quando da chegada dos métodos ágeis que traziam esta proposta (HIRAMA, 2011).
2.1.1.2 MODELO EM ESPIRAL
Tanto Pfleenger (2004) como Sommerville (2007), apontam que o modelo em Espiral foi proposto por Boehm, pois ele buscava encontrar uma forma de
controlar os riscos, sendo assim, sugeriu que este modelo poderia combinar atividades de desenvolvimento com o gerenciamento de riscos.
Segundo Pfleenger (2004, p. 46), “em cada iteração, análise de riscos poderá diferentes alternativas em face dos requisitos e das restrições. A prototipação verifica a viabilidade e a adequação, antes que haja a decisão por alguma alternativa”.
Um ciclo da espiral começa com a elaboração de objetivos, como desempenho e funcionalidade. Os caminhos alternativos para alcançar esses objetivos e as fontes de riscos de projetos são identificados. O próximo passo é resolver esses riscos por meio de atividades de coleta de informações, tais como análise mais detalhada, prototipação e simulação. Após a avaliação dos riscos, é realizada uma parte do desenvolvimento, seguida pela atividade de planejamento para a próxima fase do processo (SOMMERVILLE, 2007, pág. 49).
Com a figura 4, pode-se entender melhor o funcionamento do modelo Espiral.
Fonte: PFLEEGER (2004 p. 49).
Observe que o modelo Espiral inicia-se na atividade de planejamento e segue a partir de seu centro no sentido horário. Este modelo permite que tanto o cliente quanto o desenvolvedor compreendam os riscos em cada nível da evolução do projeto. Note que diferente do modelo cascata, há diversas etapas de validação da fase anterior (HIRAMA, 2011).
2.1.2 RATIONAL UNIFIED PROCESS (RUP)
Sommerville (2007, p. 54), menciona que “o Rational Unified Process (RUP) é um exemplo de processo moderno que foi derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software associado”.
O Processo Unificado é uma tentativa de aproveitar os melhores recursos e características dos modelos tradicionais de processo de software, mas caracterizando-os de modo a implementar muitos dos melhores princípios do desenvolvimento ágil de software. O Processo Unificado reconhece a importância da comunicação com o cliente e de métodos racionalizados (sequencializados) para descrever a visão do cliente sobre um sistema (os
casos de uso). Ele enfatiza o importante papel da arquitetura de software e “ajuda o arquiteto a manter o foco nas metas corretas, tais como compreensibilidade, confiança em mudanças futuras e reutilização”. Ele sugere um fluxo de processo iterativo e incremental, proporcionando a sensação evolucionária que é essencial no desenvolvimento de software moderno (PRESSMAN, 2011, p. 71).
De acordo com Martins (2006, p. 175), o RUP “é uma metodologia para gerenciar projetos de desenvolvimento de software que usa o UML como ferramenta para especificação de sistemas”.
O RUP define as etapas do projeto, os papéis de quem deve executar cada uma destas etapas, quando deverá ser executada, o que deve ser gerado durante o processo de desenvolvimento e como deverá ser feito, de forma que o projeto possa atingir os objetivos finais que é a concepção de um novo software ou a evolução de um já existente (MARTINS, 2006; MACHADO, 2011).
A figura 5 mostra de forma esquemática como o RUP é aplicado no processo de desenvolvimento de software. Há um conjunto de responsabilidades e definições que norteiam a utilização do RUP.
Figura 5 – Framework e utilização do RUP
O RUP é composto basicamente de quatro fases nas quais ocorrem as iterações com as disciplinas envolvidas no projeto, sendo elas: iniciação, elaboração, construção e transição (KRUCHTEN, 2003).
Kruchten (2003, pág. 19) apresenta a arquitetura geral do RUP da seguinte maneira:
O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve.
O eixo vertical representa, por natureza, disciplinas que agrupam logicamente as atividades.
A figura 6 demonstra as iterações das disciplinas nas fases do RUP. Observa-se que cada fase é executada em uma ou mais iterações.
Figura 6 – O ciclo de vida de desenvolvimento de um software
Fonte: BOOCH et al. (2000, p. 444).
A figura 6 apresenta as iterações, que representam marcos durante o desenvolvimento utilizando RUP. Cada iteração tem como resultado um incremento, ou uma entrega de executável (release) (HIRAMA, 2011).
A perspectiva prática do RUP descreve boas práticas de engenharia de software recomendadas para uso em desenvolvimento de sistemas. São recomendadas seis melhores práticas fundamentais:
1. Desenvolver o software iterativamente. Planejar os incrementos de software com base nas prioridades do cliente e desenvolver e entregar antes as características de sistema de maior prioridade no processo de desenvolvimento.
2. Gerenciar requisitos. Documentar explicitamente os requisitos do cliente e manter acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças sobre o sistema antes de aceitá-las.
3. Usar arquiteturas baseadas em componentes. Estruturar a arquitetura de sistemas com componentes [...].
4. Modelar o software visualmente. Usar modelos gráficos de UML para apresentar as visões estática e dinâmica do software.
5. Verificar a qualidade do software. Garantir que o software atenda aos padrões de qualidade da organização.
6. Controlar as mudanças do software. Gerenciar as mudanças do software, usando um sistema de gerenciamento de mudanças e procedimentos e ferramentas de gerenciamento de mudanças e procedimentos e ferramentas de gerenciamento de configuração [...] (SUMMERVILLE, 2007, p. 56)
Um grande diferencial dos processos até então existentes que o RUP incorporou em sua ideologia, foi adotar outros fluxos de trabalho, como por exemplo, modelagem de negócios, implantação e gerenciamento de projetos.
2.1.3 MODELOS ÁGEIS
Com o crescimento constante da tecnologia, novidades nesse meio estão sempre surgindo, e isso faz com que tudo fique mais rápido no nosso dia-a-dia e principalmente nos negócios. Segundo Sommerville (2007), o software é parte de quase todas as operações de negócio, e por isso seria adequado que um novo software seja desenvolvido rapidamente. Por isso a maioria das empresas de software quer acompanhar esse ritmo acelerado e oferecerem uma entrega rápida e com qualidade no desenvolvimento.
Sommerville (2007, p. 260), ainda destaca características fundamentais de desenvolvimento rápido:
1. Os processos de especificação, projeto e implantação são concorrentes. Não há especificação detalhada de sistema e documentação de projeto é
minimizada ou gerada automaticamente por um ambiente de programação usado para implementar o sistema. O documento de requisitos do usuário define somente as características mais importantes do sistema.
2. O sistema é desenvolvido em uma série de incrementos. Os usuários finais e outros stakeholders com o sistema participam da especificação e da avaliação de cada incremento. Eles podem propor alterações e novos requisitos que devem ser implementados em um incremento posterior do sistema.
3. As interfaces com o usuário do sistema são geralmente desenvolvidas usando-se um sistema de desenvolvimento interativo que permite que o projeto de interface seja criado rapidamente por desenho e inserção de ícones na interface. O sistema poderá, então gerar uma interface baseada na Web para um navegador ou uma interface para uma plataforma especifica, como a Microsoft Windows.
Uma metodologia muito conhecida utilizada pelas empresas de desenvolvimento rápido de software são os métodos ágeis. Machado (2011) acredita que essa metodologia é a realidade dos negócios do século 21, pelos mesmos motivos citados por Sommerville (2007). Nos métodos ágeis, o escopo dos projetos são mais flexíveis e não são utilizados uma documentação completa e restrita de requisitos na etapa inicial do projeto.
Em fevereiro de 2001, surgiu o Manifesto Ágil por um grupo de desenvolvedores de software. O Manifesto Ágil é uma declaração com os princípios que regem o desenvolvimento ágil (GOMES, 2013).
Métodos ágeis assumem imprevisibilidade natural do desenvolvimento de software, por isso, considera-se que o cliente também esta aprendendo sobre o que precisa e, que a cada feedback pode mudar de ideia e alterar o escopo do projeto. Assume-se também que estimativas de esforço e tempo de desenvolvimento são, de fato, estimativas, e não devem ser tratadas como algo certo e sem margem de erro(GOMES, 2013, pág. 6).
O quadro 2 mostra os princípios dos métodos ágeis, conforme comentado por Sommerville (2007).
Quadro 2 – Princípios dos métodos ágeis
Princípio Descrição
Envolvimento do cliente
Clientes devem ser profundamente envolvidos no processo de desenvolvimento. Seu papel é fornecedor e priorizar novos requisitos do sistema e avaliar as iterações do sistema.
Entrega incremental O software é desenvolvido em incrementos e o cliente especifica os requisitos a serem incluídos em cada incremento.
Pessoas, não processo
As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritivos.
Aceite as mudanças Tenha em mente que os requisitos do sistema vão mudar, por isso projete o sistema para acomodar essas mudanças.
Mantenha a simplicidade
Concentre-se na simplicidade do software que está sendo desenvolvido e do processo de desenvolvimento. Sempre que possível, trabalhe ativamente para eliminar a complexidade do sistema.
Fonte: SOMMERVILLE (2007, p. 263).
Para Foggetti (2014), a simplificação deste método é útil para as empresas, pois além de ter uma documentação mais simples, economiza tempo e custos. Porém Foggetti acredita que este método também tem desvantagens já que nem sempre o cliente estará disponível para acompanhar o desenvolvimento do sistema, é necessário maior envolvimento dos colaboradores no projeto, podem ocorrer conflitos de prioridades quando se trata de mais de um cliente e também existe a questão da pressa que, quando os prazos vão acabando, pode comprometer soluções simples.
O Scrum é um framework que aplica os conceitos dos métodos ágeis que é utilizado neste trabalho como foco principal para o desenvolvimento de software, porém antes de abordar esta ferramenta, serão apresentados os conceitos do
Extreme Programming (XP), apenas a título de conhecimento sobre este modelo.
Essas duas abordagens são muito conhecidas nos métodos ágeis.
2.1.3.1 EXTREME PROGRAMMING (XP)
Segundo Mariotti (2012, p.7), “o Extreme Programming ou XP [...] possui muitas diferenças em relação a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos dinâmicos [...] conduzidos por equipes de tamanho médio e pequeno”.
Muitas pessoas tem uma ideia equivocada desta metodologia por conta de seu nome “Programação Extreme”. Uma pessoa sem subsídios suficientes sobre esta abordagem pode concluir que não é necessário fazer planejamento e nem ter preocupações com o projeto (design) de software, porém isto é uma ideia bastante inadequada, já que na verdade o XP refere-se à utilização dos princípios e práticas
de XP em níveis extremos e não à atividade específica de programação (MACHADO, 2011).
Como todo método ágil, o XP procura responder com velocidade às mudanças nas especificações do projeto, com base em princípios, valores e práticas bem definidos. Este método enfatiza o desenvolvimento rápido garantindo a satisfação do cliente e cumprindo as estimativas do projeto (MARIOTTI, 2012, p.7).
O XP não define papéis, artefatos, pontos de sincronização, entradas e saídas. Somente quatro atividades são definidas: codificar, testar, ouvir e projetar.
Para Gomes (2013, p. 15):
É preciso ouvir porque desenvolvedores nem sempre possuem o conhecimento de negócio necessário para se construir o software. O Planning Game é uma reunião que acontece uma vez a cada iteração, em que o principal objetivo é decidir quais funcionalidades serão desenvolvidas na iteração e aprender mais sobre elas. O cliente escreve histórias de usuário em cartões que representam a necessidade de funcionalidade a ser desenvolvida, e explica para os desenvolvedores tudo o que for preciso para que eles possam implementá-la. Um bom design é uma excelente ferramenta para que todos possam compreender melhor os sistemas complexos, suas estruturas, dependências e regras de negócio. O principal objetivo é manter o design sempre simples, evitando aumentar a complexidade com a criação de funcionalidades que não sejam realmente necessárias.(...) Codificar é uma atividade essencial para o desenvolvimento de software, afinal de contas, sem código não existe software algum. Nessa etapa, é extremante importante que o cliente continue acessível para que possa oferecer feedback e responder às diversas dúvidas que surgem durante o desenvolvimento. Com XP, os testes de unidade são escritos antes do código de produção todo o código fonte que será executado em produção é desenvolvido em pares; a integração do código fonte é realizada frequentemente através da prática de integração contínua; e o código fonte é coletivo, ou seja, pertence a todos os membros da equipe, e deve ser escrito de acordo com os padrões definidos pelo próprio time.
A seguir na figura 7 é apresentado o processo XP, onde é possível verificar as etapas até a entrega de pequenas versões, os releases.
Figura 7 – Processo XP
Fonte: HIRAMA (2011, p. 46).
De forma detalhada da apresentação do XP através da figura 7, observa-se que os requisitos partem das estórias do usuário. Com baobserva-se nas estórias, é realizado o planejamento de versão e a divisão de tarefas. Na iteração, há a etapa de testes por parte do cliente que apenas é liberado após esta aprovação. Caso houver novas estórias, novos planejamentos poderão ser realizados em um novo ciclo do XP.
2.1.3.2 SCRUM
O Scrum será amplamente utilizado neste trabalho, por isso este
framework é abordado de forma mais detalhada.
Conforme Machado (2011, p. 206):
Scrum é um processo empírico para o desenvolvimento de software de alto valor agregado através de ciclos sucessivos de incrementos ao produto. O trabalho é realizado com prazo fixo, de forma colaborativa e autônoma e baseado em uma lista dinâmica de requisitos.
O Scrum é um framework que é usado de forma iterativa e incremental, ou seja, existem períodos definidos que se repetem até que o produto final fique pronto, e no fim de cada período, existe um bloco funcional do produto final entregue. Este framework tem como estratégia iterações curtas para avaliar os requisitos periodicamente (MACHADO, 2011).
Em projetos que utilizam métodos tradicionais, apenas uma ou poucas entregas são realizadas ao final do projeto ou ao final de uma grande etapa. Com Scrum, partes prontas do produto são geradas em ciclos curtos de desenvolvimento, que ocorrem um atrás do outro. As partes entregues são as mais necessárias para seus clientes e usuários no momento da entrega e, por essa razão, serão utilizadas imediatamente. Uma vez que são utilizadas, representam retorno ao investimento realizado (SABBAGH, 2013, p. 5).
No Scrum, caso seja necessário fazer algumas mudanças, as prioridades poderão ser mudadas. É bastante previsível que um desenvolvimento de software poderá mudar durante um processo, por isso é necessário que se tenha uma flexibilidade para acompanhar essas mudanças e o Scrum se adapta à realidade das mudanças (PRIKLADNICKI et al., 2014).
Na figura 8 a seguir, é possível ver detalhadamente como funciona o todo o processo do Scrum, os artefatos e reuniões que fazem parte deste framework e que serão abordadas adiante.
Figura 8 – Planejamento da Sprint
Fonte: MACHADO (2011, p. 216).
Segundo Audy (2015), o Scrum é baseado em três pilares, o primeiro é a “Transparência” que requer que os envolvidos no projeto se posicionem, com sentimento de pertencimento. Outro pilar é a “Inspeção” em que todos devem dar o seu melhor e buscar o melhor do time a cada relato. O último pilar é a “Adaptação” para quando for indicada a necessidade de um plano de ação, todos se empenhem pelo sucesso.
2.1.3.2.1 PAPÉIS DO SCRUM
Cada pessoa da equipe de Scrum é igualmente responsável pelos resultados do trabalho. Existem três papéis diferentes, porém todos trabalham de forma colaborativa (SABBAGH, 2013).
Machado (2011) define os seguintes papéis existentes no Scrum:
Scrum Master: Deve ter iniciativas para melhorar o projeto, garantir que o processo seja entendido por todos da equipe, verificar se a equipe está engajada com o projeto, ou seja, seu papel é manipular a equipe para que estes consigam se auto gerenciar e os objetivos sejam alcançados;
Product Owner (PO): É o responsável pelo produto, ou seja, é ele quem deve ficar ao lado do cliente e ter uma participação constante no projeto e não somente ser um “patrocinador” que cuida da verba do desenvolvimento;
Time de desenvolvimento: São os analistas, desenvolvedores e testadores que entregaram alguma parte do software pronto a cada
Sprint.
O quadro 3 a seguir, mostra como é feita a divisão de tarefas nos diferentes seus papéis:
Quadro 3 – Divisão de tarefas nos papéis do Scrum.
Fonte: SABBAGH (2013, p. 108).
Resumidamente o papel do Product Owner é o analista de negócio, ou melhor, o representante do cliente. O Scrum Master oferece suporte na execução das etapas do Scrum e o Time de Desenvolvimento executa a construção do incremento de software (AUDY, 2015).
2.1.3.2.2 PRODUCT BACKLOG
Segundo Foggetti (2014), o Product Backlog é um documento definido pelo cliente em que são descritas as funcionalidades esperadas e a ordem das prioridades. A figura 9 mostra alguns exemplos de como pode ser feito o Product
Figura 9 – Três exemplos de formatos de Product Backlog
Fonte: SABBAGH (2013, p. 113).
O Product Backlog pode ter como base a técnica de levantamento de histórias de usuário, previstas no Scrum, de forma a gerar uma lista funcionalidades a serem desenvolvidas de acordo com a prioridade, valor, complexidade e expectativa dos principais envolvidos (AUDY, 2015).
2.1.3.2.2.1 HISTÓRIAS DE USUÁRIO (USER STORIES)
Segundo Sabbagh (2013), é importante utilizar formas simples para descrever a necessidade do usuário do ponto de vista dele mesmo, para tanto, existem as histórias de usuário. Para Matos et al. (2014, p. 7), “histórias de usuário é um dos modelos de especificação de requisitos indicados para MA’s e descreve uma funcionalidade que é valiosa para o cliente do sistema.”
Sabbagh (2013, p. 135) menciona que “é importante destacar que as histórias de usuário não fazem parte do framework Scrum e, assim seu uso é opcional”. A seguir, a figura 10 apresenta um exemplo de história de usuário. Observe que é escrita considerando o ponto de vista do usuário.
Figura 10 –Exemplo de História de Usuário
Fonte: SABBAGH (2013, p. 135).
As histórias devem ser simples e claras para que possam ser bem entendidas e estimadas pelo time no planejamento, por isso, é interessante detalhar cada interação do usuário fracionando em situação objetivas para determinado fim (AUDY, 2015).
2.1.3.2.2.2 CRITÉRIOS DE ACEITAÇÃO
Segundo Sabbagh (2013, p. 141), “critérios de aceitação são expressos por enunciados pequenos e de fácil entendimento. São utilizados para determinar quando a funcionalidade produzida pelo Time de Desenvolvimento está completa e, assim, nada mais deve ser adicionado a ela”. O quadro 4 apresenta um exemplo de critério de aceitação.
Quadro 4 – Exemplo de Critérios de Aceitação
Critério 1 Somente podemos aceitar cartões de crédito com bandeiras com que temos convênio.
Critério 2 Somente podemos aceitar cartões de crédito com data de expiração no futuro.
Fonte: SABBAGH (2013, p. 142).
Para Audy (2015), os critérios de aceitação é uma parte importante das histórias de usuário que deverão ser validadas para que o PO aceite a entrega como pronta ao final de cada Sprint, além de ser uma forma simples para transmitir ao time de desenvolvimento o que precisa ser feito a fim de agregar valor ao produto.
2.1.3.2.3 SPRINT BACKLOG
Segundo Foggetti (2014), o Sprint Backlog é um planejamento que representa a estratégia dos itens dispostos no backlog para que seja dividido o Product Backlog em pedaços menores para sua implementação. A figura 11 mostra um exemplo de representação de um Sprint Backlog.
Figura 11 – Sprint Backlog
Fonte: SABBAGH (2013, p. 149).
Para Audy (2015) o Product Backlog contém todos os requisitos (histórias já levantadas para incrementar o produto). Este Product Backlog será refinado no planejamento da sprint de forma a selecionar as histórias que serão desenvolvidas na próxima sprint.
2.1.3.2.4 SPRINT
As sprints são ciclos que ocorrem no Scrum e apresentam um conjunto de atividades que devem ser executados (MACHADO, 2011).
Segundo Sabbagh (2013), a duração de cada sprint é decidida pela a equipe, normalmente é de duas a quatro semanas, no fim deste período espera-se ter um incremento do produto finalizado. Cada incremento é realizado de acordo com o Sprint Backlog, que apresenta os itens que a equipe decidiu á serem realizados. A figura 12 mostra o ciclo da sprint.
Figura 12 – Ciclo de vida do Scrum
Fonte: MACHADO (2011, p. 209).
Inicialmente é realizada a reunião de planejamento em que são definidos os itens que farão parte do Sprint Backlog e como serão desenvolvidos. Após isso, o desenvolvimento do produto começa a ser realizado e, em paralelo, também é feito a Scrum Diária. A Scrum Diária é uma reunião de apenas 15 minutos em que o Time de Desenvolvimento se reúne todos os dias e discutem o que foi realizado e o que será feito a seguir. Com o desenvolvimento finalizado, é feito a Revisão da Sprint para que o produto seja apresentado para a equipe e para o cliente, se todos estiverem satisfeitos com o produto então a próxima etapa é a reunião de Retrospectiva da Sprint que são discutidos os aprendizados obtidos pela a equipe com a sprint corrente e novas melhorias que podem ser feitas nas próximas sprints.
A figura 13 é representação esquemática de uma sprint, evidenciando as quatro cerimônias supracitadas.
Figura 13 – Representação esquemática de uma Sprint
Fonte: PRIKLADNICKI et al. (2014, p. 31).
Segundo Gomes (2013), “ao longo da sprint a equipe mantém sempre em mente a sua meta e quando o andamento das coisas foge do que foi previsto, é possível negociar o escopo com o PO, de forma que não comprometa a meta”.
2.1.3.2.5 REUNIÃO DE PLANEJAMENTO DA SPRINT (SPRINT PLANNING)
Nesta reunião será conhecida e planejada a meta da sprint. Para isso, a reunião é dividida em duas partes. Na primeira parte é definido o que será entregue no incremento resultante nesta sprint e na segunda parte o que será feito para entregar este incremento, essas duas partes originam o Sprint Backlog (PRIKLADNICKI et al., 2014).
Na reunião de Planejamento da sprint é preciso estabelecer métricas para que se possa planejar o tempo de entrega de uma determinada funcionalidade. Sabbagh (2013, p. 121) elenca os as seguintes unidades para estimativas no Scrum:
tempo real: dias ou horas reais de trabalho, ou seja, uma estimativa de quanto tempo em dias ou horas a realização da atividade irá durar. É a unidade mais tradicional de estimativa;
tempo ideal: dias ou horas ideias de trabalho, ou seja, quanto tempo se levaria para realizar uma atividade caso todo o foco de trabalho
estivesse nessa atividade e não existissem quaisquer interrupções, como conversas, leitura de e-mails, idas ao banheiro, reuniões, cafezinho etc. A estimativa com tempo ideal também pode ser expressa em homens-dias ou homens-horas, ou seja, quantas pessoas são necessárias para completar o item de trabalho em um dia ou uma hora, sem interrupções;
Story Points: unidade relativa de tempo criada pelo Time de Desenvolvimento. É a unidade mais utilizada por equipes Ágeis.
Para que a reunião de planejamento da sprint seja eficaz, um item importante é que o Product Backlog esteja com detalhes suficientes para que possa ser discutido. Para tanto, é necessário estabelecer um acordo definido como “definição de preparado”. Esta definição deve ser através de um acordo formal entre o PO e o time de desenvolvimento. A figura 14 apresenta um exemplo de definição de preparado (SABBAGH, 2013).
Figura 14 – Exemplo simples de definição de preparado
Fonte: SABBAGH (2013, p. 190).
Para Sabbagh (2013), a definição de “preparado” é muito importante para diminuir riscos de uma sprint mal planejada, quando demais detalhes podem ser deixados para serem discutidos na Sprint Planning.
2.1.3.2.6 SCRUM DIÁRIAS (DAILY SCRUM)
Elevam o nível de auto-organização do time de desenvolvimento que se reúnem rapidamente diariamente para todos se atualizarem do que está sendo desenvolvido e talvez serem definidos alguns novos pontos. Esta reunião tem duração de apenas 15 minutos (PRIKLADNICKI et al., 2014).
Segundo Sabbagh (2013) em cada reunião é realizado os seguintes questionamentos para cada membro do time:
O que foi feito desde a última reunião diária? O que será feito depois da reunião diária?
Quais problemas estiveram ou estão tendo que impedem o trabalho de ser executado?
2.1.3.2.6.1 GRÁFICO BURNDOWN
O gráfico Burndown é utilizado para acompanhar o progresso da sprint e também utilizado como um indicador para predizer quando o trabalho será concluído. É possível usar a linha de tendência para verificar se está propenso a terminar as tarefas na meta pretendida pela a equipe (RUBIN, 2013).
Conforme a figura 15, o eixo vertical representa a estimativa de esforço-horas restante e o eixo horizontal são os dias de uma sprint. Cada dia o gráfico é atualizado para mostrar o total estimado, esforço restante nas tarefas incompletas (RUBIN, 2013).
Figura 15 – Gráfico de Burndown
Fonte: RUBIN (2013, p. 358).
O gráfico de burndown é um artefato indispensável no Scrum para o entendimento do quadro de tarefas e é um indicador de tendência “previsão e trabalho” para atingir os objetivos pretendidos (AUDY, 2015).
2.1.3.2.7 REVISÃO DA SPRINT (SPRINT REVIEW)
Na revisão da sprint é apresentado os itens finalizados na sprint para o cliente e toda a equipe, com o objetivo de receber um feedback. Nesta reunião é discutido e inspecionado se o incremento do produto é satisfatório ou se será necessário modificá-lo ou adaptá-lo, neste caso retornará ao Produtct Backlog para ser realizada em sprints futuras. É primordial nesta fase esclarecer ao cliente qual é a meta da sprint para melhor entendimento do incremento final. Também é muito importante que toda a equipe participe para que haja compreensão de tudo o que foi realizado na sprint, evitando futuros problemas nas próximas sprints, e também para ter novas sugestões de futuros Product Backlog que podem melhorar o produto (PRIKLADNICKI et al., 2014. SABBAGH, 2013).
Na apresentação do produto é demonstrado cada item realizado na sprint e possibilita o cliente experimentar o produto para que haja um bom esclarecimento
do que foi realizado estimulando ainda mais perguntas e feedbacks de melhorias futuras (SABBAGH, 2013).
Seguindo uma premissa importante de qualquer timebox, a condução deve ter em vista a natureza de sua pauta, deve ficar na apresentação do previsto e do realizado. Não é hora para fazer testes e homologação, nem para revisar ou discutir estratégia ou filosofar sobre o Product backlog (AUDY, 2015, p. 84).
Sabbagh (2013) também cita que outro acordo importante no Scrum é a “definição de pronto”. Este por sua vez é um acordo realizado também entre o PO e o time de desenvolvimento para indicar que um item da sprint está pronto, ou seja, que determinada funcionalidade possa ser entregue ao cliente. A figura 16 a presenta um exemplo que pode seguido para uma definição de pronto.
Figura 16 – Exemplo simples de um acordo de definição de pronto
Fonte: SABBAGH (2013, p. 156).
A definição de pronto oferece um alto nível de confiança que o incremento desenvolvido tem qualidade e pode ser realmente entregue ao cliente (RUBIN, 2013).
