Gesto de projetos

Aplicada Web

Professor

Joo Carlos Carib

caribe@entropia.blog.br

Introduo
Histria da Gerncia de Projeto

4
5

Gesto de projetos na prtica Anatomia de um projeto

Variveis controlveis e incontrolveis
Variveis controlveis ou previsveis Variveis incontrolveis ou imprevisveis

6 7
8
8 8

As variveis do tringulo de gerncia de projeto

Tempo ou prazo Custo Escopo ou contexto

9
9 9 9

Caminho crtico
Relacionamento entre tarefas

10
10

Plano de contingncia
Princpio de Pareto

11
12

Etapas de um projeto
Ciclo de monitoramento e controle

12
13

Abordagens em gesto de projeto

Abordagem tradicional Desenvolvimento gil de software SCRUM Caractersticas de Scrum
Backlog de produto e backlog de sprint Planejamento de sprint Scrum simplicado Algumas caractersticas de Scrum

13
13 15 15 16
17 17 17 18

Agendando discusses dirias Scrum Solo

18 18

Gesto do conhecimento em gesto de projetos 19

Mind maps 19

Tecnologias disponveis
Para uso no computador
Microsoft Project Serena Open Project

20
20
20 20

Para uso online

Serena Projects on demand dotProject

20
20 20

Tecnologias auxiliares
Mindmeister

20
20

Introduo
Gerncia de projetos ou gesto de projetos a aplicao de conhecimentos, habilidades e tcnicas na elaborao de atividades relacionadas para atingir um conjunto de objetivos pr-denidos. O conhecimento e as prticas da gerncia de projetos so mais bem descritos em termos de seus processos componentes. Esses processos podem ser classicados em cinco grupos de processo (iniciao, planejamento, execuo, controle e encerramento) e nove reas de conhecimento (gerncia de integrao de projetos, gerncia de escopo de projetos, gerncia de tempo de projetos, gerncia de custo de projetos, gerncia de qualidade de projetos, gerncia de recursos humanos de projetos, gerncia de comunicaes de projetos, gerncia de riscos de projetos e gerncia de aquisies de projetos). Reduzida sua forma mais simples, a gerncia de projetos a disciplina de manter os riscos de fracasso em um nvel to baixo quanto necessrio durante o ciclo de vida do projeto. O risco de fracasso aumenta de acordo com a presena de incerteza durante todos os estgios do projeto. Um ponto-de-vista alternativo diz que gerenciamento de projetos a disciplina de denir e alcanar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espao, etc). A gerncia de projetos freqentemente a responsabilidade de um indivduo intitulado gerente de projeto. Idealmente, esse indivduo raramente participa diretamente nas atividades que produzem o resultado nal. Ao invs disso, o gerente de projeto trabalha para manter o progresso e a interao mtua progressiva dos diversos participantes do empreendimento, de modo a reduzir o risco de fracasso do projeto.

pgina 4

Histria da Gerncia de Projeto

Como uma disciplina, a gerncia de projeto foi desenvolvida de diversos campos de aplicao diferentes, incluindo a construo, a engenharia mecnica, projetos militares, etc. Nos Estados Unidos, o 'pai da gerncia de projeto Henry Gantt, chamado o pai de tcnicas do planejamento e do controle, que conhecido pelo uso do grco de 'barra' como uma ferramenta de gerncia do projeto, para ser um associado as teorias de Frederick Winslow Taylor da administrao cientca, e para seu estudo do trabalho e da gerncia do edifcio do navio da marinha. Seu trabalho o precursor a muitas ferramentas de gerncia modernas do projeto, tais como a WBS (work breakdown structure) ou EAP1 (estrutura analtica do projeto) de recurso que avalia o trabalho.

Grco de Gantt

Os anos 50 marcam o comeo da era moderna da gerncia de projeto. Outra vez, nos Estados Unidos, antes dos anos 50, os projetos foram controlados basicamente se utilizando os grcos de Gantt, tcnicas informais e ferramentas. Nesse tempo, dois modelos programando do projeto matemtico foram desenvolvidos: 1) de 'Program Evaluation and Review Technique' ou o PERT 2, desenvolvido como a parte programa do mssil do submarino Polaris da marinha dos Estados Unidos' (conjuntamente com o Lockheed Corporation); e o 2) 'Critical Path Method' (CPM) desenvolvido em conjunto por DuPont Corporation e Remington Rand Corporation para projetos da manuteno de planta. Estas tcnicas matemticas espalharam-se rapidamente em muitas empresas. Em 1969, o Project Management Institute (PMI3) foi dando forma para servir ao interesse da indstria da gerncia de projeto. A premissa de PMI que as ferramentas e as tcnicas da gerncia de projeto so terra comum mesmo entre a aplicao difundida dos projetos da indstria do software indstria de construo. Em 1981, os diretores do PMI autorizaram o desenvolvimento de o que se transformou em um guia de projetos o 'Project Management Body of Knowledge'4, contendo os padres e as linhas mestras das prticas que so usados extensamente durante toda a prosso.

1 2 3 4

http://pt.wikipedia.org/wiki/EAP http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique http://www.pmi.org http://pt.wikipedia.org/wiki/PMBOK pgina 5

Gesto de projetos na prtica

Embora no percebamos, estamos o tempo todo planejando. Planejar faz parte da existncia humana, qualquer um planeja, vejamos: Atravessar a rua exige planejamento? Pegar nibus exige planejamento? Paquerar exige planejamento? Sendo voc um ser racional, voc planeja, ou por acaso atravessa a rua sem prestar ateno no sinal, ou sem avaliar a distncia e velocidade dos carros? Voc pega qualquer nibus? E na hora de paquerar, chega de qualquer jeito ou prefere antes observar e ver como vai chegar junto? Estamos o tempo todo avaliando risco, e avaliar riscos signica avaliar os riscos e as chances. Apesar do nome avaliar riscos tambm avaliar as chances. Estamos o tempo todo avaliando diversos fatores em nossas tomadas de deciso, na paquera avaliamos o contexto, as pessoas que esto prximas a nossa vitima. Depois e em geral tentamos um gesto que sirva para sondar a nossas chances. Se tudo der certo tentamos uma abordagem direta. Veja que isto esta no nosso DNA, somos seres planejadores, quando deixamos de planejar o fazemos por puro livre arbtrio, ou na pior das hipteses por pura imaturidade, desconhecimento ou limitaes. Crianas abaixo de dez anos no conseguem avaliar elementos variveis como a velocidade e distncia dos carros, por isto nunca devem atravessar a rua sozinhas, mas agem assim por imaturidade. Um portador de decincia visual, no consegue pegar um nibus sozinho porque possui limitaes fsicas que o impedem de fazer isto sozinho. Um analfabeto tambm no consegue distinguir duas linhas de nibus da mesma empresa de transportes, pois lhe falta conhecimento para identicar as siglas numricas que representam cada linha, mas mesmo assim conseguem contornar esta limitao decorando o smbolo numrico que representa a linha de nibus.

pgina 6

Anatomia de um projeto
Para explicar um pouco mais sobre projetos e gesto de projetos, vamos fazer uma analogia didtica usando como exemplo a atividade de pegar nibus. Responda algumas perguntas: Voc pega qualquer nibus? Se o nibus estiver lotado voc esperar o prximo? O dinheiro esta trocado? Separado? Onde existe mais chance de ter um lugar livre? Meu ponto esta chegando, preciso me dirigir saida? Provavelmente voc no pega qualquer nibus, decide o nibus a pegar em funo de diversas variveis como por exemplo: Qual nibus pegar depende do trajeto, pode ser para onde voc deseja ir s tenha uma linha de nibus ou pode ser que praticamente todos passem no seu destino. Se voc for uma pessoa com hbitos prativos5, deve estar com tempo suciente para ch e g a r a o s e u d e s t i n o a t o h o r r i o programado e pode se dar ao luxo de aguardar o nibus mais vazio passar. Quem utiliza dinheiro para pagar a passagem, costuma ter mo dinheiro trocado, e separado para pagar a passagem, assim evita que a la que engarrafada esperando voc pagar, e no costuma chamar ateno para o dinheiro que tem em sua carteira.

Pintura de Joo Werner

Ao entrar no nibus, caso ele esteja cheio, voc costuma se deslocar para o fundo 6, prximo sada de forma que que mais fcil para descer, e onde existe maior probabilidade de algum levantar e voc conseguir sentar. Estas variveis dependem de diversos fatores, inclusive caractersticas fsicas do nibus e o fato de conhecer as pessoas que pegam diariamente, assim ca mais fcil saber quem desce onde e quando, e se posicionar com preciso prximo pessoa onde existe maior chance de voc sentar. Isto se aprende no ciclo de projetos, no caso andar de nibus, e onde os conhecimentos so transformados e registrados, conrmando a mxima de que a prtica leva perfeio.
5 6

pr-ativo aquele que toma as iniciativas, que procura formas de resolver um problema de forma positiva No Rio de janeiro a maioria dos nibus possui a sua sada na parte traseira. pgina 7

Variveis controlveis e incontrolveis

Dentro de um ambiente de projetos, e at mesmo no seu dia-a-dia existem variveis que podem ser controladas e/ou previstas e outras que no podem ser previstas e/ ou controladas. Um bom planejamento leva ambas em considerao. Variveis controlveis ou previsveis Existem variveis previsveis e controlveis no seu ciclo de projeto, so variveis que voc conhece claramente. Por controlvel entendemos que algo que voc possa prever e/ou medir. Por exemplo tempo, valores, recursos so variveis controlveis. Voc no tem controle sobre o tempo, mas pode considera-lo em seus planejamentos, possvel calcular o tempo necessrio para executar uma tarefa, mas no se pode extende-lo por exemplo. possvel prever os recursos nanceiros, e atravs do controle possvel at mesmo redimensiona-los. possvel aumentar a produtividade de uma tarefa, otimizando os mtodos e processos utilizados e/ou alocando mais recursos humanos tarefa. No nosso exemplo, o valor da passagem e o tempo so variveis controlveis ou previsveis. Variveis incontrolveis ou imprevisveis So variveis que no podemos controlar, em geral imprevistos, ou atividades que dependam de terceiros. No nosso exemplo por exemplo no podemos controlar a hora exata em que o nibus vai passar no ponto, isto depende por exemplo da habilidade do motorista e de fatores imprevisveis do trnsito e do prprio nibus que pode por exemplo enguiar. Num planejamento de projeto, levamos em conta os recursos humanos partindo do principio de que eles estaro sempre disponveis para trabalhar e sempre com o mesmo nvel de produtividade, o que no verdade, funcionrios podem estar desmotivados, e podem faltar, e isto precisa ser levado em conta. Pode acontecer uma catstrofe, um recurso material pode ser danicado e/ou utilizado equivocadamente para outra tarefa, isto pode acontecer, assim como pode faltar determinado material, mas neste caso a falta pode se dar por diversos fatores: Pode ser que a entrega esteja atrasada, ou que ele tenha sido mal dimensionado, ou ainda que tenha sido providenciado tarde demais. Mas isto previsvel, voc pode se informar de todo o processo e considerar o prazo necessrio no seu
pgina 8

planejamento. O que seria imprevisvel neste caso por exemplo seria o roubo ou danicao de materiais. Controlar todas as variveis em todas as atividades de um projeto extremamente trabalhoso, prev-las muito mais difcil, por mais experiente que o gestor de projetos seja, ele sempre encontrar novas variveis em novos projetos.

As variveis do tringulo de gerncia de projeto

Alguns empreendimentos necessitam ser executados e entregues sob determinadas variveis. As variveis principais tambm podem ser denominadas como tradicionais. So eles o escopo, o tempo e o custo. Isto conhecido tambm como "tringulo da gerncia de projeto", onde cada lado representa uma varivel. Um lado do tringulo no pode ser mudado sem impactar no outro. A restrio do tempo inuencia o prazo at o termino do projeto. A restrio de custo informa o valor monetrio includo no oramento disponvel para o projeto. J a restrio do escopo designa o que deve ser feito para produzir o resultado de m do projeto. Estas trs variveis esto freqentemente competindo: o escopo aumentado signica tipicamente o tempo aumentado e o custo aumentado, uma restrio apertada de tempo poderia signicar custos aumentados e o escopo reduzido, e um oramento apertado poderia signicar o tempo aumentado e o escopo reduzido. A disciplina da gerncia de projeto sobre fornecer as ferramentas e as tcnicas que permitem a equipe de projeto (no apenas ao gerente de projeto) organizar seu trabalho para se encontrar com estas variveis . Tempo ou prazo O tempo requerido para terminar as etapas do projeto, normalmente inuenciado quando se pretende baixar o tempo para execuo de cada tarefa que contribui diretamente concluso de cada componente. Ao executar tarefas usando a gerncia de projeto, importante cortar o trabalho em diversas partes menores de modo que seja fcil denirmos condies de criticidade e de folga. Custo O Custo para desenvolver um projeto depende de diversas condies iniciais que possumos para o desenvolvimento de cada projeto tais como: custo de mo de obra, custos de materiais, gerncia de risco, planta (edifcios, mquinas, etc.), equipamento, e lucro. Escopo ou contexto So as exigncias especicadas para o resultado m, ou seja, o que se pretende, e o que no se pretende realizar. A qualidade do produto nal pode ser tratada como um componente do escopo. Normalmente a quantidade de tempo empregada em cada tarefa determinante para a qualidade total do projeto.

pgina 9

Caminho crtico
Existem atividades em um projeto que so mais importantes que as outras, muitas dependem de outras de alguma forma e precisam ser executadas porque afetam sensivelmente a execuo do projeto, estas tarefas so as chamadas tarefas do caminho crtico. Relacionamento entre tarefas Estas dependncias entre as tarefas pode se dar entre uma tarefa e outra, ou entre vrias tarefas e uma unica tarefa sucessora, ou entre diversas tarefas. Usando a lgica booleana, as relaes entre as tarefas podem ser de uma para uma, muitas para muitas, uma para muitas e muitas para uma. Basicamente existem quatro tipos de relacionamento entre tarefas: Termino para Inicio (TI) - O inicio de uma tarefa depende da concluso de outra, ou seja, para que a tarefa inicie, preciso que a outra seja concluda. Inicio para Inicio (II) - O inicio de uma tarefa esta relacionada ao inicio de outra, ou seja, para iniciar a tarefa precisamos que outra inicie tambm. Termino para Trmino (TT) - O trmino de uma tarefa depende do trmino de outra. Ou seja as duas tarefas precisam terminar juntas. Incio para Trmino (IT) - Esta a relao mais rara, mas possvel de acontecer, ou seja, uma tarefa s pode terminar se outra for iniciada. Existe ainda a chamada latncia, que signica um tempo adicional nos relacionamentos de tarefa acima. Por exemplo, na pintura de uma parede, existem trs tarefas: Aplicao da massa, lixamento da massa e pintura, entretanto existe a necessidade da massa secar, por exemplo ela precisa de 48 horas para secar completamente a ponto de ser lixada. Ento o relacionamento entre aplicao da massa e o lixamento da massa uma relao TI com latncia de 48 horas, ou seja aps terminar a aplicao da massa preciso esperar 48 horas para lixa-la. Voc pode aplicar a latncia em todos os tipos de relacionamento de tarefas, por exemplo pode usar uma relao II com uma latncia de 24 horas, de forma a que uma tarefa deve iniciar no dia seguinte ao inicio de sua predecessora. No nosso exemplo do nibus, supondo que tenhamos de pegar dois nibus para completar o trajeto, pegar o primeiro nibus uma tarefa predecessora para pegar o segundo, ou seja, a relao e n t r e p e ga r o p r i m e i r o Pegar o primeiro nibus Pegar o segundo nibus nibus e o segundo uma relao TI (trmino para incio). As tarefas que no possuem nenhum relacionamento, e isto normal de acontecer, no fazem parte do caminho crtico e podem ser executadas no momento que for mais conveniente para o gestor de projetos, em geral so programadas para serem
pgina 10

executadas em momentos de baixa atividade do projeto, para melhor aproveitamento da mo de obra.

Plano de contingncia
Seria timo se tudo na vida acontecesse como planejado, viveramos num mundo perfeito, onde tudo daria certo, tudo aconteceria no tempo programado, utilizaria os recursos alocados, e dentro do custo previsto... Que saco ! A vida seria um tdio, que graa teria? Muitas vezes sonhamos com um mundo perfeito, mas nos esquecemos que so as imperfeies do mundo que o torna interessante, que torna a vida desaadora, dando o seu tempero. Em gesto de projetos no poderia ser diferente, existe a famosa Lei de Murphi7 que quer dizer o seguinte: Se algo tiver de dar errado, vai dar errado!

Lembre-se das variveis incontrolveis ou imprevisveis, elas esto ai para dar o tempero do seu projeto. Gestores de projetos costumam considerar margens de segurana denidas com o apoio de gestores tcnicos que iro executar o projeto. Por exemplo, aplica-se uma margem de segurana na mo de obra, para cobrir eventuais faltas e atrasos, e para prover o projeto uma certa margem de manobra para que atividades de emergncia sejam executadas sem um impacto muito grande no prazo nal do projeto. Aplica-se uma margem de segurana nos recursos materiais prevendo desperdcios e eventuais danos ou extravios, mas as margens neste caso devem ser aplicadas com critrio para que a excessiva margem de segurana em materiais no seja um prejuzo no projeto. Um projeto bem planejado leva em conta o imprevisto, se alguma coisa der errado, o projeto vai parar? Pode-se executar outra tarefa enquanto resolvemos o problema que impede o andamento do projeto? E este problema pode ser simplesmente uma etapa de aprovao do cliente por exemplo. Neste caso as tarefas que no fazem parte do caminho crtico podem ser executadas para que a equipe no que parada por exemplo.

http://pt.wikipedia.org/wiki/Lei_de_Murphy pgina 11

Princpio de Pareto O principio de Pareto 8, tambm conhecida pela regra 80-20 se resume em que 80% dos efeitos so provenientes de 20% das causas. O estudioso de Administrao Joseph M. Juran identicou o principio que ganhou este nome aps o economista Italiano Vilfredo Pareto ter observado que 80% da renda Italiana proveniente de 20% da populao. Esta uma regra comum nos negcios, em geral 80% das suas vendas so provenientes de 20% de seus clientes. O princpio de Pareto um bom critrio para voc usar no planejamento e anlise do seu projeto. No estamos falando que a relao ser precisamente 80-20, pode-se variar entre 90-10 e 70-30, mas geral ca nesta faixa. Por exemplo 80% do custo do seu projeto esta relacionado 20% das tarefas, ou 80% do prazo esta relacionado 20% das tarefas, e por ai vai. O importante mesmo identicar no seu projeto quais as tarefas que fazem parte destes 20% e dedicar uma ateno especial elas.

Etapas de um projeto
Todo projeto desenvolvido em cinco etapas: Iniciao, planejamento, execuo, controle e concluso Iniciao a etapa onde tomamos conhecimento do projeto a ser feito, o momento da confeco do brieng, ou de sua leitura equipe, nesta hora onde surgem diversas dvidas do projeto. Em geral uma etapa que deve ser desenvolvida em uma reunio de brainstorm. Planejamento onde o projeto detalhado, se aplicarmos o principio de Pareto, onde investimos 80% do nosso tempo. o momento em que detalhamos as atividades, pesquisamos, determinamos prazos, alocamos recursos e custos. O resultado do planejamento uma lista de tarefas e/ou um grco de Gantt. Execuo o objetivo do projeto, a hora da verdade, quem executa o gestor tcnico, a hora de colocar o projeto em prtica. Controle, o gestor do projeto faz o controle da execuo, registrando tempo e recursos, e gerenciando as possveis mudanas. Concluso, bom concluso dispensa mais comentrios, a hora em que o projeto termina.

http://en.wikipedia.org/wiki/Pareto_principle pgina 12

Ciclo de monitoramento e controle Na verdade as cinco etapas do projeto no acontecem como uma seqncia linear, anal como j vimos existem problemas no previstos, existem ajustes serem feitos. E estes ajustes so feitos on the y, ou seja, durante a execuo do projeto, congurando um ciclo claro que passa por execuo, controle e planejamento.

Iniciao

planejamento

execuo

controle

concluso

Geralmente na hora da execuo que o planejamento posto a prova, o controle o acompanhamento que o gestor de projetos faz junto ao gestor tcnico, ele registra os tempos e uso de recursos. Este controle pode apontar tanto uma tendncia economia de recursos quando necessidade de utilizar recursos alem do planejado. atribuio do gestor de projetos revisar seu planejamento para avaliar os impactos destas variaes e tomar as devidas providncias.

Abordagens em gesto de projeto

Na indstria de informtica, geralmente h dois tipos de abordagens comumente utilizadas no gerenciamento de projetos. As abordagens do tipo "tradicional" identicam uma seqncia de passos a serem completados. Essas abordagens contrastam com a abordagem conhecida como desenvolvimento gil de software9, em que o projeto visto como um conjunto de pequenas tarefas, ao invs de um processo completo. O objetivo desta abordagem reduzir ao mnimo possvel o overhead. Essa abordagem bastante controversa, especialmente em projetos muito complexos. Mesmo assim, tem conquistado adeptos em nmeros crescentes. Nas ltimas dcadas, emergiram uma srie de abordagens na indstria em geral. Dentre essas abordagens se destaca a abordagem do PMBOK, que tem se tornado um padro de fato em diversas indstrias.

Abordagem tradicional
Na abordagem tradicional, a que vimos at agora, distinguimos cinco grupos de processos no desenvolvimento de um projeto: 1. 2.
9

Iniciao Planejamento

http://en.wikipedia.org/wiki/Agile_Project_Management pgina 13

3. 4. 5.

Execuo Monitoramento e Controle Encerramento

Nem todos os projetos vo seguir todos estes estgios, j que projetos podem ser encerrados antes de sua concluso. Alguns projetos passaro pelos estgios 2, 3 e 4 mltiplas vezes. O projeto ou empreendimento visa a satisfao de uma necessidade ou oportunidade, denida no texto acima como fase inicial na qual existem muitas reas e/ ou pessoas envolvidas. Em geral sempre existe mais que uma soluo ou alternativas para atender s mesmas necessidades. A tcnica usada para denir a soluo nal passa pelo desenvolvimento de alternativas extremas. A primeira de baixo custo que atende as necessidades mnimas para ser funcional. A segunda tenta atender a maior parte das as exigncias das diversas reas envolvidas no escopo que resulta num projeto com custo muito maior e pouco competitivo. A partir de ambas as alternativas desenvolvida uma soluo intermediria entre as mesmas, que atende a uma boa parte das exigncias com um custo competitivo. Vrios setores utilizam variaes destes estgios. Por exemplo, na construo civil, os projetos tipicamente progridem de estgios como Pr-planejamento para Design Conceitual, Design esquemtico, Design de desenvolvimento, construo de desenhos (ou documentos de contrato), e administrao de construo. Embora os nomes diram de indstria para indstria, os estgios reais tipicamente seguem os passos comuns resoluo de problemas (problem solving): denir o problema, balancear opes, escolher um caminho, implementao e avaliao. O gerenciamento de projetos tenta adquirir controle sobre trs variveis: tempo custo escopo Algumas literaturas denem como quatro variveis, sendo qualidade a quarta varivel, contudo a qualidade uma das principais componentes do escopo. Estas variveis podem ser dadas por clientes externos ou internos. O(s) valor(es) das variveis remanescentes est/esto a cargo do gerente do projeto, idealmente baseado em slidas tcnicas de estimativa. Os resultados nais devem ser acordados em um processo de negociao entre a gerncia do projeto e o cliente. Geralmente, os valores em termos de tempo, custo, qualidade e escopo so denidos por contrato. Para manter o controle sobre o projeto do incio ao m, um gerente de projetos utiliza vrias tcnicas, dentre as quais se destacam: Planejamento de projeto Anlise de valor agregado Gerenciamento de riscos de projeto Cronograma Melhoria de processo

pgina 14

Desenvolvimento gil de software

O desenvolvimento gil de software rene uma srie de metodologias de baixo overhead. Reconhecem que software algo difcil de controlar. Essas metodologias minimizam riscos garantindo que os engenheiros de software foquem em unidades menores de trabalho. Os mtodos geis diferenciam-se de outras metodologias mais "pesadas" (como por exemplo, o Modelo Cascata) na nfase que do a valores e princpios, ao invs de processos. Ciclos tpicos so de uma semana ou um ms, e no m de cada ciclo h uma reavaliao das prioridades do projeto - caracterstica que ele compartilha com metodologias de desenvolvimento iterativas, e com a maioria das teorias modernas de gerenciamento de projetos.

SCRUM
um dos mtodos da metodologia gil para gerenciamento de Projetos. Scrum vem sendo amplamente adotado por empresas como o porta Terra e a Globo.com, justamente por atender com preciso s necessidades do desenvolvimento de software e sites. Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricao de automveis 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 ecazes formao Scrum do Rugby (utilizada para reincio 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 denio 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 funo primria 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. Porm, 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 cientca, ou at mesmo o planejamento de um casamento. Mesmo que o Scrum tenha sido idealizado para ser usado em gesto de projetos de desenvolvimento de software, ele tambm pode ser usado para gerenciar equipes de
pgina 15

manuteno, ou como uma abordagem para gesto de programas: Scrum de Scrums.

Caractersticas de Scrum
Cada sprint uma iterao 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 xo de itens do backlog em uma srie de iteraes curtas ou sprints; Uma breve reunio diria ou scrum, onde cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm chamado de Standup Meeting, j que os membros do time geralmente cam em p). Uma breve sesso de planejamento, na qual os itens do backlog para uma sprint (iterao) so denidos; Uma retrospectiva, na qual todos os membros da equipe reetem sobre a sprint passada. O Scrum facilitado por um Scrum Master, que tem como funo primria remover qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas) mas atua como um rewall entre a equipe e qualquer inuncia desestabilizadora. Outra funo extremamente importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint. Scrum permite a criao de equipes auto-organizadas, encorajando a comunicao verbal entre todos os membros da equipe e entre todas as disciplinas que esto envolvidas no projeto. Um princpio chave do Scr um o reconhecimento de que desaos fundamentalmente empricos no podem ser resolvidos com sucesso utilizando uma
pgina 16

abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem emprica, aceitando que o problema no pode ser totalmente entendido ou denido, focando na maximizao da habilidade da equipe de responder de forma gil aos desaos emergentes. Um dos grandes defeitos do Scrum, porm, a abordagem de "receita de bolo" do gerenciamento de projetos exemplicado no Project Management Body of Knowledge ou Prince2, que tem como objetivos atingir qualidade atravs da aplicao de uma srie 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 Proprietrio do Produto e uma lista de requisitos que tipicamente vm do cliente. O backlog de sprint uma interpretao do backlog do produto e contm tarefas concretas que sero realizadas durante o prximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint so, ento, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nvel e o segundo contendo informaes sobre como a equipe ir implementar os requisitos. Planejamento de sprint Antes de todo sprint, o Proprietrio do Produto, o Scrum Master e a Equipe decidem no que a equipe ir trabalhar durante o prximo sprint. O Proprietrio do Produto mantm 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 ento planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto so ento destrinchados em tarefas que se tornam o backlog do sprint. Scrum simplicado Muitas organizaes tm sido resistentes s metodologias introduzidas em baixos nveis da organizao. Porm, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisvel ("stealth"), usando os trs passos: 3. 4. 5. Agende uma demonstrao do software com seu cliente em um ms a partir de agora; Como equipe, tome um ms para deixar o software pronto para uma demo, com funcionalidades prontas, no simplesmente telas; Na demonstrao, obtenha feedback e use-o para guiar o seu prximo ms de trabalho de desenvolvimento.

pgina 17

Algumas caractersticas de Scrum Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na sada); Entregas freqentes e intermedirias de funcionalidades 100% desenvolvidas; Planos freqentes de mitigao de riscos desenvolvidos pela equipe; Discusses dirias de status com a equipe; A discusso diria na qual cada membro da equipe responde s seguintes perguntas: O que z desde ontem? O que estou planejando fazer at amanh? Existe algo me impedindo de atingir minha meta? Transparncia no planejamento e desenvolvimento; Reunies freqentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso; Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer problema no visto; Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" no necessariamente signica "produzir mais". Agendando discusses dirias Um momento bom para as discusses dirias depois do almoo. Durante a manh pode ser complicado. Estas discusses de status no demoram e uma forma eciente de fazer estas reunies seria car em p e em frente a um quadro negro. Como as pessoas tendem a car cansadas depois do almoo, ter uma viva reunio em p nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manh, suas mentes esto focadas no trabalho e no em questes pessoais. Scrum Solo Scrum baseado em pequenas equipes. Ele permite a comunicao 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 beneciar de alguns princpios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo uma verso adaptada para uso de programadores solo.

pgina 18

Gesto do conhecimento em gesto de projetos

Mind maps
Mind maps so excelente ferramentas para planejamento e organizao de idias. Partem do conceito de que o ser humano tem diculdade de lidar com listas, apesar de usa-las diariamente. Mind maps utilizam o mesmo conceito de conexes e interconexes de ideias que utilizamos naturalmente para gerenciar nosso conhecimento, desta forma torna-se quase intuitivo para usar.

Mapa mental, mind map ou mapa semntico o nome dado para um tipo de diagrama, sistematizado pelo ingls Tony Buzan, voltado para a gesto de informaes, de conhecimento e de capital intelectual; para a compreenso e soluo de problemas; na memorizao e aprendizado; na criao de manuais, livros e palestras; como ferramenta de brainstorming (tempestade cerebral); e no auxlio da gesto estratgica de uma empresa ou negcio. Os desenhos feitos em um mapa mental partem de um nico centro, a partir do qual so irradiadas as informaes relacionadas. Eles podem ser feitos com um programa de computador adequado ou com canetas coloridas e um bloco de papel, e podem ser usados por todos os prossionais para gerenciar qualquer tipo de informao. Este mtodo de registro cada vez mais usado por uma srie de prossionais de todas as reas de conhecimento humano. Existem diversos programas para construo de mind maps, e inclusive um online e colaborativo, o Mind Meister em http://www.mindmeister.com. Em nosso curso utilizaremos mind maps para o planejamento de projeto, construo de brieng e organizao de idias.

pgina 19

Tecnologias disponveis
Existem diversas tecnologias disponveis on e ofine para gesto de projetos, a grande maioria esta disponvel gratuitamente. So elas:

Para uso no computador

Microsoft Project http://ofce.microsoft.com/pt-br/project/FX100487771046.aspx a verso comercializada pela Microsoft e o padro do mercado. O Microsoft project proporciona todas as ferramentas para gesto de projetos de acordo com as especicaes do PMI, e conta com a possibilidade de compartilhamento utilizando o Microsoft project server. Serena Open Project http://openproj.org/openproj O Serena Open Project muito semelhante ao Microsoft Project, em praticamente todas as suas funcionalidades, e inclusive l arquivos do Microsoft Project. Alem disto completamente gratuito e possui verses para Windows, Linux e Mac OS 10.

Para uso online

Serena Projects on demand http://openproj.org/pod uma verso online compatvel com o Serena Open Project, esta verso online permite mltiplos usurios. Para utilizar a verso online o usurio paga uma taxa mensal. dotProject http://www.dotproject.net/ O dotProject uma soluo online totalmente gratuita, necessrio um servidor com suporte a PHP e MySQL para sua instalao. Ele apresenta uma interface um pouco mais complexa que a dos demais gerenciadores e totalmente focado no uso colaborativo, contendo inclusive um forum de discuso, lista de links e arquivos dentro do ambiente de gesto de projetos.

Tecnologias auxiliares
Mindmeister http://www.mindmeister.com/ O Mindmeister uma ferramenta online para criao de mapas mentais, muito til na organizao de idias para o planejamento do projeto.
pgina 20