UNIVERSIDADE FEDERAL FLUMINENSE – UFF
ESCOLA DE ENGENHARIADEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO GRADUAÇÃO EM ENGENHARIA DE PRODUÇÃO
ANÁLISE DA APLICAÇÃO DA METODOLOGIA SCRUM POR UMA EMPRESA DE
CONSULTORIA EM UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE: UM ESTUDO DE CASO
AUTOR: PEDRO LOPES MAGALHÃES
ORIENTADOR: PROF. LUIZ CARLOS BRASIL DE BRITO MELLO, D.sC.
NITERÓI Dezembro / 2019
UNIVERSIDADE FEDERAL FLUMINENSE ESCOLA DE ENGENHARIA
DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO
PEDRO LOPES MAGALHÃES
ANÁLISE DA APLICAÇÃO DA METODOLOGIA SCRUM POR UMA EMPRESA DE CONSULTORIA EM UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE: UM
ESTUDO DE CASO
Niterói, RJ 2019
PEDRO LOPES MAGALHÃES
ANÁLISE DA APLICAÇÃO DA METODOLOGIA SCRUM POR UMA EMPRESA DE CONSULTORIA EM UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE: UM
ESTUDO DE CASO
Projeto Final apresentado ao curso de Graduação em Engenharia de Produção da
Universidade Federal Fluminense, como
requisito parcial para obtenção do grau de Engenheiro de Produção
ORIENTADOR:
PROF. LUIZ CARLOS BRASIL DE BRITO MELLO, D.sC.
Niterói, RJ 2019
PEDRO LOPES MAGALHÃES
ANÁLISE DA APLICAÇÃO DA METODOLOGIA SCRUM POR UMA EMPRESA DE CONSULTORIA EM UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE: UM
ESTUDO DE CASO
Projeto Final apresentado ao curso de Graduação em Engenharia de Produção da
Universidade Federal Fluminense, como
requisito parcial para obtenção do grau de Engenheiro de Produção
Aprovado em 04 de dezembro de 2019.
BANCA EXAMINADORA
___________________________________________________________________________ LUIZ CARLOS BRASIL DE BRITO MELLO, DsC. – UFF
ORIENTADOR
___________________________________________________________________________ GILSON BRITO ALVES LIMA, DsC. – UFF
___________________________________________________________________________ NÍSSIA CARVALHO ROSA BERGIANTE, DsC. – UFF
Niterói, RJ 2019
AGRADECIMENTOS
Agradeço primeiramente a Deus por me proporcionar esta oportunidade de estudar no curso de Engenharia de Produção da UFF e por me orientar durante toda essa trajetória. Nestes seis anos, pude vivenciar momentos bons e ruins, que me fizeram crescer como pessoa e me prepararam para iniciar esta nova etapa de minha vida.
A toda a minha família por me dar suporte em todas as minhas decisões. De forma especial a minha mãe Denise por me acolher nos momentos de dificuldades e me incentivar a seguir em frente sempre. Ao meu pai Marcio por me trazer paz nos momentos de maior angústia e me aconselhar a acreditar cada vez mais nos planos de Deus. A minha avó Delphina por sempre ter confiado no meu potencial e por me acompanhar em toda a minha trajetória. A Jorgete, pela paciência e por ter se dedicado tanto tempo a minha criação.
A minha namorada Lívia, por toda a paciência, carinho e compreensão para se aventurar comigo em um novo sonho a cada dia.
Aos meus amigos, por proporcionarem grandes alegrias e tornarem cada dia mais leve. Que possamos continuar a compartilhar e vivenciar momentos únicos juntos.
A Universidade Federal Fluminense, pelo ensino de qualidade e por todas as oportunidades proporcionadas que me auxiliaram a chegar onde estou.
Agradeço ao corpo docente, por construírem a cada dia o futuro de seus alunos e se colocarem a disposição para qualquer problema. De forma especial aos professores, membros da banca, que participaram ativamente na minha formação.
Por fim, ao meu orientador professor Luiz Brasil, pela dedicação ao longo deste ano, por meio de sugestões, correções e questionamentos que possibilitaram a realização deste projeto final.
RESUMO
Com a crescente inovação no desenvolvimento de Softwares, muitas empresas se veem na necessidade de entregar produtos mais sofisticados com prazos menores. O presente trabalho tem por objetivo apresentar as metodologias ágeis de desenvolvimento de Software, mais especificamente a metodologia Scrum, e realizar uma comparação entre o modelo de aplicação do framework Scrum e o seguido pela empresa de consultoria estudada, em um dos seus projetos externos. A metodologia utilizada é uma pesquisa bibliográfica em conjunto com um estudo de caso. Os resultados mostram que o método utilizado no projeto para a aplicação da metodologia Scrum diverge do framework teórico, distanciando-se dos princípios ágeis, aumentando o estresse das equipes e interferindo na eficiência de desenvolvimento do Software. Assim, a empresa deveria investir mais em treinamento para os funcionários e buscar uma padronização na aplicação da metodologia Scrum, a fim de aumentar a eficiência dos próximos projetos.
Palavras-chave: Desenvolvimento de Softwares, Metodologias Ágeis, Scrum, Gestão de Projetos, Framework, Consultoria.
ABSTRACT
With the growing innovation in software development, many companies find themselves needing to deliver more sophisticated products with shorter lead times. The present work aims to present the agile Software development methodologies, more specifically the Scrum methodology, and to make a comparison between the Scrum framework application model and the model followed by the consultancy company studied, in one of its external projects. The methodology used is a bibliographic research together with a case study. The results show that the method used in the project of the application of the Scrum methodology differs from the theoretical framework, in a way that distances itself from agile principles, increases team stress and interferes with Software development efficiency. Thus, the company should invest more in employee training and seek standardization in applying the Scrum methodology in order to increase the efficiency of future projects.
Keywords: Software Development, Agile Methodologies, Scrum, Project Management, Framework, Consulting
LISTA DE FIGURAS
Figura 1 Modelo Cascata 12
Figura 2 Tipos de processos em operações de serviços 19
Figura 3 Ciclo de vida de um projeto 21
Figura 4 Processo de Mudança 24
Figura 5 Forças atuantes em um processo de mudança 25
Figura 6 O processo da Extreme Programming (XP) 29
Figura 7 Ciclo de Vida ASD 30
Figura 8 Desenvolvimento dirigido a funcionalidades 32
Figura 9 Fluxo do processo Scrum 35
Figura 10 Fluxograma da metodologia do trabalho 39
Figura 11 Organograma funcional da empresa Alpha 41
LISTA DE TABELAS
LISTA DE SIGLAS
AM - Agile Modeling (Modelagem Ágil); APP – Aplicativo
ASD - Adaptive Software Development (Desenvolvimento de Software Adaptativo) AUP - Agile Unified Process (Processo Unificado Ágil);
CMT - Communication, Media & Technology DEV - Desenvolvedores
DSDM - Dynamic Systems Development Method (Método de Desenvolvimento de Sistemas Dinâmicos);
FDD - Feature Drive Development (Desenvolvimento Dirigido a Funcionalidades); GAP – Gerenciamento Ágil de Projetos
GP – Gestão de Projetos HH – Homem x Hora
HPS - Health & Public Service
IBCO - Instituto Brasileiro de Consultores de Organização
LSD - Lean Software Development (Desenvolvimento de Software Enxuto); MVP - Minimum Viable Product
PMBOK - Project Management Body of Knowledge PMI - Project Management Institute
PO – Product Owner
UP - Unified Process (Processo Unificado) XP - Extreme Programing
SUMÁRIO 1. INTRODUÇÃO ... 12 1.1. CONSIDERAÇÕES INICIAIS ... 12 1.2. DESCRIÇÃO DO PROBLEMA ... 14 1.3. OBJETIVOS DO TRABALHO ... 14 1.3.1. Objetivo geral ... 14 1.3.2. Objetivos específicos ... 14 1.4. DELIMITAÇÃO DO ESTUDO ... 15 1.5. RELEVÂNCIA DO ESTUDO ... 15 1.6. QUESTÕES ... 16 1.7. ORGANIZAÇÃO DO ESTUDO ... 16 2. REVISÃO BIBLIOGRÁFICA ... 18 2.1. SERVIÇOS ... 18 2.1.1. Definição ... 18 2.1.2. Classificação de Serviços ... 18 2.1.3. Serviços de consultoria ... 19 2.2. PROJETOS ... 20 2.2.1. Definição ... 20
2.2.2. Ciclo de vida de um projeto ... 20
2.2.3. Gestão de projetos ... 21
2.3. GESTÃO DA MUDANÇA ... 23
2.4. MODELO CLÁSSICO ... 25
2.5. METODOLOGIAS ÁGEIS ... 26
2.5.1. Definição ... 26
2.5.2. Modelos de Processos Ágeis ... 27
2.5.2.1. Extreming Programming ... 28 2.5.2.2. ASD ... 30 2.5.2.3. DSDM ... 30 2.5.2.4. Crystal ... 31 2.5.2.5. FDD ... 31 2.5.2.6. LSD ... 32 2.5.2.7. AM ... 33 2.5.2.8. AUP ... 33 2.5.2.9. Scrum ... 34 2.5.2.9.1. Origem ... 34 2.5.2.9.2. Pilares do Scrum ... 34 2.5.2.9.3. Ciclos do Scrum ... 35
2.5.2.9.4. Artefatos do Scrum ... 36 2.5.2.9.5. Eventos do Scrum ... 36 3. METODOLOGIA ... 38 3.1. INTRODUÇÃO ... 38 3.2. PESQUISA BIBLIOGRÁFICA ... 38 3.3. ESTUDO DE CASO ... 39 4. ESTUDO DE CASO ... 40 4.1. INTRODUÇÃO ... 40 4.2. DESCRIÇÃO DA EMPRESA ... 40 4.3. DESCRIÇÃO DO PROJETO ... 42
4.4. SITUAÇÃO PROBLEMA A SER ESTUDADA ... 43
5. ANÁLISE DE RESULTADOS E RECOMENDAÇÕES ... 45
5.1. ANÁLISE ... 45 5.1.1. Pilares do Scrum ... 45 5.1.2. Ciclos do Scrum ... 45 5.1.3. Eventos do Scrum ... 46 5.2. RESULTADOS ... 47 5.3. RECOMENDAÇÕES ... 48
6. CONCLUSÕES E SUGESTÕES PARA TRABALHOS FUTUROS ... 52
6.1. CONCLUSÕES ... 52
6.2. SUGESTÕES PARA TRABALHOS FUTUROS ... 55
1. INTRODUÇÃO
1.1. CONSIDERAÇÕES INICIAIS
Até o início da década de 90, o desenvolvimento de Softwares restringia-se à modelos tradicionais de gestão de projetos. O software era todo planejado e documentado antes de ser implementado, visto que o acesso aos computadores era limitado e as ferramentas como analisadores de códigos eram escassas. Dessa forma, o custo de fazer alterações ao longo do projeto era muito alto (SOARES, 2004).
Nesse sentido, o modelo Clássico ou Sequencial (PRESSMAN, 2016) foi o primeiro processo publicado de desenvolvimento de software, cuja metodologia tinha o foco na documentação padronizada a cada término de uma etapa. Esta por sua vez, necessitava ser aprovada para que a etapa seguinte fosse iniciada, como ilustrado na Figura 1.
Figura 1: Modelo Cascata Fonte: Pressman (2016)
A aplicação destes métodos clássicos no desenvolvimento de produtos cada vez mais inovadores gerou problemas tais como atrasos nas entregas, pressão sobre os desenvolvedores e maior probabilidade de ocorrência de erros (THE STANDISH GROUP, 2009).
A busca por soluções para estes problemas fomentou o desenvolvimento de novas metodologias de gerenciamento e organização que foram posteriormente nomeadas como Gerenciamento Ágil de Projetos – GAP (Amaral et al., 2011). Para fomentar essas novas práticas de Gestão de Projetos (GP), houve sua disseminação no decorrer dos anos por meio da sistematização de “guias de conhecimento” (KIOPPENBORG & OPFER, 2002; KOLLTVEIT Et al., 2007; SHENHAR & DVIR, 2007).
Vale ressaltar que um desses “guias do conhecimento”, que apresentam um conjunto de técnicas, ferramentas e ações para gerir projetos, se concretizou, quando dezessete especialistas em processo de desenvolvimento de software estabeleceram princípios entre diferentes métodos: Scrum [Schwaber e Beedle (2002)], Extreme Programming (XP) [Beck (1999)] e outros. Assim, criou-se a Aliança Ágil e o “Manifesto Ágil” foi instituído [AGILE MANIFESTO (2004)].
Dentre as diversas metodologias ágeis existentes, a metodologia Scrum, criada em 1995, é uma forma rápida, eficaz e confiável para desenvolver Softwares para o setor de tecnologia. Ela vem sendo implementada não só em desenvolvimento de Softwares, mas também em projetos de diversas áreas de atuação. De forma geral, o Scrum possibilita um aumento na previsibilidade e controle de riscos, a partir de teorias de controle de processo (JÚNIOR; GURGEL, 2016).
O Scrum foi descrito por Sabbagh (2013) como uma ferramenta leve, simples e ágil para o gerenciamento e desenvolvimento de produtos complexos. Tem como referência o empirismo e realiza entregas interativas e incrementais de valores frequentes.
Embora o Scrum esteja sendo aplicada em diversas áreas de atuação por diferentes empresas, ainda há grandes dificuldades em sua aplicação. Nesse sentido, Varaschim (2009) afirma que um dos maiores desafios do Scrum é manter ao longo do projeto o Project Backlog organizado, de forma a seguir as prioridades pré-estabelecidas e cumprir as histórias planejadas.
Considerando a evolução histórica nas metodologias ágeis de gestão de projetos e as dificuldades envolvidas na aplicação destas, o presente trabalho busca analisar, em uma empresa de consultoria, a aplicação da metodologia ágil Scrum em um projeto de desenvolvimento de um aplicativo para uma das maiores empresas de telecomunicações do Brasil.
1.2. DESCRIÇÃO DO PROBLEMA
Devido a disseminação das metodologias ágeis de desenvolvimento de Softwares, a empresa de consultoria objeto do estudo também está aplicando a abordagem Scrum em seus projetos externos de desenvolvimento de aplicativos mobile.
Nesse contexto, todo projeto de desenvolvimento de Software deve ser bem gerenciado, a fim de que os objetivos deste sejam alcançados. Porém, a gestão de projetos continua sendo um dos maiores desafios, visto que muitas vezes os projetos atrasam, não cumprem seus objetivos ou excedem o orçamento planejado, como evidenciado em diversas pesquisas (DAI; WELLS, 2004; THE STANDISH GROUP, 2009; WHITE; FORTUNE, 2002).
Considerando que o projeto apresenta problemas como atrasos nas Sprints, alto nível de estresse dentre os funcionários e erros recorrentes no aplicativo, esta pesquisa consiste em verificar a aplicação da metodologia Scrum pela consultoria estudada em um dos seus projetos externos de desenvolvimento de Software, no qual o autor deste estudo faz parte como membro da equipe do projeto.
Assim, serão levantados os possíveis problemas da aplicação da metodologia Scrum neste projeto, comparando-a com o framework proposto por Jeff Sutherland e Ken Schwaber em 1995. Dessa forma, serão propostas soluções, após a identificação das possíveis causas.
1.3. OBJETIVOS DO TRABALHO
1.3.1. Objetivo geral
Este trabalho tem como objetivo analisar as práticas adotadas na aplicação da metodologia Scrum por uma empresa de consultoria em um projeto externo de desenvolvimento de Software e comparar se o framework teórico proposto está sendo seguido.
1.3.2.Objetivos específicos
São os seguintes os objetivos específicos:
• Descrever as práticas de aplicação da metodologia Scrum no projeto em questão; • Identificar os principais problemas ocorridos com a aplicação do modelo proposto; • Apresentar propostas de melhorias.
1.4. DELIMITAÇÃO DO ESTUDO
Embora a empresa, objeto desse estudo, atue em diferentes indústrias com diversos projetos em diferentes países, este trabalho limita-se ao estudo da aplicação de metodologias ágeis em um projeto, localizado no Rio de Janeiro, de desenvolvimento de aplicativo para mobile em uma grande empresa de telecomunicações, de forma a verificar as possíveis divergências entre o framework descrito na teoria da abordagem Scrum e a aplicação da mesma no projeto alvo do estudo. O referido projeto está sendo desenvolvido desde Agosto 2018 com previsão de término em Julho de 2020.
Por questões estratégicas não foram divulgados neste trabalho o nome da empresa e de seus respectivos funcionários. Vale ressaltar que os estudos envolvendo empresas de consultoria apresentam restrições, visto que as informações disponibilizadas por empresas deste departamento são escassas (CANBACK, 1998).
1.5. RELEVÂNCIA DO ESTUDO
O presente trabalho apresentará significativa relevância para a empresa de consultoria que é o foco desse estudo, visto que este caso servirá como apoio para futuros casos semelhantes de desenvolvimento de softwares.
Além disso, empresas que atuem no mesmo ramo poderão utilizá-lo como base para estudos, visto que as metodologias ágeis são de extrema importância para a gestão de projetos. Vale ressaltar que o uso dessas abordagens ágeis cresce cada vez mais, o que possibilita o surgimento dos primeiros trabalhos empíricos que buscam adaptá-las para projetos de outras
Por fim, este trabalho pode servir de consulta para outros estudantes cujos interesses estejam relacionados ao tema de modelos de gestão voltados para projetos de desenvolvimento de softwares aplicados não apenas por empresas de consultorias, mas também por empresas de engenharia no geral.
1.6. QUESTÕES
Buscando melhor entender o aperfeiçoamento nos modelos de gestão de projetos de engenharia de software aplicados por uma empresa de consultoria, o principal questionamento que motivou a estruturação desse projeto foi: Como a aplicação do atual modelo de desenvolvimento de Softwares (Scrum) aplicado pela consultoria estudada diferencia-se do framework proposto por Jeff Sutherland e Ken Schwaber, criadores da metodologia alvo do estudo?
A partir da questão central da pesquisa foram estabelecidos questionamentos secundários que auxiliarão com resultados parciais na busca pelo resultado final:
• Como é estruturado o modelo de gestão de projetos de desenvolvimento de Softwares na empresa de consultoria estudada?
• De que maneira as divergências encontradas auxiliam ou dificultam o andamento do projeto?
• De que maneira podem ser resolvidos ou amenizados os impactos decorrentes dos problemas encontrados?
1.7. ORGANIZAÇÃO DO ESTUDO
Com o foco em alcançar os objetivos citados acima, o estudo foi estruturado em seis capítulos, conforme descrito a seguir:
Capítulo I: Destinado a contextualização das metodologias de gestão de projetos de desenvolvimento de Softwares, da situação a ser analisada e a formulação da situação-problema, com definição e limitação dos objetivos almejados e a definição do método, ou seja, a organização do estudo para o alcance das metas estabelecidas.
Capítulo II: Seu foco consiste na realização do embasamento teórico acerca do problema em análise com o intuito de estruturar uma base conceitual para o desenvolvimento e intepretação dos resultados da pesquisa.
Capítulo III: Consiste na descrição do plano de pesquisa determinado para o alcance do objetivo. Neste momento, será definida a metodologia de pesquisa, o método de coleta de dados, definindo suas limitações, bem como, explanada a forma de tratamento e ferramentas de análises posteriores.
Capítulo IV: Dedicado a descrever as informações gerais da empresa de consultoria analisada, assim como o delinear melhor o projeto. Por fim, será apresentada a situação problema a ser solucionada.
Capítulo V: Apresenta as comparações realizadas entre o framework proposto pelos criadores da metodologia analisada e a sua respectiva aplicação no projeto estudado. Além disso, expõe os resultados obtidos, de forma a propor soluções para a empresa estudada.
2. REVISÃO BIBLIOGRÁFICA
Neste capítulo serão expostos os conceitos, métodos e teorias que auxiliarão na aplicação deste estudo de caso. A fim de melhor entender a aplicação de metodologias ágeis em projetos de desenvolvimento de Softwares, primeiramente será definido o conceito de serviços, englobando os serviços de consultoria, seguido pela definição de projetos.
Em seguida, serão tratadas brevemente as práticas de Gestão da Mudança. Depois, serão detalhadas as metodologias de gestão de projetos, focando por último na metodologia Scrum, que é o objeto principal do estudo.
2.1. SERVIÇOS
2.1.1.Definição
O debate sobre o conceito de serviços pode ser considerado bem vasto, trazendo diversas definições diferentes. Para Vargo e Lusch (2004), o serviço pode ser definido como “a aplicação de competências especializadas (habilidades e conhecimento), por meio de ações, processos e atuações para benefício de uma outra entidade ou de si próprio (autosserviço)”
Já, Silva e Meirelles (2006) definiram posteriormente “Serviço é trabalho em processo, e não o resultado da ação do trabalho; por esta razão elementar, não se produz um serviço, e sim se presta um serviço.”
2.1.2.Classificação de Serviços
Uma proposta de classificação de serviços surgiu, ao comparar critérios de volume e variedade, gerando três grupos principais de serviços conforme ilustrado na Figura 2 (SLACK, 2018):
• Serviços profissionais: Esses serviços são caracterizados por oferecerem um alto nível de customização, de forma que o processo é altamente adaptável para atender as necessidades individuais dos clientes. Além disso, a relação de funcionários por cliente é alta, pois muito tempo e atenção são despendidos para
cada cliente. Como exemplo, podem ser citadas as consultorias, advogados, arquitetos e cirurgiões;
• Lojas de serviços: São caracterizadas por estarem entre os opostos dos serviços profissionais e serviços de massa. Lojas de serviços podem compreender bancos, comércios, Shopping Centers e restaurantes;
• Serviços de massa: São caracterizados por um alto nível de clientes e pouca customização, de forma que estes serviços são baseados em equipamentos e orientados para o produto. Como exemplo, podem ser citados os supermercados, aeroportos, serviços ferroviários.
Figura 2: Tipos de processos em operações de serviços Fonte: Slack (2018)
2.1.3.Serviços de consultoria
A ascensão das consultorias ocorreu principalmente nos Estados Unidos com o crescimento exponencial das empresas, e consequentemente o aumento da complexidade no gerenciamento das organizações (DONADONE, SILVEIRA & RALIO, 2012). Nesse cenário, a contratação de consultorias externas surgiu como oportunidade, visto que estas possuem um know how, por conhecerem as boas práticas de outras empresas e também por terem amplo conhecimento do mercado.
Nesse sentido, a consultoria pode ser classificada como uma empresa prestadora de serviços especializada no diagnóstico empresarial, de forma a identificar as principais não-conformidades e elaborar planos de ação (INSTITUTO BRASILEIRO DE CONSULTORES DE ORGANIZAÇÃO – IBCO, 2017)
No Brasil, Donadone, Silveira & Ralio (2012) identificaram um crescimento dos serviços de consultoria no final da década de 1950, com a entrada de empresas multinacionais no país. Assim, esse serviço que já estava em alta no exterior foi absorvido pelo Brasil.
2.2. PROJETOS
2.2.1. Definição
Segundo Maximiano (2002) todo projeto se caracteriza por ter início, meio e fim determinado. O objetivo de um projeto deve ser um produto único, considerando as restrições de prazo e orçamento.
Ainda sobre essa definição, o guia Project Management Body of Knowledge (PMBOK) (2017) explica que:
Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado único:
• Produto, serviço ou resultado único. Projetos são realizados para cumprir objetivos através da produção de entregas. Um objetivo é definido como um resultado a que o trabalho é orientado, uma posição estratégica a ser alcançada ou um propósito a ser atingido, um produto a ser produzido ou um serviço a ser realizado. Uma entrega é definida como qualquer produto, resultado ou capacidade único e verificável que deve ser produzido para concluir um processo, fase ou projeto. As entregas podem ser tangíveis ou intangíveis. Vale ressaltar que os projetos abrangem todos os níveis da organização, desde operários até a alta gerência, além de fornecedores, clientes, parceiros e governo, fazendo parte, em sua maioria, da estratégia de negócios da companhia (VARGAS, 2005).
2.2.2. Ciclo de vida de um projeto
Todo projeto tem um ciclo de vida definido, o qual pode ser dividido em fases. Segundo Vargas (2005, p 39) existem 5 fases características de um projeto conforme ilustrado na Figura 3:
• Fase de iniciação; • Fase de planejamento; • Fase de execução; • Fase de controle; • Fase de finalização.
Figura 3: Ciclo de vida de um projeto Fonte: Vargas (2005, p. 35)
2.2.3.Gestão de projetos
O gerenciamento de projetos (GP) busca ser ágil, inovador e desafiador. Nesse contexto, com o objetivo de aumentar a produtividade, competitividade perante o mercado e alcançar melhorias na gestão, empresas buscam investir na melhor formação de seus funcionários, o que proporciona melhores resultados para a organização (BOMFIN, NUNES & HASTENREITER, 2012).
Ainda sobre a GP, Kerzner (2006) comenta que:
A Gestão de Projetos combinada com o gerenciamento de mudanças pode permitir a concretização dos seguintes benefícios:
• capacidade de reagir com rapidez às mudanças exigidas pelos clientes; • redução do impacto da mudança no orçamento e na programação; • aumento dos esforços de adição de valores em nome dos clientes; • boas relações com os clientes;
Segundo o PMBOK (2017), a GP é composta por processos relacionados a nove áreas de conhecimento, sobre as quais o gerente de projetos deve ter domínio. Os grupos de processos são: iniciação, planejamento, execução, controle e encerramento. As áreas de conhecimento são: gestão da integração, gestão do escopo, gestão do tempo, gestão dos recursos humanos, gestão de custos, gestão das aquisições, gestão da qualidade, gestão do risco, gestão da comunicação. Além disso, o gerente de projeto também deve possuir aspectos comportamentais, como: liderança, comunicação interpessoal, gestão de conflitos, etc.
Ainda sobre as áreas de conhecimento, PMBOK (2017) define-as como:
• Gerenciamento da integração do projeto. Inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos e atividades de gerenciamento de projetos nos Grupos de Processos de Gerenciamento de Projetos.
• Gerenciamento do escopo do projeto. Inclui os processos necessários para assegurar que o projeto contemple todo o trabalho necessário, e apenas o necessário, para que este finalize com sucesso.
• Gerenciamento do cronograma do projeto. Inclui os processos necessários para gerenciar o término pontual do projeto.
• Gerenciamento dos custos do projeto. Inclui os processos envolvidos em planejamento, estimativas, orçamentos, financiamentos, gerenciamento e controle dos custos, de modo que o projeto possa ser finalizado dentro do orçamento aprovado.
• Gerenciamento da qualidade do projeto. Inclui os processos para incorporação da política de qualidade da organização com relação ao planejamento, gerenciamento e controle dos requisitos de qualidade do projeto e do produto para atender as expectativas das partes interessadas.
• Gerenciamento dos recursos do projeto. Inclui os processos para identificar, adquirir e gerenciar os recursos necessários para a conclusão bem-sucedida do projeto.
• Gerenciamento das comunicações do projeto. Inclui os processos necessários para assegurar que as informações do projeto sejam planejadas, coletadas, criadas,
distribuídas, armazenadas, recuperadas, gerenciadas, controladas, monitoradas e finalmente organizadas de maneira oportuna e apropriada.
• Gerenciamento dos riscos do projeto. Inclui os processos de condução de planejamento, identificação e análise de gerenciamento de risco, planejamento e implementação de resposta e monitoramento de risco em um projeto.
• Gerenciamento das aquisições do projeto. Inclui os processos necessários para comprar ou adquirir produtos, serviços ou resultados externos à equipe do projeto. • Gerenciamento das partes interessadas do projeto. Inclui os processos exigidos
para identificar as pessoas, grupos ou organizações que podem impactar ou serem impactados pelo projeto, analisar as expectativas das partes interessadas e seu impacto no projeto, e desenvolver estratégias de gerenciamento apropriadas para o seu engajamento eficaz nas decisões e execução do projeto.
Por fim, segundo Kretan (2009), o sucesso ou fracasso de um projeto pode ser traduzido pela percepção dos stakeholders sobre o valor criado pelo projeto e a natureza do relacionamento com a equipe do projeto. Enquanto no passado o foco estava no desenvolvimento e controle do escopo, cronograma e orçamento, atualmente o foco está no balanceamento do controle e do fortalecimento dos relacionamentos dentro dos projetos, de forma a assegurar o engajamento dos stakeholders-chave.
2.3. GESTÃO DA MUDANÇA
O processo de gestão da mudança ao longo do projeto é de extrema importância para o sucesso deste dentro da organização. Neste sentido, o processo pode ser definido em três etapas ilustrados na Figura 4 (CHIAVENATO, 2004):
• Descongelamento do padrão atual de comportamento: Nesta etapa, a organização como um todo percebe a necessidade de deixar de lado o padrão atual, para dar espaço para a entrada das novas ideias e práticas.
• Mudança: Nesta etapa, um agente de mudança é responsável por conduzir as pessoas durante o processo de mudança. Ele deve introduzir os valores e promover
atitudes, a fim de mostrar a eficácia do processo, de forma que elas se identifiquem e queiram internalizá-los.
• Recongelamento: Na última etapa, os novos valores são incorporados pelos membros da organização, passando a ser a cultura das pessoas envolvidas. Por fim, os funcionários incorporaram e praticam os novos valores de forma eficiente.
Figura 4: Processo de Mudança Fonte: Chiavenato (2004)
Ainda segundo Chiavenato (2004), o processo de mudança é afetado por um campo de forças, divididas em positivas e negativas:
• Forças positivas: São as forças que são a favor da mudança;
• Forças negativas: São as forças opositoras a mudanças, resistentes a elas.
Para que a organização funcione, é necessário um equilíbrio entre as forças citadas anteriormente, definido por equilíbrio estacionário. Vale ressaltar, que este será rompido, quando surgir uma nova tentativa de mudança, conforme ilustrado na Figura 5 (CHIAVENATO, 2004).
Figura 5: Forças atuantes em um processo de mudança Fonte: Chiavenato (2004)
2.4. MODELO CLÁSSICO
O modelo Clássico ou Sequencial (PRESSMAN, 2016) foi o primeiro processo publicado de desenvolvimento de software, cuja metodologia associava a cada término de uma etapa uma documentação padronizada. Esta por sua vez, necessitava ser aprovada para que a etapa seguinte fosse iniciada, como ilustrado na Figura 1.
Ainda sobre o modelo cascata, também denominado ciclo de vida clássico, Pressman (2016) afirma que ele tende a funcionar bem quando o trabalho flui da comunicação ao emprego de forma linear.
Por outro lado, quando o trabalho não se encontra nesse contexto específico, o modelo cascata tende a ser insuficiente. Pressman (2016) cita alguns dos possíveis problemas:
1. Projetos reais dificilmente seguem o fluxo sequencial proposto pelo modelo. Nesse sentido, mudanças ao longo do projeto podem provocar confusões.
2. Como premissa do modelo, o cliente deveria estabelecer todas as suas necessidades, porém algumas delas são mapeadas ao longo do projeto e a metodologia apresenta dificuldades de adequá-las ao escopo.
3. Com o sequenciamento do modelo, o cliente não costuma receber versões parciais antes da fase final do projeto. Com isso, erros detectados após a revisão do programa operacional podem ser desastrosos.
Por fim, Soares (2004 apud Standish Group, 1995) cita que:
Dados de 1995, utilizando como base 8380 projetos, mostram que apenas 16,2% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades especificadas. Aproximadamente 31% dos projetos foram cancelados antes de estarem completos e 52,7% foram entregues, porém com prazos maiores, custos maiores ou com menos funcionalidades do que especificado no início do projeto. Dentre os projetos que não foram finalizados de acordo com os prazos e custos especificados, a média de atrasos foi de 222%, e a média de custo foi de 189% a mais do que o previsto. Considerando todos os projetos que foram entregues além do prazo e com custo maior, na média, apenas 61% das funcionalidades originais foram incluídas.
2.5.METODOLOGIAS ÁGEIS
2.5.1.Definição
As Metodologias Ágeis surgiram como alternativa às abordagens tradicionais no desenvolvimento de Softwares (SOARES, 2004). Em 2001, foi criada a Aliança Ágil (Agile Alliance, 2003) e estabelecido o “Manifesto Ágil” (Agile Manifesto, 2004), que estabelecia princípios comuns compartilhados pelos métodos ágeis de desenvolvimento de Softwares.
Nesse contexto, a Agile Manifesto (2004) estabelece 12 princípios de agilidade:
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
2. 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.
3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
6. O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
2.5.2.Modelos de Processos Ágeis
Entre os modelos mais comuns de processos ágeis estão (PRESSMAN, 2016): • Extreme Programming (XP);
• Desenvolvimento de Software Adaptativo (Adaptive Software Development, ASD);
• Método de Desenvolvimento de Sistemas Dinâmicos (Dynamic Systems Development Method, DSDM);
• Crystal;
• Desenvolvimento Dirigido a Funcionalidades (Feature Drive Development, FDD); • Desenvolvimento de Software Enxuto (Lean Software Development, LSD);
• Modelagem Ágil (Agile Modeling, AM);
• Processo Unificado Ágil (Agile Unified Process, AUP). • Scrum;
Vale ressaltar que o modelo mais utilizado de todos os processos ágeis é o XP (PRESSMAN, 2016). Dessa forma, o presente trabalho procurou realizar uma breve descrição de
cada modelo listado, porém optou por focar no modelo Scrum, o qual é utilizado pela equipe de projetos no estudo de caso pesquisado.
2.5.2.1.Extreming Programming
Como citado anteriormente, o modelo Extreming Programming é o mais utilizado para desenvolvimento de Softwares ágeis. Cinco valores são definidos para o XP: comunicação, simplicidade, feedback, coragem e respeito. Estes foram melhor descritos a seguir (BECK, 2004): • A comunicação efetiva remete a relação entre os engenheiros de Software e
clientes, de forma a estabelecer uma colaboração estreita entre os envolvidos. • A simplicidade diz respeito a projeção apenas das necessidades imediatas,
deixando de lado as necessidades futuras. Dessa forma, deve-se criar um projeto simples que possa ser implementado em código, possibilitando que o projeto possa ser refabricado no futuro, caso necessário.
• O feedback provém de três origens: Software implementado, cliente e membros da equipe. Assim, o Software retorna feedbacks ágeis, visto que à medida que cada classe é desenvolvida, são realizados testes da unidade. O cliente tem visibilidade das classes desenvolvidas e as histórias dos usuários são utilizadas como base para testes de aceitação. Por último, os membros da equipe dão ao cliente um rápido feedback com relação ao impacto nos custos e no cronograma.
• A coragem remete a disciplina que a equipe deve ter para focar nas necessidades presentes, e não pensar no “projetar para amanhã”, ou seja, ter coragem de reconhecer que as necessidades futuras estão sujeitas a mudança e a necessidade de “projetar para hoje”.
• Por último, deve existir respeito entre os membros da equipe, de forma que a mesma desenvolve cada vez mais respeito pelo processo XP, à medida que entregam com sucesso incrementos no Software.
Vale ressaltar que o processo da XP é dividido em quatro etapas: planejamento, projeto, codificação e testes, conforme ilustrado na Figura 6. A seguir, essas etapas são brevemente descritas de acordo com a visão de Beck (2004):
• Planejamento: decisões devem ser tomadas para decidir o que deve ser feito e o que pode ser adiado. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros.
• Projeto: o programa a ser desenvolvido pelo método XP deve seguir o princípio Keep It Simple (KIS, isto é, preserve a simplicidade), de forma a satisfazer os requisitos atuais.
• Codificação: Um conceito difundido na etapa de codificação é a programação em dupla, na qual dois membros da equipe trabalham juntos em uma mesma estação de trabalho. Isso favorece a qualidade em tempo real, visto que um planeja os detalhes da codificação, enquanto o outro assegura que os padrões da codificação estejam sendo utilizados.
• Testes: no método da XP, o projeto é validado durante todo o processo de desenvolvimento. Antes de desenvolverem o Software de fato, os programadores criam primeiramente os testes de unidades.
Por fim, é necessário admitir que os processos de desenvolvimento de Softwares pela XP estão sujeitos a falhas, as quais devem ser mapeadas e o projeto deve ser adaptado as necessidades específicas de sua organização (PRESSMAN, 2016).
Figura 6: O processo da Extreme Programming (XP) Fonte: Pressman (2016)
2.5.2.2.Adaptive Software Development (ASD)
O modelo ASD foi desenvolvido por Jim Highsmith, com o objetivo de focar na colaboração humana e na auto-organização das equipes. O ciclo de vida ASD é formado por três etapas: especulação, colaboração e aprendizagem conforme ilustrado na Figura 7. High (2000) argumenta que a aprendizagem irá aumentar os níveis reais de entendimento dos desenvolvedores de Softwares, considerando que muitas vezes estes superestimam seu próprio conhecimento. Dessa forma, essas três etapas fornecem uma probabilidade muito maior de sucesso para o projeto.
Figura 7: Ciclo de Vida ASD Fonte: Pressman (2016)
2.5.2.3.Dynamic Systems Development Method (DSDM)
O método de desenvolvimento DSDM utiliza a prototipagem incremental em um ambiente de projeto controlado, a fim de construir sistemas que atendem a restrições de prazos (CONSULTING SERVICES, 2002). O modelo se baseou no Princípio de Pareto em que 80% de uma aplicação pode ser concluída em 20% do tempo, o qual duraria para concluir 100% da aplicação (PRESSMAN, 2016). O ciclo de vida DSDM, criado pelo grupo mundial de
empresas-membro do DSDM Consortium, é composto por três ciclos iterativos diferentes, com duas atividades extras que os precedem: estudo da viabilidade, estudo do negócio, iteração de modelos funcionais, iteração de projeto e desenvolvimento e implementação.
2.5.2.4.Crystal
A família Crystal de métodos ágeis foi criada por Alistair Cockburn e Jim Highsmith com o objetivo de fornecer adaptabilidade para o “jogo” de invenção e comunicação cooperativo, com recursos limitados (COCKBURN, 2002).
Vale ressaltar que a família Crystal de métodos ágeis é um conjunto de exemplos de processos ágeis que são efetivos para diferentes tipos de projetos. Assim, a equipe ágil deve selecionar o membro da família mais apropriado para o projeto a ser desenvolvido (PRESSMAN, 2016).
2.5.2.5.Feature Drive Development (FDD)
O desenvolvimento dirigido a funcionalidade foi criado por Peter Coad. A ênfase na definição de funcionalidades favorece:
• Colaboração entre os membros da equipe;
• Gerenciamento das situações complexas, a partir da decomposição baseada em funcionalidades e posteriormente pela integração dos incrementos de Softwares; • Comunicação de requisitos técnicos, por meio da verbalização, gráficos e textos. Ainda nesse contexto, Coad et al (1999) definem funcionalidade como “É uma função valorizada pelo cliente passível de ser implementada em duas semanas ou menos.”
No FDD, são definidas cinco atividades metodológicas “colaborativas”, conforme ilustrado na Figura 8 (COAD, 1999).
Figura 8: Desenvolvimento dirigido a funcionalidades Fonte: Coad (1999)
2.5.2.6.Lean Software Development (LSD)
O método LSD inspirou-se nos princípios da fabricação enxuta, trazendo-a para a engenharia de Software. Poppendieck (2003), o desenvolvedor deste método, definiu o objetivo como: “Eliminar desperdício, incorporar qualidade, criar conhecimento, adiar compromissos, entregar rápido, respeitar as pessoas e otimizar o todo.”
Vale ressaltar que cada princípio da fabricação enxuta pode ser incorporado no processo de desenvolvimento de Software, como por exemplo eliminar desperdício (DASARI, 2005):
• Não adicionar recursos desnecessários;
• Avaliar o impacto de custo e no cronograma da adição de algum requisito solicitado posteriormente;
• Eliminar etapas que não sejam agregadoras ao processo;
• Estabelecer mecanismos para aprimorar o método de levantamento de informações;
• Garantir que os testes encontrem o maior número de erros possíveis;
• Reduzir o tempo necessário para tomada de decisões com relação ao Software; • Racionalizar o método de transmissão de informações aos envolvidos do projeto.
2.5.2.7.Agile Modeling (AM)
A metodologia AM é descrita por Ambler (2002) no “The Official Agile Modeling Site” como:
Modelagem ágil (AM) consiste em uma metodologia baseada na prática, voltada para o modelamento e documentação de sistemas com base em Software. Simplificando, modelagem ágil consiste em um conjunto de valores, princípios e práticas voltados para a modelagem do Software que podem ser aplicados em um projeto de desenvolvimento de Software de forma leve e efetiva. Os modelos ágeis são mais efetivos do que os tradicionais pelo fato de serem meramente bons, pois não tem a obrigação de ser perfeitos.
Ainda nesse sentido, Ambler (2002) define os princípios que tornam a AM única: • Modele com um objetivo;
• Use modelos múltiplos; • Viajar leve;
• Conteúdo é mais importante que a representação;
• Tenha conhecimento, domínio dos modelos e das ferramentas que for utilizar; • Adapte localmente.
2.5.2.8.Agile Unified Process (AUP)
O Processo Unificado Ágil utiliza as atividades em fases Unified Process (UP): início, elaboração, construção e transição, porém fornecendo uma camada serial que permite que a equipe tenha uma visão global do fluxo do projeto. Por outro lado, em cada atividade a equipe itera para alcançar a agilidade e entregar os requisitos de Software necessários.
Dessa forma, cada iteração AUP contempla as seguintes atividades (AMBLER, 2006): • Modelagem;
• Implementação; • Teste;
• Aplicação;
2.5.2.9.Scrum
2.5.2.9.1.Origem
O método Scrum foi desenvolvido em 1995 por Jeff Sutherland e Ken Schwaber. Os dois apresentaram a metodologia em um artigo, Scrum and the Perfect Storm. Além disso, os dois participaram da assinatura do manifesto ágil em fevereiro de 2001 (AUDY, 2015).
Ainda segundo Audy (2015), o termo Scrum tem origem no Rugby, de forma a representar uma jogada na qual os membros da equipe ficam todos juntos, um se apoiando no outro frente ao time adversário. Essa jogada ocorre toda vez em que a bola sai de campo, e a cada “Scrum” os times se auto organizam novamente para reiniciar a partida.
O Scrum foi descrito por Sabbagh (2013) como uma ferramenta leve, simples e ágil para o gerenciamento e desenvolvimento de produtos complexos. Tem como referência o empirismo e realiza entregas interativas e incrementais de valores frequentes. Assim, objetiva-se reduzir os riscos e falhas do projeto.
2.5.2.9.2.Pilares do Scrum
Segundo Schwaber e Sutherland (2013), o Scrum possui três pilares durante o projeto como um todo, são eles:
• Transparência – Todos os envolvidos no projeto precisam estar cientes dos acontecimentos;
• Inspeção – Todas as tarefas precisam ser inspecionadas, de forma a evitar problemas futuros;
• Adaptação – Nas reuniões diárias, os processos sofrem adaptações e são redefinidos a fim de otimizar o trabalho.
2.5.2.9.3.Ciclos do Scrum
O Product Owner é único, responsável por alinhar junto ao cliente o que é esperado do produto pelas partes interessadas do projeto. A definição do plano do trabalho e de como ele evoluirá ao longo do projeto, é chamada de Road Map. Na fase inicial, conhecida como “pré-jogo”, são definidos os membros da equipe Scrum pelo Product Owner e Scrum Master. Vale ressaltar que cada integrante da equipe tem seu papel definido e uma habilidade específica que permitirá a conclusão do projeto com sucesso (SABBAGH, 2013).
Segundo Carvalho & Mello (2012) o Scrum Master possibilita o andamento do processo, afastando os impedimentos para a realização do trabalho do time, de forma que cada um possa se concentrar nos principais objetivos. Vale ressaltar que o Scrum Master não deve ter poder sobre os integrantes do time Scrum (COHN, 2011).
A metodologia Scrum utiliza o desenvolvimento incremental, de forma que seus processos são divididos em Sprints, isto é, interações que ocorrem no processo com duração média de 30 dias. Cada Sprint possui um objetivo claro com requisitos definidos, os quais podem ser modificados em tempo real pela equipe do Scrum. O fluxo do processo é ilustrado na Figura 9 (PRESSMAN, 2016).
Figura 9: Fluxo do processo Scrum Fonte: Pressman (2016)
Segundo Cruz (2015), a velocidade do time Scrum é medida de acordo com a quantidade de pontos por história que consegue completar por Sprint. Em função disso, as Sprints devem ter o mesmo tamanho durante todo o projeto. Assim, caso as Sprints tenham tamanhos diferentes, a definição de velocidade perde o significado.
Vale ressaltar que a definição de velocidade é de extrema importância, pois esta determinará quantas Sprints o projeto deverá ter, além da duração total do projeto (CRUZ, 2015).
2.5.2.9.4.Artefatos do Scrum
A ferramenta Scrum utiliza quatro artefatos: Product Backlog, Sprint Backlog, a Definição de Pronto e o Incremento do Produto (SABBAGH, 2013).
Segundo Pressman (2016), o Product Backlog (Registro pendente de trabalhos) é uma lista com os requisitos ou funcionalidades, definidas junto ao cliente. Novos requisitos, podem ser adicionados ao Backlog a qualquer momento.
O Sprint Backlog define os trabalhos que são considerados essenciais para o alcance dos objetivos da Sprint. Nesse sentido, quando ocorre uma inserção de serviço, o Sprint Backlog é adicionado ao Product Backlog. Vale ressaltar que durante o andamento do trabalho, os itens podem ser alterados ou removidos, porém apenas o time de desenvolvimento do projeto tem permissão para realizar as alterações durante a Sprint (SCHWABER & SUTHERLAND 2013).
A Definição de Pronto, por sua vez, gera muitos conflitos e de fato se concretiza quando toda a equipe entra em um consenso de que o processo está pronto (CRUZ, 2013).
Por fim, no Incremento do Produto são trabalhados os itens selecionados para o Sprint Backlog, sem deixar de lado a Meta do Sprint. O Incremento traduz-se na soma dos itens completos no Sprint (SABBAGH, 2013).
2.5.2.9.5.Eventos do Scrum
Ainda de acordo com Sabbagh (2013), existem alguns eventos necessários na metodologia Scrum, são eles:
• Sprint;
• Reunião de sprint planning (planejamento da sprint); • Reunião de sprint review (revisão da sprint);
• Reunião de sprint retrospective (retrospectiva da sprint); • Daily Scrum (Scrum diário).
A Release Planning é uma reunião de planejamento da versão de entrega. Nesta reunião as seguintes questões são feitas (CRUZ, 2015):
1. Como podemos transformar a visão do produto em um produto real da melhor maneira possível?
2. Como podemos alcançar a satisfação do cliente e o ROI desejados? 3. Quando, no pior cenário, podemos entregar a versão X do sistema?
Para Sabbagh (2013), uma Sprint pode durar de uma a quatro semanas. Neste ciclo, o produto é desenvolvido e o incremento é feito pela equipe, de acordo com os itens do Product Backlog. Vale ressaltar que uma Sprint se inicia, quando a anterior termina.
Segundo Cruz (2015), a Sprint Planning é uma cerimônia, na qual o time planeja em conjunto todos itens que serão realizados na próxima Sprint.
A Sprint Review ocorre sempre no encerramento de cada Sprint e tem o objetivo de apresentar as novas versões e alterações realizadas no produto para os responsáveis. Assim, estes irão verificar se os incrementos atendem as expectativas e objetivo do projeto (SALES, 2013)
Diferentemente, a Sprint Retrospective é uma reunião feita pelo time de desenvolvimento e o Scrum Master com o intuito de verificar o que pode ser melhorado no andamento do projeto e o que não agradou durante a Sprint (SILVA, 2009)
Daily Scrum são realizadas diariamente com duração curta, de aproximadamente 15 minutos. Nesta reunião são discutidos os marcos alcançados desde a última reunião, os problemas que foram encontrados nas tarefas realizadas e quais as próximas tarefas a serem realizadas até a próxima reunião (PRESSMAN, 2016).
3.METODOLOGIA
3.1.INTRODUÇÃO
O trabalho em questão baseia-se em uma pesquisa bibliográfica em conjunto com um estudo de caso que compara a aplicação da metodologia Scrum pela empresa de consultoria estudada com o framework proposto em 1995 por Jeff Sutherland e Ken Schwaber, criadores da metodologia Scrum.
Com base no que foi proposto para o estudo, as escolhas metodológicas se complementam, de forma que o embasamento teórico necessário do tema através da pesquisa bibliográfica agrega para a aplicação do estudo de caso.
3.2.PESQUISA BIBLIOGRÁFICA
A presente pesquisa tem uma abordagem aplicada, visto que gera conhecimentos que podem ser aplicados na prática dirigidos à solução de problemas específicos. Sua natureza é qualitativa, pois a revisão de literatura gera o embasamento necessário para identificação das divergências na aplicação da metodologia e a teoria descrita pelo framework. Por fim, seu objetivo é de caráter exploratório, pois em conjunto com o estudo de caso estabelece critérios, métodos e técnicas para a elaboração de uma pesquisa e visa oferecer informações sobre o objeto desta e orientar a formulação de hipóteses (CERVO E SILVA, 2006).
Foram utilizadas palavras-chave relacionadas ao tema para pesquisa da bibliografia que sustenta o trabalho: “gestão de projetos”, “desenvolvimento de Softwares”, “metodologia cascata”, “métodos ágeis” e “Scrum”.
As pesquisas foram realizadas no período de março a junho de 2019 em fontes como Periódicos CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior), dentre outros repositórios de teses, dissertações de diversas universidades brasileiras, livros e artigos.
3.3.ESTUDO DE CASO
O caso é construído a partir da observação participante, exercendo funções no projeto, considerando que o autor é funcionário da empresa estudada.
Os dados coletados são adquiridos internamente na empresa, através de participação em entrevistas e reuniões com a equipe e com o cliente, visto que o projeto, que está aplicando o método Scrum, está em andamento e o autor deste trabalho faz parte da equipe.
A metodologia utilizada para o presente estudo pode ser ilustrada no fluxograma apresentado na Figura 10:
Figura 10: Fluxograma da metodologia do trabalho Fonte: Autor, 2019 Início Definir situação-problema Definir questões a serem respondidas Definir metodologia da pesquisa
Pesquisar bibliografia Concluir o trabalho Analisar resultados
Comparar a metodologia aplicada
com o framework Coletar dados para o
estudo de caso
A
A
4.ESTUDO DE CASO
4.1.INTRODUÇÃO
Após a apresentação da metodologia utilizada neste projeto, neste capítulo será descrita a empresa estudada, com as suas principais características e áreas de atuação. Embora a organização tenha se apresentado colaborativa durante todo o desenvolvimento do estudo, assim como seus funcionários, para preservar o nome da mesma, bem como manter em sigilo as suas informações, a empresa será nomeada durante o estudo de caso como empresa Alpha.
Da mesma forma, o projeto em questão também será detalhado neste capítulo, sem citar o nome do cliente, a fim de preservar a identidade dele. Assim, o cliente em questão será nomeado durante o estudo de caso como empresa Omega. Em seguida, será descrita a situação atual do projeto, com relação a aplicação da metodologia Scrum.
4.2.DESCRIÇÃO DA EMPRESA
Alpha é uma empresa multinacional de capital aberto, de consultoria de gestão, tecnologia da informação e outsourcing, que foi fundada na década de 80 nos Estados Unidos. Atualmente, sua sede corporativa está localizada em Dublin, na Irlanda. Pode ser considerada uma organização de grande porte, contando com mais de 477.000 funcionários, realizando projetos em mais de 200 cidades de 120 países. No ano de 2018, apresentou uma receita líquida de 39,6 bilhões de dólares e foi eleita a empresa mais diversa e inclusiva do mundo.
No Brasil, a empresa Alpha possui mais de 13.000 funcionários e possui escritórios em São Paulo, Rio de Janeiro, Recife, Brasília, Belo Horizonte, Nova Lima, Vitória, Campina Grande, Porto Alegre e São Bernardo do Campo.
Atualmente, fornece serviços em cinco áreas:
• Strategy – Utilizam as competências no desenvolvimento de estratégias de negócio, tecnologia e operações. Buscam entender como a tecnologia criará impacto na indústria e nos modelos de negócio, a fim de garantir o sucesso do cliente;
• Consulting – Fornece ferramentas aos clientes, para que estes sejam capazes de realizar escolhas inovadoras e arrojadas;
• Digital – Utilizam três áreas que possibilitam os clientes reinventarem seus negócios: Applied Intelligence, Industry X.O e Interactive;
• Technology – Ajudam os clientes com novas plataformas líderes de mercado, a fim de que estes acompanhem o avanço das transformações digitais;
• Operations – Reunem equipes para criar modelos de operações inteligentes para os clientes utilizarem no longo prazo.
Além disso, as áreas de atuação da empresa Alpha são divididas por indústria, de forma que ela atua principalmente nas indústrias abaixo:
• Communication, Media & Technology (CMT) • Resources
• Financial Services • Products
• Health & Public Service (HPS)
Assim, o organograma funcional da empresa Alpha está melhor descrito na Figura 11.
Figura 11: Organograma funcional da empresa Alpha Fonte: Dados empresa Alpha, 2019
4.3.DESCRIÇÃO DO PROJETO
O projeto estudado está em andamento há mais de um ano e tem como objetivo o desenvolvimento de um Software, mais especificamente um aplicativo para mobile. Conforme citado anteriormente, está sendo utilizada a metodologia ágil Scrum como abordagem para o gerenciamento do desenvolvimento do projeto.
Nesse sentido, uma equipe mista foi formada para estar à frente do projeto. Embora o projeto possa ser classificado na área de Digital, uma parte da equipe é composta por funcionários de Consulting e a outra parte é formada por integrantes de Digital. Dessa forma, a equipe como um todo busca criar valor para o cliente, a partir de entregas no prazo, suporte para o aplicativo e bom relacionamento com os stakeholders. Assim, a equipe do projeto é dividida em duas equipes menores:
• Equipe Funcional (Consulting) – Esta equipe fica responsável pela relação com o cliente Omega, realizar o planejamento do projeto e testar as funcionalidades desenvolvidas pela equipe de desenvolvedores (DEV) em cada Sprint. Além disso, a equipe dá suporte aos usuários do Aplicativo (APP) ou seja, parceiros da empresa Omega, visto que o APP já subiu para produção e recebe novas funcionalidades a cada Sprint.
• Equipe de Desenvolvedores (Digital) – Esta equipe, como o próprio nome diz, é responsável por desenvolver o Software. Seus integrantes possuem experiências prévias em programação e utilizam a abordagem Scrum para atender a demanda do projeto.
A estrutura da equipe está especificada no organograma hierárquico do projeto, conforme ilustrado na Figura 12.
O cliente, empresa Omega, é uma das maiores empresas brasileiras de telecomunicações. Portanto, pela empresa Alpha, este cliente é classificado na indústria de Communication, Media & Technology (CMT), sendo esta a maior indústria de atuação de projetos pela empresa Alpha no Rio de Janeiro.
Figura 12: Organograma hierárquico da equipe do projeto Fonte: Autor, 2019
4.4.SITUAÇÃO PROBLEMA A SER ESTUDADA
Por se tratar de um projeto externo em que o cliente Omega contratou a consultoria Alpha para o desenvolvimento de um Software, existem diversos fatores que influenciam no andamento do projeto e consequentemente na aplicação da metodologia Scrum, a qual está sendo utilizada em todos os projetos em andamento de desenvolvimento de Software na empresa Alpha.
O projeto, conforme citado anteriormente, está em andamento há mais de um ano e o Software que está sendo desenvolvido, encontra-se atualmente na Sprint 17. Durante esse período, é perceptível que as equipes, tanto funcional como DEV, muitas vezes estão sobrecarregadas e trabalham constantemente sob uma pressão que pode interferir no andamento do escopo.
Essa pressão pode ser considerada top down, visto que o Product Owner (PO) do cliente cobra a equipe da empresa Alpha por resultados. A pressão é passada de forma hierárquica para baixo. Assim, o conceito ágil definido na metodologia Scrum é interpretado pelo cliente como um maior volume de entregas em um curto período de tempo. Entretanto, ao programar sob pressão,
os desenvolvedores estão mais sujeitos a cometer falhas. Estas, muitas vezes, serão notadas apenas na fase de testes ou pelos usuários quando a funcionalidade já está em produção.
Vale ressaltar, que a falta de tempo para inspeção possibilita a ocorrência de um maior número de falhas, as quais geram retrabalho, atrasando o escopo do projeto e principalmente a entrega da Sprint.
Nesse sentido, a verticalidade afeta a hierarquia dentro do projeto, de forma que na prática existem três PO que não pertencem a equipe de DEV, sendo um do cliente e os outros dois da equipe funcional , os quais decidem as funcionalidades que subirão em cada Sprint. Dessa forma, o time Scrum fica sem autoridade para vetar alguma user story ou seja, uma necessidade do usuário do produto, um requisito sob o ponto de vista desse usuário.
Além disso, nem todos os componentes do time Scrum conheciam a metodologia utilizada a fundo, visto que apenas dois componentes realizaram cursos e possuem certificações de Scrum, sendo um o Scrum Master e o segundo um analista.
Por fim, foi observado que o framework da metodologia Scrum, que foi desenvolvido pelos criadores da abordagem, aparentemente não está sendo seguido como foi idealizado. Assim, no próximo capítulo serão analisadas as divergências existentes entre o framework teórico e a aplicação da metodologia na prática.
5.ANÁLISE DE RESULTADOS E RECOMENDAÇÕES
5.1.ANÁLISE
A análise do estudo será realizada, comparando o framework apresentado anteriormente na Figura 9 e a aplicação da metodologia Scrum na prática, de forma a verificar as divergências existentes.
5.1.1.Pilares do Scrum
Ao analisar os três pilares do Scrum definidos por Schwaber e Sutherland (2013), percebeu-se que há divergências em todos os pilares no projeto:
• Transparência – Considerando que a estrutura da equipe foi dividida em equipes menores (funcional e DEV), a transparência muitas vezes fica comprometida, visto que os times não se comunicam a todo momento;
• Inspeção – Levando em conta a cobrança e a pressão por parte dos superiores e do cliente, não há tempo para inspeção pela equipe de DEV após o desenvolvimento de alguma funcionalidade. A inspeção é feita apenas pela equipe funcional ao testar a funcionalidade no APP;
• Adaptação – Devido a verticalidade do projeto, a equipe DEV muitas vezes não tem autonomia para realizar adaptações nas user stories sem aprovação prévia dos gerentes da equipe funcional.
5.1.2.Ciclos do Scrum
Conforme citado anteriormente, na prática existem três PO neste projeto e nenhum dos três faz parte do time DEV, trazendo um distanciamento entre os programadores e os PO. Além disso, a definição do que subirá em cada Sprint é definido pela gerente da equipe funcional e posteriormente é validado pelo gerente sênior do projeto, o que atrasa a definição de cada Sprint, além de não envolver o time Scrum nessas decisões.
O Scrum Master cumpre seu papel no projeto, afastando os impedimentos para a realização do trabalho do time, conforme definido por Carvalho & Mello (2012), porém na estrutura da equipe do projeto, o Scrum Master também ocupa a função de gerente da equipe DEV, o que lhe impõe poder hierárquico sobre os integrantes da equipe, contrariando a definição de Cohn (2011).
Analisando a duração das Sprints do projeto definida como duas semanas, é possível perceber que está dentro do período aceitável de uma a quatro semanas. Entretanto, a pressão e a cobrança causam falhas e consequentemente atrasos nas Sprints de alguns dias que passam a ter tamanhos diferentes. Assim, a despadronização no tamanho das Sprints prejudica a definição de velocidade do time Scrum.
5.1.3.Eventos do Scrum
Conforme a definição de Sabbagh (2013), existem alguns eventos necessários na metodologia Scrum, porém conforme analisado no projeto alguns destes não são seguidos de forma correta:
• Reunião de release planning – Por falta de tempo durante as Sprints, a reunião de release planning não é realizada no projeto;
• Sprint – Conforme citado anteriormente as Sprints não são padronizadas, ou seja, não possuem o mesmo tamanho;
• Reunião de sprint planning – A Sprint Planning ocorre normalmente no início de cada Sprint. Porém não é discutido detalhadamente cada item, pois o time Scrum sofre pressão com relação ao tempo de entrega e os integrantes do time não tem poder para vetar alguma user storie;
• Reunião de sprint review – Não existe uma reunião formal de Sprint review. Apenas são realizados testes de cada funcionalidade da Sprint pela equipe funcional;
• Reunião de sprint retrospective – Não é realizada regularmente ao final de cada Sprint pela falta de tempo;
