Gerenciamento de Projetos vs Gerenciamento de Operações: Diferenças e Semelhanças, Transcrições de Gestão de Projetos de Software

Baixe Gerenciamento de Projetos vs Gerenciamento de Operações: Diferenças e Semelhanças e outras Transcrições em PDF para Gestão de Projetos de Software, somente na Docsity! IH SE Sumário Introdução... seia ese ieeraee aee aaee aeee aee eae naaa aaa eaa aaa aaa aeee aaa ceara career arena 3 Uma breve história dos projetos no tempo... sister enero eee certas 3 A certificação PMPO... eteeeeeat aeee eateera aee eaeara es catate rates cata re ne anesceranereanea 4 Requisitos da certificação PMPO. Mas afinal o que é o Guia PMBOKR? ...... teias erteen ereta ares erterere res ettates 5 O exame de certificação... eee aerea aerea es eaear tes eat nere ares creree 5 O que será avaliado... tire ater eeteeaa ee aaaara escanear nes cataratas care nereanea 6 O Gerente de Projetos e o Triângulo de Talentos... sessenta 7 O Triangulo de talentos do PMIO ......... eretas aeee aerea reatar arena 7 Ciclo de vida e Tailoring.......... eee eee aee eataneaa es eae teres catarata nara ater cranea 9 O que é um Projeto? ....... tire aeee aee aaanaaa aaa ceaana eseata rentes care rere rara 9 Operações Rotineiras........... see iesereeet aee aaeeaa aee eaeaaa esa ne rates career araras 1 Projetos, subprojetos, programas e portfólios .. Gerenciamento de projetos, programas e portfólios... series enter 12 Gerenciamento de portfólios ........... eee atas eaenea tes eteee tes erenee teres 14 Gerenciamento de subprojetos............. tetas eee essere essere teares atenas 15 Gerenciamento de projetos x gerenciamento de operações... 15 Ciclo de vida do projeto e ciclo de vida de desenvolvimento... 15 Ciclo de vida de desenvolvimento preditivo ........... eee aeee essere 19 Ciclo de vida de desenvolvimento iterativo e incremental... 20 Ciclo de vida de desenvolvimento iterativo ............ eita 20 Ciclo de vida de desenvolvimento incremental... east 21 Ciclo de vida de desenvolvimento ágil... ereta essere eternas 23 Hoje, o gerenciamento de projetos é cada vez mais aceito e difundido, e está presente em torno de todas as áreas e organizações. Milhares de profissionais e muitos investimentos são empregados e envolvidos diretamente na gerência de projetos. E a crescente necessidade de rapidez na entrega dos projetos com os menores recursos e garantia de qualidade, faz de hoje esses os maiores desafios para esta grande organização. A certificação PMPO O Project Management Institute (PMI) oferece uma certificação profissional para gerentes de projeto, conhecida como PMPO (Project Management Professional). Globalmente reconhecida e exigida, essa certificação demonstra aos empregadores, clientes e colegas que o profissional possui profundos conhecimentos em gerenciamento de projetos de forma a levá-los à sua conclusão bem- sucedida. Como a demanda por gerentes de projeto qualificados está em um nível de urgência crítica, os profissionais que possuem a certificação PMPO estão bem-posicionados para fornecer as habilidades profissionais necessárias para liderar equipes de projeto e alcançar resultados bem- sucedidos. Pesquisas realizadas pelo PMI mostram que os salários de profissionais certificados são pelo menos 25% mais altos em comparação com outros profissionais que não possuam a credencial. Requisitos da certificação PMPO Para se candidatar à certificação PMPO você precisa ter: e Diploma de nível superior de quatro anos ou mais (bacharel ou equivalente); e Mínimo de 36 meses liderando projetos; e 35 horas de formação em gerenciamento de projetos. e Diploma de ensino médio (ensino médio ou equivalente); e Mínimo de 60 meses liderando projetos; e 35 horas de formação em gerenciamento de projetos. As horas de experiência devem de ser adquiridas nos últimos 8 anos, independente do grau de educação. Em todo mundo existem mais de 1.000.000 profissionais certificados PMPO que prestam serviços em 214 países. Mas afinal o que é o Guia PMBOKE? O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOKQ) é a principal publicação do PMIO e é um recurso fundamental para o gerenciamento de projetos eficaz em qualquer setor. Ao longo dos anos, os negócios mudaram consideravelmente, mas os projetos continuam sendo fatores críticos para o sucesso dos negócios. O conteúdo da sétima edição do Guia PMBOKR incluiu: e Toda a gama de abordagens de desenvolvimento (preditiva, tradicional, adaptativa, ágil, híbrida etc.). e Uma seção inteira dedicada a adaptar a abordagem e os processos de desenvolvimento. e A lista de ferramentas e técnicas em uma nova seção, “Modelos, Métodos e Artefatos”. Além disso, ele não deve ser utilizado sozinho, uma vez que ele se integra ao PMIstandards+ TM, um site do próprio PMI, que ajuda o usuário a aplicar o Guia PMBOKQ no trabalho. O exame de certificação O exame é composto por 180 questões a serem respondidas em 230 minutos. Dessas questões 5 não são pontuadas, ou seja, 175 questões serão efetivamente utilizadas para gerar a sua pontuação. As questões não pontuadas se referem a novas questões inseridas no banco de questões do PMIO que estão sendo testadas em relação à sua aplicabilidade. Por exemplo, se nenhum candidato consegue acertar uma questão, isso significa que a pergunta ou está mal formulada ou está muito além dos conhecimentos necessários exigidos. Estima-se que para ser aprovado o candidato deverá acertar entre 65% e 69% das 175 questões pontuadas. Considerando que você terá quatro horas para responder 180 questões, você terá em média um minuto e 30 segundos para responder cada uma. Apresentamos esta média não para assustar o candidato, e sim para que você tenha em mente que se demorar mais de três minutos em uma questão terá que compensar na resposta de outras. Como não existe pontuação negativa, isto é, uma resposta errada NÃO anula uma resposta certa, você deve responder a todas as questões. E como todas as questões possuem o mesmo valor, não perca tempo com aquelas que não souber a resposta ou as quais tenha dúvidas. Marque-as para revisão (o software permite isso) e siga em frente. Após passar por todas as questões volte às que foram marcadas para revisão e utilize o tempo restante para solucioná-las. O que será avaliado O exame se concentra em três domínios que permitem que o profissional obtenha uma vantagem competitiva e possa provar que trabalha de forma mais inteligente. Os domínios são definidos como “areas de conhecimento em alto nível” que são essenciais para a prática do gerenciamento de projetos. E esses domínios são: e Pessoas. enfatiza as habilidades sociais que o gerente de projetos precisa para liderar efetivamente uma equipe. e Processo: reforça os aspectos técnicos do gerenciamento de projetos. e Ambiente de negócios: destaca a conexão entre projetos e estratégia organizacional. No exame as perguntas aparecerão nas seguintes proporções: Domínio % No. de questões Pessoas 42 76 Processos 50 90 Ambiente de negócios 8 14 TOTAL 100 180 O Guia ECO (Exam Content Outline) disponível em: https:/www.pmi.org/- imedia/pmi/documents/public/pdf'certifications/pmp-examination-content- outline.pdf?v=fbóbd86f-6ec 1-4836-a6f5-6f8bSb9b7d99& sc lang temp=pt-BR detalha o conteúdo cobrado no exame. CICLO DE VIDA E TAILORING O que é um Projeto? Segundo o Guia PMBOKO: Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Entre outras características de um projeto, podemos destacar: e Um projeto é gerenciado pelo gerente do projeto auxiliado pela sua equipe de gerenciamento; e Todo projeto possui ao menos um patrocinador; e Todo projeto afeta um grupo de partes Interessadas, e Um projeto é composto por entregas parciais ou finais (“deliverables”); e Os projetos interagem com outros projetos e com as operações rotineiras da organização; e Os projetos também podem ser elaborados utilizando-se da elaboração progressiva. Projetos são temporários porque tem início e fim bem definidos. Observe que um projeto pode ter a duração de semanas ou até mesmo anos, no entanto o seu resultado deve ser duradouro. Projetos são exclusivos porque devem sempre produzir algo novo. Exemplos de projetos: e Construção de um navio, ponte, rodovia, prédio; e Desenvolvimento de software, websites; e Festa de formatura, casamento; e Melhoria de processos de produção. O término de um projeto pode acontecer por diversos motivos, tais como: e Seu objetivo foi alcançado. e Seu objetivo NÃO será alcançado. e Ele não é mais necessário. e O cliente não quer mais. e O dinheiro acabou. Projetos impulsionam mudanças e criam valor de negócio. Normalmente um projeto é criado para levar uma pessoa, grupo de pessoas ou organização de um estado a outro de forma a atingir um objetivo especifico. Esse objetivo pode ser um benefício tangível (como valores financeiros, instalações, ferramentas), intangível (reconhecimento da marca, reputação) ou ambos. Os projetos são frequentemente utilizados como meio de atingir o plano estratégico de uma organização. Eles normalmente são autorizados como resultado de uma ou mais das seguintes estratégias: e Cumprir requisitos regulatórios, legais ou sociais - ou seja, atender às leis; e Atender a pedidos das partes interessadas; e Implementar ou alterar estratégias de negócios ou tecnológicas; e Criar, melhorar ou corrigir produtos, processos e serviços. Quando uma empresa adota o gerenciamento de projetos, estará adotando uma importante ferramenta para o sucesso dos negócios, pois ao invés de executar projetos aleatoriamente, estará melhorando seus processos e alinhando esses projetos às necessidades e estratégias do negócio. A empresa irá focar em projetos e programas que suportem seus objetivos obtendo assim melhores tesultados, melhor rendimento e aumento na vantagem competitiva sobre seus concorrentes. O planejamento organizacional pode orientar o financiamento e dar suporte aos projetos com base em diferentes categorias, tais como: riscos, linhas específicas de negócios ou tipos gerais de projetos, como infraestrutura e melhoria de processos internos. A figura a seguir mostra como os projetos, programas e portfólios se encaixam no planejamento estratégico de uma empresa: 10 SEA) Organizacional e (o) JfSn irei Recursos Organizacionais Os projetos, em programas ou portfólios são um meio de atingir metas e objetivos organizacionais, geralmente no contexto de um planejamento estratégico. Operações Rotineiras Operações rotineiras, ou continuas, são todas as atividades repetitivas sem data de término e que geralmente repetem um processo da organização. Os projetos normalmente interagem com algumas das operações rotineiras da empresa. Exemplos: e Processamento de contas a receber/pagar; e Pagamento de funcionários; e Vendas; e Produção. Projetos, subprojetos, programas e portfólios 1 Programa é um conjunto de projetos relacionados que são administrados de forma coordenada. Gerenciados dessa forma, os projetos capitalizam benefícios que não seriam aproveitados caso fossem gerenciados de forma individual. Gerenciamento de portfólios Os projetos e programas do portfólio NÃO precisam ser interdependentes, pois o gerenciamento do portfólio concentra-se em garantir que os projetos e programas serão avaliados de acordo com a sua importância para a organização e a partir daí priorizar a alocação de recursos para cada um deles. Projeto Z Programa Projeto A Projeto B Projeto € Um exemplo de portfólio são os projetos e programas de um grupo empresarial que atue em vários setores (petróleo, logistica, energia, mineração etc). O portfólio é uma coleção de programas e projetos que satisfazem metas ou objetivos de negócios. O estabelecimento de um portfólio proporciona a análise, seleção e avaliação dos projetos que a organização deve realizar, sejam novos ou em andamento, vinculando-os dessa forma às diretrizes estratégicas da organização. 14 Gerenciamento de subprojetos Um subprojeto é criado quando um projeto é dividido em componentes ou partes menores mais facilmente gerenciáveis. A subdivisão pode ocorrer por conta de: e Especialização tecnológica; e Requisitos de habilidades dos recursos; e Fases do projeto. Subprojetos não fazem sentido isoladamente. Gerenciamento de projetos x gerenciamento de operações Embora sejam coisas distintas o gerenciamento de operações e o gerenciamento de projetos têm alguns pontos em comum: e Executado por pessoas; e Restringidos por recursos limitados; e Planejado, executado e controlado. No entanto, os pontos discordantes são em maior número: Projetos Operações Esforço temporário Esforço contínuo Melhorias percebidas ao final Melhorias surgem durante o processo Produto entregue somente ao final (em Produto uniforme e constante modelos preditivos) Inovativo Repetitivo Mudanças para alcançar objetivo Conservadorismo e similaridade Tem data limite para execução Dia-a-dia da empresa Ciclo de vida do projeto e ciclo de vida de desenvolvimento O ciclo de vida do projeto é o conjunto de fases pelo qual o projeto passa, desde a sua concepção até o seu encerramento. O ciclo de vida de um projeto geralmente está ligado ao tipo de produto, 15 serviço ou resultado que este projeto irá produzir. Os ciclos de vida de projetos podem ser preditivos, adaptativos e híbridos. O ciclo de vida do projeto é o conjunto de fases pelo qual o projeto passa, desde a sua concepção até o seu encerramento. O ciclo de vida de um projeto geralmente está ligado ao tipo de produto, serviço ou resultado que este projeto irá produzir. Perceba que para cada tipo de projeto, podemos ter um ciclo de vida diferente. Na verdade, para um mesmo tipo de projeto (exemplo: criação de um software) é comum vermos empresas utilizando ciclos de vida de projeto completamente diferentes. Criação de um Estratégia de Construção de uma software marketing casa Levantamento de Diagnóstico Terraplanagem requisitos Criação de estratégia Fundação Análise Implantação da Estrutura (paredes) Modelagem estratégia Infraestrutura (tubulação Codificação Medição dos resultados água) Teste Acabamentos Implantação Habite-se Embora as fases do ciclo de vida possam variar de projeto a projeto, elas possuem algumas características em comum, tais como: e O custo é normalmente mais baixo nas fases iniciais, aumentando progressivamente (e em alguns casos, exponencialmente) nas fases de execução do trabalho, para depois cair novamente conforme o projeto vai chegando ao fim. (Obs: esse é o comportamento típico. No entanto, exceções podem existir, como projetos que necessitam altos investimentos logo no seu início, como por exemplo, com a compra de equipamentos e treinamento de pessoal nas fases iniciais). e Os riscos e incertezas são altos no início, já que há muito ainda que planejar e executar. Esses fatores diminuem ao longo da vida do projeto à medida que as decisões são tomadas e as entregas vão sendo feitas e aceitas. 16 Ciclo de vida de desenvolvimento preditiv: O ciclo de vida de desenvolvimento preditivo é aquele em que o planejamento é totalmente verificado e concluído antes de se prosseguir com o trabalho do projeto e, uma vez que o trabalho começa, é monitorado e controlado para cumprir o plano do projeto. Em um modelo preditivo, os requisitos são bem conhecidos e documentados antes do início do trabalho do projeto. As equipes são estabelecidas com antecedência e tendem a permanecer estáveis durante todo o projeto. O risco é menor em uma metodologia preditiva porque há muita certeza sobre o projeto, os requisitos, o escopo, o cronograma e o custo. Esses elementos são bem definidos antes do início dos trabalhos, reduzindo o risco. A principal característica de um modelo preditivo é que todas as fases do projeto são executadas em série, onde uma só inicia após a conclusão da anterior, como neste exemplo: projeto = Análise . . Levantamento Cronogramação => Codificação b Implantação de requisitos Monitoração Projeto Teste Entrega Comunicação . Planejamento Iniciação do Modelagem x o Estimativas => E Construção Manutenção Feedback Obviamente, dependendo do modelo usado, uma ou outra fase tem seu nome modificado, ou ainda fases são acrescentadas ou eliminadas. Mas de qualquer forma, o que todos tem em comum é que uma fase só se inicia após o término da anterior. Esses modelos são também chamados de Cascata ou Waterfall, porque a fase seguinte sempre estará depois da anterior, e nunca vai voltar para trás como as águas de uma cachoeira. Estes modelos são altamente prescritivos, ou seja, tem foco em planos detalhados definidos no princípio do projeto, como custo, escopo e um cronograma bem detalhado. Mudanças são geralmente indesejadas. O modelo cascata é utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos. Uma forma de utilizar o modelo cascata é quando precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente. Por exemplo, quando temos um 19 sistema já pronto e precisamos fazer uma adaptação porque alguma lei governamental foi alterada ou criada. Também podemos utilizar o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis. O modelo cascata tem sido usado ha séculos na construção civil e sempre com resultados muito satisfatórios. Embora tenham evoluído ao longo dos tempos com novas máquinas e equipamentos, projetos de construção civil existem há eras na história da humanidade e, em linhas gerais, sua forma de execução se manteve a mesma: uma longa fase de definições e especificações no início que tem como saída um plano, seguida de sua fase de execução. Mas e a construção de software? E de produtos inovadores e disruptivos? O modelo cascata ainda é válido? Ciclo de vida de desenvolvimento iterativo e incremental Antes de abordamos o ciclo de vida iterativo, precisamos definir o que é iteração. Para entender o que isso significa, é preciso pensar na repetição de um processo. Uma iteração representa uma “caixa de tempo” (timebox) no qual o projeto é realizado, dividido em trabalho funcional específico. Ou seja, a cada 30 dias, por exemplo, novas funcionalidades são lançadas. E essas funcionalidades são agregadas ao que se chama de incremento (que é um conjunto de funcionalidades lançadas ao longo das iterações). Terminada a iteração, uma nova se inicia logo na sequência. No Scrum a iteração é chamada de Sprint. Ciclo de vida de desenvolvimento iterativo A abordagem de ciclo de vida iterativa permite feedback sobre o trabalho à medida que avança o projeto e não somente em suas fases finais como são as abordagens preditivas. Assim, melhorias e modificações podem ser feitas durante todo o ciclo de desenvolvimento. Não que isso não seja possível em abordagens preditivas, mas o controle de mudanças é bem menos complexo quando estamos tratando de abordagens iterativas. Este ciclo de vida faz uso de protótipos ou mock-ups, o que permite o feedback da equipe e melhorias sucessivas no protótipo a cada iteração. A equipe agirá com base nas informações 20 tecebidas e incorporará modificações e novas ideias nas próximas iterações. Ou seja, a cada nova iteração o protótipo é melhorado até o ponto em que se torna o produto finalizado. Um ciclo de vida iterativo reduz a incerteza, por isso ele é a abordagem ideal quando o projeto for altamente complexo, houver mudanças frequentes e / ou quando o produto final não for totalmente compreendido por todas as partes interessadas. Importante destacar que ciclos de vida ITERATIVOS são orientados à aprendizagem e não à rapidez de entrega, pois construímos um protótipo, mostramos ao cliente, ele dá o feedback e com isso temos novas informações que nos permitirão aprimorar o produto. A partir dai, melhorias e alterações são realizadas no protótipo e realizamos uma nova entrega. Esse ciclo de entrega e aprendizagem continua segue até a entrega final do projeto. Assim, um processo iterativo é aquele que faz progresso através de tentativas sucessivas de tefinamento. Por exemplo, uma equipe de desenvolvimento faz sua primeira tentativa para construção de um software, porém, existem pontos de informação falhos ou incompletos em algumas partes. A equipe de forma iterativa refina essas partes até que o produto esteja satisfatório. Com cada iteração, o software é melhorado através da adição de mais e mais detalhes. Ciclo de vida de desenvolvimento incremental A abordagem de ciclo de vida incremental entrega funcionalidade completa ou entregas no final da iteração que o proprietário ou dono do produto pode usar imediatamente. Isso pode incluir a entrega de um produto minimo viável nos casos em que não é possível realizar uma entrega totalmente funcional. Nesse método, a equipe planeja as entregas antes de iniciar o trabalho, bem como pode planejar com antecedência as entregas de iterações futuras. A abordagem incremental aumenta a velocidade com que a equipe pode produzir entregas. Em vez de esperar que cada entrega seja concluida e então apresentada ao cliente no final do projeto (como em uma abordagem preditiva), subconjuntos do produto são entregues ao longo da vida do projeto. Essas pequenas e frequentes entregas consistem em um trabalho acabado, ou seja, não são protótipos que serão aprimorados em iterações futuras. Assim, no modelo incremental o projeto é construído e entregue por partes. E cada uma dessas partes é adicionada ao que normalmente chamamos de “incremento”. 21 Cada iteração (ou Sprint) entrega uma parte utilizável do software para o cliente e assim ele vai vendo se o que ele tinha em mente é exatamente o que está sendo construído. Este modelo é o que chamamos de iterativo e incremental, ou seja, a cada nova iteração entregamos um novo incremento de software. Mas veja que isto não é a adoção de mini cascatas em cada iteração. O que se tem é a divisão dos requisitos em partes menores e a entrega dessas partes sendo feitas a cada nova iteração. Assim, nos métodos ágeis as iterações não são divididas em fases, por exemplo: não existe a fase análise de requisitos onde todos os requisitos daquela Sprint são definidos. O que se faz é selecionar um requisito (ou uma parte menor dele), realizar a análise, projeto, implementação e teste. Nesse meio tempo, outro requisito pode ter sido escolhido e o ciclo (análise, projeto, implementação e teste) é executado para ele também. E assim se prossegue até o término da iteração gerando incrementos do produto. E como se construissemos uma suíte por vez, ou seja, indicamos o que queremos que tenha nessa suite, aí é elaborada a planta somente dessa suite, depois a suite é construida, testada e entregue. Na próxima iteração, passaremos à construção da segunda suite e assim por diante. Aqui já deu para perceber que os métodos ágeis não são a melhor forma de construir casas, não é mesmo? Mas sem dúvida, é o melhor método para construção de projetos que tenham escopo volátil e complexo de ser definido logo no início. Ou seja, não somente projetos de software, mas qualquer projeto da área do conhecimento que muitas vezes criam produtos intangíveis ou nunca antes desenvolvidos. Assim, os modelos ágeis vêm para resolver 3 falhas importantes dos modelos tradicionais (ou preditivos): e Os projetos reais construidos em alguns tipos de indústria (como a de software ou de produtos inovadores) raramente seguem o fluxo sequencial que o modelo prega. e É muito raro e dificil para o cliente saber e estabelecer explicitamente todas as suas necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que existe no início dos projetos. e O cliente precisa ter muita paciência, o que raramente acontece. Uma versão operacional (pronta para ser executada no cliente) não estará disponível até estarmos próximo ao final 24 do projeto. Se tivermos um erro grave nas etapas iniciais, como uma especificação mal compreendida e mal especificada, podemos ter um resultado desastroso, ou seja, o cliente se recusará a aceitar e meses de trabalho podem ter que ser jogados fora. O ciclo de vida ágil, que pode também ser chamado de “orientado a mudanças”, somente é possível quando houver um mecanismo para dividir os requisitos do produto em partes, para que cada parte seja alocada a iteração de desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada requisito. Ou seja, a cada iteração escolheremos juntamente com o cliente os requisitos mais importantes. E ao final dessa iteração, o subconjunto escolhido deve estar pronto e totalmente funcional para a sua revisão pelo próprio cliente. Este tipo de ciclo de vida requer equipes muito envolvidas que incluam os patrocinadores ou cliente para proporcionar continuo feedback. Geralmente se opta por métodos ágeis em ambientes que mudam rapidamente, quando o Comparativo Ciclos de Vida de Desenvolvimento escopo é indefinido e/ou muito complexo. Preditivo Iterativo Incremental Agile Levantamento de requisitos Esforço único para documentar todos os requisitos do projeto No início de cada iteração com modificações durante a iteração. No início de cada iteração ou no início do projeto No início de cada iteração com modificações durante a iteração Como os processos de planejamento são executados O planejamento é executado antes do início do trabalho. O plano direciona o trabalho. Planejamento é realizado no início de cada iteração e pode consistir em protótipos e maquetes. O cliente avalia e fornece feedback. O produto é aprimorado por meio de melhorias contínuas em protótipos ou maquetes. O planejamento envolve a decomposição do trabalho do projeto geralem subconjuntos sucessivos de entregas que podem ser entregues no final de cada iteração. O planejamento pode ocorrer para uma ou mais entregas O planejamento é executado no início de cada iteração. 25 antes de iniciar o trabalho. Como o trabalho é executado Otrabalho é executado no grupo de processos de execução depois que todos os processos de planejamento são concluídos. Otrabalho é executado uma vez, a menos que haja alterações aprovadas. Otrabalho é realizado em períodos de tempo (como uma iteração) e é repetido e, em seguida, modificado em iterações futuras até encontrar especificações. Otrabalho é executado uma vez durante uma iteração. Se forem necessárias correções, elas serão feitas na próxima iteração. Cada estágio de trabalho é repetido durante cada iteração (ou seja, projetar, construir, verificar, entregar). Otrabalho é repetido até que atenda às especificações. Frequência de | Os entregáveis são | Uma entrega no final | Pequenos Pequenos entregas produzidos nos da iteração resultados entregáveis processos de recorrentes ao recorrentes ao Execução e longo do projeto longo do projeto, Monitoramento e normalmente Controle do projeto entregues no e apresentados ao final de cada cliente no final do iteração, mas projeto. podem ser concluídos no meio do caminho Foco Controle de escopo, | Otimização de Rapidez de entrega | Valor para o custo e cronograma | aprendizagem cliente Benefícios Ajuda na gestão de | Ajuda a garantir que | Ajuda na execução | Ajuda a agregar custos e escopo. Reduz a complexidade e a incerteza porque muito se sabe sobre o projeto. a solução seja correta eatendaa necessidade. Permite um feedback sobre o trabalho parcialmente concluído, a fim de modificar ou melhorar o trabalho. do trabalho mais rápido, agilizando o projeto. As entregas utilizáveis são concluídas no final de cada fluxo de trabalho e são entregues ao cliente. valor ao negócio com frequência e a receber feedback imediato. Combina os benefícios de iterativo e incremental, permitindo modificações no trabalho durante a iteração; permite feedback 26 O sucesso do seu projeto pode significar entregar valor de forma incremental ou entregar valor de uma vez no final do projeto, porque a natureza do trabalho não permite entrega de valor de forma incremental, como é o caso de construção de pontes e viadutos. Assim que aqui vamos mostrar algumas das considerações que você deve levar em conta ao escolher um ciclo de vida ou metodologia de desenvolvimento. Quando usarmos o termo Ágil, considere qualquer abordagem genérica que se adeque, podendo ser iterativo, incremental, Adaptivo, ou ainda um framework específico como o Kanban ou Scrum. O termo Hibrido se refere à combinação de abordagens preditivas e ágeis e sendo assim, não podem ser consideradas como abordagens ágeis. Assim, a seguir apresentamos uma lista de necessidades e quais abordagens são as mais indicadas para determinada situação. Recomendamos o uso da abordagem preditiva para as seguintes necessidades: Necessidade ou situação Abordagem sugerida Baixas taxas de mudança Preditivo Requisitos bem conhecidos Preditivo Princípios ágeis não se encaixam na cultura da empresa Preditivo A natureza do trabalho do projeto não permite a entrega Preditivo incremental A cultura exibe um baixo grau de confiança, indisposição para Preditivo mudar e baixa tolerância ao risco Resultados rápidos Ágil Alto grau de complexidade Ágil Requisitos incertos, em evolução ou emergentes Ágil Incerteza ou alto risco Ágil Má qualidade em projetos anteriores de escopo e complexidade | Ágil semelhantes Alta taxa de mudança Ágil Dificuldade em descrever objetivo ou produto final Ágil Capacidade de agregar valor aos negócios de forma incremental | Ágil 29 Reduza o desperdício e retrabalho Ágil Pesquisa e desenvolvimento são necessários Ágil O feedback é necessário conforme o valor do negócio é produzido | Ágil a fim de melhorar o produto de forma incremental ou iterativa Entregas com base no cliente com frequência Ágil A cultura exibe um alto grau de confiança, capacidade de Ágil adaptação a mudanças, alta tolerância ao risco e adesão dos executivos Altas taxas de mudança durante a definição de requisitos e Híbrido escopo; processos bem definidos para realizar o trabalho Projetos que têm necessidades regulatórias ou de conformidade | Híbrido com resultados bem definidos Projeto com risco médio e baixo grau de incerteza Híbrido A cultura exibe um grau médio de confiança, alguma Híbrido adaptabilidade à mudança, tolerância média ao risco e os executivos estão abertos para agilidade A cultura da organização está disposta a tentar agilidade, mas Ágil ou híbrido nunca usou essa abordagem antes Organizações com vários projetos ativos variando de pequena a grande magnitude Preditivo, ágil ou híbrido Uma observação importante é que não existe um método híbrido campeão de audiência como é um método puro como o Scrum ou o Kanban. Um método híbrido é construído de acordo com as necessidades do projeto, da organização e da equipe. E já falando de Scrum e Kanban, vamos ver a diferença entre ciclo de vida de desenvolvimento baseado em Iteração e baseado em fluxo. Ciclo de vida baseado em iteração e em fluxo Existente duas correntes, diriamos, meio que filosóficas com relação ao tipo de cadência das entregas. No Scrum, por exemplo, as entregas são feitas geralmente ao final de uma iteração. E embora seja possível, via DevOps realizar entregas frequentemente, ainda teremos um evento para o fechamento da Sprint. 30 Já no Kanban, as entregas são continuas. Não temos eventos previstos tampouco iterações. Um item do Backlog que entre no fluxo de desenvolvimento, ao chegar ao final desse fluxo poderá ser liberado para o cliente, sem ter que esperar o final da iteração ou Sprint. Assim, temos que em projetos ágeis baseados em iterações, a equipe trabalha dentro de um timebox para fornecer funcionalidades concluídas. A equipe escolhe as funcionalidades mais importante com a participação dos principais stakeholders. Com o Backlog da iteração já definido, a equipe desenvolve os itens escolhidos e os apresenta em uma reunião de demonstração ou como é chamada no Scrum, reunião de Revisão da Sprint. Já em projetos ágeis baseados em fluxo, a equipe seleciona as funcionalidades do backlog com base na sua capacidade disponível de trabalho, ou seja, é usado um sistema puxado, onde os membros do time só puxam trabalho se tiverem capacidade de absorvê-lo. Sem iterações para definir pontos de planejamento e revisão, a equipe e as partes interessadas podem determinar um cronograma apropriado para planejamento, revisões de produto e retrospectivas. Tailoring O tailoring significa customizar o gerenciamento para o projeto. Ou seja, o gerente de projetos e sua equipe devem ser capazes de selecionar as ferramentas e processos que desejam aplicar em cada projeto, assim como definir em qual profundidade serão aplicados. Do inglês, tailoring significa alfaiataria, que é a criação de roupas sob medida pois, seu objetivo é adaptar peças a cada cliente e às suas necessidades. Assim, o conceito tailoring aplicado à gestão de projetos é uma prática que vem sendo cada vez mais utilizada em diversos tipos de empresas, pois trata basicamente de adaptação. Ou seja, da capacidade de atender, aceitar e incorporar mudanças tanto antes, quanto durante o andamento dos processos. Esse conceito exige flexibilidade, inovação e resiliência dentro do mercado para lidar com as diversas situações as quais estamos sujeitos no ambiente de negócios, projetos e vendas. Existem vários fatores que devem ser considerados ao realizar o Tailoring, e que são: e O projeto requer entrega iterativa ou incremental? 31 Identificação da ecessidade Por exemplo, um projeto realizado para apresentar ao mercado um novo celular é apenas um aspecto do ciclo de vida do produto. Fases Já vimos que o ciclo de vida do projeto é composto por uma série de fases. Mas ainda faltam alguns detalhes sobre as fases que abordaremos a seguir. Como citado anteriormente, a definição das fases do ciclo de vida de um projeto está diretamente ligada ao tipo de produto a ser gerado. Embora muitos ciclos de vida de projetos possuam fases com nomes similares e requeiram “entregas” similares, poucos ciclos são totalmente idênticos. 34 No mínimo o projeto terá um estágio inicial, uma ou mais fases intermediárias e uma fase final. O término de cada fase oferece uma oportunidade para que o gerente do projeto, o patrocinador e as partes interessadas avaliem se o projeto deve seguir em frente ou não. As fases do projeto NÃO são grupos de processos! Mas como uma fase é determinada? A determinação de uma fase pode ser feita a partir de uma combinação dos seguintes critérios: e Conclusão de uma entrega; e Alterações significativas nos recursos e habilidades para prosseguir o projeto; e Necessidade de implementar um ponto de controle para poder avançar no projeto; e e Envolvimento de uma empresa terceirizada. As fases podem também ser subdivididas em subfases, devido às restrições de tamanho, complexidade, riscos e fluxo de caixa. Cada subfase, para um maior controle e monitoramento, é associada a um ou mais produtos, que estão relacionados a algum produto da fase principal e seus nomes são dados de acordo com seus produtos, tais como requisitos, projeto, construção, teste, inicialização, entrega, e assim sucessivamente. A conclusão de uma fase está geralmente ligada a um marco do projeto Análise de final de fase (revisão de fase) A fase é concluida com a revisão do trabalho e dos produtos para indicação de sua aceitação, e para definir se será necessário mais algum trabalho complementar. A análise de final de fase é um evento predefinido no projeto com metas explícitas a fim de se obter autorização para encerrar a fase atual e iniciar a seguinte. Também pode ocorrer de uma fase ser encerrada sem que outra seja iniciada, essa situação ocorre quando o projeto foi finalizado ou então há muitos riscos para que ele continue. Este ponto pode ter diversas denominações, tais como, ponto de verificação, marco, análise de fase, revisão de fase ou ponto de término. Em muitos casos, há a necessidade da aprovação do encerramento de uma fase de alguma forma antes que ela seja considerada como encerrada. Relações entre fases Existem dois tipos de relacionamento entre fases: 35 Relação Sequencial: neste tipo de relacionamento uma fase só começa quando a anterior termina. Este tipo de relacionamento diminui as incertezas, pois só começamos a fase seguinte quando as entregas da fase anterior foram finalizadas (e aceitas!). | Relação sobreposta (e paralelismo): neste tipo de relacionamento uma fase pode iniciar sem que a anterior esteja finalizada. Este é um exemplo da técnica de compressão de cronograma chamada paralelismo que veremos com mais detalhes nos capítulos referentes ao gerenciamento do tempo. E ao contrário da relação sequencial, este relacionamento aumenta as incertezas, porque iniciamos uma fase sem que as entregas da fase anterior tenham sido finalizadas. Existem dois tipos de relações sobrepostas, conforme mostrado nas figuras a seguir: Relação sobreposta entre fases ve Relação paralela entre fases 36 Planejamento e eu Grupo de processos de Iniciação O Grupo de Processos de Iniciação é constituído pelos processos que facilitam a autorização formal para iniciar um novo projeto. Antes de iniciar as atividades do Grupo de Processos de Iniciação, os requisitos ou as necessidades de negócios da organização são documentados, estabelecendo a viabilidade do novo empreendimento através de um processo de avaliação das altemativas a fim de selecionar a melhor. São desenvolvidas descrições claras dos objetivos do projeto, incluindo as razões pelas quais um projeto específico se constitui na melhor solução alternativa para satisfazer os requisitos. A documentação dessa decisão também contém uma descrição básica do escopo do projeto, das entregas, da duração do projeto e uma previsão dos recursos para a análise de investimentos da organização. Grupo de processos de Planejamento A equipe de gerenciamento de projetos usa este grupo de processos para planejá-lo de forma bem- sucedida para a organização. Ele envolve a determinação do escopo (o que deve ser feito), a definição da equipe e suas funções e responsabilidades (quem deve fazer), o desenvolvimento do 39 cronograma (quando deve ser feito), do orçamento (a que custo), a determinação de padrões e métricas de qualidade, a identificação de riscos, a determinação do que deve ser comprado ou elaborado internamente entre outros. Grupo de processos de Execução É neste grupo onde o trabalho do projeto é realizado. Ele envolve a mobilização da equipe de trabalho, a execução do próprio trabalho de acordo com o planejado, o acompanhamento das especificações e padrões estabelecidos, a implementação de mudanças aprovadas e reparo de defeitos, o desenvolvimento da equipe e a seleção e contratação de fornecedores. A execução é a fase com maior dispêndio de recursos, sejam humanos, materiais ou financeiros. Grupos de processos de Monitoramento e Controle É neste grupo que o trabalho do projeto que está sendo executado é verificado para constatação da conformidade com o planejado. Caso ocorram divergências entre o planejado e o executado são tomadas as medidas corretivas ou preventivas para realinhar o projeto com o planejado. Essa verificação considera as linhas de base de escopo, tempo, custo, qualidade, riscos e quaisquer outros parâmetros definidos no plano de gerenciamento do projeto. Grupo de processos de Encerramento O grupo de processos de Encerramento inclui a confirmação de que o trabalho está em conformidade com os requisitos, a aceitação formal do produto pelo cliente, a emissão de relatórios de desempenho finais, a indexação e arquivamento dos registros, a atualização da base de conhecimento de lições aprendidas, o encerramento do projeto e a liberação dos recursos do projeto. Nível de interação entre grupos de processos Repare na figura a seguir como é o nivel de interação existente entre os diferentes grupos de processos de gerenciamento. Se for tirada uma foto em qualquer momento do projeto, poderá ser observado que existem processos de gerenciamento pertencentes a grupos de processos diferentes sendo executados simultaneamente. 40 Intensidade Execução Planejamento Encerramento Grupos de processos x fases do projeto x ciclo de vida do projeto Para que não haja dúvida entre os termos, vamos revisá-los? Grupo de processos de gerenciamento de projetos: é o agrupamento lógico dos processos de gerenciamento de projetos que podem incluir processos de iniciação, processos de planejamento, processos de execução, processos de monitoramento e controle e processos de encerramento. Em conjunto, esses cinco grupos são necessários para qualquer projeto, pois possuem claras dependências internas e devem ser realizados nessa mesma sequência em cada projeto, independentemente da área de aplicação ou das especificações do ciclo de vida do projeto aplicado. Os grupos de processos de gerenciamento de projetos não são fases do projeto. Fase do projeto: é o conjunto de atividades relacionadas de forma lógica que geralmente culminam com o término de uma entrega importante. Na maioria dos casos, as fases do projeto são terminadas sequencialmente, mas podem se sobrepor em algumas situações. As fases podem ser subdivididas em subfases e depois em componentes. Uma fase do projeto é um componente do ciclo de vida do projeto. Uma fase do projeto NÃO é um grupo de processos de gerenciamento de projetos. Ciclo de vida do projeto: é o conjunto de fases do projeto, geralmente em ordem sequencial, cujos nomes e quantidades são determinados pelas necessidades de controle da organização ou organizações envolvidas no projeto. 4