DOCUMENTO PROTEGIDO PELA LEIDE DIREITO AUTORAL

UNIVERSIDADE CANDIDO MENDES / AVM

PÓS-GRADUAÇÃO LATO SENSU

GESTÃO DE PROJETOS EM TI NO CENÁRIO BRASILEIRO

Por: Eduardo Ney Mattos dos Santos

ORIENTADOR:

Prof. Jorge Tadeu Vieira Lourenço

Rio de Janeiro 2018

UNIVERSIDADE CANDIDO MENDES / AVM

PÓS-GRADUAÇÃO LATO SENSU

Apresentação de monografia à AVM como requisito parcial para obtenção do grau de especialista em Gestão de Projetos.

Por: Eduardo Ney Mattos dos Santos

GESTÃO DE PROJETOS EM TI NO CENÁRIO BRASILEIRO

Rio de Janeiro 2018

AGRADECIMENTOS

A Deus, pois sem ele nada seria possível.

Aos meus pais Gerson e Tânia, pois sempre estiveram comigo em todos os momentos que necessitei, sejam nas alegrias e tristezas.

À minha amada esposa Ana Paula, pela paciência e incentivo nesta dura jornada. Te amo!

Aos meus amados filhos Giulia e Carlos Eduardo. Vocês são tudo para mim!

E em especial, a todos os meus mestres da Faculdade Integrada A Vez do Mestre pela essencial colaboração para à minha formação acadêmica e profissional.

Aos meus colegas de classe pelas trocas de experiências e aprendizado em conjunto.

Ao meu orientador Jorge Tadeu Vieira Lourenço pelo apoio incondicional.

DEDICATÓRIA

Dedico esta monografia aos meus filhos Giulia e Carlos Eduardo, à minha esposa Ana Paula e aos meus pais Gerson Ney e Tania Maria.

RESUMO

Esta monografia tem o objetivo como área de interesse a Gestão de Projetos e a partir desta área de conhecimento, o tema escolhido foi: Porque projetos em TI atrasam tanto. A questão central deste trabalho é identificar porque mais de 80% dos projetos de TI atrasam e como a metodologia ágil pode contribuir para a redução deste cenário. A hipótese principal, é que com a metodologia ágil “Scrum”, podemos realizar pequenos ciclos de tarefas a fim de entregar fases do projeto de forma incremental e possível de implementar em produção. Desta forma, o cliente consegue visualizar a escala de progresso do projeto dentro das expectativas. O objetivo geral é demonstrar que a metodologia ágil pode reduzir drasticamente este cenário e alertar que é uma tendência mundial na área de projetos em TI “Ser Ágil” é o futuro. Os objetivos específicos são: Futuro em Gestão de Projetos em TI, metodologia ágil pode ser benéfico para projetos em TI. O que os gerentes de projetos, analistas de sistemas e clientes pensam e quais as suas expectativas. Baseado neste contexto, a motivação deste trabalho é demonstrar como a metodologia ágil “Scrum” pode contribuir para redução deste problema.

METODOLOGIA

A metodologia apresentada no desenvolvimento da pesquisa desta obra motiva – se à hipótese de resposta no contesto da problemática citada nesta obra.

Todas as informações e dados apresentados neste trabalho serão expostos em referências bibliográficas de textos, forum e artigos da internet, bem como livros e relatórios estatísticos em relação ao problema que motivou a dissertação desta obra.

SUMÁRIO

INTRODUÇÃO 08

CAPÍTULO I

PRINCIPAIS MOTIVOS QUE LEVAM UM PROJETO EM TI ATRASAR 09

CAPÍTULO II

O QUE PENSAM OS GERENTES DE PROJETOS,

OS ANALISTAS DE SISTEMAS, OS CLIENTES

CAPÍTULO III

METODOLOGIA AGIL E O FRAMEWORK SCRUM PODEM

COLABORAR PARA REDUZIR ESTE CENÁRIO

CONCLUSÃO 37

BIBLIOGRAFIA 39

INTRODUÇÃO

Atualmente com a globalização e a velocidade em realizar negócios, é crescente a demanda na área da Tecnologia da Informação. Visto que hoje em dia uma empresa que não existe digitalmente está fadada à falência, por este motivo todo momento inicia – se um novo projeto em TI, porém com a grande velocidade que estes projetos iniciam – se, também sofrem com constantes atrasos e cancelamentos.

No Brasil, este cenário não é diferente, artigos facilmente encontrados na Internet demonstram que mais 80% dos projetos em TI atrasam no país. Como reverter este problema? Quais os fatores que levam a este destino tão complicado?

Esta monografia está estruturada em três capítulos.

No Capítulo 1, pretendemos entender os principais motivos que levam um projeto em TI atrasar.

No Capítulo 2, demonstraremos o que pensam os Gerentes de Projetos, os Analistas de Sistemas e os Clientes contratantes do projeto.

No Capítulo 3, apresentam – se como a metodologia Ágil e o Framework Scrum podem colaborar para reduzir esta triste realidade que assombra o mundo e o nosso país em especial.

Ao final, demonstram – se as conclusões, onde o objetivo é ajudar a solucionar um problema que é tão recorrente nos projetos em TI, reduzindo custo, tempo, aumento de performance, maior assertividade nas entregas, satisfação do Contratante ”cliente”, redução de stress na equipe de analistas de sistemas e melhor condução na gestão de projetos em TI.

CAPÍTULO I

PRINCIPAIS MOTIVOS

QUE LEVAM UM PROJETO EM TI ATRASAR

Muito se fala sobre a febre do momento, “Startup” e com elas os seus projetos com soluções inovadoras e revolucionárias, com essa nova onda o Brasil não poderia ficar de fora é claro, houve uma crescente criação de startup’s no Brasil e com isso, milhares de novos projetos e oportunidades de negócios surgiram.

Isso é muito bom, pois gera mais empregos, aumenta o índice de empregos gerados, estimula a economia do país, reduz o índice de desemprego e o conjunto desses fatores, fazem com que o país cresça e se desenvolva como um todo.

Porém, para se consolidar no mercado e conseguir bons projetos são necessários credencias que demonstram sua capacidade em entregar projetos com qualidade, agilidade, escalabilidade a um custo que não seja estratosférico, desse modo o nosso capitulo irá exemplificar alguns erros que teimamos em continuar a cometê-los.

Em uma pesquisa que criei recentemente “Por que Projetos em TI

Atrasam?”(extraído de

https://docs.google.com/forms/d/e/1FAIpQLSehfrpZB1aeqrkB012CEuDfj11EFbTv-9V9QV8TiXBsy4-ORw/viewform ativo em 20/04/2018, EDUARDO NEY, 2018) para representar e coletar gráficos para compor esta obra, expõem formas bem conhecidas de qualquer Gerente de Projetos experiente de erros grosseiros que por falta de experiência ou falta de preparo para o cargo em Gestão de Projetos em TI podem levar ao fracasso total.

Além de informações importantes para gerentes de projetos, pode – se encontrar nesta pesquisa os gráficos e informações que os analistas de sistemas demonstram pela visão deles, também na mesma pesquisa temos as opiniões dos clientes que são os contratantes dos projetos, quais seus temores e suas expectativas para a entrega do projeto.

Em TI muitos profissionais da área acham que os clientes não sabem o que querem, podem até estar certo na maioria das vezes mas quem trabalha com TI não pode e nem deve trabalhar com hipóteses em Tecnologia da informação tem uma regra bem similar ao “Código Binário” ou é 0 ou 1 ou seja sim ou não é ou não é.

E por quais motivos estes erros grosseiros acontecem? Tudo leva a crer, em alguns principais pontos que irei colocar em formas de itens para melhor visualizamos abaixo.

1.1. Falta de Preparo em Gestão de Projetos de TI

À medida que entramos em um novo milenium, o mercado de TI cresceu de uma forma sem precedentes, projetos que prometiam ser revolucionários e foram um fiasco como por exemplo a criação do Windows Milenium “Um verdadeiro Elefante Branco”, a Internet começa a dar seus primeiros passos em relação ao e-commerce e com isso, muitos administradores de empresa que não tinham a menor experiência com esse novo mercado de TI passaram a gerenciar grandes projetos de Big Data, migração de grandes sistemas corporativos não velando em consideração a opinião de pessoas especializadas “Analista de Sistemas” que olhando por uma visão fria e lógica, deveriam de ser indicados os mais experientes de cada equipe, o promovendo a líder técnico ou gestor de área de negócio ligado a projetos inerente a Gestão de Projetos em TI.

De vez em quando, a vaidade fala mais alto, grandes gestores de finanças, matemática financeira ou até mesmo de engenharia achavam que dariam conta do recado. Se você olhar para 1960 ou 1970 realmente, estes profissionais dariam conta do recado, pois nesta época não existia curso superior de Sistema da Informação, porém como tudo na vida evolui a informática passou a possuir curso como Engenharia de Software, Ciência da Computação e Analise de Sistemas que hoje recebe o nome de Sistemas de Informação.

Desta forma, havia e ainda há pessoas que por terem anos de experiência, porém não voltaram à sala de aula para se reciclar e entender que o mercado já não funciona como 1960, 1970, 1980 ou 1990 possuem cargos de gestores e até CEO de empresas de TI que sequer tem uma Pos – Graduação ou PMP. Trágico não?

Isso parece assustador não é? Mas é a grande realidade, muito se falam hoje em dia em PMBOOK, PMI, modelo de gestão de projetos waterfall.

Vejamos um pouco sobre isso, “PMI – O Instituto de

Gerenciamento de Projetos “Project Management Institute PMI”, é a uma das maiores associações para profissionais de gerenciamento de projetos. Nosso trabalho para a profissão auxilia mais de 700.000 membros, profissionais certificados e voluntários em praticamente todos os países do mundo a aumentar o sucesso das suas empresas, evoluir em suas carreiras e tornar a profissão mais madura.” (extraído de

https://brasil.pmi.org/brazil/AboutUS/WhatisPMI.aspx acessado em 21/04/2018, PMI, 2018)

Esta entidade possui um livro chamado PMBOOK que possui técnicas de como se deve gerência projetos de uma forma eficiente reduzindo

retrabalho atrasos na entrega do projeto e despesas extras com orçamentos do projeto.

Mas como disse antes, muitos de nossos gestores de TI conhecem, mas nunca voltaram para uma sala de aula para ver como funcionar e por em prática de verdade. Apenas ouvir dizer, ou conheço li sobre o assunto mas não por em prática, não adianta nada a prática te leva a perfeição pense nisso.

1.2. Inexperiência em Gestão de Projetos de TI

Existe um lado muito curioso e comum hoje em dia em Gestão de Projetos em TI, profissionais recém-formados que acabam de se formar, já começam uma Pós Graduação, MBA ou Mestrado, sem ao menos terem uma bagagem de experiência profissional. Nenhum tipo de vivência profissional que o leve a adquirir um nível de senioridade, quando este profissional decidir fazer um curso de Pós Graduação, MBA ou Mestrado eles possam ter uma fonte de pesquisa e discernimento para decidir o que é valido ou não para determinado assunto.

Isso provoca geralmente gestores inexperiente, gerenciando projetos e equipes com grau de senioridade elevado ocasionando atritos entre o time de Desenvolvimento e o Gerente de Projeto, logo teremos atrasos, retrabalhos, orçamentos acima do valor estipulado, entregas fora do prazo ou pior o cliente pode perceber este problema e simplesmente cancelar o projeto.

Outro fator que provoca este cenário é a economia equivocada que algumas empresas teimam em fazer com baixos salários para este tipo de gestores sem a experiência e o preparo adequado, deste modo não há como se ter um projeto bem gerenciado com um profissional mal capacitado e com remuneração abaixo do valor adequado.

Só para se ter uma idéia, a faixa salarial de um profissional experiente em Gestão de Projetos varia entre R$ 3.500 a R$ 38.292.

(extraído de https://www.lovemondays.com.br/salarios/cargo/salario-gerente-de-projetos-gp-senior acessado em 20/06/2018, LOVE MONDAYS LTDA, 2018)

A faixa salarial expõe bem no que corresponde ao grau de experiência, logo se você quer um projeto bem conduzido dentro do prazo, dentro do escopo e no orçamento devido, há de concordar que é necessário pagar mais para se ter mais qualidade, certo?

1.3. Falta de Ética em Gestão de Projetos de TI

Para ser um bom gestor de projetos em TI é necessário ser ético, o Código de Éticas do PMI existe para ser seguido como podemos ver abaixo.

“História deste Padrão A visão do PMI em relação ao gerenciamento de projetos como uma profissão independente orientou o nosso trabalho inicial sobre ética. Em 1981, o Conselho de Administração

do PMI formou um Grupo de Ética, Padrões e Certificação. Uma das tarefas era que o grupo deliberasse a respeito da necessidade de um código de ética para a profissão. O relatório da equipe continha a primeira discussão documentada do PMI sobre ética para a profissão de gerenciamento de projetos. Esse relatório foi entregue ao Conselho de Administração do PMI em agosto de 1982 e publicado como suplemento do periódico trimestral sobre gerenciamento de projetos de agosto de 1983. No final da década de 1980, esse padrão se tornou o Padrão de Ética para o Profissional de Gerenciamento de Projetos [PMP ® , Project Management Professional]. Em 1997, o Conselho do PMI determinou a necessidade de um código de ética para membros. O Conselho do PMI formou o Comitê de Documentação de Política de Ética para elaborar e publicar um padrão de ética para os membros do PMI. O Conselho aprovou o novo Código de Ética para Membros em outubro de 1998. Em janeiro de 1999, o Conselho aprovou os Processos para Ações de Membros, definindo um processo para apresentar reclamações sobre ética e determinar se uma infração ocorreu. Desde a adoção do código, em 1998, ocorreram muitas mudanças no PMI e do mundo dos negócios. O número de membros do PMI cresceu significativamente. Também ocorreu muito crescimento em regiões externas à América do Norte. No mundo empresarial, escândalos éticos causaram a ruína de corporações mundiais e sem fins lucrativos, causando a revolta do público e um aumento das normas governamentais. A globalização aproximou as economias, mas trouxe a compreensão de que a nossa prática ética pode diferir de uma cultura para outra. O ritmo rápido e contínuo das mudanças tecnológicas forneceu novas oportunidades, mas também apresentou novos desafios, inclusive novos dilemas éticos. Por essas razões, em 2003, o Conselho de Administração do PMI solicitou que os nossos códigos de ética fossem reexaminados. Em 2004, o Conselho do PMI encarregou o Comitê de Revisão dos Padrões de Ética [ESRC, Ethics Standards Review Committee] de revisar os códigos de ética e desenvolver um processo para a revisão dos códigos. O ESRC desenvolveu processos que estimulariam a participação ativa da comunidade mundial de gerenciamento de projetos. Em 2005, o Conselho do PMI aprovou os processos para revisão do código, concordando que a participação mundial da comunidade de gerenciamento de projetos era essencial. Em 2005, o Conselho também encarregou o Comitê de Desenvolvimento de Padrões de Ética de implementar o processo aprovado e entregar o código revisado até o fim de 2006. Esse Código de Ética e Desenvolvimento Profissional foi aprovado pelo Conselho de Administração do PMI em outubro de 2006.” (extraído de

https://brasil.pmi.org/brazil/AboutUS/EthicsInProjectManagement/~/media/76210A1C41A24B1C A4B9DCF72D5BAB6D.ashx acessado em 27/07/2018 PMI, 2018)

E quantas vezes nos deparamos com situações em que um gestor de projeto está com uma certa dificuldade e em uma situação informal comenta o assunto com outro colega gestor no qual ele o ajuda a achar a solução com uma dica simples que viabiliza o projeto e alavanca o mesmo de uma forma muito rentável, porém o gestor que estava com dificuldades, ao aplicar a

solução colhe os frutos do resultado sozinho sem sequer mencionar o nome do outro colega que o ajudou a viabilizar e alavancar o seu projeto.

O mais correto não seria dividir com o colega gestor os frutos desse resultado e desenvolver uma rotina de lições apreendidas em conjunto?

Isso ajudaria a empresa no futuro caso haja o mesmo problema no futuro, o PMI tem uma termo para este procedimento, chama – se lições apreendidas “Documento contendo conjunto de informações de sucessos

e fracassos do projeto, coletar lições apreendidas e arquivar informações do projeto para uso futuro da organização.” (extraído do PMBook 4ª Edição,

PMI, 2008, p.100)

1.4. Negligência na mitigação dos riscos

Quando não tratamos da mitigação dos riscos, podemos estar gerando retrabalho para o nosso projeto mais à frente. Um exemplo bem recente com relação a este item, foi à falta de uma analise mais apurada nos fatos históricos com relação aos riscos da construção da ciclovia entre São Conrado e o Leblon. Não é um projeto de TI, mas é um projeto e como todo projeto deve – se sempre ser levado em conta fatos históricos ligados a riscos em projetos sejam de TI ou não.

No PMBook, existe um capítulo inteiro sobre esta questão chamado

Gerenciamento dos Riscos do Projeto (extraído do PMBook 4ª Edição, PMI,

2008, p.273).

1.5. Pra quê PMBOOk? Quê raios é PMI?

Ok, vamos pelo começo, a sigla PMI significa Project Management Institute é um instituto sem fins lucrativos que rege as boas práticas em Gerenciamento de Projetos.

“O PMI é a maior associação sem fins lucrativos do mundo para profissionais de gerenciamento de projetos, com mais de meio milhão de associados e de Profissionais Certificados em 185 países. Nosso trabalho ao redor do mundo na divulgação do gerenciamento de projetos tem como base nossos padrões de credenciais mundialmente reconhecidas, nosso constante programa de pesquisa e nossas oportunidades de desenvolvimento profissional. Esses produtos e serviços são a base de um maior reconhecimento e aceitação do papel bem sucedido do gerenciamento de projetos por parte de governos, organizações, academia e indústrias.” (extraído de https://brasil.pmi.org/brazil/AboutUS.aspx

Entendi, acho que deu para entender o que é o PMI, mas e esse tal de PMBOOK? Simples é um conjuntos de regras e boas práticas definidos em forma de processos e procedimentos que o ajudam a entender e melhorar a forma de conduzir projetos, simplificando chamamos de Livro.

Este Guia é constantemente atualizado, a cada 4anos ele passa por atualizações em suas definições e processos são considerados a Bíblia em Gestão de Projetos, todo bom Gerente de Projetos que se preze, alguma vez na vida já leu este livro ou o lê constantemente, afinal se ele é tido como o maior livro de referência em Gestão de Projetos como posso deixar ler? Pois é, mas por incrível que pareça ele ainda é ignorado por muitos.

Outro detalhe importante, o PMI oferece uma prova para que o Profissional em Gestão de Projetos se certifique como PMP “Project Management Professional” esta certificação atesta que tal profissional tem as qualificações necessárias para Gerenciar Projetos seguindo as normas e boas praticas de Gestão em Projetos seguindo as recomendações do PMI.

CAPÍTULO II

O QUE PENSAM OS GERENTES DE PROJETOS, OS

ANALISTAS DE SISTEMAS E OS CLIENTES

Neste capítulo, iremos identificar quais as expectativas, de cada parte interessada do projeto, quais as opiniões de cada um sobre a ótica da Gestão de Projetos em TI, o que é solicitado e o que realmente é entregue ao fim do projeto, assim teremos uma idéia mais contextualizada de quais alguns dos motivos que podem ajudar a identificar alguns problemas que motivam impactos e atrasos em Projetos de TI.

2.1. O que pensam os Gerentes de Projetos?

Todo Gerente de Projeto tem o desejo de entregar um projeto no prazo combinado, dentro do orçamento e com qualidade. Porém nem sempre isso acontece, logo quais serão os motivos que levam a esta enorme dor de cabeça para os Gerentes?

Boa parte deste atraso está atrelada ao que chamamos de “Fraca definição de Escopo”. Esta definição quer dizer que grande parte dos Usuários ou Clientes não sabe expressar seus desejos em um primeiro momento, no decorrer do projeto fazem constantes mudanças no escopo do projeto solicitando ao Gerente de Projeto que não alterem seu cronograma, criando assim retrabalhos, stress desnecessários na equipe de Desenvolvimento do Projeto, aumento nos custos do projeto e deixando o Gerente de Projeto em uma situação constrangedora, pois em alguns casos utilizam – se de sua influência corporativa para compelir o Gerente de Projeto a manter os prazos estipulados no cronograma para que não gerem indicadores de atraso.

O que seria mais recomendado para este fato, nós veremos mais a frente controle sua ansiedade, agora só estamos demonstrando alguns dos muitos problemas que temos em Gestão de Projetos de TI. Por mais absurdo que isso seja, não faz idéia de como isso acontece em Empresas Publicas como por exemplo: Petrobrás, BNDES e tantas outras que conhecemos além é claro de empresas privadas também aquelas principalmente que prestam serviços ao Governo seja federal, estadual e até municipal.

Quem já brincou de telefone sem fio que levante a mão! Pois é, outro fator simples que muitas vezes fazemos sem muitas das vezes sem notar, como por exemplo enviamos aquela mensagem importante para alguém mas esquecemos de checar se a informação foi recebida e compreendida pelo receptor.

Já imaginou você como Gerente de Projeto entregando aquele projeto maravilhoso dentro do prazo, abaixo do custo esperado com uma qualidade seis sigma, mas que na hora de realizar o encerramento do projeto

com aquela festa com toda a diretoria da empresa e você esqueceu de checar se a acessória de imprensa da empresa divulgou ao público e a imprensa especializada no segmento do Projeto que você acabou de entregar.

Abaixo temos um gráfico retirado dos resultados coletados da pesquisa “Por que Projetos em TI Atrasam?”

Figura 1 – Por que Projetos em TI Atrasam? (extraído de

https://docs.google.com/forms/d/e/1FAIpQLSehfrpZB1aeqrkB012CEuDfj11EFbTv-9V9QV8TiXBsy4-ORw/viewform ativo em 20/04/2018, EDUARDO NEY, 2018)

Outra analise que gera muito stress, mas desta vez é entre o Gerente de Projeto e Analista de Sistemas é a qualidade na codificação dos projetos em TI que se entregam no Brasil.

Como já sabemos, mais de qualidade em tudo que se faz é um diferencial e em projetos em TI não é diferente, muito se cobra por parte da Gerência em relação aos Analista de Sistemas é a qualidade no código, porém o que muitos Gerentes de Projetos identificam é a falta de comprometimento por parte dos Analista de Sistemas com falta de Padrões de Projetos, uma definição de arquitetura na construção dos projetos de forma clara e de fácil entendimento por parte dos clientes e não aquela chuva de termos técnicos que só os Analistas de Sistemas entendem e os demais envolvidos ficam boiando.

Como esta falta de qualidade pode afetar o projeto? Bom, se existe falta de qualidade no desenvolvimento de um projeto, você terá retrabalho e com isso atrasos em seu cronograma tendo que refazer trabalhos que já deveriam ter sido entregue em entregas anteriores, com isso o Gerente tem que reorganizar seu cronograma e aumentando o tempo de entrega de seu projeto, logo futuro projeto sendo entregue fora do prazo e com orçamento estourado por conta de retrabalhos por conta de má qualidade na codificação.

Não é só isso, temos também casos em que a equipe de desenvolvimento não segue o que está especificado no escopo do projeto.

Codificam funcionalidades que as vezes nem estava definida na documentação do projeto isso acarreta em? Bingo atraso e retrabalho, pois o cliente irá dizer “Eu não pedi isso!” e o Gerente de Projeto ficará vendido sem ter como justificar o atraso e pior, como ele irá se explicar a alta cúpula de Gestores que viabilizaram o projeto?

Pois é vida de Gerente de Projeto é difícil, entretanto se ele for esperto ele tem como evitar tais situações, veremos isso no capitulo a frente controle sua ansiedade.

2.2. O que pensam os Analistas de Sistemas?

Pois bem, vimos acima o que os Gerentes de Projetos pensam com relação a atrasos de Projetos em TI agora chegou à vez de quem faz a mágica acontecer Gerente de Projeto é como se fosse o maestro da orquestra, mas quem dá o espetáculo é a Orquestra não?

Então vamos lá, o gráfico abaixo demonstra um percentual de 42,9% de Analista de Sistemas e 28,6% de Arquitetos de TI que também está inserido no contesto de Analista de Sistemas e ou Desenvolvedores que responderam a pesquisa “Por que Projetos em TI Atrasam?”

Figura 2 – Por que Projetos em TI Atrasam? (extraído de

https://docs.google.com/forms/d/e/1FAIpQLSehfrpZB1aeqrkB012CEuDfj11EFbTv-9V9QV8TiXBsy4-ORw/viewform ativo em 20/04/2018, EDUARDO NEY, 2018)

A estes profissionais, fora perguntado o que na visão deles quais fatores contribuem para que os projetos de TI atrasem. Alguns temas que já vimos aqui foram bastante citados.

Como por exemplo: Escopo do Projeto mau definido, Fraca definição das funcionalidades do Projeto e o que ele realmente deverá fazer, mas o que muitos informaram é que o cliente não tem a menor idéia o que realmente deseja com isso, o cliente pressiona o Gerente de Projeto solicitando mudanças no projeto em tempo Record, que por sua vez o Gerente de Projeto solicita a equipe de Desenvolvimento que acatem a solicitação o que gera? Surpresa! Mais retrabalhos atrasos, horas extras, aumento nos custos do projeto além do aumento do nível de stress na Equipe de Desenvolvimento.

Outro fato que os Analistas de Sistemas alegam, é a falta de tempo para atualização na documentação das funcionalidades do Projeto para que fiquem aderentes ao que fora solicitado pelo Cliente.

A falta de tempo consiste em prazo apertado para a entrega da solicitação de mudança que o Cliente havia solicitado e o que ainda resta para implementar no projeto e que não afetem os prazos acordados entre o Cliente e o Gerente de Projeto.

Pois bem, na visão dos Analistas e Desenvolvedores, Escopo de Projetos mau definidos consiste em Planejamento equivocado por Parte de Gerentes de Projetos inexperientes para a função, não gerenciar as expectativas do cliente com relação ao que é esperado e o que realmente de fato é entregue estes itens assim como outros tantos itens tem que está bem claro, uma definição de fácil compreensão por conta do cliente na Definição de Espoco do Projeto. Neste quesito é de suma importância para delimitar o que o projeto tem de atender, quais normas seguir, que prazo cumprir, quais impactos ocorrerá em um eventual atraso, quais as consequências caso isso ocorra e qual solução de contorno.

Documentação fraca? O que é isso? É um termo usado por muitos Desenvolvedores e Analistas para exemplificar que um documento de Requisitos de Funcionalidade de Sistema ou um documento de Caso de Uso está mau feito ou com poucas definições para que a construção da funcionalidade seja possível de ser implementada. Um entendi, mas isso não é de responsabilidade de um Analista de Negócios que também compõe a figura de Analista de Sistemas assim como o Arquiteto de Sistemas?

Sim de fato, porém em algumas situações a esta questão é levado ao Gerente de Projetos que por sua vez é levado ao cliente e ele informa que é para ser implementado este jeito mesmo e em muitos casos até formalizam em forma de documentos que é para acatar o que está redigido na documentação de Caso de Uso ou Requisitos de Sistemas.

Já sabemos o resultado desta mistura explosiva não! Atrasos, horas extras para alterar as documentações com relação ao projeto, nível de stress da equipe elevado e o pior aumento na rotatividade da equipe e senso de estar andando em círculos.

Coisas assim levam um projeto à beira do caos, aumenta o nível de curva no aprendizado, pois a rotatividade da equipe aumentando, fatalmente os profissionais mais experientes nas equipes terão de parar o que estão fazendo para ajudar o novo integrante da equipe a conhecer toda a rotina do projeto, isso demanda tempo atraso na entrega e consequentemente alterações no cronograma, no planejamento da condução do projeto e alterações na definição do escopo do projeto.

Um item que na visão dos Analistas e Desenvolvedores muitos clientes não viabilizam por achar que qualquer PC é capaz de ajudar o Analista fazer a tarefa é constantemente feito. Exemplo: Um Analista Desenvolvedor Java que geralmente Roda um IDE Eclise, Servidor de Aplicação JBOSS e outras coisinhas mais que consomem bastante poder processamento do processador e muita memória. Dão a ele um PC 486 com 512MB de memória e um processador Pentium 2.

Entendeu onde quero chegar? É fato que não vai prestar concorda! Pois bem, muitos Clientes e Gerentes achando que já gastou muito na parte de Gestão de Aquisição com relação a contratações esquecem de viabilizar equipamento adequado para a execução do trabalho e impactando em todo ciclo do projeto como entregas, prazos em fim “Caos”.

2.3. O que pensam os Clientes?

Segundo dados da pesquisa “Por que Projetos em TI Atrasam?”, o gráfico

abaixo demonstra as expectativas dos Clientes com relação a entrega do projeto.

Figura 3 – Por que Projetos em TI Atrasam? (extraído de

https://docs.google.com/forms/d/e/1FAIpQLSehfrpZB1aeqrkB012CEuDfj11EFbTv-9V9QV8TiXBsy4-ORw/viewform ativo em 20/04/2018, EDUARDO NEY, 2018)

O gráfico acima demonstra bem os percentuais de Cliente e Usuários que sabem o que querem e conhecem do negocio ao qual estão

inseridos e outros que não tem a idéia concreta do que querem e alteram constantemente o espoco do projeto.

Interessante não? Pois se fizermos uma reflexão do percentual de projetos que atrasam no Brasil com relação deste gráfico iremos notar por qual motivo eles atrasam. Mas o que estes gráficos querem dizer em relação ao sentimento dos Clientes e ou Usuários.

Muitas das vezes eles necessitam de auxilio por parte dos Gerentes de Projetos para melhor definir as ordens de prioridades das demandas e assim definir melhor o escopo do projeto e quais são os caminhos críticos, entretanto quando isso não acontece, eles se sentem perdidos e muitas das vezes por falta de experiência de um Gerente de Projetos, o mesmo ordena que o Cliente alinhe seus desejos diretamente com a equipe técnica.

Com isso a equipe técnica fica sobre carregada tendo que definir as prioridades do espoco das demandas com o cliente quando deveriam estar trabalhando em cima do escopo definido anteriormente gerando carga excessiva de trabalho por má definição de escopo do projeto. Pois bem, os Clientes necessitam de atenção por parte dos Gerentes com relação as expectativas ligadas ao projeto afinal eles querem ser surpreendidos.

Quando 85,7% dos Clientes dizem que querem que faça coisas além das expectativas deles, não querem dizer que tem que ser feito coisas que não estão no escopo do projeto, mas tem haver com a qualidade do projeto que se entrega ao cliente.

Quem de um modo geral, nunca teve aquela expectativa de receber aquele produto que fora solicitado atendendo todas as especificações de acordo com o escopo do projeto, mas que fizesse você ficar de boca aberta com a qualidade de como foi feito. Um exemplo clássico de coisas assim são lançamentos de automóveis não?

Você tem um carro que já tem 10 anos de uso e quando sai o modelo do ano com mesmo nome e fabricante do seu carro, mas quando colocamos lado a lado parece que estamos falando de carros completamente diferentes. É isso que os Clientes querem, ser surpreendido e não precisa custar mais nem ter retrabalho.

Se tivermos um pouco mais de cuidado na gestão e controle das expectativas dos Clientes, com toda certeza teremos um projeto de grande sucesso.

Quando um Cliente solicita qualquer coisa ligado ao projeto, escute com atenção veja qual o grau de importância que ele tem no projeto, pois ele pode alavancar o projeto ou fazê – lo atrasar e as vezes até engavetar o projeto por ser não favorável ao projeto. Muitos clientes quando estão em uma reunião com a equipe técnica e o Gerente de Projetos geralmente vão pré - dispostos ao não favorecimento do projeto.

Mas por qual motivo isso acontece? Como vimos anteriormente, por não se sentirem no contesto do projeto, não receberem feedback constantes do que está ocorrendo na evolução do projeto, por não ser questionados com relação as expectativas do que está sendo feito no projeto, pela falta de sensibilidade do Gerente em não saber quais são os seus temores e anseios a falhas nas entregas do projeto.

Muitos Clientes também questionam a forma como a equipe técnica os tratam julgando – os como se eles soubessem termos técnicos que só a equipe de desenvolvimento conhecem afinal eles estudaram para isso.

Clientes são importantes para divulgar e recomendar novos projetos para empresas parceiras, porém segundo relatos de muitos deles, as firmas de consultorias de TI insistem em vender um “Iate e entregar uma canoa furada cheia de remendos” não dá para entender como ainda em 2018 empresas de consultorias de TI agem desta forma.

Na opinião dos Clientes, o que pode ser feito para melhorar este cenário? Quase 100% afirmam que o problema está na forma como o projeto é conduzido por falta de acompanhamento do Gerente no que está sendo feito e o que está sendo entregue para o cliente como falta de qualidade, código mau implementado e muitas das vezes dados fake colocados nas telas para enganar o contratante do Projeto no caso os Usuários.

2.4. Consideração e consenso das Partes

Para termos uma sinergia e um sentimento único de equipe todos concordam que há a necessidade de existir uma forma ou metodologia de trabalho que seja mais dinâmica eficiente que deixe de ser a famosa “Waterfall” Projetos em Cascada e torne – se algo mais ágil e dinâmico de fácil compreensão de todos. Estamos em 2018 e não podemos nos prender a métodos e framework’s de trabalhos de 1960, 70, 80. Estas considerações estão na linha de raciocínio tanto dos Gerentes de Projetos, quanto equipe de Desenvolvimento além dos Clientes.

CAPÍTULO III

METODOLOGIA AGIL E O FRAMEWORK SCRUM

PODEM COLABORAR PARA REDUZIR ESTE CENÁRIO

Neste capítulo, vamos enteder o que é o Framework Scrum, o quando ele pode ser benéfico para um projeto de TI e qual é o grande diferencial deste poderoso Framework que compõem a metodologia Ágil.

Seus criadores, Jeff Sutherland e Ken Schwaber tiveram uma grande saca há mais de vinte anos atrás, uma maneira eficiente e mais rápida de desenvolver softwares na industria de tecnologia de forma que fossem separados por períodos “Sprint’s”. Isso permite que o projeto seja entregue de forma incremental, empírico, reduzindo os custos, tempo gastos no projeto além de gerenciar melhor as expectativas do Cliente e trazendo o cliente para dentro do projeto controlando suas expectativas com relação a entrega.

3.1. O que é a metodologia ágil

“Método ágil é uma expressão que define um conjunto de metodologias utilizadas no desenvolvimento de software. As metodologias que fazem parte do conceito de desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software”.

(extraída de

https://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software

acessado em 11/08/2018, WIKIPEDIA, 2018)

Muitos framework's estão inseridos nesta metodologia tais como: SCRUM, XP “eXtreme Programming” e outros. Estes framework's passaram a ter grande credibilidade a partir de que o próprio FBI comprovou sua

eficiência utilizando o framework SCRUM, Conforme relatado pelo próprio Jeff Sutherland em seu livro “O FBI em 2005 anunciou um novo programa chamado Sentinel” (extraído de JEFF SUTHERLAND, SCRUM a arte de

fazer o dobro do trabalho na metade do tempo, pág. 12, 2016) o que dera

errado neste projeto após a avalidação do Jeff Sutherland, foi que mesmo após as lições apriendidas seguindo a regra do PMBOOK, toda a estrutura de desenvolvimento estava em cascata seguinto um fluxograma de 1910 criado por Henry Gantt.

Obviamente não foi feito seguindo este fluxograma de 1910 a risca, porém em homenagem a seu criador Henry Gantt, na década de 1980 com o bum dos computadores pessoais, tornou-se fácil criar estes gráficos seguindo este fluxograma que hoje em dia os chamamos de Microsoft Project.

Esta ferramenta se baseia neste mesmo fluxograma gerando gráficos em cascata seguindo uma linha de base para informar a sequência de trabalho em forma de cascata, informando se está em atraso ou adiantado.

Até o momento da analise de Jeff Sutherland, o projeto Sentinela já tinha gasto nada mais nada menos que 405 milhões de dólares do orçamento, desenvolvera apenas metade do projeto que já estava com um ano de atraso. Um valor bem significativo dos contribuintes americanos já que o valor gasto a mais já tinham passado do orçamento em mais de 350 milhões de dólares.

Com o framework SCRUM sobre o comando de Jeff Sutherland como diretor técnico da equipe responsável pelo desenvolvimento do programa Sentinela, fora entregue com 20 milhões dos restantes do recurso em um prazo de 12 meses. Olhando assim, parece locura só que o framework SCRUM é baseado no impirismo e incremental ao qual se determina um período para executar as tarefas e ao termino deste período tudo que fora desenvolvido até aquele momento é capaz de ser entregue e utilizável em um ambiente de produção, livres de bugs e escalável.

3.2. O que é o SCRUM e para que ele serve?

Scrum é um Framework que faz parte da metodologia ágil, é impírico e incremental. Um framework dentro do qual pessoas podem tratar e

criativamente entregam produtos com o mais alto valor possível. Scrum é: leve, simples de entender e difícil de dominar. Scrum é um framework estrutural que está sendo usado para gerenciar o trabalho em produtos complexos desde o início de 1990. Scrum não é um processo, técnica ou um método definitivo. Em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa de suas práticas de gerenciamento de produto e técnicas de trabalho, de modo que você possa continuamente melhorar o produto, o time e o ambiente de trabalho.

O framework Scrum consiste de times Scrum associados a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras do Scrum integram os papéis, eventos e artefatos, administrando as relações e interações entre eles.

(extraído de

http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf acessado em 15/08/2018, SCRUM.ORG, 2018)

Scrum é uma nova forma de gerenciar projetos, ao qual não se tem uma figura com a nomenclatura Gerente de Projetos, mas sim um líder servo que é capaz de identificar os problemas, remover os impedimentos apontados pela equipe de desenvolvimento, auxiliar o Dono do Produto(PO) a identificar quais são os itens de maior prioridade no Backlog do projeto além de blindar a equipe de desenvolvimento a fotores externos como solicitações da alta diretoria, membros de outras equipes que não estão integradas ao projeto este lider servo atende pelo nome de Scrum Master.

3.3. Usando o Kanban no SCRUM

Kanban é um termo de origem japonesa que tem seu significado

Seu primeiro caso de sucesso foi na Toyota para o Sistema Toyota de Produção desenvolvido por Taiichi Ohno que um dos conceitos

chave apresentou, foi a ideia de fluxo. Com isso a produção deveria fluir calma e rápida seguindo o cartão é colocado indicativos como: To do, Doing e Done. Abaixo, temos um gráfico de exemplo como é implemendado nas empresas o sistema Kanban no decorrer das Sprint's para entrega de um produto.

.Figura 4 – Quadro Kanban (extraída de

http://agilitaconsultoria.com.br/como-o-kanban-pode-ajudar-na-sua-empresa/ acessado em 11/08/2018)

Desta maneira, a equipe de desenvolvimento e toda equipe Scrum é capaz de identificar de forma clara e transparente o andamento da Sprint o que há a fazer, o que está sendo feito e o que está pronto.

3.4. Como funciona o Scrum

Projetos que utilizam framework SCRUM, possuem alguns rituais ao qual são importante serem seguidos no qual descreveremos abaixo.

DOD – Definition of Done, antes que aja a planning é recomendado que a Sprint tenha um propósito, no qual o PO com o auxilio do Scrum Master define quais os itens devem ser considerados prioritários dentro de um Backlog da Sprint e em qual nível a definição de pronto é considerada aceita pelo PO. Exemplo: Uma tarefa será aceita como Done se for testada e entregue em ambiente de homologação.

Planning – Cerimônia de planejamento do que será feito na Sprint no qual a equipe de desenvolvimento em conjunto com o PO entram em acordo

do que pode ser atendido dentro de um prazo de tempo para a Sprint. Exemplo: A equipe de desenvolvimento identificou que em um prazo de duas semanas de Sprint poderá atender quinze das vinte demandas estipuladas pelo PO para a Sprint. O PO redefini quais os itens de backlog da sprint são mais importantes e as priorizam para que a equipe de desenvolvimento façam. Afinal, quem irá fazer as tarefas é a equipe de desenvolvimento, logo no SCRUM quem dá o prazo é quem faz a coisa acontecer e cabe ao SCRUM Master fazer com que o PO entenda esta questão. O tempo máximo para uma Sprint de quatro semanas é de 8 horas.

Figura 5 – Imagem de uma Sprint (extraída de

http://testingfreak.com/wp-content/uploads/2014/12/agile2.png acessado em 15/08/2018)

Sprint – É o tempo que é estipulado pelo PO para que os itens de backlog da sprint sejam feitos. Recomenda – se que uma sprint dure no máximo 4 semanas e não mais que isso. Entretanto, o volume de trabalho de cada sprint “itens do backlog da sprint” são definidos pela equipe de desenvolvimento e o Dono do Produto “P.O”. A imagem acima demonstra como é o comportamento de uma sprint, compondo o produto, a sprint, daily diária de 15 minutos por dia e por fim o done informando que todos os itens da definição de pronto foi contempla e assim podendo ser definida como feita.

Figura 6 – Imagem do Backlog (extraída de

https://image.slidesharecdn.com/scrum-evoluocontnua-150909055655-lva1-app6891/95/scrum-evoluo-contnua-20-638.jpg?cb=1441778308 acessado em

15/08/2018)

Backlog do Produto – Lista de tarefas ao qual o PO é responsável por gerenciar e definir quais são as de maior valor “ROI” para o projeto. Isso permite o Dono do Produto “P.O” visualizar, alterar, incluir e até retirar a ordem de prioridade das tarefas que serão levadas para a próxima sprint.

Figura 7 – Imagem Itens do Backlog da Sprint – (extraída de https://scrumorg-

website-prod.s3.amazonaws.com/drupal/inline-images/2017-03/SprintBacklog_0.png acessado em 15/08/2018)

Item de backlog da Sprint – Item de tarefa que está inserido dentro de uma sprint corrente. Significa que o volume de atividades uma determinada sprint terá, estes itens são mensurados entre o Dono do Produto e a equipe de desenvolvimento.

Definição de esforço e tempo para a atividade – quando a equipe de desenvolvimento estima os prazos das atividades, utilizam – se de várias formas para mensurar o tamanho da duração da atividade podemos citar duas formas:

Figura 8 – Imagem Planning Poker (extraída de

https://danielettinger.files.wordpress.com/2015/07/img_2627.png acessado em

16/08/2018)

Planning poker ou em português “Poker do planejamento”, é uma técnica baseada no consenso para estimar, é um jogo e ao mesmo tempo um exercício. Através dessa técnica podemos estimar o esforço necessário para determinada quantidade de trabalho, tendo como base informações recolhidas do cliente, normalmente sendo, através de estórias de usuário.O planning poker foi definido e nomeado pela primeira vez por James Grenning, em 2002, e mais tarde popularizado por Mike Cohn, no livro Agile Estimating and Planning. De maneira resumida, no planning poker cada membro da equipe recebe um conjunto de cartas, com os valores de uma determinada seqüência.

Em seguida, a cada estória de usuário analisada, cada membro da equipe joga uma carta com a face para baixo sobre a mesa, nela estará contido o valor numérico de pontos que o mesmo considera justo para que a estória seja concluída. Caso haja grandes diferenças entre as cartas jogadas, os membros que jogaram as cartas de maior e menor valor explicarão suas razões e, então, com base em suas explicações, as cartas são jogadas novamente até que um consenso seja encontrado e uma estimativa seja definida.

Seqüência Fibonacci, como citei anteriormente, as cartas possuem uma sequência de valores, que podem ser uma sequência simplificada (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) ou uma sequência de Fibonacci. De acordo com a Wikipédia, a sucessão de Fibonacci ou sequência de Fibonacci é uma

sequência de números naturais, onde os dois primeiros números começam normalmente por 0 e 1, na qual, cada termo subsequente corresponde a soma dos dois anteriores

Figura 8 – Imagem do P.O (extraída de

https://www.agivetta.com/images/cspo-1.png acessado em 16/08/2018)

PO – Abreviatura de Produt Owner “Dono do Produto” é responsável pelo gerenciamento dos itens de backlog do Produto priorizando – os para que se tornem itens de backlog da sprint.

Figura 9 – Imagem Scrum Máster (extraída de

Scrum Master – Figura responsável por blindar a equipe de desenvolvimento a fatores externos ao projeto, remover impedimentos apontados pela equipe de desenvolvimento e auxiliar o PO na priorização dos itens de backlog do produto.

Figura 10 – Imagem Daily (extraída de

http://www.xqa.com.ar/visualmanagement/wp-content/uploads/standup2.jpg

acessado em 17/08/2018)

Daily – Reunião diaria onde todos do time de desenvolvimento devem participar de pé e que não dure por mais de quinze minutos.

Figura 11 – Imagem Sprint Review (extraída de http://www.agile-scrum.be/wordpress/wp-content/uploads/2014/08/AGILE-SCRUM-VISUAL.jpg

acessado em 17/08/2018)

Sprint Review – Reunião onde todo o time SCRUM (SCRUM Master, PO e Time de Desenvolvimento) se reunem para descobrir o que foi feito e o que podemos fazer para melhorar nas Sprint's futuras. Seu tempo de duração é de três horas para uma Sprint de 4 semanas.

Figura 12 – Imagem Retrospectiva da Sprint (extraída de

http://www.luiztools.com.br/wp-content/uploads/2016/08/Sprint-Retrospective-300x166.png acessado em 18/08/2018)

Encerramento da Sprint – Reunião para colher o feedback do PO com relação a condução da Sprint onde todo Time SCRUM participa e seu tempo em horas é de 2 horas para uma Sprint de 4 semanas.

Conforme o tempo de duração de uma Sprint, estes valores em horas podem variar para menos à medida em que a Sprint tem um tamanho menor do que uma Sprint de quatro semanas.

3.5. Burndown chart

É um gráfico de queima de tempo ao qual demonstra em forma de horas o quanto de tempo gasto já fora utilizado dentro de uma Sprint. Podemos verificar conforme quadro abaixo uma forma de repesenta – lo.

Figura 5 – Figura Ilustrando o grafico Burndown (extraída de

https://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png

acessado em 18/08/2018)

3.6. Burnup chart

Criado para fornecer status do projeto como um topo não apenas da Sprint, como no caso do gráfico burdown. Conforme imagem abaixo, podemos ver um exemplo deste gráfico que nos dá uma visão macro do projeto.

Figura 6 - Figura Ilustrando o grafico Burnup (extraída de

https://www.inflectra.com/HelpViewer/GraphicsViewer.ashx?name=Spira-5-4-User-Manual&image=wordml://03000173.png acessado em 18/08/2018)

Como vimos neste capítulo, o Framework Scrum demonstra como ele consegue reduzir o grau de ansiedade do Clientes Donos do Projeto, trazendo para o cenário da construção do projeto, participando ativamente nas decisões ligadas ao que será construído primeiro, trabalhando junto com a equipe de desenvolvimento do projeto agilizando as tomadas de decisões e aumentando a celeridade dos afazeres dentro de um ciclo de desenvolvimento “sprint”.

Vimos também que no Framework Scurm, o Scrum Master substitui a figura do gerente de projetos, o Scrum Máster tem uma posição gerencial, porém diferente do papel do Gerente de Projetos que conduz o projeto de uma forma mais em sequenciamento, o Scrum Máster conduz o projeto de forma mais dinâmica, removendo todo e qualquer problema que possa atrapalhar a equipe de desenvolvimento durante a sprint corrente.

Scrum Master é um líder servo que está preocupado com o que a equipe de desenvolvimento necessita e blindando a equipe contra fatores externos ao projeto e ao andamento da sprint.

Notamos que a equipe de desenvolvimento é autogerenciável multidiciplinar composta segundo o Guia Scrum Book entre três e nove pessoas onde todos são capazes de realizar todas as tarefas inerentes ao projeto ao qual estão inseridos. Isso aumenta a produtividade, reduz atritos motivados pela síndrome do egocentrismo, pois uma vez que temos profissionais com o mesmo nível de capacidade para a realização das tarefas ligados ao projeto. Logo, não há maneira de um dizer que é melhor que o outro. A equipe de desenvolvimento não tem atritos com o gerente de projetos com no método tradicional, pois no Framework Scrum o Scrum Master está inserido no projeto para ajudar a equipe de desenvolvimento a obter os resultados esperados e não ordenar o que vai ou não ser feito.

Tal tarefa é de responsabilidade do Dono do Projeto em conjunto com a própria equipe de desenvolvimento, isso é bom, pois permite quem vai fazer as demandas do projeto alinhar com o Cliente e estabelecer um tempo razoável para execução das demandas atreladas a sprint.

CONCLUSÃO

A obra em questão buscou apresentar como podemos identificar por quais motivos os projetos em TI atrasam no cenário Brasileiro, quais são as opiniões das partes envolvidas no projeto, quais as melhores formar de identificar os problemas e técnicas para condução de um Projeto em TI.

No Capítulo 1, verificamos que as principais causas que levam os projetos de TI atrasar.

No Capítulo 2, foi demonstrado o que pensam os Gerentes de Projetos, os Analistas de Sistemas e os Clientes contratantes do projeto.

No Capítulo 3, demonstramos a metodologia Ágil e o Framework Scrum são benéficos para a Gestão do Projeto em TI e a colaboração para reduzir o tempo gasto na condução dos projetos reduzindo atrasos e cancelamentos dos projetos em TI.

O ponto central deste trabalho, ajuda a esclarecer que o Framework Scrum é benéfico para a condução de gestão de projetos tende a reduzir a ansiedade dos donos dos projetos “Clientes”, melhora em nivela tecnicamente os participantes do projeto, a figura do gerente de projeto não existe e sim um líder servo “Scrum Master” que remove qualquer impedimento que venha atrapalhar a condução do projeto, diminuindo o stress da equipe e elevando a capacidade de entrega da equipe aumentando seu nível de autogerenciamento.

Concluímos que em projetos de TI padrões de projetos em efeito cascata “waterfall project management” não é o mais indicado para projetos em TI, logo se você pensa em gerenciar projetos de TI fazendo planilha em Excel e estimando suas tarefas no Project, esqueça pois você estará fadado ao insucesso atrasos e custos elevados além de correr o risco de ter seu projeto cancelado pelo patrocinador do seu projeto.

Procure seguir o PMBook em conjunto com o Scrum Book, pois o PMBook tem processos que ajudam a vizualizar determinadas situações

quando você está indo pelo caminho errado e o Scrum Book te mostra como aplicar estes processo na metodologia ágil.

O Framework Scrum e o Scrum Book não substitui o PMBook e sim segue uma linha similar ao do PMBook, porém de uma forma mais dinâmica sem tantas seqüências matriciais.

Portanto se você quer saber sobre Gerenciamento do Risco, dê uma olhada no PMBook e se você quer saber como priorizar uma demanda em Projetos de TI olhe o Scrum Book.

Com toda certeza essas duas ferramentas de Gestão de Projetos irão fazer você chegar no objetivo de uma forma tão eficiente que você mudará a maneiro de conduzir seus projetos em TI.

BIBLIOGRAFIA

ABNT. Referências Bibliográficas. Rio de Janeiro, 2001.

ABNT. Apresentação de citações em documentos. Rio de Janeiro, 2001.

Um Guia do Gerenciamento em Projetos, PMBook 4ª Edição 2008.

Scrum: a arte de fazer o dobro do trabalho na metade do tempo, Jeff Sutherland 2ª edição 2016.

Media salarial de Gerente de Projetos -

https://www.lovemondays.com.br/salarios/cargo/salario-gerente-de-projetos-gp-senior

Um pouco sobre PMI - https://brasil.pmi.org/brazil/AboutUS/WhatisPMI.aspx

Historia do Código de ética -

https://brasil.pmi.org/brazil/AboutUS/EthicsInProjectManagement/~/media/7621 0A1C41A24B1CA4B9DCF72D5BAB6D.ashx

Desenvolvimento ágil de software -

https://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software

Guia do Scrum - http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf

Imagem kamban - http://agilitaconsultoria.com.br/como-o-kanban-pode-ajudar-na-sua-empresa/

Imagem Burndown -

Imagem Burnup -

https://www.inflectra.com/HelpViewer/GraphicsViewer.ashx?name=Spira-5-4-User-Manual&image=wordml://03000173.png

Imagem Planning Polker

https://danielettinger.files.wordpress.com/2015/07/img_2627.png Imagem Sprint http://testingfreak.com/wp-content/uploads/2014/12/agile2.png Imagem Backlog https://image.slidesharecdn.com/scrum-evoluocontnua-150909055655-lva1-app6891/95/scrum-evoluo-contnua-20-638.jpg?cb=1441778308

Imagem Item de backlog da Sprint

https://scrumorg-website-prod.s3.amazonaws.com/drupal/inline-images/2017-03/SprintBacklog_0.png Imagem do PO https://www.agivetta.com/images/cspo-1.png Imagem da Daily http://tecnologia.culturamix.com/blog/wp-content/gallery/daily-scrum-perguntas-5/Daily-Scrum-Perguntas-8.jpg

Imagem da Sprint Review

http://www.agile-scrum.be/wordpress/wp-content/uploads/2014/08/AGILE-SCRUM-VISUAL.jpg

ÍNDICE

PRINCIPAIS MOTIVOS QUE LEVAM UM PROJETO EM TI ATRASAR 09 1.1. Falta de Preparo em Gestão de Projetos de TI 10 1.2. Inexperiência em Gestão de Projetos de TI 11 1.3. Falta de Ética em Gestão de Projetos de TI 11 1.4. Negligência na mitigação dos riscos 13 1.5. Pra quê PMBOOk? Quê raios é PMI? 13

CAPÍTULO II

O QUE PENSAM OS GERENTES DE PROJETOS, OS ANALISTAS DE

SISTEMAS, OS CLIENTES 15

2.1. O que pensam os Gerentes de Projetos? 15 2.2. O que pensam os Analistas de Sistemas? 17 2.3. O que pensam os Usuários e ou Clientes? 19 2.4. Consideração e consenso das Partes 21

CAPÍTULO III

METODOLOGIA AGIL E O FRAMEWORK SCRUM PODEM COLABORAR

PARA REDUZIR ESTE CENÁRIO 22

3.1. O que é a metodologia ágil 22

3.2. O que é o SCRUM e para que ele serve? 23

3.3. Usando o Kanban no SCRUM 24

3.4. Como funciona o Scrum 25

3.5. Burndown chart 33

3.6. Burnup chart 34

CONCLUSÃO 37