Principais dificuldades na Implementação de Métodos Ágeis e como Resolvê-las

São Paulo, 12/02/2018 Paulo Roberto Bernice TERMO DE APROVAÇÃO Paulo Roberto Bernice Principais dificuldades na Implementação de Métodos Ágeis e como Resolvê-las Monografia apresentada e aprovada em dd/mm/aaaa Nome do Professor — Orientador Nome do Professor — Convidado Nome do Professor — Convidado São Paulo Mês/ano RESUMO Informações automatizadas, utilização de técnicas e sistemas ágeis que sejam eficazes no resultado tornou-se uma necessidade, principalmente no que tange desenvolvimento de software e gerenciamento de projetos em equipes. Por essa razão torna-se impar a analise quanto a utilização de metodologias ágeis no ambiente de trabalho em desenvolvimento de softwares, mais especificamente a Metodologia SCRUM, analisando os efeitos de sua aplicação tanto do ponto de vista dos desenvolvedores e analistas da equipe quanto do gestor.

Para a referida analise questiona-se o porquê, de tantas vezes, em que o Scrum é implementado na rotina da equipe, ocorre erros ou mesmo o abandono de seu correto uso. Objetivando encontrar a causa para esta problemática, realizaram-se pesquisas com pessoas que trabalham no mercado de desenvolvimento de software. Pode-se, desse modo, avaliar a origem do problema no despreparo técnico do time de desenvolvimento, dos gestores e também no falho processo de seleção de profissionais. software development. LISTA DE TABELAS Tabelas 1 Scrum x Waterfall 48 Tabelas 2 Resultados de projetos 48 Tabelas 3 Relação Pergunta-Hipótese 51 Tabelas 4 Resultado Pesquisa de Desenvolvedores 53 LISTA DE qUADROS Quadro 1 Classificação do porte de empresas adotado nesta pesquisa 52 Quadro 2 Caracterização das empresas estudadas 52 Quadro 3 Fatores que influenciam resultados 53 LISTA DE figuras Figura 1 Ilustração de um modelo de Kanban 17 Figura 2 Principio Scrum 19 Figura 3 Transparência em Scrun 20 Figura 4 Inspeção em Scrum 21 Figura 5 Objetivos de um Time Auto-Organizado 22 Figura 6 Princípio da Colaboração em Scrum 13 Figura 7 Time-Boxing 25 Figura 8 Gráfico de Iteratividade do Projeto 31 Figura 9 Organização dos Papéis no Scrum 32 Figura 10 Papéis Scrum 33 Figura 11 Processo de Justificativa de Negócio 35 Figura 12 Fórmula do VPL 37 Figura 13 Gráfico de Análise de Kano 38 Figura 14 Fase Iniciar 42 Figura 15 Planejar e Estimar 43 Figura 16 Implementar 44 Figura 17 Revisão e Retrospectiva 46 Figura 18 Entrega 47 SUMÁRIO 1.

INTRODUÇÃO 11 1. Questão de pesquisa 12 1. Objetivo geral da pesquisa 12 1. Auto-Organização 21 2. Colaboração 23 2. Priorização baseada em Valor 24 2. Time-Boxing 24 2. Scrum Master 26 2. Papeis Centrais 32 2. Product Owner 33 2. Scrum Master 33 2. Time Scrum 34 2. Papeis Não-Centrais 34 2. Mudanças 40 2. Fases do Scrum 41 2. Iniciar 41 2. Planejar e estimar 43 2. Implementar 44 2. O que se dar “Por diversos fatores: investimento alto em divulgação, custo de equipe de vendas, custo de suporte técnico, concorrência” (citação) mesmo reduzindo a parte do recursos humanos deparava-se ainda com a necessidade de locomoção, e os interurbanos, o que ocasionava uma grande perda de tempo. Na atualidade com a internet é possível ter um alcance muito alem das fronteiras de um país com baixo custo e dispensando uma equipe de vendas. O suporte remoto, a intranet e extranet aperfeiçoaram e muito o trabalho, pois os usuários podem além de muitas outras ações como atualizar seus sistemas, fazer backup, e acessarem base de conhecimentos multimídia.

Na visão de Jacobson (2002), agilidade é palavra da moda para software modernos, desse modo uma equipe ágil é aquela destra e eficaz em responder a mudanças, de modo a reconhecer que o software é desenvolvido por uma equipe e que as habilidades e capacidades das pessoas que compõe essa equipe estão na essência do sucesso do projeto. Nesse viés a vantagem obtida pela metodologia ágil no atual mercado de TI é que ela é principalmente orientada à entrega, (PRESSMAN, 2011) mesmo que priorizando a comunicação ativa e continua entre a equipe desenvolvedora e o cliente a entrega possui mais foco que a própria analise do projeto. • Obter opiniões de desenvolvedores, gestores e “stakeholder” nas empresas. • Identificar em que fase do desenvolvimento do projeto a metodologia é abandonada. • Elaborar recomendações para a gestão de projetos de desenvolvimento de sistemas de informação • Propor alternativas de solução dos problemas visando colher os benefícios apontados como vantagens na utilização de metodologias de desenvolvimento de sistemas.

Metodologia Para confecção do presente trabalho foi adotado o tipo de escrita explanatória e explicativa. Explanatória por que com o tema proposto busca-se entender a funcionalidade do tipo de metodologia escolhida no que seja a Scrum e suas possíveis correções quando da pratica. Na verdade, fazer medições torna-se uma medida imperativa para as organizações que buscam a perenidade. Para gerenciar um processo é necessário dispor de informações sobre ele, pois, Segundo Harrington (1993), medir é fundamental para que se possa controlar, gerenciar, e aperfeiçoar. Desse modo, indicadores de desempenho é uma forma de medir o desempenho de uma organização, em todas as suas macro-funções (marketing, recursos humanos, financeira e produção) objetivando avaliar campos de resultados que podem ser identificados através de fatores, tais como: eficácia, eficiência e adaptabilidade.

Nesse sentido, esses campos de resultados são preceituados por Harrington (1993), que estabelece, dentre os elementos de controle de processo, o fator eficácia como sinônimo de qualidade e o fator eficiência como de produtividade. Metodologia Scrum A Scrum apresenta uma abordagem empírica que aplica algumas idéias da teoria de controle de processos industriais para o desenvolvimento de softwares, reintroduzindo as idéias de flexibilidade, adaptabilidade e produtividade. HISTÓRIA Como descrito no Guia SBOK (2013), no fim dos anos 80, Hirotaka Takeuchi e Nonaka Ikujiro definiram uma estratégia flexível para o desenvolvimento de produtos, onde a equipe de desenvolvimento funciona como um só, para alcançar um objetivo comum. Era uma abordagem inovadora, que na época apelidaram de abordagem holística ou "rugby", pois assim como no esporte, o time trabalha a bola para a frente e para trás com o intuito de atingir o objetivo à frente.

Ainda no conceito do rugby, cada membro do grupo tem sua função e, apenas com o bom funcionamento de cada um, é que a jogada terá sucesso. Eles basearam esta abordagem nos estudos de caso de diversas indústrias. O conceito de Scrum obtido do rugby foi introduzido para descrever a proposta dos autores de que o desenvolvimento do produto deve envolver "o movimento de Scrum campo abaixo " (“moving the Scrum downfield” – tradução livre). Conceitualmente, a metodologia divide-se em três blocos: princípios, aspectos (processos) e fases. Principio Scrum Os princípios do Scrum são suas características chave, seguem seus pontos e objetivos durante o desenvolvimento do projeto. Figura 1 - Princípios Scrum FONTE: Guia SBOK™ De modo que se busca a colaboração da equipe, a auto organização, o controle do processo, o desenvolvimento interativo e a priorização orientada a valor.

Fatores que designam bem o processo de agilidade que se busca. Controle de Processos Empíricos O primeiro conceito de Scrum, é que não é necessário um detalhamento inicial aprofundado do projeto. Isto é tornado possível em razão das reuniões diárias, da identificação constante de riscos, da solicitação de mudanças, do Guia SBOK™, das reuniões de retrospectiva da Sprin, e das reuniões de retrospectiva do projeto. Auto-Organização Este princípio do Scrum defende o empoderamento da equipe desenvolvedora. O estilo de liderança conhecido como “liderança servidora” é aquele onde não há a figura de um “chefe” detentor de todo o poder de decisão e que delega tarefas. A própria equipe é auto gerenciável, tendo autonomia para escolher as suas próprias tarefas, resolver seus problemas e auxiliar na montagem de cronogramas.

Isto apenas é possível por alguns fatores muito importantes do ambiente. Para o Scrum, é muito importante que ambos tenham as ideias alinhadas e compartilhem informações sobre o andamento do projeto. Rotineiramente, são feitas reuniões para criação de demandas, validação e entrega de entregáveis e consulta de dúvidas entre esses dois personagens, o que traz diversos benefícios como: Necessidade de mudanças no Backlog devido à requisitos mal descritos ou mal compreendidos: Os riscos são identificados logo cedo e tratados de forma eficiente; O time consegue atingir níveis de potencial mais altos; Processo de melhoria contínua devido ao aprendizado recorrente. Figura 4 - Princípio da Colaboração em Scrum FONTE: Guia SBOK™ (2013) Nesse âmbito o princípio da colaboração pode ser atingido seguindo três pilares básicos: 1) Consciência: consiste em que todos os membros da equipe estejam cientes do trabalho dos colegas; 2) Articulação: é a capacidade de dividir o trabalho entre si e depois reintegrá-lo em uma solução única; e 3) Apropriação: habilidade para completar atividades utilizando a tecnologia de forma criativa.

Priorização baseada em Valor O Scrum Core Team tem, entre outras, como metas entregar o máximo em menor tempo, então é realizada uma ordenação das atividades segundo o quanto ela agrega ao projeto. De modo que a priorização baseada em valor é o princípio que direciona as entregas do Scrum e permite que cada entrega tenha o máximo de valor possível para o cliente. Figura 5 - Time-Boxing FONTE: Guia SBOK™ (2013) Assim o Time-Boxing determina a duração das reuniões. Conforme demonstrado na imagem a Sprint de uma 1 (uma) a 6 (seis) semanas, as reuniões diárias devem durar no Maximo 15 (quinze) minutos ou ainda as reuniões de revisão da Sprint que deve durar em torno de 4 (quatro) horas quando se tratar de uma Sprint de um mês.

De forma geral, os principais benefícios que o Time-Boxing traz são: eficiência nos processos, redução de despesas e times velozes. Dito isto destaca-se agora que no método Scrum, seus participantes estão divididos em três papéis principais, sendo eles: 1) Scrum Master; 2) Product Owner; e 3) Equipe; 2. Scrum Master O Scrum Master é o membro da equipe responsável pela manutenção do processo em funcionamento. Essas informações são registradas no documento de controle Product Backlog. O Product Owner é o responsável por transmitir os requisitos de negócios para que a equipe possa transformar esses conceitos em código de Software. Equipe (Time) A Equipe nas organizações que utilizam Scrum devem variar, idealmente, entre cinco a nove pessoas. É importante que seus membros possuam perfis de trabalho multifuncionais (cross-functional).

Isto é, para integrar a equipe, são necessárias pessoas com perfis de Testadores, Desenvolvedores, Analistas de Bancos de Dados (DBA), Analistas de Negócios, Designers e etc. Ao fim da reunião, a equipe passa a trabalhar nas tarefas que foram atribuídas à Sprint, seguindo a ordem de prioridades que agregue o maior valor ao produto. A priorização das tarefas é realizada pelo Product Owner. Após deve ocorrer novos encontros da equipe. Conforme pontua GOMES (2014, p. todos os dias é realizada uma reunião para que a equipe converse sobre o andamento do sprint". Seu objetivo é atualizar a equipe sobre o andamento das atividades de cada um, sinalizando dificuldades, impedimentos e outros problemas para que estes possam ser logo solucionados com a ajuda do próprio Time Scrum ou do Scrum Master.

Para isso, são geralmente feitas três perguntas objetivas: • O que eu fiz ontem? • O que vou fazer hoje? • Quais problemas estou enfrentando atualmente? Para mais detalhes, verificar no capítulo “2. Implementar”. Reunião e planejamento da Sprint Também chamada de “Reunião de Planejamento de Tarefas” ou “Reunião de Estimativa de Tarefas”. É uma reunião realizada, como o próprio nome já diz, logo antes da criação do Sprint, tendo como objetivo criar o Backlog da Sprint – uma lista de User Stories pegas do topo da pilha do Backlog Priorizado pelo Product Owner a ser transformadas pelo Time Scrum em entregáveis que serão distribuídos entre eles mesmos e então desenvolvidos na Sprint – e o Gráfico de Burndown da Sprint – um gráfico que representa, em linhas, o risco de cada atividade dentro do Backlog da Sprint.

Para um Sprint de um mês, é Time-boxed em quatro horas, e é realizada como parte do processo de Retrospectiva do Sprint. ” (Guia SBOK™, 2017, p. De modo que o objetivo da Reunião de Retrospectiva da Sprint é identificar deficiências nos processos ou no mau uso de ferramentas para providenciar melhorias para a próxima Sprint e também identificar pontos positivos para continuar fazendo. Desenvolvimento Interativo O desenvolvimento interativo é um princípio que o Scrum traz que o diferencia, e muito, de outras metodologias tradicionais de desenvolvimento, como o Waterfall por exemplo. Neste modelo, não é necessário que o cliente tenha desde o começo toda a documentação de requisitos bem definida para que se possa dar início ao desenvolvimento. Os personagens são extremamente importantes, cada um com sua função dentro do time, como visto no começo deste capítulo na descrição do conceito de “Scrum”.

Figura 7 - Organização dos Papéis no Scrum FONTE: Guia SBOK™ (2013) Portanto a organização e dada de forma sistemática o Time Scrum cria as estratégias do projeto, o Scrum Master assegura um ambiente de trabalho adequado ao Time Scrum, o qual por sua vez demonstra o incremento do produto ao dono do produto, o Dono do produto entrega vaor de negocio ao cliente, enquanto que o cliente fornece seus requisitos ao Dono do Produto, o qual mais uma vez, comunica os requisito de negocio ao Time Scrum que define, por meio do Backlog Priorizado, os critérios de aceitação. Papeis Centrais Também conhecido como Core Scrum Team, são, basicamente, os personagens que atuam diretamente no desenvolvimento do projeto. Figura 8 - Papéis Scrum FONTE: Guia SBOK™ Aqui encontra-se os papeis Scrum que conforme já exposto configura-se no Dono do Produto, no Scrum Master e no Time Scrum.

Product Owner Product Owner é o personagem que faz a interface entre o Time Scrum e os Stakeholders. Papeis Não-Centrais De uma forma geral, estes são os personagens que não atuam diretamente no projeto, mas que de alguma forma estão envolvidos são os denominados de Stakeholders. Podem ocupar esses papéis o próprio cliente, os patrocinadores ou até mesmo os usuários. Justificativa de Negócio A Justificativa de Negócio é o aspecto do Scrum relacionado ao princípio da Priorização Orientada ao Valor. É ela que vai indicar as razões para que o projeto ocorra e posteriormente nortear o seu andamento. A partir do momento em que os Stakeholders já não enxergam a justificativa como válida, o projeto pode e deve ser cancelado ou reformulado.

Retorno Sobre Investimento (ROI) Calcula o lucro líquido esperado de um projeto, tendo como base os investimentos e custos iniciais sobre o retorno. Fórmula ROI ROI = (Receita do Projeto – Custo do Projeto) / Custo do Projeto Este resultado – o lucro líquido – é em seguida dividido pelos custos futuros esperados para se obter uma taxa de retorno sobre o custo ou investimento completo do projeto. Valor Presente Liquido (VPL) Segundo a definição do Guia SBOK™ (2013), o VPL resulta do total esperado da renda subtraído o custo previsto sem desconsiderar o valor do dinheiro no tempo, ou seja, ele utiliza como base de cálculo financeiro o valor do dinheiro esperado por causa da inflação e pode calcular em quanto tempo o projeto irá “se pagar”. Figura 10 - Fórmula do VPL FONTE: https://blog.

luz. • Indiferentes: recursos não fazem diferença se estiverem presentes ou não. Figura 11 - Gráfico de Análise de Kano FONTE: Guia SBOK™ (2013) Nesse contesto o Gráfico de Analise de Kano busca esquematizar as projeções a partir das necessidades atendidas e não atendidas frente à satisfação e insatisfação do cliente. De modo a demonstrar ao Dono do projeto e a Time Scrum as lineares do projeto 2. Priorização MoScoW MoSCoW é uma abreviatura para os termos “Must have” (deve ter), “Should have” (deveria ter), “Could have” (poderia ter), e “Won’t have” (não vai ter). Estes rótulos estão ordenados por importância e devem ser atribuídos às características ou requisitos do projeto. Critérios de Aceitação Conforme já descrito, o Backlog Priorizado do Produto é composto por User Stories.

Mas para que elas componham esta pilha, é preciso que sejam aceitas pelo Product Owner. Cada User Story deve ter um critério de aceitação associado, que são os objetivos pelos quais elas serão julgadas. Portanto devem ser muito bem definidas para que a qualidade das entregas seja sempre boa. Há, também, os Critérios Mínimos de aceitação. De acordo com dados apresentados em uma palestra sobre desenvolvimento ágil na Faculdade de Tecnologia do Estado de São Paulo - FATEC-SP (na Semana de Tecnologia da FATECSP em 2016), cerca de 76% dos projetos sofrem algum tipo de mudança que causa impacto na entrega final. Com uma porcentagem tão alta, é mais que necessário estar apto a gerenciar sem maiores impactos qualquer alteração solicitada pelos Stakeholders em qualquer parte do projeto.

O Scrum permite isso com algumas técnicas básicas. Primeiramente, o Time Scrum deve sempre trabalhar próximo dos Stakeholders, para que ambos estejam sempre alinhados em ideias. Então, sempre que um Stakeholder nota algo que pode ser preciso mudar – isso já em tempo de desenvolvimento -, ele pode informar o Time Scrum e as medidas necessárias podem ser tomadas. Primeiramente temos o Processo de Visão do Projeto. A partir de um Business Case Project, documento elaborado pelos Stakeholders com as informações básicas de ideia de um novo projeto, é realizada a Reunião de Visão do Projeto, o que gera a Declaração de Visão do Projeto, documento superimportante que contém informações como as macro necessidades do projeto, as pessoas envolvidas, orçamento, prazo e justificativa do projeto; e quem é o Product Owner.

Figura 12 - Fase Iniciar FONTE: Guia SBOK™ (2013) Em seguida vem o processo de identificação do Scrum Master, onde em uma Reunião de Seleção de Critérios o Product Owner e os Stakeholders discutem, com base na Declaração de Visão do Projeto, quais serão os critérios técnicos necessários para a montagem do Time Scrum, equipe multifuncional que irá trabalhar no desenvolvimento do projeto. Com isso, os Stakeholders se reúnem com o Scrum Master no processo de Formar o Time Scrum e assim o fazem. O próximo processo é o Desenvolvimento dos Épicos (requisitos de alto-nível do projeto). Com base na expertise desses membros, são obtidas as User Stories e os seus respectivos critérios de aceitação. Esses dois produtos são as entradas principais para o próximo passo, a Aprovação das User Stories pelo Scrum Core Team juntamente com os stakeholders do projeto.

As User Stories aprovadas são usadas na Criação de Tarefas na Reunião de Planejamento de Tarefas realizada pelo Scrum Core Team. Desse ponto, se tem a lista bruta de tarefas que devem ser feitas no decorrer do projeto. Tarefas são basicamente User Stories escritas de uma forma mais compreensível no mundo de desenvolvimento. Basicamente, o Time Scrum se reúne com o Scrum Master para os feedback citando: O que foi feito ontem, o que vou fazer hoje e quais os problemas que estou enfrentando. Com isso, a equipe tem conhecimento sobre como estão as atividades dos colegas e também podem ajudar uns aos outros com seus impedimentos. Ao fim da Sprint, é feito o último passo da fase de implementação: o Refinamento do Backlog Priorizado do Produto.

É feita uma reunião de revisão para atualizar o Cronograma de Planejamento da Release e o Backlog Priorizado do Produto, adicionando as alterações e tarefas não completas remanescentes da Sprint recém terminada. Revisão e Retrospectiva É a quarta fase do processo Scrum. Para finalizar essa fase, é feita a Reunião de Retrospectiva da Sprint, onde se analisam os métodos utilizados e se tira experiência para reutilizar nas próximas sprints. É visto que foi feito de bom e o que precisa ser melhorado ou mudado. Ali participam o Scrum Master e o Time Scrum. Entrega A fase da entrega é o último do workflow Scrum. É nele que se empacota tudo o que foi desenvolvido e entrega ao cliente para ser implantado e começar a gerar valor.

De modo que quando se tratava da aplicação de metodologias ágeis de certa forma, o método não funcionava da forma como deveria, o que acabava prejudicando o gerenciamento da equipe e assim sendo rapidamente ignorado pela mesma. Tendo o Scrum como base, o que mais ficava claro na maioria das situações era a negligência ao padrão de sprints e ao feedback regular de curto período. Um comportamento é bastante ruim, como pode ser presenciado, pois pode causar danos maiores que um simples mau-gerenciamento de um projeto ou de uma equipe, na verdade pode acarretar atrasos nas entregas, perda de qualidade no produto e até cancelamento do projeto. A problemática expressa cria um ambiente confuso e algumas vezes caótico onde era esperada a organização, pois uma metodologia deveria estar apoiando o gerenciamento das atividades.

Se apenas os resultados da Scrum forem esperados sem que se dê atenção ao processo como um todo, várias dificuldades podem surgir, como é dito no artigo “Quais as principais dificuldade de Métodos Ágeis e como Resolvê-las?” do blog “Project Builder” (2017). Não é cobrado nem esperado que os desenvolvedores que participam da equipe tenham conhecimento técnico/conceitual da metodologia utilizada no seu processo de desenvolvimento de softwares e projetos. As metodologias são implantadas em ambientes onde não seriam a abordagem mais adequada. No dia-a-dia, trabalhar da forma como essas metodologias exigem, acaba sendo muito complicado e seus processos acabam por ser alterados para que se adequem melhor ao que a equipe já está habituada, prejudicando então os resultados propostos. Alem da problemática exposta e as cinco hipóteses apontadas outros fatores como a falta de preparação técnica dos gestores ou da equipe; negligência dos contratadores sobre esse tipo de conhecimentos nas entrevistas; ambientes impróprios para implementação do Scrum; adequação forçada dos processos de forma descuidada pela equipe devido ao desconforto frente à mudança, também, podem levar ao cenário observado.

Nesse contexto foi então montado um questionário online com na plataforma de formulários do Google para que se pudesse coletar informações relevantes a cada um dos postos das hipóteses. As questões foram feitas à medida que o assunto precisava de dados mais específicos sobre o assunto quando este era muito vago. Após o levantamento de informações do ponto de vista do desenvolvedor e analista, devíamos ouvir profissionais da área de gestão, de preferência aqueles que já trabalharam ou trabalham com Scrum. Estes, em número menor para coleta de dados, responderam a questionário diferenciado. Os quadros apresentados a seguir sintetizam todo o processo de pesquisa. O quadro 1, apresenta o porte das empresas adotado na pesquisa: Quadro 1. O próximo quadro demonstra o resultado das respostas dadas pelos voluntários que acessaram o questionário.

Tabela 4 - Resultado Pesquisa de Desenvolvedores PERGUNTA SIM NÃO Você já ouviu falar no seu ambiente de trabalho sobre metodologias ágeis? 26 0 Elas são utilizadas por você e sua equipe? 22 4 Essa metodologia é Scrum? 23 3 Numa escala de zero a dez, você considera seu conhecimento sobre essa metodologia acima de seis? 20 6 Você considera que o gestor da sua equipe tem bom conhecimento de metodologias ágeis? 19 7 Conhecer sobre metodologias ágeis é algo desejável para o seu cargo na sua empresa? 20 6 É cobrado de você esse conhecimento? 13 13 Já lhe foi cobrado conhecer sobre metodologias ágeis em alguma entrevista de emprego? 16 10 Você acha que a utilização de metodologias ágeis é uma medida adequada para o seu ambiente de trabalho? 25 1 Acredita que a imposição do uso de metodologias ágeis atrapalha o progresso dos projetos da sua equipe? 21 5 Todos os integrantes da sua equipe têm conhecimentos sobre metodologias ágeis? 11 15 Há dificuldade ou descontentamento na equipe com a metodologia? 10 16 FONTE: Pesquisa de Campo com Desenvolvedore (2017) Levando em conta apenas essa primeira pesquisa e seus resultados, é bastante claro que o assunto “metodologia ágil” está muito popular no mercado, pois 100% dos entrevistados alegaram ter algum conhecimento sobre ela, e que a grande maioria (84,6%) a utilizam no seu ambiente de trabalho.

Indo ainda mais fundo, justamente querendo verificar se o que achava sobre a popularidade do Scrum estava correto, verifiquei que desses 84,6% que utilizam metodologias ágeis no seu cotidiano, 88,5% usam Scrum! Então é bastante fácil concluir que a metodologia Scrum está realmente tomando conta de uma grande parte do mercado de desenvolvimento, considerando esses números. O principal objetivo dessas perguntas era validar, da melhor forma possível, as cinco hipóteses apresentadas. Resumidamente, elas consistem em verificar se a causa para os problemas na implantação de metodologias ágeis no ambiente de desenvolvimento é: 1. Uma das características principais desta metodologia, que a diferenciam das demais, é a sua capacidade de adaptação. Segundo o Guia SBOK™ (2013), o Scrum pode ser usado para qualquer tipo de projeto de qualquer setor ou mercado ou indústria.

Ele é escalável tanto horizontalmente quanto verticalmente, servindo a projetos pequenos e grandes. De volta as respostas, descarta-se, também, a hipótese 5. Na pergunta do questionário “Acredita que a imposição do uso de metodologias ágeis atrapalha o progresso dos projetos da sua equipe?” que tinha como finalidade validar essa hipótese, 80,8% das respostas foram “não”, indicando que a utilização de metodologias ágeis não venha a ser um problema. Essa afirmação se reforça ainda em outras perguntas do formulário. A pergunta “Conhecer sobre metodologias ágeis é algo desejável para o seu cargo na sua empresa?” resultou em 20 respostas “sim” (76,9%). Ademais, houve resultados preocupantes também nas duas últimas questões. Quando foi perguntado se todos os integrantes do Time Scrum tinham conhecimento sobre a metodologia, a maioria das respostas (57,7%) foi “não”.

Se isso, não confirma a hipótese de que a causa para falhas no uso de metodologia ágil nas empresas é a carência de conhecimento técnico sobre o framework, pelo menos demonstra que é algo que realmente acontece. O fato – que aliás diz respeito à pesquisa – é que as pessoas muitas vezes não estão sendo selecionadas com base nos seus conhecimentos em Scrum, por exemplo. O que acaba abrindo brechas para os problemas indicados na Hipótese 2. Portanto, mantém-se as hipóteses 2 e 3 como válidas. Com as hipóteses 4 e 5 descartadas e as 2 e 3 aceitas, sobra apenas a análise da Hipótese 1. O primeiro fator a se considerar são os dados obtidos em uma palestra assistida na Faculdade de Tecnologia de São Paulo (FATEC-SP) sobre Desenvolvimento Ágil de Software.

Entretanto, não basta a escolha de um método busca-se, também, fatores de agilidade, eficácia, gestão dinâmica e flexibilidade no processo. O qual conforme demonstrado em todo o trabalho pode ser alcançado dentro do método Scrum. Porém para o alcance dos resultados previsíveis nesse método, juntamente com os seus benefícios é necessário outros fatores além do método adequado, com conhecimento dos integrantes, comprometimento, trabalho em equipe e auto disciplina diante da dinamicidade, principal característica do Scrum. A partir da pesquisa realisada conclui-se que das hipóteses apresentadas, três são bastante possíveis e, portanto, válidas. O cenário problemático que foi sugerido pode se formar se houver despreparo por parte da equipe de desenvolvimento ou do gestor.

Casa do Código, 2014. GOMES, Fabio – Uma Visão geral sobre Metodologias Ágeis, 2017. Disponível em: <http://www. devmedia. com. JANONES, Ramos de Sousa. A Evolução dos Negócios e as Tendencias de Software. Disponível em: <http://www. devmedia. com. Gerenciamento Ágil de Projetos. Rio de Janeiro. Brasport, 2014. MOREIRA, Daniel. Administração de Produção e Operações. McGraw-Hill, 2006. PROJECT MANAGEMENT INSTITUTE: PMI Standards Committee. PMI Guide to the Project Management Body of Knowledge. ed. Newtown Square, PA, USA: Project Management Institute, 2008. com/trends/explore?q=%2Fm%2F0c3tq11,%2Fm%2F0ck_p8,%2Fm%2F02zhbn> Acesso em: 23 de outubro de 2017. SOMMERVILLE, I. Engenharia de Software. ª Ed. Pearson Prentice-Hall, 2008. PMI: É uma sigla para Project Management Institute. É o instituto de gerenciamento de projeto, órgão responsável pela publicação das melhores práticas de gerenciamento através do PMBOK.

PMP: É sigla para Project Management Professional. Nível de certificação dado pelo PMI que permite ao profissional que o obtém trabalhar com projetos de qualquer tamanho ao redor do mundo. Ownership: É um conceito usado no mundo corporativo que incentiva a tomada de responsabilidade das coisas para si mesmo.