Baixe o app para aproveitar ainda mais
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.
Compartilhar