PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM GERENCIAMENTO DE PROJETOS

Transcrição

1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM GERENCIAMENTO DE PROJETOS COM ÊNFASE EM TECNOLOGIA DA INFORMAÇÃO LEONARDO NUNES ALEGRE GESTÃO ÁGIL PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA Porto Alegre 2011

2 LEONARDO NUNES ALEGRE GESTÃO ÁGIL PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA Monografia apresentada como requisito parcial à obtenção de grau de especialista em Gerenciamento de Projetos com Ênfase em Tecnologia da Informação da Pontifícia Universidade Católica do Rio Grande do Sul. Orientador: Rafael Prikladnicki Porto Alegre 2011

3 LEONARDO NUNES ALEGRE GESTÃO ÁGIL PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA Monografia apresentada como requisito parcial à obtenção de grau de especialista em Gerenciamento de Projetos com Ênfase em Tecnologia da Informação da Pontifícia Universidade Católica do Rio Grande do Sul. Aprovada em de de. BANCA EXAMINADORA: Me. Eduardo Meira Peres Dr. Marcelo Hideki Yamaguti Dr. Rafael Prikladnicki

4 GESTÃO ÁGIL PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA À minha mãe Sônia, ao meu pai Sérgio, aos meus irmãos Leandro e Lucas e à minha namorada Mariane.

5 GESTÃO ÁGIL PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA AGRADECIMENTOS À minha família e namorada Mariane Amado de Paula pelo carinho e afeto que me proporcionaram até aqui e pela paciência que sempre tiveram para comigo durante a elaboração deste trabalho. Ao orientador Prof. Dr. Rafael Prikladnicki pela rica contribuição e revisão deste trabalho. Ao gerente de desenvolvimento do projeto AGHU Tiago Vaz pelo incentivo e motivação no assunto estudado. A equipe do projeto AGHU, pelo tempo dispensado nas entrevistas. Ao amigo e colega do projeto AGHU Bruno Souza de Oliveira por compartilhar o aprendizado desde a graduação. Por fim, a todos que contribuíram de forma direta ou indireta na realização deste trabalho. Muito Obrigado!

6 GESTÃO ÁGIL PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA RESUMO Este trabalho tem como objetivo apresentar uma proposta de gestão ágil com a utilização de métodos ágeis como o SCRUM em projetos de migração de tecnologia. Para isso foi planejado um estudo de caso de um projeto que tem o propósito de migrar um sistema de Gestão Hospitalar, construído na arquitetura cliente/servidor, utilizando plataforma Oracle Forms/Oracle 9i, para uma versão WEB adotando software livre. Foi realizado um estudo durante um período da migração do sistema onde já foi possível constatar que os métodos ágeis podem contribuir consideravelmente no sucesso de um projeto de migração de tecnologia. Com base nesse estudo foi elaborada uma proposta de processo para projetos de migração de tecnologia. Esta proposta é apresentada neste trabalho. AGHU. Palavras-Chave: Projetos de migração de tecnologia, métodos ágeis,

7 GESTÃO ÁGIL PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA ABSTRACT This paper aims to submit a proposal for agile management with the use of agile methods such as SCRUM in technology migration projects. To reach this goal a case study was executed including a project which has the purpose of migrating a hospital management system, built in client/server architecture and platform using Oracle Forms/Oracle 9i, for adopting an open source web platform. A study was conducted during the system migration period where it has been possible to verify that agile methods can contribute to the success of a technology migration project. Based on this study proposal of process for technology migration projects was developed, presented in this document. Keywords: Technology migration projects, agile methods, AGHU.

8 LISTA DE ABREVIATURAS AGH AGHU HCPA MEC PMBOK PMI Aplicativo de Gestão Hospitalar Aplicativo de Gestão para Hospitais Universitários Hospital de Clínicas de Porto Alegre Ministério da Educação Project Management Body of Knowledge Project Management Institute

9 LISTA DE ILUSTRAÇÕES Figura 1: Mapeamento entre os grupos de processo (PMBOK, 2009) Figura 2: Áreas de Conhecimento PMBOK Figura 3: Fluxo do Scrum Figura 4: Postura de Equipes Ágeis (Prikladnicki, 2010) Figura 5: Ciclo de Reuniões Figura 6: Burndown Figura 7: Gestão Visual Figura 8: Task Board planejado para o Sprint Figura 9: Task Board executado no Sprint Figura 10: Task Board planejado para o Sprint Figura 11: Task Board executado no Sprint Figura 12: Processo Proposto para Projetos de Migração de Tecnologia... 44

10 LISTA DE TABELAS Tabela 1: Análise dos Artefatos do Scrum nos dois Sprints em estudo Tabela 2: Análise dos Papéis do Scrum nos dois Sprints em estudo Tabela 3: Reuniões do Scrum nos dois Sprints em estudo Tabela 4: Gestão Visual nos dois Sprints em estudo Tabela 5: Sprint proposto

11 SUMÁRIO 1. INTRODUÇÃO Motivação e Situação Problemática Justificativa Estrutura do Trabalho OBJETIVOS Objetivos gerais Objetivos específicos REFERENCIAL TEÓRICO Gerenciamento de Projetos O que é um Projeto? Áreas do Gerenciamento de Projetos Segundo o PMBOK Projetos de Migração de Tecnologia Gestão Ágil de Projetos Métodos Ágeis Scrum Times de Scrum Sprint Reuniões do Scrum Burndown da Release e Burndown da Sprint Gestão Visual Kanban ESTUDO DE CASO Projeto AGHU Metodologia de Desenvolvimento... 33

12 4.2 Coleta de Dados Perfil dos usuários Metodologia Análise dos Dados Percepção sobre os resultados encontrados PROCESSO PROPOSTO PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA Mapeamento de Processo Pré-Análise Construção Homologação Planejamento do Próximo Sprint Gerenciamento do Projeto CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A PROTOCOLO PARA O ESTUDO DE CASO... 54

13 13 1. INTRODUÇÃO 1.1 Motivação e Situação Problemática Migrar um sistema complexo de tecnologia defasada para uma tecnologia moderna não é trivial para ser concluído com sucesso. Esse tipo de projeto é essencial em muitas iniciativas de negócio, desde fusões e aquisições e até mesmo em atualizações de sistema. O fato de parecer um projeto comum em todas as empresas faz com que gerentes de projetos acreditem que migrar um sistema para outra tecnologia seja uma tarefa rotineira. Geralmente encontramos problemas como documentação desatualizada ou até mesmo inexistente, desconhecimento das regras de negócio do sistema que em muitos casos foram desenvolvidas por recursos que não fazem mais parte da empresa (Itweb, 2009). Em um estudo realizado pela Bloor Research, encomendada pela Informatica Corporation, constatou-se que 84% dos projetos de Migração de dados falham apesar dos investimentos ultrapassarem 5 bilhões de dólares em 2007 e deverão chegar a 8 bilhões de dólares em 2012 (ComputerWorld, 2008). A pesquisa entrevistou mais de 700 empresas que possuem projetos de migração de dados com orçamento igual ou superior a 1 milhão de dólares. Segundo essa pesquisa, quando há atrasos ou falha nos projetos de migração de tecnologia, a iniciativa de negócios também podem sofrer mudanças no cronograma ou até mesmo fracassar. O problema ocorre geralmente pelo conhecimento inadequado do escopo do projeto, que acaba aumentando o tempo de finalização do mesmo e conseqüentemente o custo, tornando-se uma das características de projetos de

14 14 migração de tecnologia. Na fase de análise, por exemplo, a tendência é descobrir que todas as suposições iniciais em relação ao tamanho do projeto estavam equivocadas. Tendo em vista que projetos de migração de tecnologia fracassam na sua maioria, este trabalho tem objetivo de estudar e elaborar uma proposta de utilização de métodos ágeis em projetos desta natureza, visando contribuir com o aumento da taxa de sucesso destes projetos. 1.2 Justificativa O excesso de tempo e de custo em projetos de migração de tecnologia pode ser reduzido através de medidas como adoção de metodologia específica para migração (Itweb, 2009). Conforme visto, projetos de migração de tecnologia se diferem dos demais projetos, pois envolvem incertezas ainda mais difíceis de serem gerenciadas em comparação com projetos tradicionais de desenvolvimento. Desta forma, durante a fase de análise é comum se descobrir que as estimativas iniciais em relação ao tamanho do projeto estavam equivocadas. Outra grande diferença dos projetos de migração de tecnologia para os demais projetos é o uso da análise qualitativa de riscos. Projetos que abandonam uma tecnologia já ultrapassada e migram para uma nova, possuem um alto grau de risco, pois existe pouca documentação de problemas encontrados em outros projetos (Techoje, 2011). Segundo Philips (2003), projetos que não existem históricos recorrentes, como é o caso de projetos de migração de tecnologia, apresentarão mais incertezas e possuem recursos

15 15 limitados como base para hipótese de risco. Todos os riscos são baseados em alguma crença, em provas e em dados. A precisão e a fonte dos dados devem ser avaliadas para que seja determinado o nível de confiança nos riscos identificados. Sendo assim, pretende-se explorar como os métodos ágeis (especificamente o Scrum) podem contribuir para minimizar os principais desafios encontrados em projetos de migração de tecnologia, contribuindo assim para reduzir os riscos de atraso e aumento de custo, entre outros. 1.3 Estrutura do Trabalho Com o intuito de facilitar a compreensão do leitor, este trabalho está dividido da seguinte forma: Capítulo 1 No primeiro capítulo são apresentadas as motivações que levaram a este trabalho. Capítulo 2 Apresenta a definição dos objetivos do trabalho. Capítulo 3 Neste capítulo é abordado todo o referencial teórico para o desenvolvimento do trabalho. Capítulo 4 Neste capitulo apresenta-se o estudo de caso e os resultados encontrados. Capítulo 5 Neste capítulo é apresentada uma proposta de processo para projetos de migração de tecnologia baseado no estudo de caso e na revisão da literatura especifica da área. Capítulo 6 O sexto e último capítulo descreve as conclusões deste trabalho.

16 16 2. OBJETIVOS 2.1 Objetivos gerais O objetivo geral deste trabalho é desenvolver uma proposta de processo de gestão para projetos de migração de tecnologia baseado em métodos ágeis. 2.2 Objetivos específicos A seguir estão listados alguns objetivos específicos deste trabalho. Estudar métodos ágeis como o SCRUM. Executar um estudo de caso para avaliar os benefícios do uso de métodos ágeis em projetos de migração de tecnologia. Elaborar uma análise do estudo de caso e desenvolver uma proposta de processo de gestão para projetos de migração de tecnologia baseado em métodos ágeis.

17 17 3. REFERENCIAL TEÓRICO 3.1 Gerenciamento de Projetos Fazem parte do referencial teórico desde trabalho os conceitos básicos de projeto, gerência de projetos, projetos de migração de tecnologia e gestão ágil de projetos O que é um Projeto? Lewis (2000) define projeto como um trabalho único que possui um início e um fim claramente definidos, um escopo de trabalho detalhado com um orçamento e uma meta de desempenho que deve ser atingida. Goodpasture (2000) seguindo o mesmo raciocínio de LEWIS, define projeto como conjunto de tarefas únicas, interdependentes e não repetitivas, planejadas e executadas de forma a produzir algum resultado. Numa visão mais recente, VARGAS (2006), definiu projeto como um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade. Tendo em vista as três definições acima, conclui-se que projetos possuem um ciclo de vida, ou seja, todo projeto possui um objetivo e deve ter um fim. Para Kerzner (2002): gerenciamento de projetos é a arte de criar a ilusão de que todos os resultados obtidos pelo projeto foram previamente

18 18 previstos e planejados quando, na realidade, não passaram de uma seqüência absurda de pura sorte. O termo Gerenciamento de Projetos às vezes é usado para descrever uma abordagem organizacional ou gerencial do gerenciamento de projetos e de algumas operações já em andamento, que podem ser redefinidas como projetos, o que também é chamado gerenciamento por projetos (PMBOK, 2009) Áreas do Gerenciamento de Projetos Segundo o PMBOK O PMBOK não pode ser definido como uma metodologia, pois não distingue os diferentes tipos de projetos e sim como um guia de boas práticas de gerenciamento de projetos criado e mantido pela Project Management Institute (PMI). O livro formaliza os diferentes conceitos em gerenciamento de projetos, como a própria definição de projeto reconhecendo cinco grupos de processo e nove áreas de conhecimento. Figura 1: Mapeamento entre os grupos de processo (PMBOK, 2009)

19 19 Conforme é possível visualizar na figura 1, os cinco grupos de processo reconhecidos pelo PMI são Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento. Esses grupos possuem dependências claras e são executadas na mesma seqüência em todos os projetos. As nove áreas de conhecimento abordam o gerenciamento dos seguintes processos listados abaixo: Integração: Integra os requisitos de acordo com o planejamento do projeto. Escopo: Processos que verificam apenas o trabalho necessário para que o projeto seja concluído com sucesso. Tempo: Processos relativos ao prazo de término do projeto. Custos: Processos que envolvem planejamento e controle de custos de modo que o projeto termine dentro do orçamento aprovado. Qualidade: Processos que asseguram que o projeto irá cumprir os objetivos para os quais foi acordado com o cliente. Recursos Humanos: Processos que organizam e gerenciam a equipe do projeto. Comunicações: Processos que disseminam as informações relacionadas ao projeto. Riscos: Processos responsáveis pelo gerenciamento de riscos do projeto. Aquisições: Processos que compram ou adquirirem bens, produtos ou serviços. Engloba também os processos de gerenciamento de contratos. O processo integrado utilizando as áreas do gerenciamento de projetos segundo o PMBOK pode ser visualizado na figura 2 a seguir.

20 20 Figura 2: Áreas de Conhecimento PMBOK Fonte: Projetos de Migração de Tecnologia Tecnologia defasada, menor custo de propriedade, melhor desempenho e consolidação de diferentes tecnologias são alguns dos motivos que levam as empresas decidirem a migrar de tecnologia um sistema. Projetos de Migração de Tecnologia não consistem apenas em decisões técnicas e arquiteturais sobre um sistema. Faz parte desse tipo de projeto decisões estratégicas sobre a evolução e entrega dos novos módulos do sistema. Existe, por exemplo, a abordagem de se congelar a versão atual do projeto e na migração do sistema incluir também funcionalidades novas, ou então, se mantém o projeto atual enquanto o projeto novo é construído.

21 21 Projetos de desenvolvimento em grande parte possuem quatro fases comuns como análise, projeto, construção e teste. Mas no caso de projetos de migração de dados, por exemplo é comum termos as fases de análise, extração e transformação, validação, carga e testes. Se considerarmos como fases não distintas, é muito provável que o projeto venha a fracassar, pois metodologias inadequadas são a causa de grande parte dos atrasos e das falhas da migração de dados (Itweb, 2009). Segundo o estudo da Bloor Research (ComputerWorld, 2008) o excesso de custo e tempo pode ser reduzido e até mesmo eliminado através de metodologias com foco em migração de tecnologia. 3.2 Gestão Ágil de Projetos Nesta seção serão abordados conceitos relacionados a métodos ágeis com foco no framework do SCRUM e conceitos relacionados a práticas de gestão visual como o uso de Task Board Métodos Ágeis Segundo Abrahamsson et al. (2002) o que os métodos ágeis buscam não é como conter as mudanças mais cedo em um projeto de software, mas a melhor maneira de tratar mudanças inevitáveis ao longo de seu ciclo de vida. Para alcançar seu objetivo, os métodos ágeis são projetados, a princípio, para produzir a primeira entrega em semanas e alcançar o feedback do cliente rápido e mais cedo, criando assim soluções mais simples de modo que se

22 22 houver mudanças que haja mais facilidade e menor volume de alterações a serem feitas. Para ele, métodos ágeis também buscam melhorar continuamente a qualidade do projeto, fazendo com que a iteração seguinte tenha menor custo de implementação. Para isso, é necessário testar constantemente, para detectar defeitos mais cedo e removê-los com menor custo. Em fevereiro de 2001 surgiu o Manifesto de Desenvolvimento Ágil de Software através de uma reunião em Utah. A reunião era formada por 17 desenvolvedores experientes que procuravam discutir idéias e uma alternativa aos processos burocráticos e as práticas adotadas nas abordagens tradicionais da Engenharia de Software e gerência de projetos. Dessa reunião concluiu-se que: Indivíduos e iterações são mais importantes do que processos e ferramentas; Software funcionando é mais importante do que a documentação abrangente; Colaboração do cliente é mais importante do que a negociação de contrato; Resposta às mudanças é mais importante do que um plano préestabelecido. Além dos quatro valores básicos apresentados, o manifesto ágil também apresentou 12 princípios que auxiliam na difusão das suas idéias: A maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software com valor agregado. Mudanças de requisitos são aceitas, mesmo tardiamente no

23 23 desenvolvimento. Processos ágeis tiram vantagens das mudanças visando vantagem competitiva para o cliente. Entregar software funcionando com freqüência, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o projeto. Construir projetos ao redor de indivíduos motivados disponibilizando a eles um ambiente e suporte necessário, e confiar que farão seu trabalho. O método mais eficaz e eficiente de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Contínua atenção a excelência técnica e bom design, aumentam a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e aperfeiçoam seu comportamento apropriadamente. Esses princípios trazem motivação para o time de desenvolvimento e informações mais precisas da situação do projeto para o cliente.

24 24 Métodos ágeis no geral buscam minimizar os riscos do desenvolvimento de software através de entregas menores num menor espaço de tempo, sempre enfatizando a qualidade e a comunicação em tempo real Scrum Desenvolvido nas décadas de 80 e 90 por Ken Schwaber, Jeff Sutherland, e Mike Beedle, o Scrum consiste num framework que emprega um conjunto de boas práticas voltadas para gerenciamento de projetos. Segundo Ken Schwaber e Jeff Sutherland, o propósito do Scrum é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um framework dentro do qual, produtos complexos podem ser desenvolvidos. A teoria do Scrum (Scrum.org) é fundamentada na teoria de controle de processos empíricos que é sustentada pelos três seguintes pilares: Transparência: Garante que resultados que afetam o resultado ou a meta devem ser visíveis e transparentes para quem os gerenciam. Inspeção: Diz que diversos aspectos dos processos devem ser inspecionados com freqüência suficiente para detectar variações inaceitáveis do processo. Adaptação: Quando na Inspeção for detectado que um ou mais processos estão fora do que é considerável aceitável, o inspetor deverá ajustar o processo o mais rápido possível diminuindo o risco de desvio posterior. A figura 3 apresenta o framework do Scrum conforme é possível visualizar a seguir:

25 25 Figura 3: Fluxo do Scrum Fonte: Times de Scrum São times que buscam o autogerenciamento sendo multidisciplinares e trabalham em iterações. Cada time de Scrum possui os três seguintes papeis definidos: ScrumMaster: Tem a responsabilidade de garantir que o processo seja compreendido e seguido pelo time. Possui o papel de liderar o time e a função de remover os seus impedimentos, garantindo melhor produtividade e

26 26 qualidade na entrega do produto. Product Owner: É a pessoa com o papel de maximizar o valor do trabalho realizado pelo time. Tem a responsabilidade de levantar os requisitos e gerenciar o Product Backlog. O Product Backlog representa o esforço necessário para desenvolver e lançar um produto com sucesso e, somente o Product Owner tem a permissão de priorizá-lo e de realizar o aceite do software no final de cada iteração. Time: Formado por desenvolvedores, possuem o papel de realizar o trabalho de transformar os requisitos do Product Owner em algo entregável e executável do produto no final de uma iteração. São multidisciplinares e devem possuir todo o conhecimento necessário para entregar um produto utilizável. Os Times devem ser auto-organizáveis e ninguém de fora do time diz como o mesmo deve trabalhar. Um Time deve ter no máximo nove pessoas e um mínimo de cinco pessoas. Times com mais de nove pessoas exigem um trabalho maior de coordenação e times com menos de cinco pessoas perdem em produtividade. A postura de equipes ágeis pode ser visualizada na figura 4 a seguir. Figura 4: Postura de Equipes Ágeis (Prikladnicki, 2010)

27 Sprint A Sprint representa uma iteração de um mês ou menos com duração fixa. Cada Sprint deve começar imediatamente após o término do anterior e têm como resultado uma parte do produto final entregável e testável. A composição do Time e as metas de qualidade devem ser as mesmas durante todo o Sprint. Com o conceito de Sprints, realizando entregas curtas estaremos diminuindo o risco de que o projeto saia do controle ou então se torne imprevisível. Pois se o projeto for longo demais, é comum que a sua definição mude durante o seu desenvolvimento e entre variáveis que não estavam planejadas Reuniões do Scrum O Scrum sugere como boa prática a realização das seguintes reuniões durante um Sprint: Reunião de Planejamento da Release: Reunião opcional onde são priorizadas as funcionalidades que vão compor uma versão do produto final. Reunião de Planejamento da Sprint: Momento onde o Sprint é planejado com o tempo fixo de oito horas para iterações de trinta dias. Essa reunião pode ser divida em duas partes, onde na primeira parte é discutido o que será realizado no Sprint e na segunda parte o time entende como transformará o que foi solicitado em um incremento do produto. Faz parte também da segunda parte do planejamento da Sprint estimar o que foi priorizado do Product Backlog e cabe apenas ao time de desenvolvedores decidirem o quanto do backlog deve entrar no final da Sprint.

28 28 Revisão da Sprint: Realizada ao final de cada Sprint, essa reunião deve ter duração máxima de quatro horas onde o time de Scrum e as partes envolvidas verificam o que deu certo durante o Sprint e as dificuldades que foram encontradas. Essa reunião fornece entradas importantes para a próxima reunião de planejamento de Sprint. Retrospectiva da Sprint: Após a revisão da Sprint, o ScrumMaster se reúne com time para alinhar os pontos positivos e negativos em relação ao próprio time, dos processos e das ferramentas. Após a reunião são identificadas as ações necessárias para eliminar os pontos negativos e manter o que foi encontrado de positivo durante a iteração. Essa reunião é fundamental para a melhoria contínua. Daily Scrum: Essa reunião é realizada em todos os dias do Sprint, sempre no mesmo horário e no mesmo local. Teve ter no máximo quinze minutos onde cada membro do time diz o que foi feito desde a última reunião, o que vai fazer até a próxima reunião e os impedimentos quando existirem. O objetivo dessa reunião é melhorar a comunicação dentro do time e remover os impedimentos com mais agilidade. Na figura 5 a seguir é apresenta o ciclo de reuniões do Scrum:

29 29 Figura 5: Ciclo de Reuniões Fonte: visaoagil.wordpress.com/2008/07/08/scrum-overview Burndown da Release e Burndown da Sprint Burndown da Release é uma representação gráfica que mede o restante do Product Backlog ao longo do tempo de acordo com as estimativas de cada item desse backlog. No Scrum temos também o Burndown da Sprint que representa graficamente a quantidade restante de trabalho do Sprint durante o tempo do Sprint. Ambas as ferramentas são fundamentais para monitorar o progresso do time, como por exemplo, revelando com antecedência se o projeto vai atrasar ou vai ser entregue dentro do prazo. A figura 6 a seguir apresenta um exemplo de Burndown.

30 30 Figura 6: Burndown Fonte: Kanban e Scrum obtendo o melhor de ambos Gestão Visual com task board O task board é um artefato utilizado para o acompanhamento da realização das tarefas de um Sprint entre as suas diversas etapas ( To do, Doing, Done, ou outras classificações desejadas). Tem o objetivo de representar visualmente o trabalho que está sendo feito pela equipe. O funcionamento de consiste em dividir em tarefas cada item do Product Backlog selecionado para a Sprint e para cada tarefa se cria um cartão com uma breve descrição, fixando-o na parede dentro do fluxo de trabalho definido pela equipe. Desta forma, uma equipe que possua um grande conjunto de pequenas tarefas a serem realizadas pode utilizar este quadro para um acompanhamento visual do andamento destas e de quem está responsável por cada uma. Isto não pode ser considerado ainda uma adoção do Scrum, mas é uma opção para um

31 31 entendimento gradual da filosofia ágil (Bridge Consulting, 2011). O uso do task board motiva a equipe a seguir o processo ajudando a construir confiança e transparência. Assim como o Burndown, o task board auxilia no monitoramento do progresso da equipe, facilitando no processo de autogerenciamento. Figura 7: Gestão Visual

32 32 4. ESTUDO DE CASO Baseado no método de estudo de caso proposto por Yin (2001), foi conduzido um estudo de caso sobre o projeto AGHU, projeto que foi utilizado como base para a elaboração da proposta de gestão ágil para projetos de migração de tecnologia. 4.1 Projeto AGHU De acordo com o portal do MEC (portal.mec.gov.br), o Aplicativo de Gestão para Hospitais Universitários (AGHU) é um projeto do Ministério da Educação que objetiva padronizar práticas assistenciais e administrativas em todos os 46 hospitais universitários de sua rede. A utilização do AGHU vai proporcionar que os hospitais aprimorem seus processos de atendimento, estendendo aos pacientes de todo o país inúmeras facilidades, como o prontuário eletrônico e todos os benefícios a ele relacionados. Além disso, com o AGHU o MEC passará a dispor de indicadores padronizados entre todos os integrantes da rede, o que facilitará a implantação de melhorias e a divulgação transparente de dados para o público. Para desenvolver este trabalho, o MEC utiliza como base o Hospital de Clínicas de Porto Alegre (HCPA), levando em conta o sucesso de seu modelo de gestão e a disponibilidade do sistema de Aplicativos para gestão Hospitalar desenvolvido pela instituição (AGH). Para isso, o projeto AGHU objetiva migrar um sistema construído numa arquitetura cliente/servidor proprietária, na plataforma Oracle Forms, para uma

33 33 arquitetura WEB, numa versão em software livre. Enquanto o AGHU é construído através da migração do AGH para um sistema WEB software livre, a versão atual do AGH permanece congelada e não recebe novas funcionalidades Metodologia de Desenvolvimento O projeto AGHU desde o seu início adotou como metodologia de desenvolvimento um processo baseado em métodos ágeis como o Scrum. Os Sprints possuem duração de três semanas onde nas duas primeiras ocorre a construção do sistema e na terceira semana ocorre a fase de testes e planejamento. Através de entregas curtas e com a priorização do Product Backlog, foi possível implantar na Maternidade Vitor Ferreira do Amaral, de Curitiba, Paraná, a primeira versão do AGHU. A primeira versão corresponde apenas uma pequena parte do AGH (dois módulos), mas é suficiente para facilitar o processo de atendimento de pacientes dentro da Maternidade. Pouco a pouco, novos módulos vão sendo implantados e mais instituições ingressam no grupo de hospitais que dispõem do AGHU. 4.2 Coleta de Dados A coleta de dados foi planejada para avaliar se de fato uma equipe do projeto AGHU utiliza o framework do SCRUM, verificando os benefícios dessa abordagem num projeto de migração de tecnologia durante seis semanas (dois

34 34 Sprints de três semanas) Perfil dos usuários Para a coleta de dados foram utilizados cinco participantes, ambos de uma mesma equipe e envolvidos no mesmo projeto. Todos os usuários possuem idade maior ou igual á 23 anos, nível superior completo, com conhecimentos avançados de informática e com alguma noção de gerenciamento de projetos. Além disso, todos têm pleno conhecimento dos processos que ocorrem na empresa onde trabalham. Dos cinco participantes, quatro são desenvolvedores e um é analista de qualidade Metodologia a) No início de duas iterações os participantes foram orientados a descrever o processo que utilizariam no próximo Sprint (Protocolo para o Estudo de Caso Apêndice A). A finalidade desta questão era comprovar se os participantes em estudo possuem o conhecimento do processo que estão utilizando. b) Ao final de cada iteração em estudo, os participantes foram orientados a responder as demais questões do protocolo com o objetivo de constatar se o Scrum está sendo aplicado, verificando os benefícios dos métodos ágeis em projetos de migração de tecnologia. Ambos os questionários foram encaminhados e entregues pessoalmente.

35 Análise dos Dados A fim de verificar os reais benefícios dos métodos ágeis como o Scrum em projetos de migração de tecnologia, foi desenvolvida a relação do que é recomendado pelo o Scrum e o que foi planejado e executado em duas Sprints do estudo, conforme é possível visualizar nas tabelas a seguir Artefatos Scrum Product Backlog Sprint Backlog Burndown de Release Burndown de Sprint O que é recomendado O Product Owner é o responsável pelo seu conteúdo, disponibilidade e priorização. Somente o Time pode modificar o seu conteúdo durante o Sprint. Deve registrar o restante do product backlog do release. Deve medir os itens do Sprint Backlog restantes durante o Sprint. Sprint 1 Planejado Não foi planejado neste Sprint. Foi planejado e estimado durante a reunião de planejamento da Sprint. Foi disponibilizado num quadro na sala de desenvolvimento com as estimativas planejadas para a Release. Foi colocado num quadro na sala de desenvolvimento com os itens estimados e planejados para o Sprint. Sprint 1 Executado Product Owner disponibilizou o Product Backlog, mas em alguns momentos a equipe constatou priorizações externas. Apenas o time de desenvolvimento modificou o conteúdo do Sprint Backlog. Foi atualizado de acordo com as estimativas restantes da release. O burndown foi atualizado diariamente pelo time de desenvolvimento. Sprint 2 Planejado Não foi planejado neste Sprint. Foi planejado e estimado durante a reunião de planejamento da Sprint. Foi disponibilizado num quadro na sala de desenvolvimento com as estimativas planejadas para a Release. Foi colocado num quadro na sala de desenvolvimento com os itens estimados e planejados para o Sprint. Sprint 2 Executado Product Owner ficou responsável e não ocorreu interferência externas. Apenas o time de desenvolvimento modificou o conteúdo do Sprint Backlog. Foi atualizado de acordo com as estimativas restantes da release. O burndown foi atualizado diariamente pelo time de desenvolvimento. Tabela 1: Análise dos Artefatos do Scrum nos dois Sprints em estudo.

36 36 Papéis Scrum O que é recomendado ScrumMaster Deve remover os impedimentos da equipe e manter o processo funcionando. Product Owner Time Deve ser a única pessoa responsável pelo gerenciamento do Product Backlog. Devem ser multidisciplinares, autoorganizáveis e o único responsável em transformar o Product Backlog em incremento de funcionalidade entregável. Sprint 1 Planejado Time planejado com um ScrumMaster que também realiza tarefas de análise e desenvolvimento. Uma pessoa com o papel de Product Owner ficou responsável pelo Product Backlog. Time planejado com 4 desenvolvedores, 1 analista de qualidade. Sprint 1 Executado O ScrumMaster esteve disposto a remover os impedimentos e manteve o processo funcionando. O Product Owner atribuiu as prioridades para as funcionalidades desenvolvidas. Os itens do Sprint Backlog foram estimados e assumidos pelo Time. Sprint 2 Planejado Time planejado com um ScrumMaster que também realiza tarefas de análise. Uma pessoa com o papel de Product Owner ficou responsável pelo Product Backlog. Time planejado com 4 desenvolvedores, 1 analista de qualidade. Sprint 2 Executado O ScrumMaster esteve disposto a remover os impedimentos e manteve o processo funcionando. O Product Owner atribuiu as prioridades para as funcionalidades desenvolvidas. Os itens do Sprint Backlog foram estimados e assumidos pelo Time. Tabela 2: Análise dos Papéis do Scrum nos dois Sprints em estudo.

37 37 Time Boxes Scrum Reunião de Planejamento da Release Reunião de Planejamento da Sprint Revisão da Sprint Retrospectiva da Sprint O que é recomendado Deve-se estimar e priorizar o Product Backlog para a release. Reunião onde a iteração é planejada. Com duração de 8 horas, o time deve decidir o que irá ser feito e como o trabalho será executado. Deve ser realizada no final da Sprint com duração máxima de 4 horas. É revisado nessa reunião o que foi feito no Sprint e o que deixou de ser realizado. Duração de 3 horas com o propósito de inspecionar como ocorreu a Sprint em se tratando de pessoas, das relações entre elas e dos processos de desenvolvimento. Sprint 1 Planejado Não foi planejado neste Sprint. Planejado para a terceira semana do Sprint. Planejado para a terceira semana do Sprint. Planejado para a terceira semana do Sprint. Sprint 1 Executado Não foi executado neste Sprint. A reunião foi executada na terceira semana do Sprint. Foi identificado que desafios muito grandes deveriam sofrer uma avaliação diferenciada. Executado no último dia do Sprint com todos os times de desenvolvimento onde foi revisado o andamento do projeto. Executado na terceira semana da Sprint e considerada pelo Time como a reunião mais importante do processo e fundamental para a melhoria contínua. Sprint2 Planejado Não foi planejado neste Sprint. Planejado para a terceira semana do Sprint. Planejado para a terceira semana do Sprint. Planejado para a terceira semana do Sprint. Sprint 2 Executado Não foi executado neste Sprint. A reunião foi executada na terceira semana do Sprint. Foi identificado que reuniões rápidas de planejamento podem gerar uma visão superficial sobre o dimensionamento de certas atividades. Executado no último dia do Sprint com todos os ScrumMasters e o Gerente de Projeto onde foi revisado o andamento do projeto. Executado na terceira semana da Sprint com apenas o time de desenvolvimento. Cada integrante explicou os pontos positivos e negativos que ocorreram durante o Sprint.

38 38 Daily Scrum Deve ocorre diariamente durante 15 minutos onde cada membro explica o que realizou desde a última reunião, o que irá fazer até a próxima reunião e os impedimentos que estão em seu caminho. Planejado para ocorrer todos os dias às 14h. Executada diariamente às 14h sempre no mesmo local. Em alguns casos a reunião passou dos 15 minutos alinhados. Planejado para ocorrer todos os dias às 14h. Executada diariamente às 14h sempre no mesmo local. Tabela 3: Reuniões do Scrum nos dois Sprints em estudo. Gestão Visual Task Board O que é recomendado Deve-se dividir o trabalho a ser realizado em pequenas tarefas. Para cada tarefa é criado um cartão que deve ser posto na parede com colunas nomeadas de acordo com o fluxo de trabalho. Sprint 1 Planejado As funcionalidades selecionadas para o Sprint foram quebradas em pequenas tarefas e colocadas no task board. (Figura 9) Sprint 1 Executado Diariamente o task board foi atualizado pelo time de desenvolvimento. De acordo com as respostas do questionário, o task board é fundamental para o autogerenciamento e organização do time. (Figura 10) Sprint2 Planejado As funcionalidades selecionadas para o Sprint foram quebradas em pequenas tarefas e colocadas no task board. (Figura 11) Sprint 2 Executado Diariamente o task board foi atualizado pelo time de desenvolvimento. A coluna que representa a fase de testes foi dividida em três fases: Qualidade, Aderência e Homologação. (Figura 12) Tabela 4: Gestão Visual nos dois Sprints em estudo.

39 39 Legenda: Cartão Azul: Melhoria Cartão Verde: Funcionalidade a ser migrada Cartão Amarelo: Tarefa relacionada à funcionalidade, como por exemplo, um requisito de negócio ou uma interface. Cartão Laranja: Integrante do time que está executando a tarefa. Cartão Rosa: Defeito aberto pela equipes de qualidade ou aderência ou homologação. Figura 8: Task Board planejado para o Sprint 1

40 Figura 9: Task Board executado no Sprint 1 40

41 Figura 10: Task Board planejado para o Sprint 2 41

42 Figura 11: Task Board executado no Sprint 2 42

43 Percepção sobre os resultados encontrados De acordo com as respostas dos entrevistados pôde-se concluir que o Scrum se adaptou no projeto de migração de tecnologia em estudo. Segundo os entrevistados, os métodos ágeis contribuem para que o foco do desenvolvimento permaneça apenas nas atividades que foram planejadas, não permitindo que nenhuma outra atividade adicional interferira no processo. Alem disso, as opiniões expressas por cada integrante do time ao final de cada Sprint ajudam na melhoria contínua do grupo. A principal desvantagem relatada pelos entrevistados explica que o modelo de processo baseado em métodos ágeis não funciona com pessoas que não possuem perfil para trabalhar em equipe.

44 44 5. PROCESSO PROPOSTO PARA PROJETOS DE MIGRAÇÃO DE TECNOLOGIA Baseado na análise dos dados dos questionários e na metodologia de desenvolvimento do projeto AGHU, foi elaborada a proposta de processo conforme figura a seguir: Figura 12: Processo Proposto para Projetos de Migração de Tecnologia O processo proposto compreende a adoção de Sprints com três semanas de duração com as fases de Mapeamento de Processo, Pré-Análise do Próximo Sprint, Construção, Homologação, Planejamento do Próximo Sprint e Gerenciamento do Projeto. Segundo o guia do Scrum (scrum.org), realizando entregas curtas estaremos diminuindo o risco de que o projeto saia do controle ou então se torne imprevisível. Conforme visto neste trabalho, é comum que o escopo dos projetos de migração de tecnologias mude durante o seu desenvolvimento e entre variáveis que não estavam planejadas.

45 Mapeamento de Processo Esta fase antecede a migração do sistema, é onde os analistas de processo junto com os Product Owners mapeiam as funcionalidades e realizam a Reunião de Planejamento da Release, conforme é recomendada pelo Scrum. A Reunião de Planejamento da Release é onde são planejadas as funcionalidades que devem ser migradas que vão compor uma versão do produto. A mesma deve ser realizada por um time de processo juntamente com os Product Owners. Apesar de ser opcional no Scrum, é obrigatória neste processo proposto. 5.2 Pré-Análise do Próximo Sprint Nessa fase o analista de sistemas descreve de maneira preliminar no documento de pré-análise como deve ser implementada a funcionalidade a ser migrada no próximo Sprint. São levantados nesse documento todos os requisitos do que deve ser migrado do sistema antigo analisando também regras de negócio que não são mais utilizadas, ou então não fazem mais sentido a sua implementação no sistema novo. Seguindo as orientações dos métodos ágeis, na documentação deve constar somente o que é necessário para migrar o item selecionado do Product Backlog, sendo pertinente apenas ao escopo em questão. Esta fase ocorre nas duas primeiras semanas do Sprint paralelamente com a fase de Construção.

46 Construção A fase de construção ocorre nas duas primeiras semanas do Sprint e é quando o time de desenvolvimento desenvolve a migração das funcionalidades selecionadas do Sprint Backlog tendo como base o documento de pré-análise, realizando os devidos testes. Depois de migrada a funcionalidade para o sistema com a nova tecnologia, o item migrado recebe os testes funcionais pelo analista de qualidade na etapa de validação. Não conformidades encontradas são encaminhadas para o time de desenvolvimento e a funcionalidade permanece em validação até que mesma atenda a todos os requisitos do documento de pré-análise. Durante a fase de construção, apenas o time pode alterar o Sprint Backlog, conforme é recomendado pelo Scrum. Nesta fase ocorre também a reunião diária. A Reunião Diária seguindo as recomendações do Scrum deve ocorrer diariamente com tempo máximo de quinze minutos. Essa reunião é sempre realizada no mesmo horário e no mesmo local durante as Sprints. Durante a reunião cada membro do time deve explicar o que foi realizado desde a última reunião, o que vai fazer antes da próxima reunião e quais obstáculos estão em seu caminho. 5.4 Homologação Consiste no aceite final do Product Owner e do usuário final do sistema na terceira semana do Sprint. Nesta fase são realizados os testes num ambiente idêntico ao de produção e caso a funcionalidade migrada atenda a todos os requisitos, o usuário final deverá assinar o documento de aceite

47 47 formalizando a homologação. Assim como na fase de construção, na homologação também deve ocorrer às reuniões diárias. 5.5 Planejamento do Próximo Sprint Após as duas primeiras semanas de desenvolvimento e pré-análise, ocorre na terceira semana paralelamente com a fase de homologação, a fase de planejamento do próximo Sprint, onde devem ocorrer as seguintes reuniões: Workshop de Análise: Reunião realizada pelo time de desenvolvimento, ScrumMaster e Product Owner, onde é repassado o documento de pré-análise e definido como a funcionalidade deve ser migrada a nível de negócio. Nessa reunião o time inteiro terá a oportunidade de opinar e levantar melhorias antes que as mesmas sejam desenvolvidas. Esse modelo de reunião complementa o Scrum, visto que a mesma não é citada pelos métodos ágeis. Planejamento da Sprint: Reunião onde deve ser discutido como e qual o esforço necessário para migrar os itens selecionados para o Sprint. O time deve projetar a maneira que irá migrar as funcionalidades e dividi-las em tarefas. Para cada tarefa é criado um cartão com uma breve descrição e ser colocado num quadro que esteja visível para todos do time, auxiliando assim o autogerenciamento do time. Após o entendimento da resolução das funcionalidades deve ser feito a estimativa para definir o esforço necessário para produção da iteração seguindo o modelo de reunião de planejamento de Sprint proposto pelo Scrum. Revisão da Sprint: Conforme é sugerido pelo Scrum, no final da Sprint

48 48 é realizada a reunião de revisão da iteração. Esse encontro consiste na apresentação do que foi migrado na Sprint e as métricas levantadas, analisando o que falta para se concluir do que foi planejado para o release. Lições Aprendidas: Realizada também na terceira semana da Sprint e seguindo as recomendações do Sprint Review do Scrum, cada time deve se encontrar entre as reuniões de planejamento da Sprint e revisão da Sprint para realizar a etapa de retrospectiva. Nessa reunião são avaliados os pontos fracos e pontos fortes do time na última iteração. Os pontos fracos devem ser planejados e atribuídos para que sejam resolvidos (Adaptação e Melhora Contínua). Ao final da reunião é realizada uma autocrítica de cada membro do time, dizendo o que acha que errou, o que acertou e o que fazer para melhorar. 5.6 Gerenciamento do Projeto O gerente do projeto deve monitorar e controlar todas as demais fases do processo proposto com o auxílio das métricas levantadas pelos líderes de equipe.

49 49 Semanas 1 e 2 Semana 3 Desenvolvimento Pré-Análise (próximo Sprint) Testes funcionais Correções de não-conformidades Reunião Diária Workshop de Análise Planejamento da Sprint Revisão da Sprint Lições Aprendidas Reunião Diária Testes de Homologação Correções não-conformidades Aceite final do usuário Tabela 5: Sprint proposto.

50 50 6. CONCLUSÃO Migrar a tecnologia de um sistema pode parecer um projeto de escopo definido, com objetivos claros desde o início, com baixa incerteza e estimativas precisas, não sendo necessária a adoção de uma metodologia de desenvolvimento. Mas conforme visto neste trabalho, projetos de migração de tecnologia possuem alta incerteza e as estimativas passam a ser precisas somente após a fase pré-análise. O escopo muda com muita freqüência durante a migração, pois é comum o cliente informar que certas funcionalidades não são mais utilizadas e conseqüentemente não necessitam da migração para o sistema com nova tecnologia. Tendo em vista que não existe uma metodologia específica para projetos de Migração de Tecnologia e que este tipo de projeto fracassa na sua maioria, foi verificado através de um estudo de caso que métodos ágeis podem contribuir para reduzir os riscos de atraso neste tipo de projeto. Através de equipes multifuncionais que adotaram o framework Scrum como metodologia de desenvolvimento, foi possível provar no estudo de caso num período de seis semanas que métodos ágeis também podem ser aplicados em projetos de migração de tecnologia. O objetivo deste trabalho foi elaborar uma proposta de processo de gestão baseado em métodos ágeis para projetos de migração de tecnologia. Conforme visto na introdução deste trabalho, metodologias inadequadas é a causa de grande parte dos atrasos de projetos de migração de tecnologia. É muito comum também durante a migração de sistemas, aparecerem melhorias e novas funcionalidades por parte do Product Owner para o time de desenvolvimento, gerando um aumento do escopo do projeto. O processo

51 51 proposto pode e deve ser ajustado dependendo da complexidade do sistema migrado como, por exemplo, acrescentar uma fase de aderência caso seja um sistema Web onde deve ser validados padrões de interface. Pode-se concluir também que através de pequenas entregas por iterações, o usuário final já consegue utilizar uma parte do sistema migrado sem que o mesmo já esteja totalmente concluído, alcançando o feedback do cliente mais cedo diminuindo o risco de que o projeto saia do controle.

52 52 7. REFERÊNCIAS BIBLIOGRÁFICAS 1. ABRAHAMSSON, P. Salo, O. Ronkainen, J. Warsta, J. Agile SoftwareDevelopment Methods. Review and Analysis, Espoo. VTT Publications 478, BECK, Kent; Beedle, Mike; Bennekum, Arie van; Cockburn, Alistair; Cunningham, Ward; Fowler, Martin; Grenning, James; Highsmith, Jim; Hunt, Andrew; Jeffries, Ron; Kern, Jon; Marick, Brian; Martin, Robert C.; Mellor, Steve; Schwaber, Ken; Sutherland, Jeff; Thomas, Dave ; Agile Manifesto. Disponível em: < >. Acesso em 21 de maio de Bridge Consulting; Scrum além do desenvolvimento de software, escrito por Caroline Abrantes, disponível em < scrum_alem_do_desenvolvimento_de_software.html?tmpl=component&print=1 >. Acesso em 30 de Agosto de COMPUTERWORLD, publicação em 24 de janeiro de 2008, disponível em < Acesso em 15 de abril de GOODPASTURE, John C. The Project Office: Finding Pearls and Avoiding Perils, HENRIK Kniberg, Mattias Skarin. Kanban e Scrum - obtendo o melhor de ambos. C4Media, editora do InfoQ.com, ITWEB, O papel estratégico dos projetos de migração de tecnologia. <

53 53 migracao-de-dados/> Publicação em 30 de janeiro de Acesso em 15 de abril de PHILIPS, Joseph. Project Management. McGraw-Hill/Osborne, Kerzner, Harold. Gestão de Projetos. Editora Bookman, LEWIS, James P. Como Gerenciar Projetos. Editora Campus, PMBOK - PMI, Um guia do conjunto de conhecimentos em gerenciamento de projetos. 4ª edição, PORTAL MEC, disponível em < Acesso em 15 de maio de PRIKLADNICKI, Rafael. Notas de aula Tópicos e Gerenciamento de Projetos, curso de Especialização em Gerenciamento de Projetos com Ênfase em Tecnologia da Informação. PUCRS, SCHWABER, Ken; Sutherland, Jeff; Scrum Guide. Disponível em: < >. Acesso em 30 de maio de Techoje, disponível em < Acesso em 01 de julho de VARGAS, Ricardo Viana. Gerenciamento de Projetos. Estabelecendo diferenciais competitivos. 6ª Edição. Editora Brasport, YIN, Robert. Estudo de Caso Planejamento e Métodos. Editora Bookman Companhia ED, 2001.

54 54 8. APÊNDICE A PROTOCOLO PARA O ESTUDO DE CASO Protocolo para Estudo Objetivo Entender se as práticas de métodos ágeis estão sendo aplicada numa determinada equipe do projeto com quatro desenvolvedores e uma analista de qualidade. O estudo ocorrerá no início e no final de dois Sprints, onde cada Sprint possui três semanas. Questão Pesquisa do Início do Sprint 1. Descreva como você irá trabalhar na próxima Sprint? Questões de Pesquisa do Final do Sprint 2. Descreva o processo que você usou na Sprint finalizada? 3. O que você melhoraria no processo utilizado? 4. Quais os benefícios encontrados no processo utilizado? 5. Quais as desvantagens encontradas no processo utilizado? 6. O tamanho dos itens do backlog foram estimados e assumidos pela equipe? 7. O ScrumMaster da equipe removeu impedimentos encontrados e manteve o processo funcionando? 8. O Product Owner atribuiu prioridades para as funcionalidades que