Proposta de implementação de metodologias ágeis em uma microempresa de desenvolvimento de sistemas web

Patricia Mateus Saramela1, Alisson Gonçalves Ferreira2

Faculdade Cidade Verde (FCV)

Avenida Horácio Raccanello Filho, 5950 Novo Centro – Maringá – PR – Brazilpatriciasaramela@live.com, alisson_gf@hotmail.com

Abstract. This paper presents a proposal for implementation of the agile methodology Scrum in a internet. system development microenterprise. With the increasing number of customers, the company's growth and increased complexity of projects, felt the need to formalize and improve the process, seeking an increase in the quality of the final software and optimize the development of the project.

Resumo. Esse trabalho apresenta uma proposta de implementação da metodologia ágil Scrum em uma microempresa¹ de desenvolvimento de sistemas para a internet. Com o aumento do número de clientes, crescimento da empresa e aumento na complexidade dos projetos, sentiu a necessidade de formalizar e melhorar seu processo, buscando um aumento na qualidade do software final e otimização no desenvolvimento do projeto.

1. IntroduçãoCom a alta competitividade no mercado de desenvolvimento de software, um dos fatores que podem destacar uma empresa perante as outras é sua habilidade de criar e entregar rapidamente produtos de software com qualidade, que consigam atender as reais necessidades do cliente. Os métodos ágeis surgem com um propósito de simplificar e organizar o processo de desenvolvimento, agregando maior valor ao produto final

O modelo Cascata é o mais antigo modelo de desenvolvimento e o mais utilizado, conforme afirma Cariel (2018 apud Pressman, 2001). No modelo Cascata, o desenvolvimento é feito de forma sequencial, no qual o projeto começa pela fase de “Análise de Requisitos”, “Projeto”, “Implementação”, “Verificação”, “Manutenção”. Uma fase só é iniciada após a conclusão da fase anterior. Para ambientes em que as mudanças são constantes, esse modelo não é muito indicado pois pode frustrar o usuário do produto desenvolvido, que após um longo período aguarda pelo software que, ao final, pode não atender suas necessidades, devido à dinâmica de mudanças nos processos e procedimentos das empresas, conforme afirma Cariel (2008).

Segundo Cariel (2008 apud Bezerra, 2004), A forma padrão de desenvolvimento de software, principalmente na pequena empresa, começa pelo código (codificação feita pelo desenvolvedor). O que pode acontecer por vários motivos como falta de conhecimento, ou até mesmo pela ilusão de que ao fazer um planejamento está se perdendo tempo e dinheiro.

XI Ciclo de Estudos da Faculdade Cidade Verde“Ciência, Tecnologia e Inovação”

12 a 17/05/2016

Com o aumento da empresa, do número de clientes ou da complexidade dos projetos, as empresas percebem a necessidade de gerenciar e planejar seu processo de desenvolvimento.

Durante o desenvolvimento de software os requisitos estão sujeitos a constantes alterações, o que o torna desafiador. Neste contesto, as metodologias ágeis buscam minimizar o impacto dessas alterações no projeto e na equipe.

Com a necessidade de um desenvolvimento mais rápido e com maior qualidade surgiram técnicas para o desenvolvimento ágil de software. Carvalho e Mello (2012) afirmam que esta disciplina foi fortemente influenciada pelas melhores práticas da indústria japonesa, particularmente pelos princípios da manufatura enxuta implementados pelas companhias Honda e Toyota.

Apesar de ser uma abordagem relativamente nova, a utilização do Scrum, uma das metodologias de gerenciamento ágil, tem aumentado nos últimos anos, impulsionado pelas recentes pesquisas que mostram que seu uso aumenta a satisfação dos clientes e diminui o atraso em projetos em relação aos métodos tradicionais Carvalho e Mello (2012 apud Mann; Maurer, 2005)

Na pesquisa “The 2015 Stade of Scrum”, realizado pela Scrum Alliance, mostrou alguns dados acerca da metodologia Scrum em 2015. A pesquisa foi feita em um grupo de 5000 pessoas, de 108 países, sendo 44% da área de desenvolvimento de software e 33% na área de tecnologia da informação. 87% dos entrevistados afirmaram que o Scrum aumentou a qualidade no ambiente de trabalho, e 95% planejam continuar usando o Scrum. A pesquisa demonstra que em média o Scrum é bem-sucedido em 62% do tempo. Quase metade dos entrevistados, 49%, citaram a satisfação do cliente como a maior prioridade em projetos Scrum, e 21% citou Reunião de orçamento, tempo erestrições de escopo como maior prioridade em projetos que usam Scrum.

A proposta desse trabalho é a implementação da metodologia ágil Scrum em uma microempresa¹ de desenvolvimento web, em busca de qualidade no processo e no produto final, auxiliando na diminuição de defeitos nos códigos e no atraso das entregas. Beneficiando a empresa e o cliente. Segundo Cariel (2008), um processo ágil pode trazer qualidade através da simplicidade e feedback constantes com uso de ferramentas de engenharia de software.

2. Cenário organizacionalA LTX Design é uma microempresa¹, localizada em Maringá, que desenvolve sistemas web e aplicativos mobile. Com pouco mais de 5 anos, a empresa não usa nenhuma metodologia de gerenciamento e gestão de projetos. Como possui uma equipe muito pequena, 5 funcionários, não havia necessidade para o uso de uma metodologia formal para o gerenciamento dos projetos.

A LTX Design é especializada no desenvolvimento de sites, e-commerce e sistemas sob medida, no qual o cliente pode controlar e editar todo o conteúdo, como imagens, textos, vídeos, entre outros, através de um painel administrativo. A empresa é conhecida perante os clientes, principalmente, por sua originalidade e ideias inovadoras. O foco principal da empresa são sites que vão além de simples sites institucionais.

2.1. Portfólio

Todos os projetos são elaborados pensando na UX (user experience), ou experiência do usuário, que envolve os sentimentos de uma pessoa ao usar um produto, que a deixe feliz ao usá-lo, através da facilidade de uso, design, acessibilidade, entre outros. De forma que o cliente tenha um bom resultado com seu site, e-commerce ou aplicativo móvel. Alguns dos projetos de maiores destaques da empresa são:

Monte Seu Arguile (www.monteseuarguile.com/): e-commerce em que o usuário seleciona as peças, faz a montagem e consegue visualizar em tempo real o arguile antes de efetuar a compra pelo site.

LH Cursos Culinários (www.lhcursos.com.br/): site de compra e transmissão de aulas de culinária, onde o usuário pode assistir a uma aula ou até mesmo uma receita especifica do site.

Accessprime (www.accessprime.com.br/): e-commerce, voltada para a venda de produtos para controle de acesso e identificação de público, com venda de pulseiras e ingressos personalizados, onde o comprador consegue customizar seu ingresso de acordo com suas necessidades e visualizar o produto final antes de finalizar sua compra.

Figura 1 - Site Responsivo LH CursosFonte: LTX Design

2.1.1. Dispositivos móveis

Recentemente, com a forte demanda do mercado, a empresa começou a desenvolver aplicativos para dispositivos móveis:

A Avaliare é uma empresa de acompanhamento físico e nutricional, em seu aplicativo, o cliente pode acessar sua conta, visualizar seu cardápio nutricional, treinos, além de relatórios e gráficos de avaliação física, personalizadas para cada cliente. A empresa é a primeira no Brasil a ter esse tipo de conceito.

A padaria Bread Fast possui o serviço de drive thru, em busca de uma melhoria neste serviço, foi desenvolvido um aplicativo onde os clientes possam fazer seu pedido antes de chegar na padaria, e serem atendidos com mais agilidade, assim que o cliente chegar no estabelecimento, seu pedido já estará pronto, sem precisar ficar esperando por um longo período de tempo.

Go! Maringá é um aplicativo que lista todos os pontos turísticos, restaurantes, bares, entre outros. Onde o turista, ou morador da cidade de Maringá poderá visualizar as melhores opções de lugares para ir, baseado nas informações do local, fotos e avaliação de outros usuários do aplicativo.

Figura 2 - Aplicativo AvaliareFonte: LTX Design

2.2. Tecnologia

Para o desenvolvimento de seus produtos, a empresa faz uso de algumas linguagens de programação para cada parte do projeto, sendo elas:

Para a criação do front-end, onde a codificação da parte visual do site é feita, é usado HTML5, que consiste em uma linguagem para estruturação e apresentação de conteúdo para a web. O CSS, sigla para Cascading Style Sheets, é usado para dar estilo ao site, com cores, transições, entre outros. Para dar mais interatividade e animação ao site a linguagem JavaScript também é usada. Para garantir a responsividade do site, ou seja, que se adapte aos vários tamanhos de telas disponíveis no mercado, da melhor forma possível, é usando o framework Twitter Bootstrap.

Na fase de back-end, para a criação da lógica do site, é usada a linguagem de programação PHP5, em conjunto com o MYSQL, que é um sistema de gerenciamento de banco de dados.

Para o desenvolvimento de aplicativos móveis, além das tecnologias citadas anteriormente, também são usados o Intel XDK, uma ferramenta completa para o

desenvolvimento de aplicativos, que funciona em conjunto com o framework Cordova.

2.3. Metodologia atual

Atualmente o ciclo de desenvolvimento, ilustrado na figura 1, é simples e funciona bem somente para projetos pequenos. Em projetos maiores e mais complexos, ocorrem falhas que comprometem o custos e prazos.

Figura 3 - Ciclo de desenvolvimento de um projeto da empresaFonte: Elaborado pelo autor

Comercial: setor que faz a prospecção de clientes, venda e a documentação necessária para o início do projeto, o briefing. Atualmente os dados coletados não são suficientes para o entendimento completo do sistema, deixando subjetivo vários pontos do projeto durante todo seu desenvolvimento.

Design: consiste na criação das telas dos sites e aplicativos, que é feita baseando-se nos dados do briefing, e na identidade visual do cliente. Respeitando os conceitos da UX (user experience). Assim que o cliente aprova a posposta de layout, o projeto avança para a próxima fase.

Desenvolvimento front-end: a codificação da página é feita, usando como base o layout. Implementando efeitos, estilos e adaptando o layout para vários tamanhos de telas. O cliente poderá ver como o site ficará, e a navegação das páginas, podendo assim ter uma visão melhor do projeto. Com a aprovação do cliente, o projeto passa para a próxima fase.

Desenvolvimento back-end: nessa fase do projeto, toda a lógica do sistema é implementada, de forma que o usuário administrador do sistema consiga customizar todo o conteúdo do site.

Teste: após o termino da programação, algum envolvido no projeto faz os testes superficiais, das principais funcionalidades do sistema antes de fazer a entrega efetiva para o cliente. Infelizmente os testes nem sempre são feitos de forma efetiva.

2.4. Equipe

A equipe é formada atualmente por cinco pessoas, um responsável pelo setor comercial, um responsável pelo design do projeto, um responsável pelo front-end, e dois

programadores responsáveis pelo desenvolvimento back-end. Como a equipe é pequena, frequentemente uma mesma pessoa exerce mais de uma função em um projeto.

O responsável pela área comercial, é formado em administração, com experiência de cinco anos no ramo de vendas e prospecção de clientes.

O profissional responsável pelo design do projeto, é formado em publicidade e propaganda, certificado pela Adobe, comprovando seus conhecimentos nas ferramentas da marca. Para executar o design de um projeto, o mesmo usa o Photoshop e Illustrator, ambos da Adobe. Além de designer, ele exerce algumas funções do setor comercial, visto que o mesmo tem experiência e especialização na área de vendas.

O encarregado pelo desenvolvimento front-end, é formado em sistemas de informação, com experiência de quatro anos em desenvolvimento web, já fez alguns cursos relacionados a qualidade e desenvolvimento ágil.

Na área de programação back-end, dois profissionais se dividem entre os projetos, ambos têm experiência e cursos na área de programação.

2.5. Gestão e controle de projetos

Até final de 2015 nenhuma metodologia de gerenciamento de projetos era usada, visto que havia somente uma pessoa em cada setor da empresa, e não havia necessidade de controlar todo o processo formalmente. Mas com a contratação de novos funcionários e o desenvolvimento de projetos maiores, surgiu a necessidade de padronizar e controlar todo o desenvolvimento do projeto.

Figura 4 - Quadro de Projetos usado para organizar os projetosFonte: Elaborado pelo autor

Inicialmente o controle dos projetos era feito em um quadro fixado na parede (Figura 3), em que eram listados os projetos a serem executados. Na coluna “job list” listava-se os nomes dos projetos. Na coluna “start” datas em que os projetos se

iniciaram, ou seja, em que o contrato foi assinado. A coluna “design” lista as datas em que a fase de design de cada projeto deveria ser iniciada. Na coluna “code” a data se referia apenas a entrega final da codificação, sem especificar o desenvolvimento front-end, ou back-end, pois quando o quadro foi construído, uma mesma pessoa executava as duas tarefas. “date-line” representa a data de finalização do projeto, nesse ponto o projeto já deveria estar finalizado para serem efetuados os testes antes de entregar ao cliente, que também iria testar o produto.

No início quadro era útil e ajudava na organização, com uma pequena quantidade de projetos. Mas com o tempo e o aumento de projetos se tornou obsoleto e desorganizado. Como os prazos nem sempre eram respeitados e não havia uma ordem padrão para adicionar os projetos, não era mais viável mantê-lo.

Figura 5 - Sistema de separação por etapas (direita). Ficha do projeto (esquerda) Fonte: Elaborado pelo autor

Com a necessidade de melhorar a organização dos projetos, foi criado um sistema que divide o projeto por fases (Figura 4), start, design, front-end, back-end. Cada projeto possui uma ficha, na qual o responsável por determinada fase do projeto informa a data do início e do fim da etapa a qual é responsável, e algumas observações importantes acerca do projeto. Porém sozinho sistema não se mostrou eficiente, os responsáveis frequentemente esqueciam de preencher a ficha, ou esqueciam das datas que devim preencher.

2.5.1. Activecollab

Com a percepção da necessidade um sistema mais completo para o gerenciamento dos projetos, o ActiveCollab se mostrou uma ferramenta muito interessante, por atender todas as necessidades da empresa.

O ActiveCollab pode ser instalado em um servidor, o que permite ser acessado de qualquer lugar através da internet, a qualquer hora. Com ele é possível cadastrar todos os projetos da empresa, dividir o projeto em tarefas, e as tarefas em sub tarefas,

que são delegados a um responsável, facilitando assim o processo de desenvolvimento. Por ser online, facilita a consulta, notificações, e andamento dos projetos. Possibilitando que até o cliente consiga acompanhar o que está sendo feito no projeto.

Até o momento a ferramenta tem se mostrado suficiente para o gerenciamento dos projetos e atividades.

O ActiveCollab foi desenvolvido pela empresa A51, e lançado em 2006, como um aplicativo de código aberto, e no ano seguinte se tornou comercial. O plano mensal tem o valor de $25, que oferece serviço de hospedagem na nuvem, ou um pagamento único de $499, em que o software pode ser instalado no servidor do usuário. Porém, sua versão grátis, de código aberto, é fácil de ser encontrada e possui ótimas funcionalidades. Grandes empresas usam o ActiveCollab, como Nokia, Universidade de Harvard, BBC, Cisco, Adobe, Apple, Universal, Universidade Berkeley da Califórnia.

Figura 6 - Visão geral de um projeto no ActivecollabFonte: Elaborado pelo autor

3. Fundamentação teóricaNo desenvolvimento de software não há como prever todas as alterações que serão feitas ao decorrer do projeto. Uma das características das metodologias ágeis é sua adaptabilidade, ou seja, elas se adaptam as mudanças ao decorrer do projeto ao invés de analisar previamente o que pode acontecer durante o desenvolvimento do projeto. Segundo Libardi (2010) em uma metodologia clássica pode acontecer de que um software seja construído por inteiro e depois se descubra que ele não serve mais para o propósito que foi desenvolvido. As metodologias ágeis buscam evitar que isso aconteça pois emprega o feedback constante, que permite ao time se adaptar rapidamente as alterações no projeto.

3.1. Manifesto Ágil

Em 2001, um grupo de pessoas, com experiência em desenvolvimento de software se reuniram para discutir e melhorar o processo de desenvolvimento de software, e publicaram o Manifesto Ágil, que mais tarde se tornou a Agile Alliance, uma organização sem fins lucrativos, que promove o desenvolvimento ágil.

Segundo a Agile Aliance, os principais valores do desenvolvimento ágil são:- Indivíduos e interações valem mais que processos e ferramentas.- Software em funcionamento valem mais que documentação abrangente.- Colaboração com o cliente vale mais que negociação de contratos.- Responder a mudanças vale mais que seguir um plano.

Metodologias ágeis se mostraram uma melhor opção em relação às metodologias tradicionais no desenvolvimento de software, principalmente em projetos em que há um grande número de alterações, em que os requisitos possam sofrer mudanças durante o projeto, onde alterar o código não gere alto custo, equipes pequenas, prazos curtos. Em suma, em que o desenvolvimento deva ser rápido, eficaz e eficiente.

O Manifesto Ágil defende 12 princípios para um software ágil:- Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e

contínua de software de valor.- Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos

ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

- Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

- Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

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

- 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.

- Software funcional é a medida primária de progresso.- Processos ágeis promovem um ambiente sustentável. Os patrocinadores,

desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

- Contínua atenção à excelência técnica e bom design, aumenta a agilidade.- Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser

feito.- As melhores arquiteturas, requisitos e designs emergem de times auto

organizáveis.- Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se

ajustam e otimizam seu comportamento de acordo.

Fazendo se uma análise entre os valores e princípios das metodologias ágeis, nota-se que os aspectos humanos são considerados muito mais importantes que conceitos e engenharia. O mais relevante no processos e desenvolvimento do projeto é conseguir entregar um sistema que atenda às necessidades do cliente, em um curto prazo.

A forma padrão de desenvolvimento de software, principalmente nas pequenas

empresas, começa pela codificação. Muitas vezes nenhum planejamento é feito e requisitos, alterações e outras informações são coletados de forma totalmente informal e incompleta, o que deixa o escopo sujeito a dualidade e subjetividade da equipe, podendo gerar um alto custo no futuro.

Com o aumento do número de funcionários, da demanda de clientes e do grau de complexidade do projeto, as empresas se deparam com diversos problemas como atrasos na entrega, qualidade possivelmente inferior, muitos erros. O que pode deixar a empresa malvista perante ao cliente.

As metodologias ágeis têm como objetivo trazer qualidade através da simplicidade, feedbacks constantes, planejamento e uso da engenharia de software.

Segundo Soares (2004), uma das principais características das metodologias ágeis é sua adaptabilidade. Sendo mais vantajoso se adaptar aos novos fatores que surgem durante o projeto do que planejar previamente, tentando descobrir o que poderá acontecer durante sua execução, o que gera um alto custo e tempo. De forma que a equipe precise trabalhar muitas horas a mais que o necessário, prejudicando a qualidade do software.

A metodologia ágil prega que erros acontecem, porém eles serão revistos entes da entrega final do produto para o cliente, de formar que atenda às necessidades dele. E que mudar não é um problema e sim uma oportunidade.

Dentro do desenvolvimento ágil existem vários frameworks, cada um com sua particularidade, algumas mais voltadas para a área de gerenciamento e outras para a área de desenvolvimento. Um determinado framework pode funcionar extremamente bem para uma empresa, mas pode funcionar não tem bem assim para outra do mesmo segmento. Cada empresa deve escolher a metodologia que mais se encaixa no seu processo e adaptá-la ao ambiente da empresa. Dentre as metodologias temos: Extreme Programming (XP), DSDM, TDD, OpenUP, Scrum, FDD.

3.2. Scrum

O Scrum é uma metodologia ágil, focado na entrega do produto que consiste em um framework de projetos para pequenas equipes.

Segundo Prikladnicki (2014), o nome Scrum vem da formação do rugby, é uma tática ordenada em conjunto onde as equipes disputam a posse da bola, a participação de todos os jogadores é muito importante. A falha de um jogador pode comprometer toda a jogada. Por esta razão, o Scrum determina que há um conjunto de práticas para auxiliar uma equipe a entregar partes do produto em um ambiente desafiador e possivelmente instável.

O Scrum maximiza a entrega de modo eficaz, adaptando-se as mudanças, de forma que as funcionalidades com maior valor são desenvolvidas antes das funcionalidades com menos valor.

Segundo Prikladnicki (2014), suas principais características são: - Equipes pequenas e multidisciplinares, que trabalham juntas para produzir

versões incrementais de um produto, em iterações curtas.- Equipes auto organizáveis, que planejam e desenvolvem, ou seja, a liderança é

distribuída para cada integrante da equipe, não havendo hierarquia.- O trabalho em equipe é facilitado pelo Scrum Master, que remove os

impedimentos e garante que a equipe esteja seguindo a metodologia.- O trabalho e organizado a partir do Backlog do Produto, que é constantemente

revisado e priorizado.- A comunicação e cooperação entre a equipe, se intensifica conforme o passar

do tempo de desenvolvimento do projeto.Prikladnicki (2014) afirma que o Scrum integra conceitos de Lean,

desenvolvimento iterativo e incremental, teoria das restrições, teoria de sistemas adaptativos complexos e do estudo feito por Takeuci e Nokada em 1986. Além disso, parte de usa estrutura vem de experiências vividas por profissionais que utilizam a ferramenta em projetos.

Segundo Schawaber e Sutherland (2013) os times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível.

Schawaber e Sutherland (2013) afirmam que os eventos e regras do Scrum são imutáveis e embora seja possível implementar somente partes do Scrum, o resultado não é Scrum. Scrum existe somente na sua totalidade.

O Scrum é formado por três papéis, três artefatos e quatro cerimônias, conforme demonstrado na Tabela 1.

Tabela 1 - Formação do Scrum

Papéis Artefatos Cerimônias

Product Owner Backlog do Produto Sprint

Scrum Master Backlog do Sprint Reunião diária

Time de Desenvolvimento Incremento Revisão da Sprint

Retrospectiva da Sprint

Reunião de planejamento da Sprint

3.2.1. Papéis

O Scrum apresenta 3 papéis, que devem trabalhar juntos e comprometidos em busca de um objetivo comum. Os membros do Time Scrum são auto organizáveis e multifuncionais, devem ter autonomia para tomar decisões da melhor forma possível, resultando em uma melhor flexibilidade e produtividade. Estes papeis são:

Figura 7 - Representação de um Sprint BacklogFonte: Roman Pichler - adaptado pelo Autor

Product Owner

Product Owner, ou dono do produto, é o responsável por representar o cliente dentro da equipe, por isso, deve estar, sempre que possível, disponível para esclarecer as dúvidas da equipe. Deve ter conhecimento acerca das necessidades do cliente, e do que deve ser desenvolvido. É responsável por definir os itens que fazem parte do Backlog do Produto, priorizando as funcionalidades que devem ser implementadas antes das demais, para que itens com mais valor agregado sejam entregues a cada iteração.

Scrum MasterO Scrum Master é o membro responsável por liderar o time Scrum, cabe a ele

garantir que os valores, métodos e práticas do Scrum sejam aplicados e entendidos por todos os envolvidos no desenvolvimento do projeto. Outra de suas responsabilidades é garantir que a equipe esteja comprometida com o projeto, motivando, removendo impedimentos e auxiliando na auto-organização. Ele executa a função de um facilitador dentro da equipe.

Time de Desenvolvimento

O Time de Desenvolvimento é formado pelos profissionais responsáveis por realizar as entregas ao final de cada Sprint, ou seja, a equipe de desenvolvimento, de iterações e versões funcionais do sistema. A equipe não pode ser muito grande, deve se ter um tamanho suficiente para se manter ágil e comprometida o suficiente para alcançar os objetivos e prazos do projeto com a melhor qualidade possível.

3.2.2. Artefatos

Os artefatos do Scrum foram projetados para ajudar na organização e transparência do projeto, de modo que todos tenham acesso a eles e obtenham o mesmo entendimento acerca do produto.

Backlog do Produto

O ponto inicial do Scrum é o Product Backlog, ou Backlog do Produto, e é de responsabilidade do Product Owner fazer qualquer mudança nele, caso necessário. Consiste em uma lista ordenada dos requisitos do projeto. Essa lista nunca está completa, pois deve acompanhar o desenvolvimento do projeto, sendo atualizado conforme necessário, para ser mais apropriado e útil ao cliente. Segundo Schawaber e Sutherland (2013) o Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor.

A ordem dos requisitos do Backlog do Produto deve ser classificada de acordo com a necessidade do cliente, ou seja, as tarefas que possuem uma prioridade maior, devem aparecer no topo da lista, com um nível de detalhamento maior, já as de menor prioridade, devem aparecer ao fim da lista.

Backlog da Sprint

O Sprint Backlog consiste em uma lista com tarefas que o Time de Desenvolvimento seleciona do Backlog do Produto, e se comprometem a desenvolver durante o Sprint e entregar um incremento pronto. Para formar o Backlog da Sprint a equipe leva em consideração as prioridades definidas pelo Product Owner, e a estimativa de tempo que será necessário para executar a tarefa.

O Sprint Backlog é atualizado durante o Sprint, para melhor visualizar quais tarefas já foram completadas, quais ainda estão em desenvolvimento e quantas ainda faltam serem desenvolvidas.

Figura 8 - Representação de um Sprint BacklogFonte: Mountain Goat Software - adaptado pelo Autor

Incremento

Ao final de cada Sprint a Equipe de Desenvolvimento faz a entrega de um incremento do sistema que foi desenvolvido durante o Sprint. O Incremento deve ser algo parcialmente entregável. O cliente poderá visualizar o que está sendo feito, e possivelmente poderá usar partes do sistema.

3.2.2. Cerimônias

As cerimônias, ou eventos, do Scrum tem um tempo de duração máxima, e buscam criar uma rotina, de forma que não haja necessidade de reuniões não planejadas. Assim que um Sprint começa, ele não é deve ser reduzido ou aumentado, a duração acordada entre o time deve ser respeitada. As demais cerimônias podem ser finalizadas assim que o proposito for atingido.

As reuniões buscam além de esclarecer e acompanhar o projeto, demonstrar transparência e melhorar o processo.

Sprint

O Sprint é um evento com uma duração especifica, geralmente entre duas a quatro semanas, que resulta na entrega de um incremento do software, possivelmente utilizável. Uma Sprint inicia-se após o termino da anterior, repetidamente até o fim do desenvolvimento do projeto.

Durante um Sprint não são feitas alterações a nível de planejamento, essas alterações devem ser analisadas durante Reunião de planejamento da Sprint ou a Reunião de revisão da Sprint.

Segundo Schawaber e Sutherland (2013), um Sprint pode ser cancelado, se o objetivo se tornar obsoleto. Porém somente o Produc Owner tem autoridade para isso, embora possa ser feito por influência de outras partes do projeto, como o cliente, Time de Desenvolvimento, Scrum Master. Porém, devido a sua curta duração, raramente faz sentido serem cancelados.

Com o cancelamento do Sprint, itens já prontos são revisados, e itens todos os itens do Backlog do Produto são estimados e analisados. Cancelamentos de Sprint são raros, mas quando acontecem podem ser traumáticos para a equipe, pois demanda tempo e recursos.

Reunião de planejamento da Sprint

Reunião de planejamento da Sprint, do inglês Sprint Planning Meeting, consiste em uma reunião em que o time responsável pelo planejamento, planeja todo o Sprint. Criando assim o Sprint Backlog, que um subconjunto derivado do Backlog do Produto. O Sprint Backlog apresenta uma lista de atividades que devem ser desenvolvidas turante o Sprint. (Kniberg, 2007) afirma que somente deve ser incluído o que for possível de ser entregue, respeitando-se os prazos estabelecidos de acordo com a duração do sprint.

Nesse tipo de reunião, deve ser discutido o que será entregue no próximo sprint, e como o trabalho será realizado. Somente a equipe de desenvolvimento deve avaliar e definir o que será implementado no Sprint.

Reunião diária

As Reuniões diárias consistem em uma reunião realizada todos os dias, de forma rápida e direta, que envolve os membros da equipe para alinhar as atividades, definir quais serão as tarefas do dia, comentar sobre o que foi feito no dia anterior, impedimentos do projeto. Essas reuniões geralmente são feitas em pé, pela manhã, sempre no mesmo

horário e no mesmo local. O papel do Scrum Master é garantir que a reunião aconteça todos os dias, que tenha uma curta duração e que seja conduzida pelos membros do Time de Desenvolvimento.

Reunião de revisão da Sprint

A Reunião de revisão da Sprint é uma reunião que ocorre ao fim de cada Sprint, onde a equipe discute seus acertos, erros, lições aprendidas, dificuldades, impedimentos. Podendo assim servir de referência para futuros projetos. Com os resultados dessa reunião, o Backlog do Produto pode ser atualizado e revisado para o próximo Sprint.

Deve ser uma reunião informal, e não uma reunião de apresentação do incremento gerado na Sprint. Toda a equipe deve participar. Como resultado da reunião, temos um Backlog do Produto atualizado e revisado para o próximo Sprint.

Figura 9 - Representação de um ciclo SprintFonte: Alvaro Marciales - adaptado pelo Autor

Retrospectiva da Sprint

A Retrospectiva do Sprint ocorre logo após a Revisão do Sprint, com um objetivo semelhante. Embora seja mais focada no time do que no produto. É uma oportunidade para o time avaliar, discutir e analisar seu trabalho durante o Sprint. Além de identificar melhorias que possam ser implementadas nos próximos Sprints.

4. Processo de qualidade

A qualidade é percebida em três dimensões: no projeto, no processo e no produto. Estas três dimensões, quando combinadas, contribuem para a qualidade total do produto,

conforme afirma Bezerra (2004).

Atualmente o processo de qualidade na empresa é feito de forma informal pela equipe, somente das principais funcionalidades do sistema são testadas, deixando a responsabilidade de testar todo o sistema para o cliente, que faz solicitações de alterações e manutenção do sistema.

O desenvolvimento de software, é passível de erros, o que torna o teste necessário e indispensável para a criação de software de qualidade. O software contém defeitos e encontrá-los é um exercício demorado e custoso, afirma Cariel (2008).

Muitas empresas eliminam a etapa de testes, para que o cliente encontre os possíveis erros, e caso necessário solicite alterações. Com isso tenta-se economizar tempo e dinheiro. Pois os testes irão encontrar os defeitos, que geram retrabalho, o que afeta os custos e o prazo do projeto.

No Scrum, as entregas são feitas de forma incremental, tornando assim possível a realização de testes feitos não somente nos incrementos entregues a cada Sprint, mas também verificar se todos os incrementos interagem corretamente entre si.

5. Metodologia propostaNeste tópico estão descritas as técnicas propostas, a fim de atender as necessidades da empresa, tendo em vista a metodologia proposta, Scrum, e os estudos apresentados anteriormente.

A primeira etapa para a implementação da metodologia na empresa é demonstrar a importância e eficiência do gerenciamento de projetos no desenvolvimento de um sistema, além de alinhar o conhecimento de todos os envolvidos acerca do Scrum. Deixando todos cientes de como funciona a metodologia e como ela poderá auxiliar no desenvolvimento e crescimento da empresa, através de minicursos, palestras e reuniões. A melhor forma de aplicar os preceitos da metodologia é de forma gradual, para que os envolvidos se familiarizem com a metodologia com um impacto menor. Para isso será escolhido um projeto piloto.

5.1. Papéis

Os papéis serão distribuídos entre os membros da equipe, de forma que eles consigam exercer a função que exercem atualmente, e se adaptem e agreguem valor com o Scrum.

O Product Owner representa o cliente dentro da empresa, por isso deve conhecer as necessidades do cliente, de forma que consiga tirar as dúvidas da equipe. Atualmente, o setor comercial efetua uma reunião para entender as necessidades do cliente antes de iniciar o projeto. Porém somente essas informações não são suficientes, e a empresa precisa entrar em contato com o cliente, para conseguir compreender melhor suas necessidades e sanar dúvidas que o setor comercial não conseguiu. Tendo isso em vista, quando possível, o cliente será o Product Owner, se comprometendo a ir a empresa, ou estar disponível por um determinado período de tempo a fim de desenvolver um melhor produto com menos retrabalho possível. Para o cliente é vantajoso pois ele poderá

acompanhar o processo de desenvolvimento do projeto e garantindo prazo e custos. Quando a presença do cliente não for necessária, ou possível, o setor comercial irá atuar no papel de Product Owner, assim como é feito atualmente, porém deverá fazer uma coleta de requisitos mais aprofundada, inicialmente podendo ser auxiliado por algum membro do Time de Desenvolvimento, para que consiga saber as informações mais importantes que devam ser coletadas.

O Scrum Master é um papel a ser executado por alguém que tenha conhecimento na metodologia, para que consiga guiar a equipe e garantir que os mesmos estão seguindo o Scrum. O Scrum Master deve ter liderança, ser imparcial e transparente, para que consiga resolver impedimentos e facilitar o desenvolvimento do projeto. Tendo isso em vista, atualmente o responsável pelo front-end se encaixa melhor nesse perfil, pois conhece a metodologia Scrum, e tem conhecimento no desenvolvimento do projeto, podendo guiar a equipe no uso do Scrum e sendo imparcial, levando o Time de Desenvolvimento e o Product Owner chegarem em acordos.

O Time de Desenvolvimento será a equipe de desenvolvimento, que envolve desenvolvimento back-end e front-end, de forma que continuem executando seu trabalho, porém usando os preceitos do Scrum. A equipe não passará por grandes mudanças para se adaptar, visto que o Scrum irá simplificar o processo de desenvolvimento, organizando e dividindo o projeto em incrementos.

5.2. Artefatos

Para a criação do Backlog do Produto, a primeira medida importante a se tomar é criar uma lista de requisitos, para identificar e ordenar os requisitos do cliente, buscando facilitar o acesso dos envolvidos aos requisitos em qualquer etapa do projeto. Buscando um fácil entendimento tanto por parte do cliente quanto dos desenvolvedores, descrevendo de forma simples e objetiva em linguagem natural, podendo ser auxiliada, caso necessário por diagramas UML (Unified Modeling Language), como diagrama de caso de uso, diagrama de sequência, diagrama de classes, entre outros. Nessa etapa também será feita a criação das User Stories, e a priorização das mesmas. As User Stories são usadas para descrever uma funcionalidade do sistema, de forma simples e de fácil entendimento, onde procura mostrar o ator, ação e funcionalidade.

De forma a aproveitar a estrutura da empresa, o quadro antigamente usado para o planejamento (figura 4), será usado como Scrum Board, onde o acompanhamento do projeto poderá ser feito, usando papéis autoadesivos para indicar as atividades a serem feitas no Sprint e sua prioridade. Ou seja, o Backlog do Sprint, ele ficará visível para todos da empresa, de forma que o acompanhamento do projeto seja mais efetivo. Como pode-se observar na figura 11, o Scrum Board será dividido em “Não Iniciado”, onde ficarão as funcionalidades que serão implementadas no Sprint. “Iniciado”, com as funcionalidades que estão em execução, e “Pronto”, onde ficarão as funcionalidades já finalizadas do Sprint. Caso mais de um projeto esteja sendo executado ao mesmo tempo, eles serão diferenciados pelas cores dos papéis autocolantes. Buscando aproveitar a tecnologia que a empresa já usa. No Scrum Board somente estarão o título da funcionalidade a ser implementada, no ActiveCollab, apresentado anteriormente, estará a descrição da tarefa, caso necessária, dividida em sub tarefas, além dos diagramas e arquivos necessários para o desenvolvimento da Sprint, fornecendo assim mais um indicativo do avanço do projeto e facilidade de acesso aos arquivos

necessários.

As Sprints, inicialmente, terão duração de duas semanas. Caso haja necessidade, esse tempo poderá ser alterado, para mais ou para menos.

Ao fim de cada Sprint o incremento entregue será adicionado aos incrementos desenvolvidos nos Sprints anteriores, formando assim um produto que possa ser entregue ao cliente e gere algum valor. O incremento só será entregue ao cliente caso gere algum valor, ou seja, caso seja útil de alguma maneira.

Figura 11 - Representação de um Sprint BacklogFonte: Kniberg (2007) adaptado pelo Autor

5.3. Cerimônias

A Reunião de Planejamento do Sprint será feita no começo de cada Sprint, com todo Time Scrum, para avaliar o Backlog do Produto e definir o que será feito no Sprint que se iniciará. O Time de Desenvolvimento verificará as funcionalidades que ainda não foram desenvolvidas e selecionará as tarefas do Backlog do Produto que serão feitas nesse Sprint respeitando o tempo total do Sprint, que nos primeiros projetos será de duas semanas.

Todos os dias serão feitas reuniões, as chamadas Daily Scrum Meeting, ou Reuniões Diária. Elas terão curta duração, a fim de garantir isso, as reuniões terão duração de 15 minutos, serão feitas antes do horário de almoço do Time Scrum, e serão ser feitas em pé, para que os participantes sintam necessidade de serem rápidos. Nessas reuniões será abordado o progresso, dificuldades, impedimentos e êxitos no projeto. Ajudando na programação diária de cada envolvido. Em busca de uma maior comunicação entre os membros da equipe, possibilitando que todos opinem e sugiram mudanças ou ajudem nas dificuldades. A Daily Scrum Meeting ajuda a equipe a identificar o progresso do projeto.

Três perguntas devem ser respondidas nessa cerimônia:- O que eu fiz desde a última cerimônia?- O que irei fazer até a próxima?

- Existe algo que possa me impedir?

Ao fim de cada Sprint será feita uma reunião para verificar o que foi executado durante o Sprint, essa reunião é conhecida como Sprint Review ou Revisão de Sprint. Os envolvidos devem fazer um resumo do Sprint que está finalizando, de forma que apresente seus sucessos, dificuldades e impedimentos, mostrando assim as lições aprendidas do Sprint. A intenção é avaliar o que foi feito e verificar se existe alguma alteração a ser feita para auxiliar e facilitar o próximo Sprint. Caso haja alguma necessidade, o Product Backlog poderá ser atualizado ou modificado. Ao fim de cada Sprint também será realizada uma reunião de Retrospectiva do Sprint, logo após o termino da Revisão do Sprint. Essa reunião tem o intuito de verificar o processo e não o produto. Verificando se algo deve ser alterado para os próximos Sprints.

6. Considerações finaisEsse trabalho tem como objetivo demonstrar o funcionamento da metodologia Scrum e adaptá-la ao ambiente de uma microempresa de desenvolvimento de sistemas web, que atualmente não usa nenhum método formal para gerenciar e controlar seus projetos.

Conclui-se que a empresa não terá muitos problemas e impedimentos para a implementação da metodologia no seu dia a dia. Visto que a metodologia Scrum é aderente a realidade da empresa, que se mostrou receptiva a novas maneiras de gerenciar o processo de desenvolvimento. Com a implementação do Scrum busca-se a alteração de alguns aspectos na empresa.

Tabela 2 - Expectativa de melhoria na empresa com uso do Scrum

Item Antes Depois

QualidadeO projeto é testado somente uma vez, antes da entrega ao cliente

Os testes serão feitos a cada entrega de incrementos do produto

Gerência do projeto Não há nenhum planejamento formal.

O projeto será planejado antes do desenvolvimento e antes de cada Sprint

Entregas

O cliente só consegue visualizar o avanço do seu projeto nas aprovações solicitadas a ele. E quando o projeto é finalizado e entregue.

As entregas serão feitas de forma incremental, de forma que o cliente consiga usar o software antes mesmo de estar completamente finalizado, conseguindo visualizar o que está sendo feito.

Contato com o cliente O contato com o cliente é de responsabilidade do setor comercial. Gerando

O cliente irá atuar dentro da empresa para sanar dúvidas e demandar

requisitos vagos.

requisitos. Na ausência do cliente, cria-se a figura do Product Owner, que tem grande interação com o cliente e conhece as regras do negócio.

Planejamento do projeto Os projetos não são planejados formalmente.

O planejamento é feito de forma rápida no início do projeto e relampejando a cada Sprint.

Funcionalidades Não há padrão ou ordem para a implementação.

As funcionalidades com maior prioridade são implementadas antes, para que o cliente consiga um retorno do investimento mais de forma mais rápida

Lições aprendidas Não há método formal para documentar.

O time realiza reuniões de revisão para documentar.

Com o uso da metodologia se espera uma melhora no processo de desenvolvimento e consequentemente no produto final. Em que o time possa estimar melhor prazos de entrega, se organizar em meio aos projetos, ser mais produtivo e dinâmico. Além de poder incluir mais o cliente no ambiente da empresa, em busca de um produto final de maior qualidade, que consiga gerar retorno financeiro e satisfação, dando a oportunidade de acompanhar todo o processo de criação.

7. Referências

Kniberg, H. (2007), Scrum e XP Direto das Trincheiras.

Prikladnicki, R, Willi, R and Milani, F. (2014), Métodos Ágeis Para Desenvolvimento de Software.

Schwaber, K, Sutherland, J. (2013), Guia do Scrum.

Schwaber, K. (2005), SCRUM Development Process.

Bezerra, C. A. (2004), A qualidade do processo de desenvolvimento de software a partir da gestão de projetos: um estudo de caso.

Soares, M. D. S. (2003), Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software.

Libardi, P. L. O and Barboda, V. (2010), Métodos Ágeis.

Carriel, G. N. (2008), Um modelo para pequenas empresas iniciarem processos de qualidade através de aspectos extraídos de métodos ágeis.

Carvalho, B. V. (2008), Um modelo para pequenas empresas iniciarem processos de qualidade através de aspectos extraídos de métodos ágeis.

Carvalho, B. V. and Mello, C. H. P. (2012), Aplicação do método ágil Scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnológica.

Yebahi, H. and Camargo, L. (2014), Desenvolvimento e aplicação de uma ferramenta para controle de solicitações e avaliação de impacto da utilização de SCRUM em empresa NIBSS: Estudo de caso.

Carvalho, B. V. and Mello, C. H. P. (2009), Revisão, análise e classificação da literatura sobre o método de desenvolvimento de produtos ágil Scrum.

Santos, J. I. dos. (2008), Papes: Processos adaptáveis para pequenas empresas de software.

Scrum Alliance (2015), The 2015 State of Scrum Report.

Roman Pichler - www.romanpichler.com - Acessado em 03/05/2016 - 18:30

Mountain Goat Software - www.mountaingoatsoftware.com - Acessado em 03/05/2016 - 19:40

ActiveCollab - www.activecollab.com/ - Acessado em 04/05/2016 - 12:40

Alvaro Marciales - http://alvaromarciales.blogspot.com.br - Acessado em 04/05/2016 - 12:55