APLICANDO AS INSTRUÇÕES DO SCRUM EM UM PROJETO DE IMPLEMENTAÇÃO DE SISTEMAS

Diego Silva1; Leopoldo Pedro Guimarães Filho2

1Universidade do Extremo Sul Catarinense (UNESC), Criciúma, SC, Brasil.

[email protected]

2Universidade do Extremo Sul Catarinense (UNESC), Criciúma, SC, Brasil.

[email protected]

.

RESUMO

No Brasil os primeiros passos dados em relação à metodologia SCRUM surgiram a partir do ano de 1998, junto com a implantação de um escritório da divisão da PMI em São Paulo, ainda em época do regime militar. No entanto já no de 1960, nos Estados Unidos, este termo já era fortemente discutido dentro do meio empresarial, onde a produtividade ainda era relacionada ao aumento de carga horária. A metodologia SCRUM, distante do que os profissionais de T.I imaginam, foi pioneiramente testada e aprovada pela indústria automobilística, tendo sido a escolha dessa metodologia, fundamentada em relação ao tempo disponível de entrega mediante a urgência de um produto. Buscou-se com esse artigo realizar uma análise da aplicação do SCRUM durante a implantação de um sistema. Salientando que esse artigo não visa afirmar a sua eficiência em todo e qualquer projeto, uma vez que foi feito a partir da análise e levantamento de requisitos para decisão de qual metodologia implementar no projeto em questão.

Palavras-chave: Tecnologia; Gestão de Projetos; Scrum.

ABSTRACT

In Brazil, the first steps taken in relation to the SCRUM methodology emerged in 1998, together with the implementation of an office of the PMI division in São Paulo, still during the military regime. However, in the 1960s, in the United States, this term was already heavily discussed within the business and corporate environment, where productivity was still related to increased workload. The SCRUM methodology, far from what IT professionals imagine, was first tested and approved by the automotive industry, having been the choice of this methodology, based on the available delivery time due to the urgency of a product. This article sought to carry out an analysis of the application of SCRUM during the implementation of a system. Emphasizing that this article does not aim to assert its efficiency in each and every project, since it was made from the analysis and survey of requirements to decide which methodology to implement in the project in question.

Keywords: Technology; Project management; Scrum.

.

1  Introdução

Mesmo contratando mais profissionais, a qualidade e os prazos sempre divergiam com o esperado, embora já se fazia uso de ferramentas para gerenciar projetos. No cenário de desenvolvimento era conhecida como metodologias leves (Lightweight Methods, 2023), porém com resultados abaixo do esperado, e no ano 2000, foi dado o primeiro passo na construção do movimento ágil, onde a primeira a ser usada como comparação com os meios anteriores foi XP (Extreme Programming). (GEP, 2016)[4]. A aplicação de metodologias ágeis neste estudo, usando o Scrum como guia, tem por foco gerenciar a criação de um software, que representa a solução diante de uma dificuldade no processo de campanhas sanguíneas, o curto espaço de tempo obrigava o processo e gerenciamento na criação do projeto ser mais dinâmico e com entregas contínuas.

A organização escolhida para esse estudo foi o Hospital Nossa Senhora dos Navegantes, localizada em Torres, Rio Grande do Sul. O motivo foi que no ano de 2014 havia dificuldade de divulgar campanhas para doação de sangue, não existia campanhas na região, e nem plataformas para isso, Torres tem cerca de 40 mil habitantes, e seu hospital atende diversos municípios vizinhos, auxiliando no atendimento médico da região. Esse tipo de apoio social foi também um dos motores para o início deste projeto e o Scrum foi fundamental para administrar as tarefas.

2  PRINCIPIOS DO MANIFESTO ÁGIL

O Manifesto Ágil é um documento que revolucionou a forma de executar projetos, ele foi assinado por 17 desenvolvedores de software, no ano de 2001, tendo sido criado a partir de uma reunião que visava procurar novas alternativas para desenvolvimento de projetos de softwares, os quais mesmo utilizando abordagens diferentes, compartilhavam das mesmas necessidades e tinham os mesmos fundamentos, como, por exemplo, o método XP, o DSDM, o SCRUM e o FDD. ​​ (BECK, et. all., 2001)Erro: Origem da referência não encontrada

 Ao considerar que as metodologias ágeis são consideradas um conjunto de ações práticas com a finalidade de facilitar e agilizar as tomadas de decisões e a organização de projetos. O manifesto ágil teve como base 12 princípios, o qual de forma resumida estão representados na figura abaixo e serão descritos a seguir:

Figura 1: Princípios ágeis de forma resumida.

Fonte: Agil Manifesto, 2001. Disponível em: https://agilemanifesto.org/iso/ptbr/principles.html  

Agile Alliance é um grupo sem fins lucrativos que tem em seu foco dar apoio e

formar ações para o desenvolvimento ágil no Brasil, o grupo também recomenda o uso

dos princípios que serão enumerados abaixo, para Agile Alliance (2004)Erro: Origem da referência não encontrada, os princípios são:

Princípio 1: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.

Esse princípio, conforme destaca Agile Alliance (2004)Erro: Origem da referência não encontrada, pode-se dizer que está relacionado a geração de valor, colocando a satisfação do cliente como prioridade, entregando não somente um produto, mas um produto que gere valor ao cliente.

Princípio 2: Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis adequam a mudanças, para que o cliente possa tirar vantagens competitivas. O segundo princípio está relacionado a flexibilidade, para Agile Alliance (2004)Erro: Origem da referência não encontrada, é necessário ser flexível e entender as mudanças necessárias solicitadas pelos clientes, seadequando conforme a necessidade, estando abertos a alterações.

Princípio 3: Entregar software funcionando com frequência na escala de semanas até meses, com preferência aos períodos mais curtos. Esse princípio, Agile Alliance (2004)Erro: Origem da referência não encontrada, está relacionado a frequência, ou seja, realizar múltiplas entregas do projeto/produto e não somente após finalizado, priorizando as partes mais importantes a serem entregues inicialmente. Essa é uma prática essencial em projetos ágeis.

Princípio 4: Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

Princípio 5: Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário e confiar que farão seu trabalho.

Princípio 6: O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

Princípio 7: Software funcional é a medida primária de progresso.

Princípio 8: Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter indefinidamente, passos constantes.

Princípio 9: Contínua atenção a excelência técnica e bom design, aumenta a agilidade.

Princípio 10: Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

Princípio 11: As melhores arquiteturas requisitos e designs emergem de times auto- organizáveis.

Princípio 12: Em intervalos regulares o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo..

 

3  SCRUM

De acordo com Rafael (2014)[8] o primeiro time de scrum foi criado em 1993 por Jeff SutherLand na empresa Easel Corporation uma empresa de Software dos Estados Unidos O intuito dos criadores era mudar a maneira como o gerenciamento dos softwares era efetivada durante seu desenvolvimento.

O nome SCRUM é uma referência a um estudo feito 1986 pelos japoneses Takenuchi e Nonaka, onde foram comparadas equipes de alto desempenho em equipes de Rugby, utilizando o método de multitarefas.

Segundo Takeushi e Nonaka (1986) scrum é um framework ágil empregado na gestão e desenvolvimento de produtos complexos, com base no empirismo.

Como pode ser observado, a adoção de metodologias ágeis traz benefícios para as organizações, sobretudo quanto aos resultados. De acordo com Schwwaber e Sutherland (2016) um time que aplica o Scrum como processo para gerenciar seus projetos, se apoia em algumas características.

• Flexibilidade nos resultadosFlexibilidade nos prazosTimes pequenos de no máximo 9 pessoasRevisões constantes do andamento dos objetivos

• Colaboração entre os membros, independente da especialização técnica de cada um.

• Para Neto (2002)Erro: Origem da referência não encontrada, “o conjunto de propósitos e princípios beneficiará os usuários de metodologias ágeis”, mas há de ser levado em consideração que cada projeto é distinto e cada equipe é distinta, fazendo a escolha da metodologia que mais se encaixa com o projeto.

Aqui será tratado sobre a metodologia SCRUM, que teve sua escolha para esse artigo por ser a metodologia que se encaixava melhor aos sistemas de sprints (conjunto de tarefas que devem ser executadas e desenvolvidas em um período pré-definido de tempo), auxiliando na entrega contínua, pelo motivo de se dispor de pouco tempo para implementação.

3.1 ETAPAS NO PROCESSO DE UTILIZAÇÃO DO SCRUM

 De acordo com a Scrum.org mais de 70% das empresas utilizam o SCRUM como metodologia ágil. Antes de adentrar nos detalhamentos do SCRUM, rapidamente considera-se importante ressaltar o significado de Extreme Programming (XP). Para Brod (2023)[3], Extreme Programming e Scrum andam de mãos dadas, ambos têm semelhança, o autor define o XP como um complemento a UML (Unified Modeling Language) para levantamento de requisitos e documentação de sistemas, porém o SCRUM se parece mais com um framework gerencial e o XP foca mais em práticas de engenharia de software.

.

.3.2 PRODUCT BACKLOG (ORGANIZAÇÃO DO BACKLOG)

O ponto de partida do SCRUM é o Product Backlog, ou seja, a lista de tudo que deve ser contemplado no projeto, de forma que o cliente possa entender, divididos em Sprints.

Brod (2023)[3], define o Product Backlog como uma lista de desejos para o seu projeto, onde as demandas são separadas conforme a prioridade e divididas em partes menores, as quais são chamadas de Sprint Logs (registros de corrida), cada Sprint tem um prazo que gira em torno de 4 semanas, ao ser finalizado é realizada uma entrega funcional.

O Product Backlog é usado como a base para o desenvolvimento do Sprint Backlog[5], ou seja, é um ciclo onde a equipe vai realizar várias atividades, baseadas na lista pré-definida. Ainda de acordo com a mesma autoria, o Product Backlog é essencial para qualquer projeto, para que seja possível organizar todas as etapas de execução.

Para Brod (2023)[3], o Product Backlog é como criar e priorizar histórias e distribui essas histórias em fases semanais, ou seja, os Sprints. No caso de surgir uma nova história no meio do caminho é necessário voltar para ajustes. Por isso o autor sugere a criação de um mapa mental, onde fique fácil identificar de que forma a nova história possa impactar e qual tempo para sua inclusão.

Figura 2: Exemplo de Product Backlog com a priorização das tarefas

Fonte: https://conteudo.movidesk.com/product-backlog-o-que-e/

Existem diversas ferramentas que podem ser utilizadas nesse processo e auxiliar na hora de montar Product Backlog, Trello foi uma boa ferramenta para construir a lista de tarefas, conforme exemplo na figura acima. Mas cabe ressaltar aqui que existem outras ferramentas que podem ser utilizadas.

4 PROCEDIMENTOS METODOLÓGICOS

 Metodologia, derivada de método que vem do latim “methodus”, que significa “caminho ou via para realização de algo”, como consta Denise (2009) a pesquisa é a atividade nuclear da ciência, ela possibilita uma aproximação e um entendimento da realidade de investigar. Partindo desses princípios iremos aplicar a metodologia descritiva para explanar o objetivo deste estudo, buscando entender o contexto e o planejamento usado para sanar da melhor forma os óbices do projeto.

Depois após de levantar os requisitos e o escopo do projeto, tivemos como planejar a execução de cada etapa do processo que iria resultar no desenvolvimento do software.

 A ideia do projeto Pró Sangue, veio da falta de divulgação de campanhas sanguíneas na época e de como o processo era engessado, existiam plataformas em outros estados como São Paulo e Rio de Janeiro, mas na Região Sul se via a necessidade de um projeto de cunho social, foram realizadas pesquisas in loco em hospitais da região de Torres-RS para absorver as informações e entender melhor o processo, outro forte motivador foi o crescente uso de dispositivos mobiles, já que o ano era 2014 e havias muitos incentivos para desenvolver soluções móveis usando tecnologias de grandes Big Techs como Microsoft, Apple e Google. Dentre as metodologias disponíveis a descritiva foi que melhor se encaixou no escopo do artigo, como destaca (Trivinos, ​​ 1987) a pesquisa descritiva exige do investigador uma série de informações sobre o que deseja pesquisar. Esse estudo pretende descrever os fatos e fenômenos de determinada realidade.

5  IMPLANTAÇÃO DO PROJETO PRÓ-SANGUE

5.1  O QUE É O PRÓ-SANGUE

​​ O Projeto PRÓ-SANGUE é um sistema desenvolvido com intuito de ampliar o acesso a informação relacionada a coletas de sangue, oferecendo um ambiente onde os usuários tivessem como suprir suas dúvidas relacionadas a doação de sangue, como doar, onde doar, qual motivo da doação.

Trata-se de um aplicativo móvel para Windows Phone tem como finalidade disponibilizar um ambiente que permite a realização de cadastro de doadores e pacientes, além do controle independente de doações de sangue.

5.2  ARQUITETURA DA INFORMAÇÃO

 Figura 7: Diagrama de uso do PRÓ-SANGUE

 Fonte: Projeto – PRÓ-SANGUE

As figuras 8, ilustra os diagramas de atividades que demonstram algumas das principais funcionalidades do software, bem como login.

 ​​ ​​​​  Figura 8: Diagrama de atividade – LISTAR CAMPANHAS

​​   Fonte: Projeto – PRÓ-SANGUE

Tabela 1: Product Backlog

Fonte: Projeto – PRÓ-SANGUE ​​ 

 Abaixo segue tabela 2 - Sprint Backlog da Sprint 1:

Tabela 2: Sprint Backlog da Sprint 1 

Fonte: Projeto – PRÓ-SANGUE

.

 ​​​​ Tabela 3: Sprint Backlog da Sprint 2 

Fonte: Projeto – PRÓ-SANGUE

 ​​ ​​ ​​ ​​ ​​ ​​ ​​​​  A Tabela 4 demonstra a Sprint Backlog da Sprint 3.

Tabela 4: Sprint Backlog da Sprint 3 

Fonte: Projeto – PRÓ-SANGUE

.

6.4  Sprint 4 – Visualizações de Campanhas e Notificações

 Nesta Sprint foram desenvolvidas as funcionalidades do item Calendário de Campanhas, Notificações e Visualizar Usuários com a mesma compatibilidade sanguínea, que implementam visualização do calendário de campanhas e notificações

por push que informarão datas de campanhas, além de permitir que os usuários visualizem uma lista de doadores ou pacientes com a mesma compatibilidade sanguínea.

Tabela 5: Sprint Backlog da Sprint 4 

Fonte: Projeto – PRÓ-SANGUE

  Como visto acima, foi elaborado o Product Backlog para o desenvolvimento do projeto, o qual foi dividido em Sprints como demonstram as tabelas, com as prioridades e estimativas de tempo a serem gastos com cada atividade. Além disso foi elaborado também um cronograma, como demonstrado na tabela 6, a seguir:

Tabela 6: Cronograma

Fonte: Projeto – PRÓ-SANGUE .

7   APRESENTAÇÃO DE RESULTADOS

  A etapa inicial é focada no levantamento de requisitos para a criação do software, tendo em vista que o produto já foi definido, o uso do SCRUM começa desde as etapas iniciais e vai até a última ponta do processo. O processo de coleta de sangue na nossa região era realizado em datas específicas, onde era encaminhado um veículo da capital para realizar a coleta, porém esses dias não eram divulgados, nem mesmo nos canais oficiais, somente ligando ou indo presencialmente até a recepção do posto para obter as informações, a partir disso montamos um Use Case, para representar este processo de forma mais visual, como pode se ver na figura 9.

Figura 9: Diagrama de atividade – LISTAR CAMPANHAS

Fonte: Projeto – PRÓ-SANGUE

.

Além das campanhas, o sistema gerenciaria as doações feitas, e o controle de datas para próximas doações de forma automatizada, enviando notificações, SMS e até mesmo e-mails para o doador. Após dividir todo o processo em Use Case, dividimos essas “histórias” em Sprints menores para diluir as demandas e tarefas menores, assim poderíamos entregar pequenas versões do software até o seu término. Após todo o levantamento de requisitos, abaixo teremos a sprints em que a entrega foi palpável e de uma rotina que não se tinha nenhuma ferramenta, agora já tínhamos auxílio de um software.

​​ Tabela 7: Sprint 1 

 ​​​​ Fonte: Projeto – PRÓ-SANGUE.

Na sprint acima, foi entregue a primeira demanda, onde já era possível, cadastrar antigos doadores que estavam no ERP do posto de saúde, uma ponte importante nesta etapa é os meios de contato que devem estar atualizados, e por meio de APIS, conseguimos validar números de telefone, e-mail e WhatsApp, assim cadastros antigos e sem registro de contato não foram inseridos na plataforma.

Tabela 8: Sprint 2

Fonte: Projeto – Pró-sangue

Nesta Sprint a entrega de valor ao software foi maior, sendo que o já deixamos funcional, com o disparo de mensagens para os contatos cadastrados, conseguíamos os informar sobre as campanhas com antecedência, ou contatar um doador com tipo sanguíneo que estava em falta no banco para o que o mesmo pudesse comparecer ao posto e realizar a doação, e também com o registro da última doação as mensagens o lembravam quando ele estava apto para uma próxima doação.

Tabela 9: Sprint 3

Fonte: Projeto – PRÓ-SANGUE

Na Sprint 3 desenvolvemos a primeira versão do aplicativo que ficou disponível na loja da Microsoft para dispositivos mobile da plataforma Windows Phone, nesta primeira etapa, o doador conseguia logar. Com seu e-mail já cadastrado na nossa base, por meio disso todo seu histórico estava disponível para consultas, como informações de campanhas e datas importantes também, o usuário poderia atualizar seus dados cadastrais tanto quanto tirar dúvidas..

.

8   ANÁLISE DE RESULTADOS

  O objetivo do presente estudo foi aplicar os processos da metodologia ágil, para entregar produtos de forma rápida em um curto espaço de tempo, usar um framework que possibilita dividir grandes tarefas em partes menores, podendo entregar o produto em etapas, agiliza e facilita muito quando o tempo é realmente um empecilho, durante o processo foi entregue diversas atualizações até a conclusão do projeto. Entregas frequentes possibilitam a constante avaliação do usuário, dando a possibilidade de realizar correções em tempo hábil sem afetar a regra de negócio ou alterar drasticamente o escopo do projeto, que possivelmente seria inviável em metodologias com a Cascata, a cada sprint tínhamos reuniões com o usuário, seus feedbacks nesse curto espaço ajudam na construção do software. Metodologias como essa por mais que frequentemente usadas no desenvolvimento de sistemas, pode ser aplicada em outros projetos, obviamente a aplicação desta metodologia não é a garantia de sucesso ou mesmo de melhora em um antigo processo, porém exclusivamente neste caso seus benefícios puderam entregar um sistema em pleno funcionamento em um curto espaço de tempo.

.

9  CONSIDERAÇÕES FINAIS

O objetivo do estudo aqui presente foi implementar uma metodologia ágil no desenvolvimento de um software que pudesse ser efetiva no gerenciamento de projetos, utilizando como referência o SCRUM , é crucial salientar que o foco aqui não é comparar o método ágil com outras metodologias, ou até mesmo o definir como regra para gerenciamento de projetos e sim de como sua aplicação pode funcionar em um cenário qualquer.

A instituição que foi usada como base de estudo foi o Hospital Nossa Senhora dos Navegantes, localizada no litoral norte do Rio Grande do Sul, a pesquisa e execução em si, pode nos confirmar a prestância do Scrum no gerenciamento de projetos. É nítido que nem todos os projetos poderão fazer uso deste tipo de framework, e que seus resultados podem ser negativos ou não tão positivos quanto o esperado. O que se pode assentir, até a publicação deste artigo, que este tipo de modelo de gerenciamento resultou em ganhos no quesito tempo, produtividade, feedback e refatoração do produto.

O artigo em si ajuda no entendimento e de como processos mais flexíveis e ágeis podem retornar resultados positivos para o meio organizacional, mesmo o projeto não ter seguido adiante devido questões burocráticas, Scrum é uma excelente ferramenta para gerir projetos e processos.

Pontos fracos também pode ser anunciado neste trabalho, como a descontinuidade do projeto devido ás questões organizacionais, pelo fato de ser uma instituição pública, e os recursos realmente limitados impediam algumas melhoras no escopo do software.

E um estudo seguinte poderia ser aplicado uma outra metodologia, como a Cascata que é orientada a documentação para analisarmos os prós e contras de processos dessemelhantes para fins iguais.

.10 REFERÊNCIAS

 

• Agile Alliance. The 12 Principles behind the Agile Manifesto.  2004https://www.agilealliance.org/agile101/12-principles-behind-the-agile-  manifesto/. Acesso em 11 de Junho de 2023.

   

• BECK, Kent et al. Manifesto for agile software development. Feb. 2001.  Disponível em http://www.agilemanifesto.org/ Acesso em Julho, 2023.

   

• BROD, Cesar. SCRUM - Projetos Ágeis e Pessoas Felizes. Disponível em:  https://scrum.brod.com.br/scrumbrod/i/. Acesso: 14 de abril de 2023.

   

• GEP. Framework Scrum, eficiência em projetos de softwares. 2016 Disponível  em: https://periodicos.uninove.br/gep/article/view/9640/4385. Acesso em 11 de  Junho de 2023.

   

• IEEP. Sprint Backlog: O que é e como fazer? Disponível em:  https://www.ieepeducacao.com.br/sprint-backlog/. Acesso em: 14 de abril de  2023.

   

• Manifesto Ágil. Princípios por trás do Manifesto Ágil. 2001. Disponível em: https://agilemanifesto.org/iso/ptbr/principles.html. Acesso em 11 de Junho de 2023.

   

• NETO, João Rotta. 2002. Manifesto Ágil. Disponível em:http://paginapessoal.utfpr.edu.br/frufrek/pos-web/p/arquivos/O_manifesto_agil.pdf . Acesso em: 04 de abril de 2023.

   

• SABBAGH, Rafael. Scrum: Gestão ágil para projetos de sucesso. Editora  Casa  do Código, 2014.