Buscar

Estudo de caso - Gerenciamento ágil de projetos

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 6 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 6, do total de 6 páginas

Prévia do material em texto

Gerenciamento Ágil 
de Projetos
Estudo 
de Caso
Professor: Reginaldo Aparecido Carneiro
2
Unicesumar
estudo de 
caso
Sobre a Caracterização do Caso, Corforme 
Manual.
Classificação do caso: tomando por base a classificação de Gil (2004), o caso é classificado 
como análise, pois tem por objetivo desenvolver a capacidade analítica do estudante com 
relação ao conteúdo do livro.
Dimensões de análise: o caso tem um grau de complexidade baixa, pois apresenta um 
cenário que pode ocorrer no cotidiano das empresas e que levam a tomadas de decisão em 
como gerir um projeto de maneira ágil. Pede-se do estudante, o estudo dos processos de 
gestão ágil de projetos, bem como a análise de situação-problema para a aplicação prática 
das técnicas estudadas na disciplina.
Caso da Empresa “X1 Distribuidora” na Imple-
mentação do Sistema de Gestão Empresarial 
Customizada
Em 2010, a empresa X1 Distribuidora iniciou um projeto de implantação de um novo sistema 
de gestão empresarial. A empresa buscava no mercado uma implementadora que tivesse 
uma solução bastante aderente ao processo da empresa, mas que também fosse possível 
customizar algumas partes do sistema que eram bem específicas. Uma vez selecionada, a 
empresa que apresentou a melhor proposta, deu-se início ao projeto. 
O projeto começou em março de 2010 da maneira tradicional de gestão de projetos, 
cuja montagem de todo o planejamento do projeto seguia as melhores práticas segundo o 
PMBOK. Havia um escopo contratado, tanto da parte que seria implantada da maneira que 
o sistema atendia como a parte que seria customizada. A primeira etapa do projeto foi a de 
levantamento de requisitos, depois, a prototipação, o desenvolvimento, os testes unitários, 
os testes integrados e, assim, partiria para a capacitação dos usuários finais e, por fim, dado 
o go-live (entrada em produção) em paralelo, em que o sistema anterior continuaria sendo 
utilizado e o novo sistema sendo executado em paralelo durante 1 mês para depois desligar 
o sistema antigo. A implantação seria no estilo “Big Bang”, no dia X, ou dia do Corte, todos os 
módulos do sistema entrariam em operação.
Unicesumar
3
estudo de 
caso
O projeto, inicialmente, estava planejado para ser entregue em 10 meses, ou seja, em 9 
meses o sistema entraria em produção e mais 1 mês de execução em paralelo, para estabi-
lização do novo sistema. Um prazo bastante ousado, mas com base nas estimativas iniciais 
e no escopo contratado, seria perfeitamente possível.
A primeira fase, a de levantamento de requisitos, planejada para durar 3 meses começou 
em abril (após 1 mês de planejamento). Iniciada essa etapa, começaram os problemas. O 
cliente colocou seus usuários chaves para definir os processos, mas eles mesmos não sabiam 
como seria e precisavam, constantemente, solicitar a presença dos diretores nas reuniões de 
levantamento. Muitas coisas eram solicitadas, sem se ater ao escopo pré-definido, aparecen-
do um volume muito grande de alterações de escopo no produto, módulos inteiramente 
novos surgiram nos levantamentos e o que era para durar 3 meses, levou mais de 6 meses 
para finalizar, atrasando todo o cronograma de desenvolvimento e entrega do projeto, mas 
o prazo final foi alterado para apenas 1 mês para frente. Para coincidir com o início do ano, 
ou seja, o projeto precisava estar pronto para iniciar a operação em 01/janeiro/2011.
Mesmo com os requisitos não finalizados em 100%, os desenvolvimentos do que estava 
aprovado, foram sendo realizados, mas os testes eram apenas executados de forma unitá-
ria, pois não tinha como testar todo o processo. O desenvolvimento foi sendo realizado, mas 
quando ia para teste do cliente, voltava com diversos problemas. Os problemas eram de in-
terface que não agradava, erros na execução das operações, cadastros que não realizavam 
certas validações, muitas delas, que não haviam sido especificadas e nem solicitadas pelo 
cliente.
Com todos esses problemas, tanto nos requisitos, como nos desenvolvimentos, ava-
liou-se que não seria possível entregar o produto em janeiro/2011. Foi ai que surgiu a ideia 
de se implantar apenas o módulo financeiro (na íntegra) a partir do momento em que ele 
ficasse pronto.
A partir desse momento, todo o time de desenvolvimento e consultores concentraram 
seus esforços no módulo financeiro, porém, ainda seguindo a forma tradicional de se fazer o 
projeto e o desenvolvimento: especificar, desenvolver, testar unitariamente, testar de forma 
integrada junto com o cliente, treinar e depois de todo o módulo financeiro pronto, colocar 
em produção.
4
Unicesumar
estudo de 
caso
O fato é que mesmo com essa estratégia, ainda ocorreram problemas, iguais aos anterio-
res. Problemas de interface, requisitos não mencionados que precisavam ser contemplados 
e, por conta do tempo que estava demorando, surgiam novas ocorrências que precisam ser 
previstas no sistema em desenvolvimento.
Após 4 meses de trabalho no módulo financeiro, ele estava pronto e poderia entrar em 
produção. Foram realizados os treinamentos aos usuários finais, colocado para rodar em 
paralelo e posto em produção. Ele ainda não estava estável e a equipe precisava, constante-
mente, arrumar algum problema e ao mesmo tempo, desenvolver todo o restante do sistema 
(compras, vendas, logística, faturamento, CRM, estoque e um módulo inteiro de controle de 
ordens de serviço).
Foi nesse momento que a gestão do projeto decidiu mudar o rumo do projeto. No meio 
do projeto, após a implantação do módulo financeiro, optou-se em adotar as práticas ágeis 
para desenvolver todos os outros módulos do sistema. 
Nesse momento, o gerente do projeto fez um encerramento parcial do projeto, elencan-
do tudo que foi entregue até o momento, o que estava fora do escopo, o que foi entregue 
do escopo contratado, incialmente, e, assim, formalizando-se o encerramento do projeto, 
para que fosse possível iniciar um novo projeto, como se estivessem começando o projeto 
de implantação do sistema de gestão na empresa X1 Distribuidora.
Para que esse novo projeto fosse iniciado, sem ônus adicionais para a X1 Distribuidora, o 
gerente do projeto listou todos os itens que ainda não haviam sido entregues no projeto an-
terior e montou a primeira versão do Backlog do Produto. O segundo passo foi transformar 
os requisitos já levantados em histórias de usuário, para que antes de iniciar o desenvolvi-
mento, o produto fosse revisado pelo cliente, avaliando se os requerimentos permaneciam 
os mesmos ou se precisariam de ajustes. Com essa ação, já foi possível eliminar muitos pro-
blemas, pois como o projeto já estava a mais de 12 meses em andamento, muitos requisitos 
levantados no segundo mês de projeto, precisavam ser ajustados, pois a realidade da empresa 
mudou neste período. Assim, já se percebeu o primeiro ganho em implantar o método ágil 
para este projeto.
Unicesumar
5
estudo de 
caso
O método ágil utilizado foi o framework Scrum, com alguns conceitos do Kanban. Assim, 
definiu-se um ciclo de 2 semanas para cada Sprint, assim, o usuário já recebia uma versão 
nova do sistema, com as implementações a cada duas semanas e não precisava esperar tudo 
ficar pronto para poder capacitar os usuários e testar a solução.
Nesse momento, já percebeu-se o segundo ganho. Com entregas menores, os usuários 
deixavam duas sextas-feiras livres no mês, para poder testar e ver o que foi feito nas duas 
semanas que se passaram e também, deixavam as segundas livres para revisar os requisitos 
e priorizar o backlog. Assim, eles conseguiam ver a evolução dos desenvolvimentos, avaliar 
se estava ficando bom ou não, em termos de tela, validações e requerimentos e já poderiam 
testar a solução, mesmo que parcialmente.
A partir daí, foram eleitas datas de implantação de cada módulo separadamente. Quando 
o módulo atingia um grau de implementação, suficiente para colocá-lo em produção, ele 
era atualizado no ambiente de produção e dava-seinício às operações no sistema, sem pre-
cisar que tudo ficasse pronto para depois poderem colher os benefícios do sistema.
Durante a execução, sugiram muitas coisas novas que precisam ser feitos, aumentando 
mais ainda o escopo, porém o cliente ficava satisfeito, pois as implementações eram feitas 
conforme havia a necessidade, ou seja, o cliente priorizava o que tinha que ser feito, primei-
ramente, e, a cada Sprint ele, podia mexer nessas prioridades. Isso, no método tradicional, 
ele não tinha autonomia e viu-se, aqui, o terceiro ganho.
Como o módulo financeiro já estava em produção, os erros precisavam ser corrigidos de 
forma ágil. Então, o gerente do projeto e o time resolveram deixar um tempo sobrando em 
cada Sprint, para correção de bugs. Dessa forma, o que eles se comprometiam a entregar 
não seria comprometido se erros fossem encontrados nos módulos já em produção. Com 
essa medida, foi possível resolver erros dos módulos e não afetar as entregas e em alguns 
casos, entregas eram antecipadas, pois a equipe começou a trabalhar de forma mais ágil e 
com menor incidência de erros no sistema, já que os requisitos estavam mais bem definidos. 
O cliente acompanhava de perto as entregas antes de ir para produção. Aqui, percebeu-se 
mais dois ganhos, antecipação de entregas e redução da quantidade de erros em produção.
6
Unicesumar
estudo de 
caso
Após 6 meses, o desenvolvimento e a implantação dos demais módulos foi encerrada, 
ou seja, em metade do tempo da primeira fase do projeto original, que só implantou o fi-
nanceiro, foi possível entregar todo o restante do projeto, que representava 60% do esforço 
total, conseguindo, ainda, entregar mais funcionalidades do que estava no escopo inicial, 
com satisfação maior do cliente, pois, agora, tinha um sistema alinhado com a realidade da 
empresa, sendo possível acompanhar mais de perto todo o processo nos últimos 6 meses.
A empresa de consultoria, com o sucesso neste e outros projetos, resolveu mudar a abor-
dagem de gestão de projeto, saindo do modelo tradicional e utilizando métodos ágeis de 
gestão de projeto para todos os projetos de seu portfólio. 
Conclusão
Conclui-se, que, neste projeto, pelo fato de ser um projeto grande e complexo, a adoção dos 
métodos ágeis foi primordial para a recuperação do projeto, que estava fadado ao fracasso. 
Ao final de 1 ano, somente um módulo conseguiu entrar em produção, porém, quando mu-
dou-se o rumo do projeto, adotando práticas ágeis, o projeto foi finalizado em 6 meses. O 
gerente de projeto teve que encerrar o projeto antigo e iniciar um novo, como se estivesse 
começando do zero, mas isso foi necessário para que pudesse ser medido o que faltava ser 
entregue, mudar a forma de controle das entregas e medir a performance do time. O time 
do projeto (time Scrum) comprou a ideia e se comprometeu, totalmente, com o projeto e 
isso, também, foi fator decisivo para que a segunda etapa do projeto desse certo.
Sem dúvidas os métodos ágeis são ideais para ambientes aonde os requisitos e priorida-
des se alteram, constantemente, pois facilitam essa mudança de rumo de forma ágil.

Outros materiais