Bernardo Dalpiaz Soares
DIAGNÓSTICO DE MÉTODOS ÁGEIS PARA EMPRESAS DO SEGMENTO DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO
Araranguá 2019
Bernardo Dalpiaz Soares
DIAGNÓSTICO DE MÉTODOS ÁGEIS PARA EMPRESAS DO SEGMENTO DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO
Trabalho Conclusão do Curso de Graduação do Centro de Ciência, Tecnologia e Saúde da Universidade Federal de Santa Catarina como requisito para a obtenção do Título de Bacharel em Tecnologias da Informação e Comunicação. Orientador: Prof. Dr. Helio Aisenberg Ferenhof
Araranguá 2019
Este trabalho é dedicado especialmente à minha família: Meu pai João Batista, minha mãe Cristina, meus irmãos Guilherme, João Vitor, Enzo, e minha namorada Suyanne.
AGRADECIMENTOS
Aos meus familiares, que contribuíram para que esta etapa fosse concluída, meus profundos agradecimentos por todo apoio e incentivo.
Agradeço ao meu orientador Prof. Dr. Helio Aisenberg Ferenhof, por toda dedicação e aprendizado repassado, tendo participação essencial para a elaboração deste trabalho.
Ao corpo docente e servidores da Universidade Federal de Santa Catarina de algum modo contribuem para a entrega de um ensino de qualidade.
À banca examinadora, Prof.ª Dr.ª Andréa Cristina Trierweiller e Profª. Dr.ª Fabiana Santos Lima, por terem aceitado o convite, tendo minha total admiração.
Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende. (Leonardo da Vinci)
RESUMO
Junto a realidade atual onde existem diversos métodos ágeis com características muitas vezes similares, encontra-se a dúvida de qual destes ser aplicado em uma empresa. Perante a isso, este trabalho buscou identificar junto a literatura, vantagens e desvantagens dos métodos ágeis a fim de encontrar uma forma de criar um ranking para a escolha de qual destes métodos seria mais adequado para determinada organização. Para a avaliação do perfil da empresa versos método ágil tomou-se base em um survey, por meio de um questionário auto administrável pela internet com perguntas fechadas, onde cada um dos respondentes foi considerado um caso. A analise deste estudo de casos, utilizou-se a métrica desenvolvida advinda da análise da literatura, resultando em uma pontuação individual para cada caso e uma recomendação de método ágil mais alinhado ao perfil da empresa caso. Com a aplicação da ferramenta, mesmo quando resultando em uma pontuação que empate, foi possível identificar os métodos que mais se adaptam ao perfil da empresa caso. Sendo assim, acredita-se que a ferramenta se mostra efetiva e pode auxiliar empresas na escolha de método ágil a ser implantado.
ABSTRACT
Alongside the current reality where there are several agile methods with characteristics often similar, one finds the doubt of which of these to be applied in a company. In this way, this work sought to identify with the literature, advantages, and disadvantages of agile methods in order to find a way to create a ranking to choose which of these methods would be more appropriate for a given organization. For the evaluation of company profile versus agile method was based on a survey, through a self-administered questionnaire with closed questions, where each of the respondents was considered a case. The case study analysis used the developed metrics derived from the literature analysis, resulting in an individual score for each case and an agile method recommendation more aligned to the company case profile. With the tool application, even when resulting in a score that tie, it was possible to identify the methods that best fit the company's case profile. Thus, it is believed that the tool is useful and can help companies in the choice of an agile method to be implemented.
Keywords: Agile Method. Ranking. Case Study. Metric.
LISTA DE FIGURAS
Figura 1 - Modelo Clássico ... 20 Figura 2 - Ciclo de vida do Scrum ... 28 Figura 3 - Pesquisa métodos ágeis. ... 33
LISTA DE TABELAS
Tabela 1 - Vantagens e desvantagens dos métodos ágeis. ... 37
Tabela 2 - Perguntas norteadoras ... 40
Tabela 3 - Respostas do Caso 1 ... 43
Tabela 4 - Respostas do Caso 2 ... 44
Tabela 5 - Respostas do Caso 3 ... 45
LISTA DE ABREVIATURAS E SIGLAS
DSDM – Dynamic Systems Development Methodology FDD – Feature Driven Development
SUMÁRIO 1 INTRODUÇÃO ... 15 1.1 OBJETIVOS ... 16 1.1.1 Objetivo Geral ... 17 1.1.2 Objetivos Específicos ... 17 2 FUNDAMENTAÇÃO TEÓRICA... 19 2.1 METODOLOGIA TRADICIONAL ... 19 2.2 METODO ÁGIL ... 20 2.2.1 Extreme Programming (XP) ... 22 2.2.2 Scrum ... 24 2.2.2.1 Práticas ... 26 2.2.2.1.1 Backlog do Produto ... 26 2.2.2.1.2 Estimar o Esforço ... 26
2.2.2.1.3 Sprint (Desenvolvimento Iterativo) ... 26
2.2.2.1.4 Reunião de Planejamento do Sprint ... 27
2.2.2.1.5 Elaborar Backlog do Sprint ... 27
2.2.2.1.6 Reunião Diária do Scrum ... 27
2.2.2.1.7 Reunião de Revisão do Sprint ... 28
2.2.2.2 Processo ... 28
2.2.2.2.1 Pré-Game ... 29
2.2.2.2.2 Desenvolvimento ... 30
2.2.2.2.3 Pós-Game ... 30
2.2.3 Demais metodologias e utilizações ... 30
2.2.3.1 Crystal ... 30
2.2.3.2 Feature Driven Development ... 31
2.2.3.3 DSDM (Dynamic Systems Development Methodology) ... 32
2.3 ABORDAGEM HIBRIDA... 33 3 METODOLOGIA ... 35 3.1 INSTRUMENTOS DE COLETA ... 35 4 RESULTADOS E DISCUSÕES ... 37 4.1 CASO 1 ... 43 4.2 CASO 2 ... 44 4.3 CASO 3 ... 45 4.4 CASO 4 ... 45 5 CONCLUSÃO ... 47
1 INTRODUÇÃO
Os Métodos Ágeis estão sendo cada vez mais procurados nas indústrias de software, afim melhorar a qualidade dos sistemas e suprir as necessidades dos clientes (SATO, 2007). A utilização destes métodos, procura entregar um projeto final que satisfaça a necessidade do cliente, pelo fato de que o mesmo participa frequentemente do início até o fim do projeto. Os métodos ágeis, possuem ferramentas e técnicas que envolvem os stakeholders na definição dos requisitos do projeto (ALMEIDA, 2017). Este fato, faz com que se leve em consideração o acompanhamento dos stakeholders, analisando e testando cada etapa. Sendo assim, a chance de ter que mudar algo ao final é mínima, resultando em economia de tempo e redução do risco de inviabilizar o projeto. Mesmo assim, o escopo é passível de mudanças e estas devem ser gerenciadas (PMBOK, 2018).
Ao cogitar a ideia de aderir a alguma metodologia ágil, para ser utilizada na empresa, deve antes disso considerar que haverá de serem feitas algumas mudanças culturais e também no estilo de gestão da organização. E, ainda a organização deve proporcionar flexibilidade e responsividade (CAVALERI; OBLOJ, 2003).
Nenhum projecto é totalmente previsível, portanto ser ‘ágil’ é ter conhecimento desta realidade e aceitar que os requisitos habitualmente mudam, em suma, estar pronto para acomodar a mudança de forma simples e rápida (TOMÁS, 2009. p.5).
Podem ser encontradas diversas metodologias ágeis, dentre as mais populares estão o XP (Extreme Programming), FDD (Feature Driven Development), Crystal, e o Scrum (SOMMERVILLE, 2007). Cockburn (2002), afirma que para a escolha de alguma das metodologias, deve levar em conta que a metodologia deve ser adequada ao projeto, e não o projeto se adequar a metodologia.
Segundo Pressman (2006), antes mesmo da escolha da metodologia, algumas características devem estar presentes nas pessoas da equipe ágil. Sendo elas: competência, foco comum, colaboração, capacidade de tomada de decisão, habilidade de resolver problemas vagos, respeito e confiança mútua, auto-organização. Contendo essas características, o autor afirma que a equipe estará preparada para obter o sucesso e enfrentar as dificuldades que se farão presentes ao longo do projeto.
Cohn (2011), defende que para obter sucesso na implementação de uma metodologia ágil, tomando como base o Scrum, não deverá ter resistência na equipe, o ideal seria ter o apoio principalmente da alta gerência, assim, motivando a participação das outras partes. O autor
16
coloca também alguns motivos pelo qual algumas partes não adotam algum novo método, dentre os motivos citados pelo autor, por parte de funcionários, são a falta de conhecimento e o medo do desconhecido. Já por parte da gerência seria a falta de tempo e o medo de perder autoridade.
Sendo assim, as metodologias ágeis para desenvolvimento de software procuram dar menor atenção para a documentação e dar enfoque no desenvolvimento do projeto em si, procurando manter frequentemente a comunicação entre os membros da equipe que estão desenvolvendo o projeto e a interação com o cliente. Os desenvolvedores nem sempre executam apenas uma tarefa, estarão sempre atenciosos às opiniões do cliente, e caso necessário, executarem alguma modificação no projeto (ALMEIDA, 2017).
Atualmente encontra-se diversas metodologias ágeis, entre elas algumas mais utilizadas devido a características em comum entre a metodologia e o projeto (SOMMERVILLE, 2007). Essas metodologias são comuns em alguns princípios, contudo não há um padrão de definição dos processos (KETTUNEN; LAANTI, 2008).
Segundo Silva et al (2011) e Abrahamsson (2000), alguns métodos ágeis, quando aplicados em desenvolvimento de software, buscam atingir objetivos específicos, por exemplo, o XP é frequentemente utilizado em implementação de software, Scrum para gerir o planejamento do projeto e implantação. Além de que há a possibilidade da utilização de mais de uma metodologia. Tendo como exemplo a utilização de um hibrido entre XP e Scrum, no qual vem sendo bastante adotado (SOARES, 2004).
Abrahamsson (2000) assume que se deve dar mais importância para analisar e estudar os fatores que implicam na satisfação dos stakeholders, pois o nível da melhoria do processo, utilizando uma metodologia ágil, é o reflexo desta satisfação.
Frente ao contexto supracitado o problema deste estudo está relacionado a adequação de qual Metodologia Ágil é mais adequada para aplicar em uma empresa? Haveria a possibilidade de utilizar mais de uma Metodologia?
Destaca-se que a literatura denomina de várias formas o conceito ágil de gestão. Sendo estas, framework ágil, metodologia ágil, método ágil, que para este trabalho são tratados de formas iguais, tendo o mesmo sentido e, neste estudo normatizado como método ágil.
1.1 OBJETIVOS
1.1.1 Objetivo Geral
Analisar determinados Métodos Ágeis com intuito de criar um ranking para a escolha do mais adequado a ser aplicado em uma determinada empresa do segmento de Tecnologia da Informação e Comunicação.
1.1.2 Objetivos Específicos
Identificar junto à literatura características dos métodos ágeis a fim de ranking os métodos.
Criar uma métrica de ranking dos métodos ágeis.
2 FUNDAMENTAÇÃO TEÓRICA
2.1 METODOLOGIA TRADICIONAL
As abordagens de métodos tradicionais tiveram início há muito tempo, quando a sequência de tarefas para desenvolver um software era realizada em mainframes e não haviam ferramentas para auxiliar na construção do mesmo (PRESSMAN, 2002).
Segundo Pressman (2002), o surgimento veio por meio da necessidade de minimizar os problemas durante a o desenvolvimento do software. Na época o custo para fazer alterações era muito alto por conta do acesso a computadores e a falta das ferramentas de apoio ao desenvolvimento, por isso a necessidade de planejar e documentar o software antes de sua implementação.
Atualmente as empresas têm muita demanda de projetos de software e necessitam de agilidade na produção devido a prazos em que o cliente espera receber produto final. Porém o desenvolvimento é instável e imprevisível, depende de fatores internos e externos, inclusive acontece frequentemente solicitações feitas pelo cliente para alteração ou adição de algum requisito. Frente a isso encontra-se o problema de que o gerenciamento tradicional não permite que os requisitos exigidos do projeto sejam alterados do decorrer do mesmo, ou seja, não tem uma alta capacidade de adaptação caso haja necessidade (NASCIMENTO, 2016, p.14).
Quanto mais impedimentos ocorreram durante a execução do projeto, maior será o retrabalho e o tempo para finalização do mesmo, o que implica em mudanças estruturais complicadas e que têm impacto muito grande sobre o custo, o prazo e na qualidade do produto final (NASCIMENTO, 2016). Segundo Soares (2004), a metodologia tradicional mais conhecida e ainda bastante utilizada é o modelo Clássico.
O modelo Clássico ou sequencial, consiste no segmento de uma sequência de etapas a serem seguidas. Em cada término destas etapas deve ser gerada uma documentação que obrigatoriamente deve ser aprovada antes de dar segmento à próxima etapa. As etapas do modelo são: Definição de requisitos, projeto do software, implementação e teste unitário, integração e teste do sistema, operação e manutenção, conforme mostrado na figura 1 (SOARES, 2004).
20
Figura 1 - Modelo Clássico
Fonte: Soares (2004).
Soares (2004) afirma que este método deve ser utilizado somente quando os requisitos forem bem compreendidos e que o modelo é inflexível, causando dificuldade em fazer modificações.
2.2 METODO ÁGIL
Com o decorrer do tempo diversos conceitos de desenvolvimento de projetos foram criados. Frente a isso houve a criação dos métodos ágeis, tendo aprovação de diversos usuários e consequentemente sendo muito utilizadas (AMBLER, 2002).
O conceito “Ágil” tornou-se popular quando 17 pesquisadores e ambiciosos que representavam diferentes métodos, formaram um grupo chamado Agile Alliance, para analisar princípios em comum entre os métodos, e resultante a isso obtiveram a criação do “Manifesto Ágil” (AGILE ALLIANCE, 2019). No Manifesto Ágil, existem 12 princípios a serem seguidos por utilizadores (BECK et al., 2001), são eles:
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,
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.
A motivação para a criação de métodos ágeis foi a necessidade de efetuarem mudanças rápidas nos projetos, que fossem solicitadas pelo usuário final. Nos métodos tradicionais, levando em consideração o desenvolvimento de um software, os requisitos são solicitados previamente pelo cliente e seguem como padrões ao longo da produção. Porém, após término, considerando o tempo do desenvolvimento, no primeiro contato do cliente com o software ele percebe que tais requisitos não eram mais úteis, causando um grande problema e retrabalho (SOMMERVILLE, 2007).
Ao utilizar algum método ágil além da equipe que está desenvolvendo, os clientes também podem obter feedbacks do projeto antes da última versão. Caso venha a surgir a necessidade de alterar algum requisito do projeto a adaptação poderá ser feita, sem comprometer o tempo de entrega e o projeto em si (SOARES, 2004).
Um outro ponto positivo das metodologias ágeis são as entregas constantes de partes operacionais do software. Desta forma, o cliente não precisa esperar muito para ver o software funcionando, como nas metodologias tradicionais (SOARES, 2004).
22
Devido à entrega periódica de partes do projeto, se faz necessário um grupo de desenvolvedores preparados para resolver mudanças de requisitos que tendem a estar sempre em mudanças (SILVA, 2016).
Os métodos ágeis tomam como base o desenvolvimento incremental, que permite o cliente ter uma visão mais clara e ampla do sistema antes de tomar decisões sobre requisitos. Neste tipo de desenvolvimento o cliente identifica quais os requisitos mais importantes a serem desenvolvidos no primeiro momento. Após o término do desenvolvimento o cliente avalia e retorna um feedback. Com base neste retorno é planejado a modificação ou o próximo incremento. (SOMERVILLE, 2003).
Charette (2001), fez um comparativo entre o desenvolvimento de um projeto utilizando métodos ágeis e tradicionais. O resultado final aplicando método ágil teve maior qualidade.
Considerando que métodos ágeis possuem alguns propósitos em comum, deve-se ressaltar que existem diversas e que podem ser utilizadas em organizações de diferentes gêneros.
2.2.1 Extreme Programming (XP)
O Extreme Programming é um método ágil utilizada em desenvolvimento de projetos em que os requisitos não são tão objetivos e se modificam com bastante frequência. Este método se adapta melhor quando a equipe tem no máximo 12 integrantes, considerada pequena e média (BECK, 1999).
Segundo o autor, este método foi desenvolvido com a finalidade de reduzir os ciclos de desenvolvimento de métodos tradicionais, que eram considerados muito longos, identificando isso como um problema.
Além disso o autor enfatiza quatro valores principais: Comunicação, simplicidade, feedback e coragem (BECK, 1999). Franco (2007), descreve os valores como:
Comunicação: A falta de comunicação entre a equipe do projeto e da equipe com o cliente pode impactar negativamente, devido a isso no XP a comunicação deve ser assídua. As reuniões com o cliente devem ser ao fim de cada iteração, que duram de 1 a 4 semanas.
Simplicidade: No XP se contrapõe a ideia de prever as necessidades futuras de um projeto. É recomendável fazer algo mais simples e barato, e alterá-lo conforme surge a necessidade.
Feedback/realimentação: Todo problema deve ser identificado o quanto antes e assim, ser resolvido. No caso de outros fatores, também devem ser descobertos mais cedo, para incorporá-los no projeto mais previamente possível.
“Quando o cliente aprende com o sistema que utiliza e reavalia as suas necessidades, ele gera feedback para a equipe de desenvolvimento”. (TELES, 2014).
Coragem: É necessária esta caraterística quando preciso apontar à equipe um problema no projeto, conversar com o cliente quando atrasar parte do projeto e alterar o processo de desenvolvimento.
Segundo Soares (2004), o XP possui características diferentes dos demais métodos, são eles:
Feedback constante. Abordagem incremental.
A comunicação entre as pessoas é encorajada.
Segundo Beck (1999) o XP é baseado em 12 práticas, levando em consideração o desenvolvimento de um software, são elas:
Planejamento: Definir o que é necessário ser feito, definir o escopo, datas de entrega das etapas do projeto, estimativas de prazo. Deve ser seguido à risca o cronograma. Entregas frequentes: Efetuar a entrega parcial do projeto ao cliente para que ele possa testar e retornar um feedback rápido. Isso proporciona uma certa garantia de que os requisitos do projeto se mantenham suficientes ao final do projeto.
Metáfora: É feita uma descrição do software sem utilizar os termos técnicos para auxiliar o entendimento e orientar o desenvolvimento.
Projeto simples: O software produzido deve ser o mais simples possível e deve conter os requisitos necessários no momento, ignorando os requisitos futuros nessa etapa.
Testes: Os testes são criados pelos programadores, onde são verificados e com base nisso o software é desenvolvido.
Programação em pares: A produção do software é feita em dupla, onde um programador digita o código e o outro observa num contexto geral, a sintaxe e a semântica, pensando em otimizar o que está sendo feito. Periodicamente os papeis dos programadores podem ser invertidos. Não possui efetivamente uma hierarquia entre programadores.
24
Refatoração: O objetivo da refatoração é otimizar o projeto do software. Deve ser feita quando os programadores identificarem a necessidade do cliente.
Propriedade coletiva: Todos os membros da equipe são responsáveis pelo código do projeto, ou seja, pode ser alterado por qualquer membro desde que tenha feito os testes necessários.
Integração contínua: Visa integrar as alterações do código de toda a equipe, e executarem testes para verificar e tratar problemas.
40 horas de trabalho semanal: Não se deve fazer hora extra com muita frequência. Caso seja necessário, é considerado que o problema é no projeto, e deve ser resolvido com planejamento, e não horas trabalhadas.
Cliente presente: O cliente deve participar assiduamente em todo o desenvolvimento do projeto, considerando um membro da equipe.
Código padrão: É importante o código ser padronizado, para que toda a equipe possa entender e compartilhar.
No XP a comunicação e indispensável e aplicada a todos os envolvidos no projeto incluindo o cliente, fazendo com que o mesmo aprenda durante o desenvolvimento do projeto e gere feedbacks como “dicas” para os desenvolvedores entenderem qual a sua necessidade. Entendendo essas dicas os construtores do produto identificam tais necessidades e implementam apenas o que é necessário no presente. O futuro não deve ser previsto pois as chances de acontecer um equívoco são grandes. Isso resulta em economia de tempo e permite ao cliente ter acesso à funcionalidade rapidamente (TELES, 2014).
Segundo Ottobboni (2014), é ideal que a equipe esteja presente no mesmo espaço físico para facilitar a comunicação.
2.2.2 Scrum
O Scrum é um framework considerado bastante popular e preferidas pelos seus usuários, na qual foi criada para auxiliar no gerenciamento de projetos ágeis, visando respeitar alguns princípios, são eles: transparência, adaptação e inspeção. Apesar do grande uso na área de desenvolvimento de software, ela pode também ser utilizada no desenvolvimento e gerenciamento de qualquer produto (CRUZ, 2013).
Segundo Cruz (2013), o nome foi inspirado em uma jogada de rúgbi na qual o framework trabalha com o mesmo princípio, que seria a equipe trabalhando em conjunto buscando chegar a ao objetivo final.
Este método é dinâmico, onde variáveis como tempo, prazo, requisitos e outros, tendem a serem alterados ao longo do projeto. Portando a equipe deve estar orientada a produzir um sistema flexível que não tenha resistência a mudanças (²SOARES, 2004).
O Scrum não é um processo ou uma técnica, mas sim um framework dentro do qual podem ser empregados diversos processos ou técnicas. Seu papel é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que seja possível melhorá-las, enquanto provê um arcabouço dentro do qual possam ser desenvolvidos produtos. (CRUZ, 2013. p.32).
Schwaber (2004), como um dos pioneiros para o desenvolvimento deste framework orienta a utilizar a Scrum em projetos onde não são possíveis prever o que irá ocorrer, pois oferece técnicas que permitem ter uma visão mais clara das etapas do projeto, assim a equipe consegue identificar melhorias ou correções que podem ser feitas, mantendo o projeto em rumo ao seu objetivo final.
Segundo Schwaber & Beedle, existem seis papéis durante a sua utilização, são eles: cliente, usuário, gerente, equipe Scrum, Scrum master, e responsável pelo produto. É aconselhável que a equipe tenha entre 5 e 9 integrantes, mas em projetos que há mais pessoas envolvidas, podem ser formadas outras equipes. Tomaz (2011), aconselha que a equipe não seja alterada até o fim do projeto, pois pode haver um grande impacto negativo.
Abaixo as descrições de responsabilidades de alguns dos papéis: Cliente: auxilia na definição de requisitos ao longo do projeto.
Gerente: trata junto ao cliente os requisitos, sendo também responsável pelas tomadas de decisões.
Equipe Scrum: possui autonomia para tomar ações necessárias para que se chegue ao objetivo.
Scrum Master: responsável por analisar se o projeto está tomando o rumo certo, levando em consideração as práticas e o desejo do cliente. Deve estar em constante interação com todos os outros responsáveis.
Responsável pelo produto: é o responsável pelo projeto, tem poder de decisão final referente às tarefas que irão resultar nas funcionalidades do produto final.
26
2.2.2.1 Práticas
Schwaber & Beedle descrevem práticas que são utilizadas com mais frequência nas etapas de projetos Scrum.
2.2.2.1.1 Backlog do Produto
Na etapa de backlog do produto devem estar descritos as funcionalidades e demais características do produto final, que são elaborados através de reuniões e decisões por parte dos stakeholders. Diversos envolvidos participam da elaboração desta etapa do projeto, porém quem tem a responsabilidade de manter o backlog atualizado é o Responsável pelo Produto.
Após a reunião inicial entre os envolvidos é criado uma lista de prioridades com base nos requisitos que foram definidos. Ao decorrer do projeto essa lista é constantemente atualizada com base nas solicitações do cliente e também no andamento do projeto.
2.2.2.1.2 Estimar o Esforço
Na estimativa de esforço, de acordo com as informações que são descobertas sobre determinado item do backlog, é estimado uma quantidade de trabalho que seja necessária para converter estes itens em funcionalidades do produto. Os responsáveis por essa etapa são os membros da equipe Scrum e o responsável pelo produto.
2.2.2.1.3 Sprint (Desenvolvimento Iterativo)
Nesta fase é realizada o desenvolvimento de software onde novas funcionalidades são adicionadas. O sprint acontece diversas vezes durante o desenvolvimento do projeto, então a cada ciclo a equipe Scrum é responsável por adicionar recursos ao software de acordo com a análise de ambiente, como tempo, recursos, tecnologias, outros. A duração de um sprint varia de sete a trinta dias (FRANCO, 2007).
Dentro de cada sprint estão inclusas algumas etapas a serem seguidas: Reunião do planejamento do sprint
Backlog do sprint Reunião diária do Scrum
Reunião de revisão do sprint. 2.2.2.1.4 Reunião de Planejamento do Sprint
Na primeira fase da reunião o Scrum master, como organizador, convoca o cliente, o responsável pelo produto e a equipe Scrum, para discutir e definir os objetivos e funcionalidades do próximo sprint. Já na segunda fase da reunião o Scrum máster e a equipe Scrum definem estratégias e planejam como será conduzido o desenvolvimento do incremento do produto ao longo do próximo sprint.
2.2.2.1.5 Elaborar Backlog do Sprint
O backlog do sprint é uma lista de itens que devem ser desenvolvidos no próximo sprint, e são selecionados com base na lista de backlog do produto. Essa lista é elaborada de acordo com os itens importantes e os objetivos definidos a serem executados na interação.
Diferente do backlog do produto, o backlog do sprint é estável até o final do sprint (interação). Quando todo os itens do backlog do sprint estão implementados, um novo incremento funcional do produto é entregue aos clientes. (FRANCO, 2007).
Os itens da lista são selecionados na reunião de planejamento do sprint, pela equipe Scrum, responsável pelo produto, Scrum master e o cliente.
2.2.2.1.6 Reunião Diária do Scrum
As reuniões diárias são conduzidas pelo Scrum máster e tem tempo de aproximadamente 15 minutos. Elas têm como objetivo analisar o desempenho da equipe Scrum, verificar se há algum obstáculo durante o processo de desenvolvimento, onde caso identificado algum, é estudado e removido para não atrapalhar o desempenho do projeto.
No ato da reunião cada pessoa da equipe Scrum deve responder três questionamentos: O que foi realizado ontem? O que será realizado hoje? Existe algum obstáculo ou impedimento?
28
2.2.2.1.7 Reunião de Revisão do Sprint
No final de cada sprint são apresentados em uma reunião, pelo Scrum master e a equipe Scrum, os resultados para o cliente, gerente e responsável pelo produto. O resultado final de cada sprint nada mais é que o incremento funcional do produto.
Os participantes da reunião fazem o teste das funcionalidades e retornam um feedback de acordo com os objetivos que foram estabelecidos na reunião de planejamento de sprint.
A reunião de revisão do sprint pode acrescentar, remover ou alterar itens do backlog do produto, bem como pode mudar o rumo do produto que está sendo desenvolvido (FRANCO, 2007).
2.2.2.2 Processo
Segundo Franco (2007), o Scrum é um framework iterativo de gerenciamento de projetos. Onde o ciclo de duração (sprint) deve durar de sete a trinta dias, e através desses sprints sequenciais o software é desenvolvido. O framework do Scrum possui três fases: pré-game, desenvolvimento e pós game.
Figura 2 - Ciclo de vida do Scrum
O ponto inicial do trabalho deve ser o levantamento de requisitos e com base nisso deve ser elaborado o backlog do produto. Junto a isso são definidos padrões, tecnologias, arquiteturas que serão utilizados no projeto.
Em seguida, com base nas características do produto, são definidos objetivos para o próximo sprint. Tendo o objetivo definido, devem ser selecionados itens do backlog do produto que irão compor o backlog do sprint, onde serão trabalhados em cima destes itens por um período que pode variar de sete a trinta dias. Ao final desta etapa (iteração), será disponibilizado ao cliente um incremento funcional do sistema. Este ciclo é repetido até ser concluído o último item do backlog do produto (FRANCO, 2007).
A fases de Pré-Game, Desenvolvimento e Pós-Game são descritas de acordo com os autores Schwaber (1995) e Schwaber e Beedle (2001).
2.2.2.2.1 Pré-Game
Na fase do Pré-Game há duas atividades a serem realizadas, planejamento e projeto de alto nível da arquitetura.
O planejamento visa definir o produto que será desenvolvido. Os requisitos que foram definidos pelo Cliente, Responsável pelo Produto, Scrum Master, Gerente e até com a participação da Equipe Scrum, são utilizados para criar a lista de backlog do Produto. Esta lista é atualizada constantemente a respeito de novos itens, prioridades e outros detalhes. Também com base nos requisitos, é estimado o esforço necessário para implementá-los.
Nessa etapa também são definidos a equipe do projeto, ferramentas e recursos, variáveis de controle, avaliação de risco, necessidade de treinamento e verificação da aprovação da gerência. A lista de backlog do produto é revisada pela equipe a cada sprint, a fim de garantir o envolvimento de todos os stakeholders para a próxima iteração.
O projeto de alto nível da arquitetura é realizado com base nos itens da lista de backlog do produto. Caso haja a necessidade de melhoria em um sistema já existente, são identificadas as mudanças necessárias juntamente com os problemas que as alterações podem causar. A avaliação das propostas de implementação e criar planos para definir os conteúdos dos incrementos do produto, é decidido em uma reunião.
30
2.2.2.2.2 Desenvolvimento
Na etapa de desenvolvimento os requisitos são divididos em sprints e as incertezas são identificadas e tratadas.
O Scrum, ao invés de considerar as características do projeto apenas no início, o mesmo mantém um constante controle para não sofrer com imprevistos caso necessite efetuar mudanças. Com isso as diferenças ambientais e técnicas (recursos, requisitos, ferramentas, tecnologias de implementação, outros) são controladas através de práticas durante os sprints. 2.2.2.2.3 Pós-Game
Assim que os stakeholders concordam que as variáveis técnicas e ambientais estão completas e que o sistema está pronto para ser utilizado, é iniciada a etapa de pós-game.
“O fechamento de cada sprint contempla práticas, como por exemplo, integração, teste de sistema, reunião de revisão dos resultados alcançados e documentação”. (FRANCO, 2007, p.27).
2.2.3 Demais metodologias e utilizações
Além das metodologias supracitadas são existentes diversas outras, que apesar de terem diferenças em determinadas etapas de seu processo, são aplicáveis e tem objetivos em comum, que é entregar um produto de qualidade e satisfazer as necessidades do cliente (COHN, 2011).
2.2.3.1 Crystal
O método Crystal foi criado em 1998 por Alistair Cockburn não como um simples método ágil, mas sim como uma família (NASCIMENTO, 2008). Esta família toma como base a gestão de pessoas, com foco na integração, habilidades, talento e comunicação (FILHO, 2011), visto que Cockburn (2004) afirma que cada pessoa da equipe tem um possuem diferentes habilidades e talentos. E acredita-se que estas diversas habilidades reunidas é uma vantagem principalmente para empresas que desenvolvem softwares para diversas áreas de segmento.
Apesar deste método ter processos bem definidos, pode ser customizado, tais como os requisitos do projeto também podem ser adaptados (OPPENSTEINER & UDO, 2003).
A família Crystal está dividida em cores, e cada uma destas cores é apropriada para cada tipo de projeto de acordo com o nível de criticidade e o tamanho da equipe (JUNIOR, 2008). A versão mais ágil é a Crystal Clear onde pode ser usada em equipes de até 8 pessoas, posteriormente se encontra a Crystal Yellow que suporta de 8 a 20 pessoas, Crystal Orange de 20 a 50 pessoas e Crystal Red que é indicada para times de 20 até 50 pessoas (LINS; BEZERRA, 2009). Os riscos do projeto aumentam também de acordo com o tamanho da equipe, onde podem surgir distrações (GATTO, 2017).
Santos (2011) afirma que a criticidade possui quatro níveis, são eles: Conforto (C), Baixo Custo (D), Alto Custo (E), e risco de vida (L).
A respeito das cores, quanto mais escura for mais crítico é o sistema (SBOCCO E MACEDO, 2012). Então em projetos menores como Clear e Yellow são projetos mais leves que demanda poucos desenvolvedores e o prejuízo será menor caso aconteça algum problema. Em projetos de segurança crítica e maiores como o Orange e Red, demandam mais desenvolvedores e em caso de problemas o impacto é bem maior (JUNIOR, 2008).
2.2.3.2 Feature Driven Development
O FDD é um método ágil que possui requisitos formais e adaptáveis, na qual permite desenvolver projetos de forma rápida, permitindo introduzir novas funcionalidades facilmente. Este método pode ser utilizado em projetos onde há bastante mudanças e extrema incerteza do que irá acontecer (BARBOSA et al. 2008).
Segundo Palmer (2002) o tamanho de equipe ideal para este método é de 10 a 30 pessoas. A equipe FDD é constituída de vários papeis, sendo eles, gerente de projeto, arquiteto principal, gerente de desenvolvimento, programador chefe, proprietário da classe, especialista e gerente de domínio, gerente de versão, especialista de linguagem de programação, coordenador de configuração, administrador de sistema, testadores, desenvolvedores, escritor técnico e responsável pela construção de ferramentas de suporte para o desenvolvimento, denominado toolsmith (FAGUNDES, 2005).
O desenvolvimento do projeto é feito por funcionalidades, onde as mesmas são definidas e listadas de acordo com a necessidade do cliente. Os itens dessa lista são postos em ordem de prioridade de desenvolvimento e assim que todas as funcionalidades estiverem
32
prontas, ocorre a junção das mesmas a fim de preparar o produto para a entrega final (SILVA et al. 2009).
Este método tem como característica os seus processos serem simples e bem definidos, onde torna propícia a aplicação em projetos grandes. Além disso caso seja necessário incluir um novo integrante na equipe, o mesmo compreenderá facilmente o projeto em um modo geral (BARBOSA et al. 2008).
2.2.3.3 DSDM (Dynamic Systems Development Methodology)
O DSDM é um método voltado para o desenvolvimento de software na qual propõe desenvolver um projeto de forma que não ultrapasse os limites de tempo e orçamento, mesmo assim, garantindo a qualidade. Este método promove grande comunicação entre os stakeholders, a inclusão bastante frequente do cliente e entregas periódicas de protótipos (TEIXEIXA et al., 2005).
Segundo Teixeira et al. (2005) um dos princípios deste método permite que outros processos sejam iniciados mesmo que seus antecessores ainda estejam em andamento, algo que difere bastante dos outros métodos citados. Outro princípio é a decomposição do projeto em partes menores, onde faz com que tenha uma abordagem iterativa e incremental. Os requisitos deste método devem ser previamente definidos de forma clara e colocados em ordem de prioridade de implementação. Em casos que requisitos não são claros e não podem ser ordenados causará um possível problema de atraso e orçamento, portanto, projetos com estas características não devem ser desenvolvidos utilizando DSDM.
Outro ambiente em que o DSDM não se encaixa é em projetos em que o produto final deverá ter um estado de segurança-crítica, pois a longa fase de testes e validação necessária pode também comprometer os fatores tempo e orçamento (TEIXEIRA et al., 2005).
2.2.3.4 Pesquisa VersionOne (2012)
Uma pesquisa global denominada Annual State of Agile Development Survey, realizada em 2012 onde foram entrevistados 4048 profissionais da área de desenvolvimento de software de todo o mundo, mostra que o Scrum foi disparado o método mais utilizado. Em segundo foi um hibrido entre o Scrum e o Extreme Programming, seguido de outras metodologias, conforme pode-se observar na Figura 3. (VERSIONONE, 2012, p. 5).
Figura 3 - Pesquisa métodos ágeis.
Fonte: VersionOne (2012).
A pesquisa VersionOne em um outro ramo aponta também que no ano de 2012 mais da metade dos entrevistados utilizavam métodos ágeis nos seus projetos, mediante a isso, no ano atual a tendência é de ter aumentado este número.
2.3 ABORDAGEM HIBRIDA
Este tipo de abordagem consiste na união de características de tais métodos ágeis, capazes de transformar em um novo método, na qual deve atender necessidades específicas (NASCIMENTO, 2016).
No mercado de software é bastante comum ser visto abordagens híbridas, conforme expõe a pesquisa supracitada VersionOne do ano de 2012, em que 11% dos entrevistados utilizavam um híbrido de Scrum e XP. Segundo Nascimento (2016), pode-se utilizar o Scrum para auxiliar no gerenciamento do projeto e o XP para aumentar a experiência dos programadores utilizando uma característica forte deste método que é a programação em pares, tendo como consequência a melhoria da qualidade do software.
3 METODOLOGIA
Neste trabalho foram utilizadas duas estratégias, o Survey e Estudo de caso, multi-casos. O survey consiste em uma forma de obter dados ou informações com base em características, ações ou opiniões de determinado grupo de pessoas (FINK, 2013). No caso deste trabalho foi utilizado para verificar qual método ágil é mais propício para a aplicação em determinada empresa.
O Estudo de caso, segundo Yin (2014) é a investigação de um fenômeno contemporâneo, no seu contexto de mundo real. O estudo de caso multi-casos foi escolhido justamente para verificar a aplicabilidade do modelo específico proposto no contexto real. 3.1 INSTRUMENTOS DE COLETA
Em pesquisas de abordagem qualitativa os instrumentos de coleta mais relevantes são questionários, entrevistas, observações, histórias de vida, que facilitam à coleta de dados (OLIVEIRA, 2013). Como instrumento de obtenção dos dados para o survey, foi utilizado um questionário auto administrável pela internet, com perguntas fechadas a fim de identificar a opinião dos respondentes quanto a características que os mesmos consideram essenciais para que um método ágil que se adapte bem na empresa que exercem suas atividades.
Os questionários podem ser definidos como um conjunto de perguntas sobre um determinado tema a fim de medir a opinião, os interesses, e as perspectivas dos respondentes, entre outros tópicos, e são frequentemente utilizados em surveys. Um questionário auto administrado significa que é disponibilizado diretamente aos participantes, não havendo outros intermédios, sendo as respostas marcadas pelos mesmos (SAMPIERI; COLLADO; LUCIO, 2013).
Um pré-teste do survey foi executado para verificação e validação do instrumento com dois especialistas. Com o feedback dos especialistas obteve-se melhorias na forma de escrita, exposição das questões e semântica.
3.1.2 Amostragem
Em pesquisas qualitativas a ideia é a seleção intencional dos participantes (também denominados atores), ou dos locais, ou documentos, ou material visual que melhor ajudaram o
36
pesquisador a entender o problema e a questão de pesquisa. Ou seja, busca-se propositadamente indivíduos que têm conhecimentos sobre o problema de pesquisa e/ou vivenciam o problema em foco (CRESWELL, 2010). No caso deste TCC, desenvolvedores de software que trabalhem em alguma organização, cada respondente se torna assim um caso a ser estudado.
4 RESULTADOS E DISCUSÕES
São apresentados neste capítulo os resultados da a aplicação do questionário no qual foi respondido por programadores de empresas que utilizam métodos ágeis.
A fim de facilitar a identificação das características dos métodos foi elaborado uma tabela contendo as vantagens e desvantagens de cada método, enfatizando o que foi considerado uma desvantagem e vantagem. Além disto, é apresentada uma análise comparativa entre características de alguns métodos, conforme pode ser visto na tabela 1.
Tabela 1 - Vantagens e desvantagens dos métodos ágeis.
Nome Vantagens Desvantagem Análise
Scrum Adaptabilidade nos
quesitos tempo, prazo, requisitos.
Possui técnicas que permitem ter uma visão mais clara das etapas do projeto. Orienta a utilizar o
Scrum em projetos onde não são possíveis prever o que irá
ocorrer.
Reunião com o cliente ao fim de cada sprint, 1 a 4 semanas.
Ideal para pequenas equipes, de 5 a 9 integrantes. Porém em projetos que possui mais integrantes, podem ser formadas outras equipes. Sensação de informalidade. Caso algum membro da equipe abandone o projeto, pode ter um grande impacto. Assim como o XP, o Scrum é bastante dinâmico e permite adaptabilidade, até muitas das vezes são
utilizados juntos, conceitualmente falando, de forma híbrida. Por isso é aconselhável utilizá-lo quando há dúvidas sobre o andamento do projeto. Este método é bastante utilizado atualmente pois permite ser facilmente integrado a outros métodos ágeis. Extreme Programming Feedback constante. Adaptabilidade a mudanças frequentes de requisitos. Espaço físico deve permitir que todos da equipe XP estejam
O XP é ideal para projetos que o cliente não sabe muito bem o que quer. E os
38 Identificação prévia de problemas. Simplicidade. Comunicação. Entrega constante de partes funcionais do software para o cliente. Inclusão do cliente ao projeto.
Reunião com o cliente de 1 a 4 semanas. Equipe de 1 a 12
integrantes.
próximos uns aos outros. Os programadores trabalham em pares, e todos trabalham juntos para que o código seja entendido por toda a equipe. Por outro lado isso pode implicar em perda de desempenho. feedbacks constantes facilitam as mudanças para atender os requisitos. O Scrum e o Feature Driven Development possuem também essa característica de ser totalmente dinâmico e adaptável, um pouco diferente do DSDM que depende de outros fatores caso seja necessário fazer mudanças.
Feature Driven Development
Processos simples e bem definidos facilita em projetos grandes. Fácil integração de
outras pessoas na equipe, pois os processos são simples e de fácil entendimento. Possui requisitos formais. Equipe de 10 a 30 pessoas. Permite adaptabilidade aos requisitos. O desenvolvimento é feito por funcionalidade. Possui um programador chefe. Diferente do Scrum e o XP, o FDD possui requisitos mais formais, proporcionando ao cliente sensação de segurança. Apesar das diferenças, o FDD e o Scrum podem
ser facilmente integrados. DSDM Tem como princípio a
entrega do projeto na data estipulada, sem ultrapassar o
orçamento, garantindo a qualidade do produto final.
Fases novas do projeto não precisam aguardar o encerramento de outras fases anteriores para serem iniciadas. Necessita de comunicação entre os stakeholders. Devem ser previamente definidos os requisitos. Deve-se ordenar os requisitos de modo que priorize a implementação. Requisitos pouco
claros ou que não possam ser colocados sem ordem de prioridade
podem fazer com que os projetos ultrapassem o tempo e orçamento estipulados, efeitos que a DSDM foi feita para evitar. Não é apropriada a utilização quando o produto final precisa de um estado de segurança crítica, pois para garantir isso, são
necessários vários testes nos quais colidem com os objetivos da DSDM, em que a produção não pode ultrapassar o O DSDM atende as necessidades quando o projeto tem orçamento fixo e prazos curtos. Das diferenças deste método em relação aos demais é a gestão do tempo no qual não é flexível. Caso necessária a alteração de algum requisito, é permitido ser feita a mudança desde que não
modifique o prazo da entrega final do projeto.
40 tempo e o orçamento estipulado. Não define tamanho da equipe.
Crystal Permite discussão para
melhorar algum processo. Permite interação e troca de conhecimentos entre membros da equipe. Possui variantes que permitem aplicar o método em diversos tamanhos de equipe. (1 a 100 pessoas).
Fácil adaptação dos requisitos. Em equipes muito volumosas podem surgir distrações. Visa facilidade de adaptação nos requisitos de acordo com a necessidade do cliente, considerando a comunicação da equipe ágil com o cliente indispensável, assim como as outras metodologias citadas. Iterativo e incremental. Fonte: Dados primários.
Com base na tabela 1, foram desenvolvidas nove perguntas norteadoras, e associadas uma métrica, aos quais ajudam a identificar qual abordagem ágil é mais indicada para cada perfil de empresa, conforme tabela 2.
Tabela 2 - Perguntas norteadoras
Pergunta Métrica
1. Quantos integrantes deve ter a equipe ágil? 5 a 9 1 a 12 1 a 100 10 a 30 Scrum XP Crystal FDD DSDM 1 1 1 0 0 1 1 1 1 0 1 1 1 1 0 0 1 1 1 0
2. A equipe ágil deve estar no mesmo espaço físico?
Sim = 1 Não = 0 XP = 1 Crystal = 0 FDD = 0 DSDM = 0 3. Deve ter um
programador-chefe responsável pela equipe? Sim = 1 Não = 0 Scrum = 0 XP = 0 Crystal = 0 FDD = 1 DSDM = 0 4. A equipe ágil deve continuar
com os mesmos integrantes até ao final do projeto?
Sim = 1 Não = 0 Scrum = 1 XP = 0 Crystal = 0 FDD = 0 DSDM = 0 5. Os requisitos podem ser
adaptados ou alterados ao longo do desenvolvimento do projeto? Sim = 1 Não = 0 Scrum = 1 XP = 1 Crystal = 1 FDD = 1 DSDM = 0 6. Qual a frequência de
comunicação com o cliente?
Semanal Quinzenal Mensal Scrum XP Crystal FDD DSDM 1 1 1 0 0 1 1 1 0 0 1 1 0 0 0
7. As etapas do projeto devem obedecer uma ordem, e iniciar uma nova etapa apenas ao término da etapa antecessora?
Scrum = 1 XP = 1 Crystal = 1
42
Sim = 1 Não = 0
FDD = 1 DSDM = 0
8. O método deve ter poder de adaptação em suas práticas? Ou não deve ser adaptado?
Deve ter poder de adaptação = 1 Não deve ser adaptado = 0
Scrum = 0 XP = 0 Crystal = 1 FDD = 1 DSDM = 1 9. O projeto é entregue quando?
Todos os itens da lista forem desenvolvidos O cliente estiver satisfeito com o sistema Não consta
Após todos os conjuntos de características forem implementados
O sistema estiver pronto no tempo limite de prazo Scrum XP Crystal FDD DSDM 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1
Fonte: Dados primários
A métrica foi criada com o intuito de determinar uma pontuação para as respostas, onde foi definido o valor 1 para respostas Sim, e valor 0 para respostas não, de forma que as respostas fiquem alinhadas aos métodos correspondentes, conforme pode ser visto na tabela 2. Com base nas respostas do questionário de cada respondente, é feito um somatório da pontuação referente a cada método, onde o método que obteve a maior pontuação será o ideal para necessidade do respondente.
Em caso de empate, levou-se em consideração o princípio do manifesto ágil que enfatiza a importância de aceitar as mudanças de requisitos, considerando isso uma grande vantagem (BECK et al. 2001). Portanto a pergunta 5, tem o peso elevado para 2.
Escolheu-se o manifesto ágil para propor o critério de desempate uma vez que o mesmo foi o precursor de todos as abordagens ágeis (AGILE ALLIANCE, 2019).
Caso ocorra novamente um empate, recomendara-se os métodos empatados para que o respondente tome sua própria escolha entre um dos métodos, ou utilize-os de forma híbrida, haja visto que os mesmos estarão alinhados ao perfil traçado.
4.1 CASO 1
O primeiro caso se caracteriza como uma empresa de pequeno porte localizada em Paihia na Nova Zelândia.
Ao computar as respostas do questionário, obteve-se uma pontuação de empate entre os métodos ágeis Scrum, XP e Crystal. Mesmo com a aplicação do critério de desempate, os três métodos ainda permaneceram empatados, conforme pode ser visto na Tabela 3.
Tabela 3 - Respostas do Caso 1
Questão Scrum XP Crystal FDD DSDM
1 1 1 1 0 0 2 0 0 0 0 0 3 0 0 0 0 0 4 1 0 0 0 0 5 2 2 2 2 0 6 1 1 1 0 0 7 1 1 1 1 0 8 0 0 1 1 1 9 0 1 0 0 0 Resultado 6 6 6 4 1
Fonte: Dados primários.
Com base nas respostas, isto indica que a empresa necessita de uma abordagem de um método adaptável, onde não seja preciso seguir à risca os processos. Sendo assim, a literatura aponta o Crystal como sendo uma boa opção, pois o Scrum e o XP são métodos que não devem ser adaptados. Em contrapartida, como pode ser analisado na pesquisa VersionOne (2012), o XP e o Scrum são bastante utilizados de forma hibrida, onde o usuário terá à disposição características dos dois métodos e, ambos estão alinhados ao perfil da empresa pesquisada.
Levando em consideração o tamanho da equipe destaca-se o Crystal por permitir trabalhar com diversos números de integrantes (1 a 100). O Scrum é ideal para equipes de 5 a 9 pessoas, porém em projetos que demandam mais integrantes, pode ser formada novas equipes.
44
Já o XP se limita em equipes de 1 a 12 integrantes. Ainda, é importante para a empresa que os integrantes desta equipe sejam os mesmos até o final do projeto, e conforme pode-se analisar na pergunta 4, o Scrum toma vantagem neste quesito.
Com a aplicação da ferramenta, foi possível identificar que a empresa precisa de métodos que possibilite adaptação dos requisitos, que para as etapas do projeto seja seguida uma ordem e que não inicie outra sem encerrar a antecessora, e que obtenha uma frequência quinzenal de comunicação com o cliente, sendo estas, características dos métodos Scrum, XP e Crystal.
Portando é aconselhável que o respondente escolha um dos métodos ágeis, ou utilize dois deles de forma híbrida.
4.2 CASO 2
No segundo a empresa também de pequeno porte, mas localizada em Palhoça, Santa Catarina, Brasil.
Neste caso o método Scrum obteve maior pontuação, seguido de Crystal, um empate entre XP e FDD, e DSDM obtendo a menor pontuação.
Baseado nas respostas permitiu-se identificar que a empresa se interessa em manter os mesmos integrantes da equipe ao longo de todo o desenvolvimento do projeto até seu fim, sendo isso uma característica única do Scrum sob os demais métodos. Outra característica exclusiva do Scrum em que o respondente optou, é ao final do projeto, que é entregue quando todos os itens de backlog do produto forem desenvolvidos.
Com a aplicação da ferramenta foi possível concluir que neste caso as duas características supracitadas foram determinantes para a indicação do método Scrum.
Tabela 4 - Respostas do Caso 2
Questão Scrum XP Crystal FDD DSDM
1 1 1 1 0 0 2 0 0 0 0 0 3 0 0 0 1 0 4 1 0 0 0 0 5 2 2 2 2 0 6 1 1 1 0 0 7 1 1 1 1 0 8 0 0 1 1 1 9 1 0 0 0 0
Resultado 7 5 6 5 1 Fonte: Dados primários.
4.3 CASO 3
No terceiro caso, foi pesquisada uma empresa de grande porte localizada em Blumenau, Santa Catarina, Brasil.
Com base nas respostas foram identificados dois métodos adequados às características desta empresa, Scrum e XP. Conforme pode ser observado na tabela 5, questão 5, o critério de desempate foi aplicado e mesmo assim tais métodos permaneceram com a mesma pontuação.
O XP pode ser uma boa escolha para esta empresa pois a mesma faz questão de que os integrantes da equipe estejam no mesmo espaço físico, e isso é característico deste método. Já o Scrum pode ser útil quando a entrega do produto é feita após os itens do backlog forem concluídos, desta forma a empresa considera que o projeto estará efetivamente pronto.
Desta forma é aconselhável que a empresa decida qual dos dois métodos utilizar, ou então aplique os dois de forma híbrida.
Tabela 5 - Respostas do Caso 3
Questão Scrum XP Crystal FDD DSDM
1 1 1 1 1 0 2 0 1 0 0 0 3 0 0 0 1 0 4 0 0 0 0 0 5 2 2 2 2 0 6 1 1 1 0 0 7 0 0 0 0 0 8 0 0 0 0 0 9 1 0 0 0 0 Resultado 5 5 4 4 0
Fonte: Dados primários. 4.4 CASO 4
No quarto caso, uma empresa de porte grande, no qual a sede é em Nova York, Estados Unidos, porém possui filial em Criciúma, Santa Catarina, Brasil. Local onde o respondente exerce suas atividades.
46
Conforme pode ser observado na tabela 6, os métodos XP, Crystal e FDD obtiveram a mesma pontuação, resultando em um empate mesmo com a aplicação do critério de desempate.
Analisando as respostas, observa-se que na equipe de programadores há um chefe no qual irá coordenar e orientar a parte da codificação do software, sendo essa uma característica presente no FDD. Este se assemelha ao Crystal na parte de adaptação do método, onde os dois possuem este poder.
Referente à entrega do projeto, o respondente optou pela característica do XP, onde assim que o cliente estiver satisfeito com o sistema, o mesmo pode ser entregue. E assim como o Crystal, possui uma frequência quinzenal de comunicação com o cliente.
Conclui-se que com base nas características obtidas pela ferramenta, o respondente possa escolher o método que melhor se adapta à empresa, ou utilize dois deles de forma híbrida.
Tabela 6 - Respostas do Caso 4
Questão Scrum XP Crystal FDD DSDM
1 1 1 1 1 0 2 0 0 0 0 0 3 0 0 0 1 0 4 0 0 0 0 0 5 2 2 2 2 0 6 1 1 1 0 0 7 0 0 0 0 0 8 0 0 1 1 1 9 0 1 0 0 0 Resultado 4 5 5 5 1
5 CONCLUSÃO
Neste trabalho primeiramente foi apresentado um estudo, baseado na literatura, contendo as características gerais dos métodos e suas vantagens e desvantagens, onde foram identificadas semelhanças e diferenças entre tais. As características de cada método foram inseridas em uma tabela a fim de melhorar a visualização, assim, proporcionando mais facilidade na elaboração do questionário. A proposta do trabalho visa encontrar uma forma de identificar qual método ágil é mais adequado para determinada empresa.
Os dados de cada respondente que foram coletados por meio de questionário e analisados. No questionário, foi elaborada uma métrica no qual pôde-se obter uma pontuação para cada método, onde o que estivesse a pontuação maior seria o indicado a ser adotado na empresa caso. Em algumas situações, mesmo com o critério de desempate, os métodos ainda permaneceram com a mesma pontuação, desta forma foi considerado mais viável o respondente escolher algum dos métodos, que obtiveram a mesma pontuação, para utilizar. Sendo assim, pôde-se considerar a métrica efetiva para pontuação dos métodos, permitindo então, ranquear os mesmos para cada caso específico.
Dito isto, com base nos dados foi possível perceber as diversas características semelhantes entre os métodos, visto que os mesmos tiveram como base de sua criação, o manifesto ágil.
A escolha entre a utilização de métodos ágeis para o desenvolvimento de software, tem sido bastante discutida em vários aspectos, o principal é a presença de alguns critérios que implicam no sucesso ou não do resultado da aplicação do método (ALMEIDA, 2017).
O trabalho concede uma visão mais clara das parecenças entre os métodos, bem como as diferenças e suas características. Assim, caso o indivíduo tenha interesse em aplicar algum método ágil em sua empresa, porém possui pouco conhecimento sobre o assunto, a métrica poderá norteá-lo. Utilizando como base as características da sua organização, indicando o método ágil que irá se adaptar melhor, podendo também aplicar de mais de um método de forma híbrida.
Desta forma acredita-se que a ferramenta pode se mostrar efetiva nos casos em que membros de determinada empresa têm dúvidas de qual método utilizar. Pois auxiliou no entendimento do perfil da organização, bem como dos métodos ágeis que podem ser adotados. Como proposta para trabalhos futuros foram identificadas as seguintes oportunidades: Aplicação da ferramenta em diversas organizações, a fim de ter um maior número
48
Entrevistar os respondentes, apresentando os resultados obtidos com a aplicação da ferramenta, e verificar se este resultado condiz com a realidade da empresa.
Utilizar escala gradual Lik ert para mensurar as necessidades dos respondentes. Desenvolvimento de um software que automatize a ferramenta, possibilitando que
REFERÊNCIAS
ABRAHAMSSON, P. Measuring the success of software process improvement: the dimensions. arXiv preprint arXiv:1309.4645, 2013.
AGIL, M. Manifesto para o desenvolvimento ágil de software. Disponível em: <http://www.manifestoagil.com.br/. 2001>.
AGILE ALLIANCE (2001). Manifesto for Agile software Development. Disponível em <www.agileallieance.org>. Acessado em: 02 de fevereiro de 2019.
ALMEIDA, G. A. M. de. Fatores de escolha entre metodologias de desenvolvimento de software tradicionais e ágeis. 2017. Dissertação (Mestrado em Ciências). Universidade de São Paulo.
AMBLER, S. Agile modeling: effective practices for extreme programming and the unified process. John Wiley & Sons, 2002.
BARBOSA, A., AZEVEDO, B., PEREIRA, B., CAMPOS, P., & SANTOS, P. Metodologia Ágil: Feature Driven Development. Faculdade de Engenharia da Universidade do Porto, 2008. BECK, K. Programação Extremas Explicada. Bookman, 1999.
BECK, K. et. al. Manifesto for agile software development. 2001. Disponível em: <http://agilemanifesto.org/>. Acesso em: 02 de fevereiro de 2019.
CHARETTE, R. Fair fight? Agile versus heavy methodologies. Cutter Consortium E-project Management Advisory Service, v. 2, p. 13, 2001.
COCKBURN, A. Agile software development: the cooperative game. Pearson Education, 2006.
COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com sucesso. Bookman, 2000.
CRESWELL, J. W. Projeto De Pesquisa: Métodos Qualitativo, Quantitativo E Misto. Porto Alegre: Artmed, 2010.
CRUZ, F. Scrum e PMBOK unidos no Gerenciamento de Projetos. Brasport, 2013.
FAGUNDES, P. B. Framework para comparação e análise de métodos ágeis. 2005. 134f. 2005. Dissertação (Mestrado em Ciência da Computação) -Universidade Federal de Santa Catarina, Florianópolis.
FINK, A. G. How to Conduct Surveys: A Step-By-step Guide. Sage Publications. 2013. FRANCO, E. F. Um modelo de gerenciamento de projetos baseado nas metodologias ágeis de desenvolvimento de software e nos princípios da produção enxuta. 2007. Dissertação (Mestrado em Engenharia). Universidade de São Paulo.
50
GATTO, E. C. Processo de produção de software. Universidade Tecnológica Federal do Paraná – UTFPR. 2017.
KETTUNEN, P., LAANTI, M. Combining agile software projects and large‐scale organizational agility. Software Process: Improvement and Practice, v. 13, n. 2, 2008. KOPPENSTEINER, S., UDO, N. Will agile development change the way we manage software projects? Agile from s PMBOK guide perspective.Projectway. 2003.
LINS, A. M., BEZERRA, S. R. Qualidade, gestão e processos de software. Editora UFPE. Pernambuco, 2009.
NASCIMENTO, L. C. D. P. Metodologias Ágeis e as Dificuldades Encontradas pelas Empresas para implantá-las. UFOP - Universidade Federal de Ouro Preto. João Monlevade – MG. 2016.
OLIVEIRA, M. M. D. Como Fazer Pesquisa Qualitativa. Petrópolis: Vozes, 2013. OTTOBBONI, J. C. Extreme Programming (XP). 2014. Disponível em:
<https://pt.slideshare.net/jcottobboni/extreme-programming-xp-42901876>. Acesso em: 27 de abril de 2019.
PALMER, S., FELSING, J. A Pratical Guide to Feature-Driven-Development. Prentice Hall, 2002.
PRESSMAN, R. S. Engenharia de Software. McGraw-Hill, 2002
PRESSMAN, R. S. Engenharia de Software – Sexta Edição. McGraw-Hill, 2006.
SAMPIERI, R. H., COLLADO, C. F., LUCIO, M. D. P. B. Metodologia de Pesquisa. Porto Alegre: Penso, 2013.
SATO, D. T. Uso eficaz de métricas em métodos ágeis de desenvolvimento de software. Dissertação (Mestrado em Ciências). Universidade de São Paulo. São Paulo, 2007.
SCHWABER, K. Scrum Development Process. OOOPLSA’95 Workshop on Business Object Design and Implementation. Austin, 1995.
SCHWABER, K. E BEEDLE, M. Agile Software Development with SCRUM. Primeira Edição. Upper Saddle River: Prentice-Hall, 2001.
SCHWABER K. Agile Project Management With Scrum. Microsoft, 2004.
SILVA, A. G. da. A importância dos métodos ágeis na engenharia de software. Universidade federal fluminense. Rio de Janeiro, 2016.
SILVA, F. G., HOENTSCH, S.C.P., SILVA, L. Uma análise das metodologias ágeis FDD e Scrum sob a perspectiva do modelo de qualidade MPS.BR. Universidade Federal de Sergipe - UFS. São Cristóvão - SE, 2009.
SOARES, M. dos S. Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos. 2004. SOARES, M. dos S. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos. 2004. SOMERVILLE, I. Engenharia de Software, São Paulo: Addison-Wesley, 2003.
SOMMERVILLE, I. Engenharia de software, 8ª ed. São Paulo: Pearson AddisonWesley. 2007.
TELES, V. M. Extreme Programming: aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade – Segunda edição. Novatec Editora, 2014.
TEIXEIRA, D. D., PIRES, F. J. A., DE SOUSA, J. P. G., & PINTO, T. A. G. P. S. DSDM - Dynamic Systems Development Methodology. Faculdade de Engenharia da Universidade do Porto, 2005.
TOMÁS, M. R. S. Métodos ágeis: características, pontos fortes e fracos e possibilidades de aplicação. UNL - Universidade Nova de Lisboa. Portugal, 2009.
TOMAZ, L. Como incorporar um novo membro à equipe Scrum?. [Blog Internet, 2011]. Disponível em: <http://blog.myScrumhalf.com/2011/12/como-incorporar-um-novo-membro-a-equipe-Scrum-parte-1-2/>. Acesso em: 1 de maio de 2019
VERSIONONE. Annual State of Agile Development Survey. 2012. Disponível em: <http://www.versionone.com/state-of-agile-survey-results/>. Acesso em: 10 de abril 2019. YIN, R. K. Case Study Research: Design and Methods. Sage publications, 2014.
