Olá pessoal na gravação de hoje eu vou falar para vocês sobre o ciclo de vida do projeto nós vamos ver que o ciclo de vida de um projeto nada mais é do que uma sequência de Fases que o projeto vai passar desde o seu início até o seu encerramento entender o ciclo de vida do projeto fornece pra gente um entendimento básico da estrutura básica para gestão de projetos independente do trabalho específico que esteja envolvido dentro do projeto e nós vamos ver que existem diversos tipos de ciclo de vida dentro de um projeto nós estamos acostumados
às vezes com ciclo de vida dentro da engenharia de software dentro da área de processo de desenvolvimento de software nós vimos muitos conceitos de ciclo de vida em Cascata espiral iterativo incremental adaptativo E isso não muda para a área de gestão de projetos embora que nós NS estejamos estudando processos propriamente ditos Estamos estudando projetos mas o conhecimento que vocês adquiriram em outras disciplinas de engenharia de software que tratam com ciclo de vida do processo esse conhecimento poderá ser reutilizado aqui inclusive é compatível com o que tá descrito dentro do pmbok o que nós temos que
lembrar é que o ciclo de vida de um projeto ele pode ser ou prescritivo onde você pode antever as atividades a seria desempenhadas dentro do projeto ou ele pode ser adaptativo tipo métodos ágeis onde as mudanças são bem-vindas elas são acolhidas e o processo é adaptado a partir dessas mudanças no no ciclo de vida prescritivo nós devemos lembrar que tanto o produto quanto as entregas os deliverables são definidos do início do projeto e todas as alterações de escopo do produto ou escopo do projeto são cuidadosamente gerenciados pois o ciclo prescritivo Teoricamente nós não deveríamos ter
grandes alterações no outro lado do espectro nós temos o ciclo de vida adaptativo onde o produto é desenvolvido em múltiplas interações e o detalhamento do escopo acontece de maneira oportuna no início de cada iteração só vai ser detalhado aquilo que vai ser implementado dentro da próxima iteração muito parecido com como nós vimos dentro de métodos ágeis por exemplo dentro do screw onde nós detalhamos o product backlog no nível de detalhe adequado apenas para a iteração que vai começar seguinte ao dia da reunião de planejamento de Sprint eu trouxe aqui para vocês algumas características do ciclo
de vida de projeto basicamente eu trouxe algumas figuras presentes no na quinta edição do pmbok só para que possamos entender melhor sobre o ciclo de vida do projeto Observe que nessa figura o que tá sendo exibido pra gente é que o custo com pessoal o custo com stepen ele começa baixo no início do meu projeto comform vocês podem ver aumenta muito durante a realização do meu projeto e cai rapidamente na Fas de encerramento do meu projeto essa é uma característica básica do ciclo de vida de um projeto principalmente os projetos prescritivos Eu troue também uma
outra figura aqui para vocês que associa na medida que o tempo do Projeto vai aumentando associa Qual que é a relação entre riscos e incertezas e e o custo de mudança associado com isso então Observe que os riscos e as incertezas acerca do projeto acerca dos requisitos são maiores no início do projeto e diminu com o passar do tempo os riscos vão sendo diminuído minimizados a partir do tempo na medida que as entregas são aceitas e as minhas decisões são tomadas Observe também que de outro lado o custo de alteração na medida que nós vamos
passa no projeto ele vai aumentando muito mais uma vez isso aqui é muito parecido com o ciclo de vida prescritivo já no em métodos ágeis com ciclo de vida adaptativo nós vamos vermos por exemplo que no método XP o Extreme programming um dos clims uma das reivindicações do método é justamente que você tem um curso de mudança uniforme dependente da fase da interação que você esteja no projeto seja no início ou seja no fim mas de maneira geral existe essa relação principalmente com os processos prescritivos onde o risco e incerteza é muito grande no início
vai diminuindo e o custo de alterações é menor no início e vai aumentando com o decorrer do tempo o que queria que vocês notarem que embora essas características que eu acabei de apresentar para vocês nesses dois gráficos estejam presentes em quase todos ciclo de vida projeto existem exceções conforme eu acabei comentar uma exceção do método de métodos usá tipo XP por exemplo os ciclos de vida adaptativos eles mantém uma alta influência dos stakeholders e menores custos de mudanças por todo o ciclo de vida isso é muito diferente dos ciclos prescritivos E conforme Eu já havia
dito para vocês é uma das características principais do método ag XP que reivindica que o Change cost Curve Ou seja a curva de custo de alteração ela é contínua no decorrer do ciclo de vida do projeto já vi alguns papers que mostra que isso não é totalmente verdade né que embora realmente haja uma redução no custo das alterações na medida que a gente avança no projeto ela não é uniforme existe realmente ainda mesmo métodos US aggis um aumento no curo de alterações na medida que a gente tá mais pro final do projeto mas é muito
menor realmente do que ciclos de vida prescritivo O que vocês vão perceber dentro dessas características do ciclo de vida do projeto é que todos os projetos praticamente podem ser mapeados para uma estrutura genérica de ciclo de vida eu vou tentar mostrar para vocês aqui talvez no próximo slide e essa estrutura ela é formado basicamente por algumas etapas que eu gostaria que vocês não confundissem o que nós vamos estudar talvez na próxima gravação que são os grupos de processo então Todo projeto possui uma estrutura genérica de ciclo de vida dentro da estrutura genérica ele é subdividido
em iniciação do projeto organização e planejamento execução do trabalho do projeto e encerramento mais uma vez nós vamos ver que isso é muito parecido com cinco grupos de processos que nós são descritos pelo pmbok para organizar e classificar os nossos processos mas não confunda esses dois termos Então nós não vamos confundir a estrutura genérica do ciclo de vida com os grupos de processos os grupos de processos pertencentes os processos que são pertencentes aos grupos de processo consem consistem de atividades que podem ser executadas e que são recorrentes dentro de cada fase do projeto bem como
o projeto como todo então uma grande diferença é que as cinco fases os cinco grupos de processos iniciação planejamento execução monitoramento controle e encerramento não estão Associados com a estrutura géria de ciclo de vida principalmente porque esses cinco grupos de processos eles podem acontecer dentro do seu projeto como todo mas também dentro de cada fase do seu projeto na primeira fase do meu projeto eu posso ter meus cinco grupos de processo na segunda fase os cinco grupos de processo na terceira fase os cinco grupos de processo e assim sucessivamente enquanto que na estrutura genérica eu
tenho essas quatro estruturas aqui no seu projeto como um todo então são coisas distintas Então vamos falar um pouco sobre as fases do projeto Acabei de tocar um pouco no assunto sobre fase do projeto nós já discutimos em outra gravação mas só para recapitulando aqui e aprofundando um pouco mais Lembrando que um projeto ele basicamente ele pode ser subdividido em várias fases né E lembrando que uma frase nada mais é do que uma coleção de atividades e tarefas de projeto que estão semanticamente relacionados e que geram uma ou mais entregas um ou mais deliverables deliverables
lembrando também que uma fase pode enfatizar processos de um grupo de processo em particular que nós vamos estudar nas próximas gravações mas o provável mesmo é que a maioria ou todos os process processos sejam executados de alguma forma em cada fase diferenciando então da estrutura genérica do ciclo de vida exibido no slide anterior normalmente as fases são sequenciais mas existe situações on que elas podem se sobrepor e também outra característica interessante a transição de uma fase A para uma fase subsequente B ou se você preferir o encerramento de uma fase se dá de alguma forma
com uma transferência que também é chamado de handoff do produto de trabalho produzido como entrega então handoff é o termo muito usado pelo pela gestão de projetos para indicar a transição de uma fase A para uma fase B sequencial a ela é o que nós chamamos dentro do processo Unificado a final de uma fase produzia que a gente chamava de Milestone o de Marco Então existe muitas muita relação entre o que a gente estudou já dentro da disciplina de de requisito projetos de software com que a gente tá estudando dentro de gerente gerência de projetos
tem o erro de grafia aqui ortografia é um ponto natural para reavaliar as atividades desempenhadas Terminamos uma fase podemos fazer uma avaliação para sabermos se o nosso projeto está indo de acordo com o planejado ou não existem alguns outros nomes pelos quais são conhecidos o handoff ou essa transição entre fases também é conhecido como Stage Gates Milestone que são os Marcos Face review Face Gate ou KP são todos nomes dados para essa transição formal que existe entre as do projeto prescritas no pmb a pergunta que Talvez possa ficar e que eu não tenho como responder
para vocês é qual é a quantidade ideal de Fases que nós devemos ter no projeto não existe essa relação nós temos projetos que vai ter uma fase só e projetos vão ter dezenas de Fases isso vai depender muito do contexto do seu projeto da natureza dele do estilo da equipe da organização da sua empresa onde você está inserido e assim sucessivamente o o que pode acontecer é que uma equipe do projeto pode decidir dividir o projeto em duas fases por exemplo enquanto uma outra equipe pode escolher gerenciar todo o trabalho em uma fase única ou
seja não existe um consenso vai depender de diversos fatores que nós vamos escrever eu trouxe aqui por exemplo por exemplo uma figura que eu peguei do pmb da quinta edição justamente mostrando isso eu tenho o exemplo de um projeto aqui que só tem uma fase Então esse projeto aqui basicamente de uma de uma de telecomunicação de gerenciamento e instalação de uma rede de telecomunicações basicamente é um processo de uma fase só onde é subdividido em algumas etapas iniciação planejamento execução e encerramento então conforme nós vimos existem essas subdivisões mas nós estamos tudo dentro de uma
mesma fase do projeto Eu também trouxe uma figura para vocês aqui que vai poder facilitar que vai mostrar um pouco mais sobre relacionamento quando o projeto tem mais de uma fase mas eu gostaria que vocês lembrassem também de uma característica importante porque nós já comentamos isso dentro da disciplina de processo de processo Unificado dentro da disciplina de geria de requisitos Talvez seja importante também lembrar aqui que existe um um dos artefatos produzidos em qualquer projeto é chamado estudo de viabilidade né muito parecido com o documento visão tem organização por exemplo que vai tratar o estudo
de viabilidade como um trabalho de pré-projetos nem tá dentro de alguma Fas fase específica do projeto tem alguma organização que pode tratar por exemplo estudo deidade como uma fase a primeira fase que acontece dentro do seu projeto é o que acontece por exemplo no processo Unificado né no processo Unificado a primeira fase que é inception que é concepção tem como dos principais objetivos produzir no final um documento visão que vai te dar estudo de viabilidade se devemos continuar ou não no projeto mas podemos ser organização que faz examente o contrário que pode por exemplo pegar
e tratar o estudo de viabilidade Como projeto totalmente sep para depois sim começarmos o projeto Ou seja é só para lembrarmos que essa questão de Fases ela varia muito de acordo com a organização com a equipe do projeto e com a natureza do próprio projeto bom agora que eu mostrei para vocês uma figura que mostra que é possível termos um projeto com uma fase apenas Eu gostaria de falar um pouco sobre o relacionamento entre fases para projetos com mais de uma fase nesse caso nós devemos lembrar que existem dois tipos de relacionamentos entre fases nós
temos o que é chamado relacionamento sequencial e temos também o chamado relacionamento de sobreposição que alguns momentos permite que trabalhemos em duas fases concomitantemente Então vamos começar com um relacionamento sequencial onde uma fase somente se inicia com o término da anterior aí eu trouxe uma figura aqui para vocês justamente mostrando um exemplo de um projeto de três fases então basicamente aqui eu tenho uma fase a uma fase b e uma fase c e observe que em cada uma das fases eu tenho basicamente aquelas aquela estrutura genérica que a gente vai ver que vai se transformar
em grupo de processo que é iniciar planejar executar e encerrar cada uma dessas minhas fases e nós temos também um outro exemplo que vou trazer um tipo de relacionamento de sobreposição basicamente a característica de um relacionamento de sobreposição é que uma fase inicia antes do término da fase precedente é o que nós chamamos de fast tracking então um dos objetivos de você trabalhar talvez com duas fases paralelo é tentar compactar o cronograma do projeto mas cuidado apesar disso ser possível em alguns casos nós temos que ter em mente que isso pode necessitar de mais recursos
para esse trabalho em paralelo e aumenta muito os riscos do do meu projeto agora que eu já mostrei então para vocês que um projeto é subdividido em fases e a quantidade de fase Independente de várias questões Ela depende na verdade da tipo de organização do tipo de equipe do tipo do próprio projeto uma vez visto isto vamos voltar aqui a nossa discussão para o ciclo de vida propriamente dito mas Lembrando que o ciclo de vida é subdividido em fases estudando as fases vamos voltar agora pro ciclo de vida eu vou voltar pro ciclo de vida
Talvez o mais tradicional que é o ciclo de vida prescritivo que nós já Vimos que não funciona muito para desento de software A não ser que você tenha os requisitos muito bem estabilizados então dentro do ciclo de vida prescritivo que é também conhecido como ciclo de vida dirigido por planos onde você tem um plano no início do seu projeto que vai nortear todo o trabalho da sua equipe dentro desse ciclo de vida o escopo do projeto data e custos necessário para as entregas previstas no escopo São determinados o quanto antes é tentarmos ingear por exemplo
muito similar ao ciclo de vida em Cascata onde nós primeiro coletamos todos os requisitos depois nós projetamos depois implementamos e assim sucessivamente trouxe até uma figura aqui de um ciclo de vida prescritivo que é que está presente no no pmb basicamente mostra essa questão nós temos um plano no início do projeto e nós vamos seguindo esse plano até o final do projeto o que vocês devem notar aqui então é que os projetos dirigidos por planos com ciclo de vida prescritivo procedem através de uma série de Fases sequenciais ou sobrepostas sendo que cada fase vai focar
em um subconjunto das atividades do projeto as alterações no escopo do projeto são cuidadosamente gerenciadas e requerem replanejamento e aceitação formal do novo escopo com relação ao ciclo de vida iterativo e incremental nós devemos lembrar então que as fases do projeto também são conhecidos como iterações e dentro desse ciclo de vida há uma repetição intencional das atividades do projeto na medida que o entendimento acerca do produto vai aumentando ao longo das interações dessa forma o produto é gerado iterativa e incrementalmente E durante cada iteração atividade de todos os grupos de processo de gão do projetos
serão executados nós vamos discutir mais uma vez com detalhes Quais são esses grupos de processo e quais são as atividades prescritas dentro de cada grupo nas próximas gravações então só mais uma vez se acordando do ciclo de vida iterativa incremental que eu acredito que não seja mais novidade para vocês dentro desse ciclo de vida na maioria dos projetos Nós criamos uma visão de alto nível que será desenvolvendo o entendimento geral e o escopo detalhado vai ser elaborado a cada iteração e lembrando também que uma entrega ou conjunto de entregas é disponibilizado no final de cada
iteração sendo que as iterações futuras podem incrementar as integras entregas feitas na interação corrente ou criar novas entregas muito parecido nós já vimos dentro da seja no processo Unificado Ou seja no método ágil SC é interessante também notar muita gente esquece disso que mesmo no ciclo de vida interativo inent normalmente o planejo para aeração subsequente ao que nós estamos no momento é executado dentro da interação atual ou seja tô da interação três alguém responsável da equipe normalmente o gerente de projetos ou product a caso seja scom já está fazendo grooming ou seja está fazendo detalhamento
do prod backlog ou do plano do projeto para a próxima iteração no caso para a iteração quatro lembrando também que Grandes projetos principalmente aqu são mais complexos normalmente são executados de forma interativa pois assim nós reduzimos os riscos pois nós atacamos os riscos o quanto antes entregamos código funcionando pro nosso cente quanto antes Caso seja um projeto para desenvolvimento de software e nós vamos incorporar as lições aprendidas e os feedbacks ao longo dessas iterações falamos então um pouco de pouco do ciclo de vida prescritivo falamos o ciclo de vida interativo incremental de um projeto nós
temos também o ciclo de vida adaptativo que são aqueles ciclos de vidas que são dirigidos por mudanças também são os nossos famosos e conhecidos métodos ágeis que também se baseia num ciclo de vida interativa incremental Mas tem como diferença principal que as interações são muito rápidas normalmente de duas À Quatro Semanas e as interações são sempre de tempo fixo Nós perdemos funcionalidades no final de uma interação mas nós não perdemos datas ou seja os tempos e as interações são fixas temos equipes que fazem interações por exemplo de dois dias temos equipes que fazem interações de
quatro semanas o que nós não recomendamos é interações muito longas pois os métodos ágeis trabalh com sistemas inconsistentes com requisitos inconsistentes então quanto antes nós apresentarmos pro nosso cliente o código funcionando e termos o feedback melhor ess são os principais objetivos dos métodos ágeis dentro desse ciclo de vida adaptativo onde se encontra os métodos ágeis normalmente executam-se vários processos em cada interação embora as interações iniciais possam se concentrar mais atividad de planejamento lembre do scrum dentro uma interação você tem no primeiro dia uma reunião de planejamento do Sprint onde você faz planejamento depois você fica
n Men do Dias fazendo código e no último dia você faz uma revisão do Sprint Ou seja você planeja você executa você faz retrospectiva e você encerra uma um Sprint uma interação dentro dos seus próprios ciclo de vida também com relação ao ciclo de vida adaptativo lembrando né que o escopo geral do projeto é decomposto em um conjunto de requisitos e de trabalho que vai ser executado pela equipe e essa posição do escopo do projeto é armazenado em um artefato chamado product backlog no início de cada iteração a equipe determina quantos itens daqueles de maior
prioridade podem ser entregues no final da iteração Lembrando que a estimativa dentro de métodos US aros é feito pelo time de desenvolvimento e não por um gerente de projetos e sendo que no final de cada interação o produto deve estar pronto e e vai ser revisado pelo cliente lembrando também que o cliente pode muito B bem rejeitar aquela entrega aí a dúvida que surge é como que então o time sabe se algo tá pronto ou não se é o cliente que bate o martelo lembre-se por exemplo que no Skunk existe uma definição que é compartilhada
por todos que é a definição de pronto que vai ser uma forma uma diretriz para sabemos se aquilo que nós estamos desenvolvendo está realmente pronto ou não mas é muito importante que o prodoctor rejeite a entrega caso ela não esteja dentro da definição de pronto e por exemplo no Passo nos testes de aceitação quando então que nós vamos usar C adaptativa a métodos ágeis Então os métodos ágeis são preferidos quando nós lidamos com um ambiente que está em constante mudança quando fica difícil detalhar todo o scope e os requisitos do seu projeto de antemão você
precisa de um entendimento de acumulando feedback do seu cliente ao longo das seus sprints ao longo das suas interações para aí sim começar a entender melhor seus requisitos e quando nós podemos entregar pequenos incrementos de funcionalidades e esses pequenos incrementos de funcionalidades vão agregar valor aos nossos stakholders quando nós temos essas características nós podemos Com certeza usar cicos de vida adaptativos e métodos os para al avancarmos nosso negócio até a próxima gravação
