Click here to load reader

Unificando PMBOK e SCRUM no gerenciamento de projetos

  • View
    141

  • Download
    1

Embed Size (px)

Text of Unificando PMBOK e SCRUM no gerenciamento de projetos

  • UNIVERSIDADE FUMEC

    FACULDADE DE CINCIAS EMPRESARIAIS - FACE

    ALEXANDER CORREIA MARQUES

    MTODOS HBRIDOS:

    Unificando o framework SCRUM e guia o PMBOK para uma gesto gil de projetos

    Belo Horizonte

    2015

  • ALEXANDER CORREIA MARQUES

    MTODOS HBRIDOS:

    Unificando o framework SCRUM e o guia PMBOK para uma gesto gil de projetos

    Artigo Cientfico apresentado UNIVER-SIDADE FUMEC como requisito parcial para obteno do certificado de Especia-

    lista em Gerenciamento Estratgico de Projetos Orientador: Prof. Renato vila Soares

    Souza

    Belo Horizonte

    2015

  • RESUMO

    O termo projetos caracterizado por incertezas e mudanas. Com isso, im-

    portante se preocupar com o seu gerenciamento. Cada dia que passa, as organiza-

    es possuem a necessidade de resultados mais geis. Mesmo possuindo diferentes caractersticas e nveis de maturidade, a maioria tem dificuldade em ge-renciar projetos. Sendo assim, o objetivo desse estudo foi a utilizao de uma tcni-

    ca nica de gerenciamento de projetos. Para tanto, utilizou-se um estudo bibliogrfico das abordagens PMBOK e SCRUM. A coleta de informaes foi reali-zada atravs de um levantamento bibliogrfico e os resultados obtidos mostram que

    a implementao de uma metodologia gil de gesto de projetos pode ajudar uma organizao a controlar melhor suas entregas, burocratizar menos os projetos e, a-lm disso, gerar mais valor aos seus clientes.

    Palavras-chave: Gerenciamento de Projetos. PMBOK. SCRUM.

    ABSTRACT

    The term projects is characterized by uncertainty and change. Thus, it is im-

    supporting worry about their management. Each day that passes, organizes tions have the need for more agile results. Even with difference-ing characteristics and ma-turity levels, most have difficulty managing projects. Thus, the aim of this study was

    the use of a single technical project management. For this, we used a bibliographic study of PMBOK and SCRUM approaches. Data collection was conducted through a literature review and the results show that the implementation of an agile project

    management can help an organization better control your deliveries, less bureaucra-tized projects and also generate more value to its customers.

    Keywords: Project Management. PMBOK. SCRUM.

  • 3

    1. INTRODUO

    Gerenciar projetos que estejam dentro do oramento, prazo e qualidade, e que

    atendam as necessidades e os objetivos dos clientes so grandes desafios que te-

    mos atualmente. Muitos fatores existentes fazem com que vrios projetos no te-

    nham o sucesso esperado.

    O PMI possui um guia de gerenciamento de projetos que atualmente um dos

    mais utilizados no mundo, porm, muitas pessoas se queixam desse guia ser muito

    engessado e complexo. J o SCRUM um framework leve para desenvolver e man-

    ter produtos complexos, alm de ser muito utilizado na rea de desenvolvimento de

    software. Todavia no possui quase nenhuma formalizao e por conta disso no

    possui muita aceitao dos clientes envolvidos nesse tipo de projeto.

    Os mtodos utilizados nesse trabalho so uma pesquisa bibliogrfica e um estu-

    do sobre o gerenciamento gil em projetos, usando o mtodo tradicional do guia do

    PMI e o framework SCRUM.

    O trabalho proposto permite explorar o que melhor existe nas duas tcnicas com

    objetivo de unificar o gerenciamento de projetos e entregar para o cliente o que de

    fato ele considera como importante. Os meios para atingir o objetivo sero discutidos

    ao longo deste trabalho.

    2. PROJETO

    Nas empresas e em nossas vidas pessoais, utilizamos e ouvimos falar cons-

    tantemente a palavra projeto. Temos a necessidade de utiliz-la, pois, a todo o mo-

    mento buscamos atingir um objetivo no qual no possvel alcan-lo sem que haja

    um esforo. Segundo o PMI (2013, p.03)1, Projeto um esforo temporrio empre-

    endido para criar um produto, servio ou resultado exclusivo. A natureza dos proje-

    tos indica que eles tm um incio e um trmino definidos.

    Para Cruz (2013), os projetos no possuem durao fixa.

    Um projeto pode ter durao de horas, semanas ou anos, alm de no haver restries para pessoas envolvidas ou recursos alocados. Um projeto pode ser: A criao de um novo sistema de tecnologia da

    1 Project Management Institute, Inc, Um guia do Conhecimento em Gerenciamento de Projetos (Guia

    PMBOK), elaborado aps consenso de voluntrios por meio de um processo para o desenvolvimento desses padres. Neste artigo ser utilizado PMI como referncia ao Guia PMBOK.

  • 4

    informao; A concepo de um novo modelo de automvel; Uma pesquisa para o desenvolvimento de um novo medicamento; O lan-amento de uma nova campanha de marketing. (CRUZ, 2013, p.02).

    2.1. Gerenciamento de projetos

    De acordo com Kerzner (2007, p15),A gesto de projetos pode ser definida

    como o planejamento, a programao e o controle de uma srie de tarefas integra-

    das de forma a atingir seus objetivos com xito, para benefcio dos participantes do

    projeto. Para o PMI (2013, p.06), o gerenciamento de um projeto inclui, mas no se

    limita a:

    Identificao dos requisitos;

    Tratamento das diferentes necessidades, preocupaes e expectativas

    das partes interessadas no planejamento e execuo do projeto;

    Estabelecimento, manuteno e execuo de comunicaes ativas, e-

    ficazes e colaborativas entre as partes interessadas;

    Gerenciamento das partes interessadas visando o atendimento aos re-

    quisitos do projeto e a criao das suas entregas;

    Equilbrio das restries conflitantes do projeto que incluem, mas no

    se restringem a:

    o Escopo;

    o Qualidade;

    o Cronograma;

    o Oramento;

    o Recursos;

    o Riscos.

    Segundo Cruz (2013, p11), O gerenciamento de projetos a aplicao con-

    trolada e coordenada de conhecimentos, habilidades, ferramentas e tcnicas aos

    eventos do projeto a fim de atingir seus objetivos.

    2.2. Ciclo de vida e fases em gerenciamento de projetos

    De acordo com o PMI (2013), no incio de um projeto os nveis de custo e

    pessoal so baixos, todavia, atingem um valor mximo enquanto o projeto execu-

    tado e caem de forma acelerada quando o projeto finalizado. Os projetos possuem

  • 5

    diferentes caractersticas, tamanhos e complexidades, porm podem ser definidos

    em uma estrutura genrica apresentada na figura 01.

    Figura 01 Nveis tpicos de custo e pessoal em toda estrutura genrica do ciclo de

    vida de um projeto

    Fonte: PMI, 2013, p.39

    De acordo com o PMI (2013), os riscos e incertezas so maiores no incio do

    projeto. A medida que ocorrem entregas e decises so tomadas esse risco diminui.

    J o custo de mudanas nos projetos menor no incio e aumenta gradativamente

    ao longo do projeto. Na figura 02 possvel ver tal variao.

    Figura 02 Impacto de varivel com base no tempo do projeto

    Fonte: PMI, 2013, p.40

  • 6

    De acordo com Rita (2009), para o gerenciamento nos pequenos projetos uti-

    lizam-se os processos de iniciao, planejamento, execuo, controle e monitora-

    mente e encerramento. Todavia, em grandes projetos se faz necessria a diviso em

    fases, onde o processo pode ser repetido diversas vezes. Portanto, a medida que

    uma fase realizada, executam-se todas as etapas do processo, desde a iniciao

    at o encerramento. Aps a finalizao, passa-se para a fase seguinte e executa-se

    o processo at o trmino de todas as fases.

    Segundo o PMI (2013, p.42), no existe uma estrutura ideal que pode ser a-

    plicada a todos os projetos. Embora prticas comuns no setor normalmente levem

    utilizao de uma estrutura preferida. Na figura 03 apresentado um exemplo de

    projeto com uma nica fase.

    Figura 03 Exemplo de projeto com fase nica

    Fonte: PMI, 2013, p.42

    Conforme o PMI (2013), quando os projetos tm vrias fases, estas so par-

    tes, em geral, de um processo sequencial projetado para garantir um controle ade-

    quado do projeto e obter o produto, servio ou resultado desejado. Na figura 04

    apresentado um projeto contendo mais de uma fase de forma sequencial.

  • 7

    Figura 04 Exemplo de projeto com trs fases

    Fonte: PMI, 2013, p.43

    2.2.1. Ciclo de vida iterativo e incremental

    Segundo o PMI (2013, p.45), Ciclos de vida iterativos e incrementais so a-

    queles em que a fase do projeto (tambm chamada de iteraes) intencionalmente

    repete uma ou mais atividades de projeto medida que a compreenso do produto

    pela equipe do projeto aumenta.

    Ainda de acordo com o PMI (2013), desenvolvida uma viso de alto nvel

    sobre o produto ou servio. Contudo, o escopo detalhado e elabora uma iterao

    de cada vez, permitindo que ocorram diversas entregas e que se somadas resultam

    na entrega total do projeto. Este tipo de ciclo normalmente utilizado quando se tem

    muitas mudanas no objetivo e escopo do projeto e quando as entregas realizadas

    s partes interessadas por cada iterao so benficas e geram valor ao negcio.

    Para Cruz (2013, p.17), o incremental vem exatamente do fato que, a cada

    entrega (final da fase), o produto ganha mais um pedao e vai crescendo e sendo

    incrementado com mais valor, at que se torne um produto completo.

    2.2.2. Ciclo de vida adaptativo

    Segundo Cruz (2013), o ciclo de vida adaptativo tambm iterativo e incre-

    mental, porm se diferencia pelo fato de possuir iteraes bem mais rpidas com

    tempo e custo fixo. O PMI da importncia para este tipo de ciclo cada vez mais usu-

    al. De acordo com o PMI (2013, p.46),os mtodos adaptativos geralmente so pre-

    feridos quando se lida com um ambiente de rpida mutao, quando os requisitos e

    escopo so difceis de definir antecipadamente, e quando possvel definir peque-

    nas melhorias incrementais que entregaro valor s partes interessadas. Para o

  • 8

    PMI (2013), o intuito deste ciclo manter as partes interessadas mais altamente in-

    fluenciadas reduzindo assim o custo com mudanas.

    2.3. Maturidade em gesto de projetos

    De acordo com KERZNER (2007), todas as empresas atravessam o processo

    de maturidade em gerenciamento de projetos e isto precede o estado da arte.

    Existem fases do ciclo de vida para a maturidade em gesto de pro-jetos. Praticamente todas as empresas que alcanaram algum grau de maturidade passaram por estas fases. A cultura da organizao e a natureza do negcio iro ditar o tempo gasto em cada uma delas. (KERZNER, 2007, p.45).

    Na figura 05 so detalhadas as fases do ciclo de vida para a maturidade em

    gesto de projetos.

    Figura 05 Ciclo de vida da maturidade

    Fonte: KERZNER, 2007, p.45

    Segundo Kerzner (2007 p.52), uma empresa que conclui de forma eficiente

    todas as fases de maturidade est apta a responder com um sim as questes a

    seguir:

    Sua organizao adotou um sistema de gesto de projetos e o utilizou?

    Introduziu uma metodologia que conduziu ao sucesso em gesto de

    projetos?

  • 9

    Assumiu o srio compromisso com o planejamento ao lanar cada no-

    vo projeto?

    Minimizou o nmero de mudanas de escopo mediante o comprometi-

    mento com objetivos realistas?

    Reconhece que controle de custo e controle de produo so insepa-

    rveis?

    Escolheu as pessoas certas para a gesto de projetos?

    Os executivos recebem informaes em nvel de promotor do projeto

    em vez de aquelas destinadas aos gerentes de projetos?

    Os executivos reforaram o comprometimento dos gerentes de rea e

    deram verdadeiro apoio aos seus esforos?

    A empresa da mais ateno aos resultados do que aos prprios recur-

    sos?

    Ela incentiva e recompensa a melhoria na comunicao, cooperao,

    trabalho em equipe e confiana?

    Os gerentes seniores costumam partilhar o reconhecimento por proje-

    tos bem sucedidos com a equipe e com os gerentes de reas?

    A empresa tem por norma concentrar-se na identificao e correo

    antecipada, rpida e econmica dos problemas?

    Os participantes utilizam software de gesto de projetos mais como

    uma ferramenta e no como um substituto do planejamento bem feito e

    da comunicao interpessoal?

    Sua empresa instituiu um programa de treinamento para todos os fun-

    cionrios baseado nas experincias aprendidas em projetos?

    Ainda segundo Kerzner (2007), o que funciona bem para uma empresa pode

    no funcionar bem a outra. As melhores prticas so desenvolvidas internamente

    observando o que executou com sucesso e o que tem maior probabilidade de fun-

    cionar bem no futuro se for repetido em vrios projetos com diversos clientes.

  • 10

    3. Metodologia de Gerenciamento de Projetos

    Segundo Xavier et al. (2014, p.163), uma metodologia apenas uma dimen-

    so do que necessrio para aumentar a maturidade em gerenciamento de proje-

    tos. Para tal, devemos: sistematizar o gerenciamento de projetos, programas e

    portflio, abordando as seguintes dimenses: pessoas (capacitao), processos

    (metodologia), governana (estrutura poltica) e tecnologia (software).

    3.1 PMBOK

    O guia do PMI uma referncia na rea de gerenciamento de projetos. Ele foi

    desenvolvimento por voluntrios e o seu contedo tem por objetivo ajudar as pesso-

    as a gerenciarem projetos utilizando as boas prticas. Para Mogollon (2014), o guia

    do PMI uma tima referncia na gesto de projetos.

    Um guia de boas prticas em gerenciamento de projetos o PMI, pois, ele rene processos, ferramentas, tcnicas e artefatos. Em mui-tos anos tem mostrado a sua eficincia no sucesso de um projeto. Alm disto, o PMI conta com uma base de vocabulrio que permite o intercambio e a troca de experincia entre os gerentes de projetos que praticam este gerenciamento. (MOGOLLON, 2014)

    O PMI possui cinco grupos de processos que abrangem dez reas de conhe-

    cimento. A partir desta unio o PMI 5 edio apresenta 47 processos que so suge-

    ridos no gerenciamento de um projeto desde o seu incio at o seu encerramento.

    De acordo com Cruz (2013, p.22 e 23), de forma resumida as 10 reas de co-

    nhecimento do Guia PMI so:

    Gerenciamento da integrao do projeto:

    a rea para consolidar, articular e integrar desde o incio do projeto

    at o seu final, gerenciando proativamente as expectativas das partes

    interessadas e contribuindo para atender os requisitos do negcio.

    Gerenciamento do escopo do projeto:

    a are que controla o que est e ou no includo no projeto.

    Gerenciamento do tempo do projeto:

  • 11

    a rea destinada a controlar o cronograma do projeto, bem como os

    esforos necessrios para realizar os trabalhos do mesmo, desde o i-

    ncio at o final das atividades.

    Gerenciamento de custo do projeto:

    Inclui atividades para controlar estimativas, oramentos e custos do

    projeto.

    Gerenciamento de qualidade do projeto:

    a principal rea para contribuio da melhoria contnua de procedi-

    mentos, metodologias e polticas envolvidas com a realizao e o ge-

    renciamento de projetos.

    Gerenciamento dos recursos humanos do projeto:

    Inclui as atividades que organizam e gerenciam a equipe do projeto.

    Gerenciamento das comunicaes do projeto:

    uma das reas mais importantes, pois, o gerente de projetos investe

    maior parte do seu tempo na comunicao com os membros da equipe

    e outras partes interessadas no projeto, tanto internas quanto externas

    a organizao.

    Gerenciamento de riscos do projeto:

    a principal rea e maior responsvel por aumentar a probabilidade e

    o impacto dos eventos positivos, conhecidos como oportunidades, e

    por reduzir a probabilidade e o impacto dos eventos negativos no proje-

    to.

    Gerenciamento das aquisies do projeto:

    a rea responsvel por gerenciar e monitorar os contratos do projeto.

    Gerenciamento das partes interessadas do projeto:

    a rea responsvel por manter um dilogo contnuo com os stake-

    holders do projeto para atingir suas necessidades e expectativas.

    A figura 06 ilustra as reas de conhecimento, os grupos de processo e os 47

    processos existentes no guia PMI.

  • 12

    Figura 06 Grupo de processos de gerenciamento de projetos e mapeamento das reas de

    conhecimento

    Fonte: PMI, 2013, p.61

  • 13

    Para Cruz (2013), o guia PMI flexvel e muito adaptvel, pois, o uso dos

    processos varia de projeto para projeto, considerando tamanho, complexidade, ex-

    tenso, valor e outras variveis mensurveis. Contudo, sua aplicao no simples

    e depende de fatores como experincia da equipe e metodologia utilizada.

    3.2 SCRUM

    O SCRUM um framework para gerenciamento de projetos que muito util i-

    zado na rea de desenvolvimento de software. Todavia, ele indicado principalmen-

    te para o desenvolvimento de qualquer produto, pois, um framework iterativo e

    incremental. De acordo com Cruz, (2013, p.31), os projetos so divididos em ciclos

    repetitivos (iterativos) e curtos, para que possam ser modificados e adaptados para

    corrigir os desvios (incrementais). Estes ciclos podem durar de duas a quatro sema-

    nas e so chamados de sprints. Na figura 07 possvel observar o ciclo clssico do

    SCRUM.

    Figura 07 Ciclo de desenvolvimento do SCRUM

    Fonte: Alan Braz, 2015

  • 14

    Para os criadores do SCRUM, Schwaber e Sutherland (2013, p.3), o SCRUM

    um framework dentro do qual as pessoas podem tratar e resolver problemas com-

    plexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o

    mais alto valor possvel. Ainda de acordo com Schwaber e Sutherland (2013), o

    SCRUM definido como um framework leve, simples de entender e extremamente

    difcil de dominar. Consistem nos times do SCRUM associados a papis, eventos,

    artefatos e regras.

    O SCRUM fundamentado nas teorias empricas. Schwaber e Sutherland

    (2013) afirmam que

    o conhecimento vem da experincia e de tomada de decises base-adas no que conhecido. O SCRUM emprega uma abordagem itera-tiva e incremental para aperfeioar a previsibilidade e o controle de

    riscos. (SCHWABER; SUTHERLAND, 2013, p.4).

    De acordo com Schwaber e Sutherland (2013, p.4), trs pilares apoiam o con-

    trole de processos emprico: transparncia, inspeo e adaptao.

    Transparncia: Aspectos significativos devem estar visveis aos res-

    ponsveis pelos resultados. Esta transparncia requer aspectos defini-

    dos por um padro comum para que os observadores compartilhem um

    mesmo entendimento do que est sendo visto;

    Inspeo: Os usurios SCRUM devem, frequentemente, verificar os ar-

    tefatos SCRUM e o progresso em direo a detectar variaes. Esta

    inspeo no deve, no entanto, ser to frequente que atrapalhe a pr-

    pria execuo das tarefas;

    Adaptao: Se um inspetor determina que um ou mais aspectos de um

    processo desviou para fora dos limites aceitveis, e que o produto re-

    sultado ser inaceitvel, o processo ou o material sendo produzido de-

    ve ser ajustado;

    O time SCRUM composto por: product owner, time de desenvolvimento e

    scrum master. Segundo Schwaber e Sutherland (2013), o produtct owner o res-

    ponsvel por maximizar o valor do produto ou do trabalho. Ele gerencia o backlog do

    produto e tem a viso geral do produto a ser concebido. O time de desenvolvimento

    composto por pessoas auto-organizadas e responsveis por transformar o backlog

    do produto em incrementos de funcionalidades potencialmente utilizveis. O SCRUM

  • 15

    master o responsvel por garantir que o SCRUM seja entendido e executado. A-

    lm disso, ele trabalha para o time de desenvolvimento ajudando a remover impedi-

    mentos e para o product owner encontrar tcnicas de facilitao no gerenciamento

    efetivo do backlog do produto.

    De acordo com Schwaber e Sutherland (2013), h eventos e artefatos no

    SCRUM usados para criar uma rotina, minimizar a necessidade de reunies no

    planejadas e fornecer transparncia e oportunidades para inspeo e adaptao. Os

    eventos e artefatos so listados no quadro 01.

    Quadro 01 Eventos e Artefatos do SCRUM

    Eventos e Artefatos

    SCRUM Propsito Regras

    Sprint

    Time-boxed de 1 ms ou

    menos, durante o qual um

    pronto verso incremental

    potencialmente utilizvel do

    produto, criado

    No so feitas mudanas que possam

    por em perigo o objetivo da Sprint;

    As metas de qualidade no diminu-

    em;

    O escopo pode ser clarificado e rene-

    gociado entre o Product Owner e o

    Time de Desenvolvimento quanto

    mais for aprendido.

    Reunio de planeja-

    mento

    O trabalho a ser realizado na

    Sprint planejado na reunio

    de planejamento da Sprint.

    Este plano criado com o

    trabalho colaborativo de todo

    o Time SCRUM

    Responde as seguintes questes:

    Qual o objetivo da sprint?

    O que pode ser entregue como re-

    sultado do incremento da prxima

    sprint;

    Como o trabalho necessrio para

    entregar o incremento ser reali-

    zado?

    Reunio Diria

    A Reunio Diria do SCRUM

    um evento time-boxed de

    15 minutos, para que o Time

    de Desenvolvimento possa

    sincronizar as atividades e

    criar um plano para as pr-

    ximas 24 horas. Esta reunio

    feita para inspecionar o

    Durante a reunio os membros do Time de

    Desenvolvimento esclarecem:

    O que eu fiz ontem que ajudou o

    Time de Desenvolvimento a aten-

    der a meta da Sprint?

    O que eu farei hoje para ajudar o

    Time de Desenvolvimento atender

    a meta da Sprint?

  • 16

    trabalho desde a ltima reu-

    nio diria, e prever o traba-

    lho que dever ser feito

    antes da prxima reunio di-

    ria

    Eu vejo algum obstculo que im-

    pea a mim ou o Time de Desen-

    volvimento no atendimento da

    meta da sprint

    Reviso da Sprint

    A reviso da sprint execu-

    tada no final da sprint para

    inspecionar o incremento e

    adaptar o Backlog do Produ-

    to se necessrio.

    A reunio de reviso inclui os seguintes

    elementos:

    Os participantes incluem o Time

    SCRUM e os Stakeholders chaves

    convidados pelo Product Owner;

    O Product Owner esclarece quais

    itens do Backlog do produto foram

    Prontos e quais no foram Pron-

    tos;

    O Product Owner discute o Bac-

    klog do Produto tal como est. Ele

    (ou ela) projeta as provveis datas

    de concluso baseado no progres-

    so at a data (se necessrio);

    O grupo todo colabora sobre o que

    fazer a seguir, e assim que a

    Reunio de Reviso da Sprint for-

    nece valiosas entradas para a Re-

    unio de Planejamento da prxima

    Sprint;

    Retrospectiva da Sprint

    A retrospectiva da sprint

    uma oportunidade para o

    Time SCRUM inspecionar a

    si prprio e criar um plano

    para melhorias a serem apli-

    cadas na prxima Sprint

    O propsito da retrospectiva da sprint :

    Inspecionar como a ltima Sprint

    foi em relao s pessoas, aos re-

    lacionamentos, aos

    processos e s ferramentas;

    Identificar e ordenar os principais

    itens que foram bem e as potenci-

    ais melhorias;

    Criar um plano para implementar

    melhorias no modo que o Time

    SCRUM faz seu trabalho

  • 17

    Backlog do produto O Backlog do Produto uma

    lista ordenada de tudo que

    deve ser necessrio no pro-

    duto, e uma origem nica

    dos requisitos para qualquer

    mudana a ser feita no pro-

    duto

    O Backlog do Produto lista todas as carac-

    tersticas, funes, requisitos, melhorias e

    correes que formam as mudanas que

    devem ser feitas no produto nas futuras

    verses. Os itens do Backlog do Produto

    possuem os atributos de descrio, ordem,

    estimativa e valor.

    Backlog da sprint

    O Backlog da Sprint um

    conjunto de itens do Backlog

    do Produto selecionados pa-

    ra a Sprint, juntamente com

    o plano para entregar o in-

    cremento do produto e atingir

    o objetivo da Sprint.

    Conforme o trabalho realizado ou com-

    pletado, a estimativa do trabalho restante

    atualizada. Quando elementos do plano

    so considerados desnecessrios, eles

    so removidos. Somente o Time de De-

    senvolvimento pode alterar o Backlog da

    Sprint durante a

    Sprint. O Backlog da Sprint altamente vi-

    svel, uma imagem em tempo real do tra-

    balho que o Time de Desenvolvimento

    planeja completar durante a Sprint, e per-

    tence exclusivamente ao Time de Desen-

    volvimento.

    Histria de usurio Identificar requisitos de ma-

    neira simples.

    Utilizar informaes como: Quem? O que?

    Aonde?

    Ex.: Como um [ator] eu quero [ao] para

    [funcionalidade].

    Fonte: Schwaber e Sutherland, 2013, p.12 a 15 (adaptado)

    4 UNINDO PMBOK X SCRUM

    De acordo com CRUZ (2013, p.46), o objetivo principal entre o SCRUM e o

    guia do PMI evidenciar de uma forma que se torne natural como uma etapa de um

    pode se encaixar em uma fase de outro, sem forar a barra. O SCRUM pode ser a-

    plicado a qualquer projeto que busque o gerenciamento gil, desde que ele seja a

    engrenagem principal.

  • 18

    4.1 Iniciao e planejamento

    Segundo Cruz (2013), no primeiro momento importante a utilizao dos pro-

    cessos do guia PMI para iniciar um projeto. Os clientes no abrem mo de uma for-

    malizao inicial, principalmente projetos grandes e complexos. Para isso so

    utilizadas tcnicas descritas no PMI, tais como:

    o TAP (Termo de Abertura do Projeto);

    o Identificao das partes interessadas;

    o Desenvolvimento do plano do projeto;

    o Criao do plano de gerenciamento comunicao;

    o Criao do plano de gerenciamento de riscos;

    o Criao do plano de gerenciamento qualidade;

    o Criao do plano de gerenciamento aquisies;

    o Criao do plano de gerenciamento das partes interessadas;

    o Criao do plano de gerenciamento do escopo.

    Vale ressaltar que os papis do gerente de projetos, product owner, scrum

    master e time de desenvolvimento participam desta fase inicial de planejamento do

    projeto e utilizam tcnicas do SCRUM, principalmente no plano de comunicao,

    como por exemplo, a utilizao no projeto do quadro kanban, a realizao dos even-

    tos de reviso e retrospectiva e a proximidade da equipe para interaes de desen-

    volvimento do projeto.

    De acordo com Cruz (2013), o product owner realiza o levantamento das his-

    trias com os clientes, com o objetivo de coletar e definir o escopo do projeto. Neste

    primeiro momento o importante detalhar as histrias das sprints mais prximas e

    que mais geram valor ao cliente. Os pacotes de trabalho levantados fornecem insu-

    mos para a criao da EAP (Estrutura Analtica do Projeto), que uma das ferra-

    mentas grficas mais utilizadas para visualizao dos entregveis do projeto.

    Ao final deste levantamento, definido o time e a quantidade de sprints ne-

    cessrias para a execuo do trabalho e utilizam-se os processos da rea de geren-

    ciamento de recursos humanos do PMI. Por fim gerado o backlog e apresentado

    as entregas equipe do projeto. Na figura 08 demonstrado o processo de levan-

    tamento do escopo.

  • 19

    Figura 08 Processo de levantamento do escopo

    Fonte: Criado pelo autor

    4.2 Execuo

    Para Schwaber e Sutherland (2013), aps apresentar o backlog do produto ao

    time, priorizada a sprint inicial, preparado o ambiente e definido o conceito de pron-

    to. Esse ltimo uma combinao para esclarecer de fato o que considerado pron-

    to para a equipe do projeto na concluso de uma histria. O product owner

    apresenta para o time o backlog contendo as histrias priorizadas referente s pr-

    ximas entregas. Cabe ao time realizar a estimativa de esforo necessrio para con-

    cluso destas histrias, comprometendo-se com as entregas e ao final quebrar as

    histrias em tarefas menores e mais fceis de serem desenvolvidas.

    De acordo com Cruz (2013), para gerenciar as entregas do projeto sugerido

    o detalhamento do cronograma definido no quadro 02.

    Id. Cronograma Data inicial Data Final

    01 Reunies de detalhamento de requisitos (itens de backlog)

    realizados antes da Sprint para definio do escopo

    DD/MM/AAAA DD/MM/AAAA

    02 Perodo de aprovao do escopo pelo cliente DD/MM/AAAA DD/MM/AAAA

    03 Prxima Sprint (Histria1, Histria 2, Histria 3) DD/MM/AAAA DD/MM/AAAA

    04 Finalizao da Sprint DD/MM/AAAA DD/MM/AAAA

    05 Reunio de reviso da sprint com o cliente DD/MM/AAAA DD/MM/AAAA

    06 Perodo de testes de validao e aceite do cliente DD/MM/AAAA DD/MM/AAAA

    07 Perodo de entrega do produto validado e aceito DD/MM/AAAA DD/MM/AAAA

    Fonte: Cruz, 2013, p.26 (adaptado)

  • 20

    Segundo Cruz, (2013), a execuo da sprint consiste em utilizar um quadro

    de tarefas, inserindo as histrias na primeira coluna, as tarefas na segunda, seguido

    pelas colunas: a fazer, fazendo e feito. Os integrantes do time pegam as tarefas lo-

    calizadas na coluna a fazer e as colocam na coluna fazendo. Assim que todas as a-

    tividades forem concludas, elas devem ser movidas para a coluna feito. Ao final da

    sprint o objetivo ter todas as tarefas de todas as histrias posicionadas na coluna

    feito. Na figura 09 possvel visualizar o quadro de tarefas.

    Figura 09 Quadro de Tarefas

    Fonte: Cruz, 2013, p.218

    4.3 Monitoramento

    De acordo com o guia do PMI (2013), o monitoramente contnuo do projeto

    deve fornecer a equipe do projeto uma compreenso clara da sade do mesmo.

    Cruz (2013) destaca que o SCRUM sugere que o quadro de tarefas seja atualizado

    diariamente. Alm disso, a reunio diria de 15 minutos proporciona ao time uma

  • 21

    inspeo de progresso na direo da meta da sprint. Uma forma de monitoramento

    importante do projeto a reunio de retrospectiva.

    Segundo Cruz (2013), a reunio de retrospectiva da sprint permite:

    o Registrar lies aprendidas;

    o Gerar painel de maturidade organizacional;

    o Atualizao do painel de controle;

    o Reportar o desempenho;

    o Monitorar e controlar os riscos.

    4.4 Encerramento

    Segundo Cruz (2013), nesta abordagem de gerenciamento unificado a fase re-

    lacionada s entregas. O encerramento de uma fase consiste na entrega de uma

    verso planejada, como por exemplo, o trmino de 4 sprints que pode resultar em

    uma entrega do produto real para o cliente de forma que gere valor para o mesmo.

    Para Cruz (2013), o encerramento de uma fase geralmente compreende os proces-

    sos de:

    o Entrega de valor;

    o Acompanhamento e orientao da homologao da entrega;

    o Controle da qualidade;

    o Atualizao do painel de controle com o quadro de tarefas (kanban);

    o Validao do escopo;

    o Gerenciamento de mudanas;

    o Controle de aquisies.

    Cruz (2013) cita que na fase de homologao o cliente pode identificar mudanas

    no projeto. Estas mudanas precisam ser aprovadas pelo comit de mudanas e en-

    tram no escopo da prxima entrega a ser realizada.

    Ainda de acordo com Cruz (2013), o encerramento do projeto ocorre quando to-

    das as fases forem encerradas e a documentao do projeto for preenchida. Para

    projetos com apoio de fornecedores, importante que os contratos sejam encerra-

    dos.

  • 22

    3 CONCLUSO

    O estudo realizado ao longo deste trabalho permite demonstrar que a unio do

    mtodo tradicional e gil busca um nico objetivo que o de atender os requisitos

    de negcio e qualidade solicitados pelo cliente. Os processos das reas de conhe-

    cimento presente no guia do PMI encaixam perfeitamente nos eventos, artefatos,

    papis e responsabilidades do SCRUM. As ferramentas aqui listadas so tcnicas

    que podem auxiliar a organizao no sucesso do projeto.

    Para definir uma metodologia a ser adotada no gerenciamento de projetos im-

    prescindvel conhecer os ativos organizacionais de uma empresa. A maturidade

    tambm extremamente importante para aplicao da metodologia. O que foi desen-

    volvido neste trabalho uma sugesto de utilizao. Cabe a organizao identificar

    o que melhor pra ela lembrando que o mais importante a gerao de valor para o

    cliente.

  • 23

    Referncias

    PROJECT MANAGEMENT INSTITUTE (PMI). Um guia do conhecimento em ge-

    renciamento de projeto: PMBOK.Quinta Edio, Project Management Institute, Inc,

    2013.

    SCHWABER, Ken e SUTHERLAND Jeff. Guia do SCRUM. Um guia definitivo para o

    SCRUM: as regras do jogo Disponvel em: . Acesso em: 01

    de mar 2015. Traduzido por Fbio Cruz, 2013

    CRUZ, Fbio. SCRUM e PMBOK unidos no gerenciamento de projetos. Brasport,

    2013.

    KERZNER, H. Gesto de projetos [recurso eletrnico]: as melhores prticas. Dispo-

    nvel em:

    . Acesso em: 13 dez. 2014, segunda edio, 2007.

    XAVIER, Magno da Silva et al. Metodologia de gesto de projetos Methodware. Dis-

    ponvel em:

    https://books.google.com.br/books?id=FwCoAgAAQBAJ&printsec=frontcover&dq=m

    etodologias+de+gerenciamento+de+projetos&hl=pt-

    BR&sa=X&ei=9tPrVMfEMfHLsASh9IGQDQ&redir_esc=y#v=onepage&q=metodologi

    as%20de%20gerenciamento%20de%20projetos&f=false. Acesso em: 23 fev. 2015,

    terceira edio, 2014.

    BRAZ, Alan. Precisa-se de Projetos Scrum pra Estudo de Caso. Disponvel em:

    .Acesso

    em: 07 dez. 2015.

  • 24

    MOGOLLON, Miguel Eduardo, As metodologias geis no framework do PMBOK. Um

    guia para PMPs,Disponvel em:http://blog.octo.com/pt-br/as-metodologias-ageis-no-

    framework-do-pmbok/>. Acesso em: 01 out. 2014.

    MULCAHY, Rita PMP. Preparatrio para o exame de PMP, 7. ed. So Paulo:

    RMC Publications, inc, 2011.