Prince 2

Project IN Controlled Enviromment. Padrão de gerenciamento de projetos criado pelo governo inglês. Metodologia da gerência de projeto que focaliza na organização, na gerência e no controle. Explanação de Prince2 do CCTA. (’89) – Português.

Que é a metodologia de Prince2? 

O método da gerência de projeto de Prince2 focaliza na organização, na gerência e no controle. Tornado originalmente em 1989 pelo computador e pela agência centrais das telecomunicações (CCTA) no Reino Unido como um padrão para ELA a gerência de projeto, ele extensamente é usada agora e é de “o padrão de facto” no Reino Unido para a gerência de projeto. A versão a mais atrasada do método, “PRINCE2”, é um abordagem genérico da gerência de projeto, que é usada para ELE e non se projeta.

PRINCE2 (PRojects IN Controlled Environments) processo-é baseado, fornecendo costurar e mudanças scaleable para a gerência eficaz dos projetos. Cada processo é definido com: entradas e saídas chaves, objetivos a ser conseguidos, e atividades a ser realizadas.Metodologia de Prince2

O método divide projetos em estágios manageable para incentivar o controle eficiente dos recursos e da monitoração regular do progresso. PRINCE2 “produto-é baseado”, significando as plantas do projeto estão focalizados em entregar resultados, e não simplesmente em planeá-los quando as atividades são feitas. É dirigido pelo business case do projeto que deve descrever a justificação, a dedicação e o rationale para os deliverables ou o resultado. O business case deve ser revisto para assegurar os objetivos é apropriado e é realizado. Também fornece uma língua comum através de um projeto e fornece limites de faturamento dentro de um framework contractual.

Origem de Prince2. História

Tornado originalmente em 1989 pelo computador e pela agência centrais das telecomunicações (CCTA) no Reino Unido como um padrão para ELE gerência de projeto. O CCTA foi rebatizado a OGC (Office of Government Commerce). O método foi baseado originalmente no ALERTA, um método da gerência de projeto criado por Simpact Sistema Ltd em 1975. O ALERTA foi adotado pelo CCTA em 1979 como o padrão a ser usado para todos os projetos do sistema de informação do governo. Quando o PRINCE foi lançado em 1989, substituiu eficazmente o ALERTA dentro dos projetos do governo.

Uso do método de Prince2. Aplicações

* Todas as sortes da gerência de projeto
* e non ELE baseou projetos

Etapas no framework de Prince2. Processo

1. Dirigindo um projeto. Etapas de que os membros de placa do projeto devem fazer exame para fornecer a sustentação e o steerage eficazes sem a dedicação excessiva do tempo.
2. Começar acima de um projeto. Como qualificar idéias iniciais e apontar uma placa do projeto que representa interesses do usuário, do fornecedor e de negócio.
3. Iniciando um projeto. Como qualificar inteiramente um projeto para o assegurar é provável se encontrar com seus objetivos finais, assegurando a compra organizational dentro antes da dedicação principal dos recursos.
4. Controlando um estágio. As etapas que do dia a dia uma gerente de projeto deve fazer exame para controlar o trabalho, reagir aos eventos e para escalar edições principais.
5. Entrega controlando do produto. As equipes das etapas devem fazer exame para concordar pacotes do trabalho, para relatá-los em seu progresso, e para entregar o trabalho terminado.
6. Limites controlando do estágio. Como se preparar para revisões da placa do projeto quando o progresso e as plantas futuras forem discutidos, e fora das condições da tolerância seguradas.
7. Fechamento. Como se fechar abaixo um projeto, como segurar siga em ações, como segurar revisões do benefício do projeto do borne.
8. Planeamento. Como planear, irrespective de quando o planeamento for feito.

Forças da metodologia de Prince2. Benefícios

* Método estruturado que fornece um abordagem padrão à gerência dos projetos, embodying práticas boas provadas e estabelecidas na gerência de projeto.
* Extensamente sendo reconhecido e compreendido lhe fornece uma língua comum para participants do projeto.
* Fornece o controle no uso dos recursos e para controlar o risco.
* Permite projetos de ter:
o Começo, meio e extremidade controlados e organizados;
o Revisões regulares do progresso à planta e ao business case;
o Pontos de decisão flexíveis;
o Controle managerial automático de alguns desvios da planta;
o Participação da gerência e do stakeholders em pontos apropriados;
o Incentiva as canaletas de comunicação entre o projeto, a gerência de projeto, e o stakeholders.
* Traz benefícios aos projetos individuais, incluindo:
o Definição dos papéis e das responsabilidades em cada nível;
o Reuniões e burocracia reduzidas, através da gerência pela exceção;
o Níveis apropriados de planear da elevação – prazo nivelado ao termo imediato de baixo nível;
o Separação de atividades da gerência das atividades técnicas;
o Uma apreciação melhor de riscos do projeto por toda interessado;
o Maneiras de controlar mudanças, reduzir o risco.

Limitações de Prince2. Desvantagens

* Prince2 não cobre contract management ou people management. Estes entretanto são cobertos pelos corpos do conhecimento de PMI (corpo profissional dos EUA) e de APM (no Reino Unido)

Suposições da metodologia de Prince2. Circunstâncias

* Os projetos são mais bem sucedidos quando controlados usando uma metodologia.

 

Fonte: http://www.pmkb.com.br

Você já ouviu falar em metodologia ágil? E em scrum?

Pois é pessoal, de tempos em tempos novas metodologias surgem no mercado, ou melhor, surgem muitas, porém poucas se consolidam e são adotadas pelos principais players do mercado de TI.

A SCRUM é uma das “novidades” que tem ganhado muita força no Brasil nos últimos 2 anos.

Veja abaixo uma descrição sucinta sobre a SCRUM:

Scrum é um método ágil para Gerenciamento de Projetos.

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo “The New New Product Development Game” (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna documentaram, conceberam e implementaram o Scrum, como descrito abaixo, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.

Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.

A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.

Mesmo que o Scrum tenha sido idealizado para ser usado em gestão de projetos de desenvolvimento de software, ele também pode ser usado para gerenciar equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum de Scrums.

Características de Scrum

* Cada sprint é uma iteração que segue o ciclo PDCA e entrega um incremento de software pronto.
* Um backlog é um conjunto de requisitos, priorizado pelo Product Owner (cliente);
* Há entrega de um conjunto fixo de itens do backlog em uma série de iterações curtas ou sprints;
* Uma breve reunião diária ou scrum, onde cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting, já que os membros do time geralmente ficam em pé).
* Uma breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;
* Uma retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master não é o líder da equipe (já que as equipes são auto-organizadas) mas atua como um firewall entre a equipe e qualquer influência desestabilizadora. Outra função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.

Scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto.

Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de “controle”. Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

Um dos grandes defeitos do Scrum, porém, é a abordagem de “receita de bolo” do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou Prince2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos.

Backlog de produto e backlog de sprint

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos.

Planejamento de sprint

Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Proprietário do Produto mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.

Scrum Simplificado

Muitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisível (”stealth”), usando os três passos:

* Agende uma demonstração do software com seu cliente em um mês a partir de agora;
* Como equipe, tome um mês para deixar o software pronto para uma demo, com funcionalidades prontas, não simplesmente telas;
* Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês de trabalho de desenvolvimento.

Algumas práticas de Scrum

* Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
* Entregas freqüentes e intermediárias de funcionalidades 100% desenvolvidas;
* Planos freqüentes de mitigação de riscos desenvolvidos pela equipe;
* Discussões diárias de status com a equipe;
* A discussão diária na qual cada membro da equipe responde às seguintes perguntas:
o O que fiz desde ontem?
o O que estou planejando fazer até amanhã?
o Existe algo me impedindo de atingir minha meta?
* Transparência no planejamento e desenvolvimento;
* Reuniões freqüentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso;
* Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
* Locais e horas de trabalho devem ser energizadas, no sentido de que “trabalhar horas extras” não necessariamente significa “produzir mais”.

Agendando discussões diárias

Um momento bom para as discussões diárias é depois do almoço. Durante a manhã pode ser complicado. Estas discussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manhã, suas mentes estão focadas no trabalho e não em questões pessoais.

Scrum Solo

Scrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um só programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma versão adaptada para uso de programadores solo.

 

Fonte: http://gestaodeprojetos.net

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos

  O “Project Management Body of Knowledge” (PMBOK® Guide) é um termo que abrange o universo do conhecimento da profissão de Gerenciamento de Projetos. Este universo de conhecimento vem dos praticantes e acadêmicos que utilizam e desenvolvem tanto as práticas amplamente testadas e aprovadas quanto aquelas modernas e inovadoras, com aplicação mais restrita.

A Guide to The Project Management Body of Knowledge – Fourth Edition (também chamado de PMBOK® Guide – Fourth Edition)

O livro identifica e descreve o subconjunto do universo do conhecimento de Gerenciamento de Projetos reconhecido como boas práticas em muitos projetos na maior parte do tempo, havendo consenso pelos praticantes sobre seus valores e aplicabilidade. Entretanto, a aceitação geral não representa a necessidade de aplicação uniforme em todos os projetos, devendo ser definido o que é apropriado para cada projeto / indústria.

O PMBOK® Guide também estabelece uma linguagem comum para a profissão, servindo de referência básica para qualquer um que se interesse pelo Gerenciamento de Projetos e, como tal, não deve ser encarado como um documento que contemple a totalidade do conhecimento de Gerenciamento de Projetos. Periodicamente serão feitas revisões e novas versões serão desenvolvidas.

O Project Management Institute é o autor e proprietário exclusivo do “A Guide to the Project Management Body of Knowledge”. O PMI possui e mantém com exclusividade todos os direitos e privilégios de copyright do PMBOK® Guide, sendo vedada a qualquer outra pessoa ou empresa a editoração, publicação, distribuição ou venda do livro ou de parte dele.

O desenvolvimento do PMBOK® Guide somente foi possível graças à dedicação e esforço voluntário de profissionais de Gerenciamento de Projetos de várias partes do mundo, que contribuem decisivamente para o avanço contínuo desta profissão.

A estrutura do PMBOK® Guide contempla nove áreas de conhecimento específicas, a saber:

Gerenciamento da Integração do Projeto;

Gerenciamento do Escopo do Projeto;

Gerenciamento do Prazo do Projeto;

Gerenciamento do Custo do Projeto;

Gerenciamento da Qualidade do Projeto;

Gerenciamento dos Recursos Humanos do Projeto;

Gerenciamento da Comunicação do Projeto;

Gerenciamento dos Riscos do Projeto;

Gerenciamento das Aquisições do Projeto.

 

Fonte: http://www.pmisp.org.br/pmbok.asp