O desenvolvimento de software é uma “aventura”, a equipe de desenvolvimento enfrentará “criaturas mitológicas” para alcançar o resultado final que é o grande prêmio. Foi com esta comparação que Cohn (2011) descreveu a criação de programas de computador, seguindo a visão poética do co-criador do scrum pode-se comparar uma pequena empresa a um pequeno grupo de caçadores pré-históricos onde qualquer alteração no cenário causa a total fragmentação do grupo e cada pequena conquista uma grande vitória.

Sutherland (2014), um dos criadores do scrum, solicitou que uma equipe de programadores assistisse ao ritual de uma equipe de rúgbi, e que eles identificassem as características que tornavam aquele grupo único. São de eventos empíricos como conceitos das artes marciais, militarismo e do próprio desenvolvimento de software que inspiram o scrum.

Derivando um pouco a teoria de Sommerville (2007) conclui-se que a viabilidade da produção do software é relacionada a técnica, método e disciplina que são inerentes a metodologia no processo de desenvolvimento de software. Sem definir as atividades que serão realizadas poderão ocorrer imprevistos como, por exemplo, pouca maturidade no escopo do projeto gerando inconsistência entre a análise de viabilidade e qual o retorno de um dado projeto.

Um processo de desenvolvimento de software com metodologia ágil possui custo reduzido quando comparado as metodologias tradicionais pois, conforme Sutherland (2014), são executadas em etapas distintas de forma lenta e imprevisível. Estas características inviabilizam a aplicação de processo com este formato em uma empresa de desenvolvimento de software de pequeno porte com recursos escassos.

Uma empresa de pequeno porte precisa de rápidos resultados para acompanhar a competitividade do mercado, uma alternativa para alcançar esse objetivo é possuir uma equipe multifuncional, auto gerenciável e transcendental. De acordo com Sutherland (2014), a metodologia scrum foi inspirada nestes princípios e com o objetivo de reduzir ao mínimo o desperdício e elevando ao máximo a produção com os recursos disponíveis.

O “minimundo” analisado possui pouca, ou nenhuma, burocracia. A hierarquia não é bem definida e os membros não possuem funções estabelecidas, o perfil dos stackholders favorece a comunicação e algum dinamismo, por consequência, adaptabilidade, transparência e auto-organização na equipe de desenvolvimento.

O objetivo do projeto é aplicar o scrum, relatar essa experiência e avaliar a eficácia perante um cenário com poucos recursos.

A metodologia ágil, categoria que engloba o scrum, é compatível com o cenário existente. Estas características indicam provável, e considerável, ganho com a autogestão, flexibilidade e entregas parciais daquilo que foi desenvolvido.

Metodologia

Realização de trabalho in loco com as seguintes etapas:

Revisão de literatura do scrum;

Captura de dados qualitativos e quantitativos antes e durante o projeto;

Análise de artefatos antes e durante o projeto;

Captura de informações durante a implantação, discriminando como, quais e quando foram iniciadas as atividades;

Realização de estudo de caso para avaliação do trabalho realizado.

Scrum

Conforme Sommerville (2007) software pode ser definido como um programa de computador e sua respectiva documentação. Um produto de software pode ser criado para um determinado cliente ou para o público em geral. O programa de computador chega a alcançar milhões de linhas, como exemplo a quantidade de linhas do sistema operacional windows são mais de 50 milhões de linhas segundo a Exame (2015).

O termo engenharia de software surgiu na década de 1960 diante das dificuldades inerentes ao processo de desenvolvimento. Segundo Sommerville (2007) os processos para a produção de software, desde a sua especificação e até a sua manutenção são o objeto de estudo da engenharia de software. É valido analisar os processos com a visão de Bauer (1998) que defende o uso de embasamento teórico com o objetivo de desenvolver software sem desperdício de recursos.

Conforme Sutherland (2014) a maior parte do desenvolvimento de software até o ano de 2005 era realizada na metodologia cascata. Segundo Rezende (2005) nesta modalidade os processos são executados em série e de forma distinta até o lançamento para os usuários. Obrigatoriamente a ordem das etapas serão seguidas, não é possível retornar a etapa anterior como pode ser observado na (Figura 1).

Figura 1 Modelo de Processo em Cascata

Fonte Sommerville (2007, p. 44)

Após diversos projetos findarem em resultados desastrosos a eficácia da metodologia em cascata foi posta em cheque. O projeto Sentinel, do FBI, pelo uso de metodologia prescritiva e hierarquizada segundo Sutherland (2014), teve orçamento e prazo estourados com enorme discrepância com os valores estimados inicialmente.

A metodologia scrum nasce para corrigir os erros da metodologia em cascata e é categorizada como ágil pois segue os princípios e valores do manifesto ágil. Este documento foi elaborado em 2001 em reunião realizada com renomados profissionais do desenvolvimento de software, onde foram compiladas as interseções entre as novas formas de fazer software.

Os criadores do scrum, Schwaber e Sutherland, participaram da criação do manifesto ágil. Eles definem a metodologia scrum como sendo “conjunto de práticas que auxiliam o desenvolvimento e manutenção de produtos complexos”.

A metodologia possui ciclos, curtos e fixos, para o desenvolvimento e lançamento de funcionalidades. Assim sendo, um retorno é obtido rapidamente garantindo a qualidade do que será entregue.

O termo scrum é referência a um movimento no rugby, quando os participantes de ambas as equipes disputam a passe da bola. Se alguém cai, o grupo inteiro ao qual ele pertence é prejudicado. A escolha do nome foi feita pela valorização que é atribuída a conexão entre os representantes de um time, de forma similar ao referido esporte.

A metodologia é divida em papéis, rituais e artefatos.

Case de Sucesso que apresentamos na Campus Party

Papéis do scrum

O scrum possui três papéis: time de desenvolvimento, scrum master e product owner.

Scrum master

Cohn (2011) afirma que este papel deve ser exercido por alguém com capacidade motivacional para a equipe, de tal forma que a mesma se auto gerencie. Deve reconhecer o valor dos princípios do manifesto ágil. Influente e subsidiado pela organização de tal forma que consiga remover quaisquer dificuldades. É importante ressaltar que o scrum master não tem autoridade sobre o time e sim sobre o processo de desenvolvimento.

Product owner

É aquele que representa os interesses do cliente em um time scrum. Este papel exige engajamento com o produto final pois determinará quais e em que ordem as funcionalidades serão produzidas, além de facilitar a troca de informações entre a equipe e o cliente.

Um item deve agregar valor, cabe ao product owner aceitar ou não sua liberação seguindo algum critério de qualidade.

Time de desenvolvimento

A equipe de desenvolvimento é composta por um grupo de pessoas multifuncionais, ou seja, expertise em áreas distintas. O grupo deve possuir de 3 a 9 pessoas, e precisa estar apto a desenvolver as funcionalidades solicitadas pelo product owner durante uma dada sprint.

Os componentes da equipe determinam a forma como serão desenvolvidas as funcionalidades e não há hierarquia, pois, o grupo é auto gerenciável.

Artefatos

Segundo o dicionário Michaelis um artefato é um “Aparelho, mecanismo ou engenho construído para finalidade específica”. O foco é direcionar o trabalho para os pilares do scrum que são a inspeção, transparência e adaptação.

Visão do produto

Este é um documento orgânico, ou seja, deve sofrer alterações conforme o projeto avança e para possibilitar agregar valor quando realizada a liberação do produto. Deve ser simples e de fácil entendimento por todos os envolvidos.

Irá conter a ideia central do projeto, “Uma loja de livros que realize vendas nas vinte e quatro horas do dia” seria uma visão de produto inicial para um portal de venda de livros.

Product backlog

Uma fila com as funcionalidades a serem implementadas. A ordem dos itens indica a prioridade, pois os primeiros serão desenvolvidos nas próximas sprints.

Novas funcionalidades e qualquer alteração no trabalho já realizado obrigatoriamente passarão pelo product backlog, o product owner é o responsável pelas alterações neste artefato.

Novas funcionalidades são inclusas no backlog e ajustadas na fila de acordo com a prioridade das mesmas, caso um item perca a utilidade será removido da lista o quanto antes.

Após o ciclo de desenvolvimento a funcionalidade finalizada será analisada pelo product owner que determinará se a mesma está ou não de acordo com os critérios de qualidade, se isto ocorrer aquele item é removido do product backlog e aquilo que foi desenvolvido é integrado ao produto já existente.

Sprint backlog

Similar ao product backlog mas esta lista possui apenas os itens que serão desenvolvidos no ciclo atual. Este documento é de responsabilidade do Time de Desenvolvimento.

A qualquer momento a equipe altera a lista, ajustando-a as alterações que ocorreram durante o desenvolvimento.

Rituais

Foram desenvolvidos com a preocupação de prover ritmo para a produção decrementando interrupções indesejadas, por exemplo reuniões desimportantes e longas.

Existe algum cuidado com o tempo, por essa razão os eventos devem ocorrer em tempo pré-estabelecido, removendo desperdícios.

Reunião de planejamento

São selecionados os itens do product backlog que farão parte do sprint backlog determinando assim quais funcionalidades serão desenvolvidas. Também são definidas quais atividades precisam ser realizadas para que aqueles itens sejam concluídos.

Sprint

Deve durar entre uma e duas semanas, momento que as funcionalidades serão produzidas pela equipe. O tempo não deve passar de quatro semanas, pois o cenário pode ter mudado drasticamente e as funcionalidades produzidas perderem a serventia. Ao final do ciclo é esperado a liberação de algo funcional e usável.

O scrum master, durante a sprint, deve isolar a equipe de situações externas, removendo as barreiras para a concretização do trabalho

O product owner precisa estar presente durante a maior parte do tempo. Sua ausência durante a sprint ocasiona transtornos pois dúvidas a respeito das funcionalidades a serem desenvolvidas dependem de sua presença para serem sanadas já que possui maior contato com o cliente.

Figura 2 Metodologia scrum

Fonte <http://www.mindmaster.com.br/scrum/> Data de acesso 20 de novembro de 2017

Reunião diária

Com duração máxima de 15 minutos, deve ocorrer em mesmo horário e local e com todos os membros da equipe de desenvolvimento participando, é interessante que pessoas externas não participem deste momento. Cada integrante responderá as três perguntas:

º Qual atividade foi realizada?

º Qual a próxima a atividade a ser realizada?

º Há algum obstáculo para a realização das atividades?

Dessa forma os integrantes da equipe podem alertar algo para o product owner ou para o scrum master.

Um certo cuidado deve ter o scrum master quanto as queixas da equipe, pois é sua função eliminar as pendencias relatadas garantindo a produtividade do grupo.

Reunião de revisão da sprint

Ocorre ao término de um ciclo, irá avaliar os itens desenvolvidos e, se for preciso, renovar o product backlog.

A equipe de desenvolvimento e os demais envolvidos irão refletir a respeito do que foi feito e sobre as próximas funcionalidades a serem desenvolvidas.

A equipe de desenvolvimento informa os pontos positivos da sprint, dificuldades encontradas e quais soluções adotadas. Apresentará as funcionalidades concluídas e responde a questionamentos sobre as mesmas.

O product owner determina quais itens estão ou não satisfatórios com os critérios de qualidade especificados. O product backlog é revisado, e estimativas de conclusão são realizadas.

Reunião de retrospectiva da sprint

Essa reunião tem com finalidade promover a melhoria contínua do time de desenvolvimento.

O scrum master atua como mediador incentivando o grupo a avaliar o modo de trabalho levantando os pontos positivos e os negativos.

A pós esse momento, o grupo terá conhecimento de quais melhorias precisam acontecer e uma listagem das ações que deram resultado o resultado esperado.Estudo de caso

Esta seção apresenta a aplicação da metodologia scrum em projetos de desenvolvimento de software, conforme afirmado na seção 1 e 2.

Descreve-se três projetos entre os meses de julho a novembro, equipe composta por três pessoas atuando em horário comercial. Os integrantes do time possuíam pouca experiência em desenvolvimento de software e com o scrum.

As informações serão apresentadas conforme Sato (2007), a tabela abaixo descreve o contexto do ambiente que a equipe de desenvolvimento atuou:

Local
Disposição Física Espaço de trabalho arranjado num espaço amplo.
Nível de Distração no Espaço de Trabalho Moderado, a sala era dividida com outra empresa.
Comunicação com Cliente Geralmente via aplicativo de mensagens em smartphone. Ocasionalmente por e-mail ou presencial.
Localização do Time Todos trabalham juntos no mesmo ambiente
Tecnologia
Modelo de Desenvolvimento Principalmente SCRUM
Linguagem PHP, com tecnologias e arcabouços relacionados (Laravel, Eloquent, Blade, Composer)
Ferramentas PHP Storm, Pencil, Workbench, Whatsapp, Trello

De um modo geral, as funcionalidades do software a serem desenvolvidas eram capturadas diretamente entre o programador e o interessado. São escritas pequenas narrativas (estórias de usuário) descrevendo uma dada funcionalidade. As “estórias” de usuário recebem valores indicativos de esforço e valor, possibilitando cálculo de métricas que auxiliam o ordenamento das atividades a serem realizadas.

Ao concluir um item um membro avalia se está de acordo com os critérios de aceitação, se estiver de acordo então o item é liberado para o cliente. Caso o item esteja com as qualidades esperadas e aprovados pela equipe e pelo cliente, então recebe a definição de pronto e outra atividade é colocada em produção. Caso não tenha atingido as expectativas mínimas é realocado na produção e refeito.

Projeto 1 – “T_Seeder”

Visão do Produto: Software desenvolvido para empresa de telecomunicações, para gestão de microchips pela identificação numérica serial dos chips.

Tabela de Informações:

Fatores Sociológicos
Tamanho da Equipe 3 pessoas
Nível de Educação da Equipe Estudantes de Graduação
Nível de Experiência da Equipe < 2 anos
Conhecimento do Domínio Baixo
Conhecimento da Linguagem Baixo
Fatores Específicos do Projeto
Estórias Entregues 5
Domínio Web, Site
Pessoas Mês 3
Tempo de Projeto 2 semanas
Total de Commits 16

Projeto 2 – “HWA”

Visão do Produto: Software desenvolvido para federações esportivas, para gestão de atletas e competições, sendo suas principais funcionalidades a inscrição de

Tabela de Informações:

Fatores Sociológicos
Tamanho da Equipe 3 pessoas
Nível de Educação da Equipe Estudantes de Graduação
Nível de Experiência da Equipe < 2 anos
Conhecimento do Domínio Médio
Conhecimento da Linguagem Médio
Fatores Específicos do Projeto
Estórias Entregues 10
Domínio Web, Site
Pessoas Mês 3
Tempo de Projeto 1 mês
Total de Commits 280

Projeto 3 – “BPMBR”

Visão do Produto: Sistema web para consultores em processos de negócio com funcionalidades de blog e captura de novos clientes

Tabela de Informações:

Fatores Sociológicos
Tamanho da Equipe 3 pessoas
Nível de Educação da Equipe Estudantes de Graduação
Nível de Experiência da Equipe < 2 anos
Conhecimento do Domínio Médio
Conhecimento da Linguagem Médio
Fatores Específicos do Projeto
Estórias Entregues 10
Domínio Web, Site
Pessoas Mês 3
Tempo de Projeto Em andamento
Total de Commits 90

5. Considerações finais

A ideia central deste trabalho foi apresentar a metodologia scrum e seus efeitos na prática. Para alcançar este objetivo foi realizada uma iniciativa de empreendedorismo, cursos teóricos e práticos sobre o scrum além de pesquisa bibliográfica sobre o assunto.

O manifesto ágil foi elaborado a fim de compilar as metodologias de desenvolvimento que demonstraram resultado acima da média, e em seu texto é afirmado que o caminho é encontrar a melhor maneira de fazer software dando preferência as pessoas do que a métodos e ferramentas.

A ausência de hierarquia favoreceu o trabalho em equipe, os membros por não possuírem tarefas bem definidas não ficavam limitados ao que foi imposto. Certa vez foi dito por um dos integrantes quando a sala estava sem refrigeração “aqui eu trabalho nesse forno por 12 horas e feliz, no meu estágio eram 4 horas que eu detestava concluir mesmo não sendo tão quente”.

A forma cíclica que as atividades são realizadas permitem um grande aprendizado perante as ferramentas, a usabilidade do produto final e diversos outros atributos favorecendo uma produção mais madura com o passar de certo tempo.

Código bem escrito é a melhor documentação para um bom programador e isto pode ser visto no manifesto ágil quando é afirmado que software funcional é medida primária de progresso. Uma grande parcela de tempo foi poupada com essa prerrogativa pois pouca documentação foi criada, aspecto crucial dado os recursos limitados do cenário analisado.

Embora o time estivesse fortemente aplicado pelo direcionamento da metodologia de desenvolvimento scrum, não possível aplicá-lo por completo, seja porque o tamanho do time fosse pequena ou seja por falta de experiência. Vale ressaltar que todos os integrantes do time foram treinados na metodologia scrum. A metodologia scrum não possui início, meio e fim. O tempo é dividido em ciclos e aqueles já ocorridos servem de alicerce para os que estão por vir e assim manifesta-se o estado da arte: evolução constante.

Importante salientar também que os resultados foram satisfatórios e serviu como incremento para melhoria do processo.

Referencias

FRANKLIN, Luccas. Google tem 2 bilhões de linhas de código, 2015. Disponível em: <https://exame.abril.com.br/tecnologia/servicos-do-google-somam-2-bilhoes-de-linhas-de-codigo/> Acesso em 12/10/2017.

SATO, Danilo. Uso Eficaz de Métricas em Métodos Ágeis de Desenvolvimento de Software, 2007. Disponível em: <http://www.teses.usp.br/teses/disponiveis/45/45134/tde-06092007-225914/pt-br.php/> Acesso em 20/08/2017.

HIRAMA, Kechi. Engenharia de Software: Qualidade e Produtividade com Tecnologia. 2012 1ª Edição Rio de Janeiro.

SOMMERVILLE, Ian. Engenharia de Software. 2007 8ª Edição Rio de Janeiro.

COHN, Mike. Desenvolvimento de Software com Scrum. 2011 1ª Edição Porto Alegre.

SUTHERLAND, Jeff. Scrum A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. 2014 2ª Edição Rio de Janeiro.

REZENDE, Dênis. Engenharia de Software e Sistemas de Informação. 2005 3ª Edição Rio de Janeiro.

ARTEFATO. DICIONÁRIO MICHAELIS ONLINE da língua portuguesa. Disponível em <http://michaelis.uol.com.br/moderno-portugues/busca/portugues-brasileiro/artefato/> Acesso em:10/11/2017

SCRUM – APRENDA SCRUM EM 9 MINUTOS. Youtube. Disponível em <https://www.youtube.com/watch?v=XfvQWnRgxG0&t=9s> Acesso em:20/07/2017

SCRUM: A METODOLOGIA ÁGIL EXPLICADA DE FORMA DEFINITIVA. Disponível em <http://www.mindmaster.com.br/scrum> Acesso 20/11/2017.

Autores:

David Alves

David Meth

Othon Batista

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *