Gesto de Projetos com SCRUM

Av. Carvalho Leal, N. 1336 Trreo Edifcio Empresarial Objetiva Cachoeirinha. Tel (92) 3631.9081

W W W .DI V U S. CO M .BR

Gesto de Projetos com SCRUM

SUMRIO
FIGURAS .................................................................................................................................................. 4 Liderana ................................................................................................................................................. 5 1.1. 1.2. 2. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 4. 4.1. 4.2. 4.3. 5. 5.1. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.3. 5.4. Entendendo Coaching ................................................................................................................. 5 O que no Coaching ................................................................................................................. 5 Facilitao........................................................................................................................................ 6 Introduo a Agilidade .................................................................................................................... 6 Os Princpios do Manifesto gil .................................................................................................. 7 Alguns Pontos Fundamentais sobre a Agilidade ......................................................................... 8 Metodologias geis ..................................................................................................................... 8 Produto do Ponto de Vista de Negcio ....................................................................................... 9 ROI ............................................................................................................................................. 10 Declarao de Viso .................................................................................................................. 10 Estimativa Inicial........................................................................................................................ 11 Diferencial do Scrum ..................................................................................................................... 11 Histria ...................................................................................................................................... 12 Como Ganhar essa Vantagem Competitiva .............................................................................. 12 E na prtica, como isso funciona? ............................................................................................. 13 O SCRUM ....................................................................................................................................... 13 O que SCRUM ......................................................................................................................... 13 Papis ........................................................................................................................................ 15 ScrumMaster ......................................................................................................................... 16 Product Owner ...................................................................................................................... 16 Time ....................................................................................................................................... 17 Gerenciamento de Escopo e Valor Agregado ao Negcio ........................................................ 18 Gerenciamento do Tempo ........................................................................................................ 19 2 Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

5.5. 5.6. 5.7. 5.7.1. 5.7.2. 5.7.3. 5.8. 5.9. 5.10. 5.11. 6. 6.1. 6.2.

Fluxo de Trabalho ...................................................................................................................... 19 Conceito de Sprint ..................................................................................................................... 20 Sprint Planning Meeting ............................................................................................................ 21 Daily Scrum Meeting ............................................................................................................. 22 Sprint Review Meeting .......................................................................................................... 22 Sprint Retrospective Meeting ............................................................................................... 23 Visibilidade, Inspeno e Adaptao......................................................................................... 23 Ajudando o Trabalho da Equipe atravs da Remoo Contnua de Impedimentos ................. 24 Definio de Pronto............................................................................................................... 25 Melhoria Contnua ................................................................................................................ 26

Outros Conceitos ........................................................................................................................... 26 PDCA .......................................................................................................................................... 26 Kanban....................................................................................................................................... 27

Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

FIGURAS
Figura 1 - Viso do Escopo do Negcio ................................................................................................. 10 Figura 2 - Exemplo de Mapa Mental ..................................................................................................... 11 Figura 3 - Viso Geral do Processo Scrum ............................................................................................. 14 Figura 4 - Histria do comprometimento x envolvimento.................................................................... 15 Figura 5 ScrumMaster deve atuar como facilitador........................................................................... 16 Figura 6 - Responsvel pela Gesto do Product Backlog ...................................................................... 17 Figura 7 - Time Interdisciplinar.............................................................................................................. 17 Figura 8 - Framework Scrum na viso geral .......................................................................................... 20 Figura 9 - Baralho de Planning Poker .................................................................................................... 21 Figura 10 - Exemplo de um quadro KanBan .......................................................................................... 24 Figura 11 - Grfico de Burndown do Projeto ........................................................................................ 24

Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

Liderana 1.1. Entendendo Coaching

Toda pessoa busca em sua vida, profissional e particular, conseguir alcanar seus objetivos. Para isto, este indivduo cria metas que iro ajud-lo durante o seu percurso no alcance de tais objetivos. A meta, que em sua definio representa a maneira que escolhemos para chegar ao nosso objetivo, ajuda as pessoas a terem um norte, mas muitas vezes o caminho para alcanar estas metas difcil. Neste ponto, o papel de coaching essencial para ajudar o indivduo a trilhar o caminho para o alcance das suas metas de uma forma mais simples. Um dos objetivos do coaching ajudar a desenvolver o potencial das pessoas ao qual ele orienta ou auxilia. Ele ajuda a remover os obstculos e faz com que cada indivduo maximize o seu potencial. Mas comumente, o coaching est associado aos esportes. Temos hoje em dia vrios exemplos de destaque em diversos esportes como o futebol e o vlei. Em todos eles o tcnico desempenha um papel fundamental para maximizar o potencial do seu grupo levando estes aos seus objetivos. Neste processo importante tambm destacar que a pessoa que ir desempenhar o papel de coaching deve trabalhar com a sua equipe, estudando cada indivduo e ajudando a melhorar os seus pontos fracos, a desenvolver a capacidade de saber resolver os problemas e ajudar a remover os obstculos que o liderado ir encontrar em seu caminho. Por isso, importante entendermos que o Coaching no somente a forma, mais todo um conjunto de qualidades (orientador, colaborativo, influente e entendido) que uma pessoa deve possuir para que possa guiar a sua equipe ou seus liderados para o alcance de suas metas.

1.2.

O que no Coaching

Neste processo de coaching, muitas vezes surgem conceitos equivocados. Tambm o que acontece que este processo aplicado de forma incorreta prejudicando e confundindo as pessoas que esto iniciando este aprendizado. A seguir uma explicao do que no considerado coaching. Consultoria O coach no d respostas. Ele no resolve os problemas. Ele busca ajudar aos seus liderados a descobrir suas prprias respostas.

Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

Aconselhamento O coach no d conselhos e nem solues prontas. O conselheiro trabalha com o seu cliente, que est desconfortvel ou insatisfeito com a vida, lhe dando uma direo e conselhos. Treinamento O coach no ensina aos seus liderados tcnicas e ferramentas para percorrer um caminho. Isto interessante, pois um coach no precisa ser algum mais capacitado do que seus liderados no assunto a ser desenvolvido. Mentoring Comumente, um mentor ensina tudo que sabe sobre um determinado assunto. Assim, o liderado apenas aprende aquilo que o seu mentor sabe, sendo uma espcie de modelo para o seu liderado. Tratamento psiquitrico ou anlise psicolgica O coaching no visa corrigir indivduos ou resolver alguma disfuno da mente. O coaching no remediativo, ele generativo. O coaching no tem foco no passo, mas sim no futuro.

2. Facilitao
Facilitao o processo ou abordagem que busca oferecer meios de tornar fcil e exequvel qualquer evento. Com isso, o facilitador busca realizar um trabalho coletivo, criativo e complementar, sempre identificando as competncias individuais. Neste tipo de trabalho tambm podem surgir os indivduos potencialmente conflitantes e neste momento que o facilitador, busca o bom senso permitindo que todos possam expressar suas ideias. Atravs desta prtica, o facilitador tambm resolve os problemas de conflitos interpessoais, a comunicao ineficiente da equipe e pouca clareza nos objetivos do evento. Isto permite que todos possam participar e se tornar responsveis por um determinado tema em discusso no evento. Isto aumenta o foco das pessoas para o encalce dos objetivos e/ou metas. Em um evento facilitado, comum haver uma forte comunicao visual. A neurocincia explica que nosso crebro possui dois hemisfrios, onde o lado direito considerado emocional e o lado esquerdo considerado racional. Com esta premissa, o uso de ferramentas para gerar uma comunicao visual proporciona uma espcie de harmonia entre estes hemisfrios, pois so fornecidos subsdios para ajudar o raciocnio lgico a materializar e organizar as emoes e sentimentos peculiares construo de novas ideias.

3. Introduo a Agilidade
H muito tempo, a maneira de desenvolver software vem evoluindo com a criao de novas metodologias e processos, que visam facilitar o trabalho. Por muito tempo, tem-se usado o processo de desenvolvimento em cascata, mas este mostrou que a maioria dos projetos obtiveram fracasso, pois neste modelo as atividades so mais onerosas e mais burocrticas. Este 6 Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

modelo segue a filosofia do conceito tradicional de desenvolver software, que consiste na ideia de um conjunto de atividades e resultados associados. Outro problema neste modelo, que a medida em que o trabalho avana, ou seja, a medida em que as fases vo passando, o custo de correo ou ajuste cresce de forma exponencial. O desenvolvimento gil um fruto da constatao feita, de forma independente, por diversos profissionais renomados na rea de engenharia de software, de que, apesar de terem aprendido segundo a cartilha tradicional, s conseguiam minimizar os riscos associados ao desenvolvimento de software, pensando e agindo de forma muito diferente do que tradicionalmente est nos livros. Com esta ideia, foi criado o Manifesto gil que um documento elaborado com o intuito de determinar qual a viso de uma equipe de desenvolvimento de software e, foi assinado por desenvolvedores e gestores de projetos do software respeitados no mundo todo. Criado por um seleto grupo de pessoas da comunidade, o Manifesto gil formado por princpios e valores que devem servir como diretrizes para as equipes. No manifesto gil, valoriza-se: Indivduos e interao entre eles, mais que processos e ferramentas; Software em funcionamento, mais que documentao abrangente; Colaborao com o cliente, mais que negociao de contratos; Responder a mudanas, mais que seguir um plano.

De forma mais direta, deve-se valorizar mais os itens em destaque. Mas isto no significa que os itens sem destaque no devem ser valorizados, mas so menos prioritrios. importante observar, que ser gil no quer dizer ser radical e nem quer dizer que existe apenas uma soluo para os projetos de desenvolvimento de software. Ser gil quer dizer, identificar e focar em objetivos bem estabelecidos, cuidar para que haja conscientizao dos membros da equipe, unir a equipe e permitir a pr-atividade e auto gerenciamento, garantir feedback continuamente, utilizar solues simples para problemas simples e, por fim, inspecionar e adaptar.

3.1.

Os Princpios do Manifesto gil

Garantir a satisfao do consumidor, entregando rapidamente e continuamente softwares funcionais; Softwares funcionais so entregues frequentemente (semanas, ao invs de meses); Softwares funcionais so as principais medidas de progresso do projeto; At mesmo mudanas tardias de escopo no projeto so bem-vindas;
Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

Cooperao constante entre pessoas que entendem do 'negcio' e desenvolvedores; Projetos surgem atravs de indivduos motivados, entre os quais existe relao de confiana; Design do software deve prezar pela excelncia tcnica; Simplicidade; Rpida adaptao s mudanas; Indivduos e interaes mais do que processos e ferramentas; Software funcional mais do que documentao extensa; Colaborao com clientes mais do que negociao de contratos; Responder s mudanas mais do que seguir um plano.

3.2.

Alguns Pontos Fundamentais sobre a Agilidade

Praticar agilidade algo que todos buscam, mas antes de qualquer metodologia ou processo, primeiramente preciso observar alguns pontos fundamentais que ajudaro na adoo e prtica de agilidade. So estes: Fracassos no devem ser encarados como coisas ruins, mas sim como lies aprendidas e assim no cometer o mesmo erro; imprescindvel saber que todos os resultados devem ser mensurados. No para encontrar culpados, mas para poder realizar melhorias na equipe ou pessoalmente. um processo de evoluo; Dividir para conquistar. Para grandes coisas sempre procure dividir para resolver por partes; Procure sempre trabalhar as ideias. D mais tempo; Quanto mais simples o software, mais barato, mais rpido para desenvolver e mais agradvel para o usurio. Quando surgir novas funcionalidades diga no; Garantir a satisfao do cliente, entregando rapidamente e de forma contnua o software funcional; Projetos surgem atravs de indivduos motivados, entre os quais existe relao de confiana; Rpida adaptao s mudanas; Responder s mudanas mais do que seguir um plano; At mesmo mudanas tardias de escopo so bem-vindas.

3.3.

Metodologias geis

Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

Dentro de filosofia de agilidade, h diversas formas de se trabalhar. Ou seja, h diversos processos e metodologias que atendem aos princpios do manifesto gil e que estes devem ser adaptados a realidade de cada um. Isto um processo de inspeo e adaptao constante. Os processos geis tiveram seu incio na dcada de 90 e eram chamados de processos leves em relao aos processos pesados e burocrticos como o modelo cascata. Dentre eles podemos citar: FDD (Feature Driven Devlopment) , XP (eXtreme Programming), Scrum e Crystal. Abaixo ser explicado um pouco sobre cada metodologia. FDD Desenvolvimento Orientado a Funcionalidades, metodologia criada entre 1997 e 1999 por um dos participantes do Manifesto gil, tem a sua base o mtodo Coad (metodologia completa para Anlise, Desenho e Programao Orientada por Objetos desenvolvida por Peter Coad) e as tcnicas de gerenciamento interativo, incremental e enxuto. A sua ideia principal Resultados frequentes, tangveis e funcionais; XP (eXtreme Programming), metodologia criada em 1996 na corporao Chrysler para ser utilizada por equipes pequenas e mdias que iro desenvolver software com requisitos vagos e em constante mudana. Segue os cinco valores fundamentais: comunicao, simplicidade, feedback, coragem e respeito. Scrum, framework criado em 1993 para desenvolvimento interativo e incremental de software. Sua principal ideia propor um framework com boas prticas e papis bemdefinidos para ajudar as equipes de desenvolvimento de software a realizarem o desenvolvimento de projetos de forma mais eficiente. No scrum, o mais importante a atitude das pessoas envolvidas de querer fazer o projeto acontecer. Os principais papis no scrum so: Scrum Master, Product Owner e a Equipe.

3.4.

Produto do Ponto de Vista de Negcio

Em termos comerciais de software, o produto resultante de um projeto de desenvolvimento de software o prprio software. Como profissionais de desenvolvimento de software, no devemos e no queremos nos preocupar com os outros fatores que no sejam a qualidade e a velocidade com o qual o software entregue. Mas do ponto de vista do cliente, este produto (software) ser o responsvel pela resoluo de alguma necessidade ou apenas ir melhorar o processo de negcio, trazendo benefcios econmicos. Destes dois pontos de vista, pode-se observar que o software tem valores diferentes, dependendo de vrios fatores. Diante destes pontos, podemos concluir que o ponto de vista do cliente a meta que a equipe de desenvolvimento de software deve alcanar e o ponto de vista da equipe (ou profissionais desenvolvimento) a forma como este software dever ser desenvolvido, sendo que cada um tem responsabilidades distintas, onde o primeiro ajuda a definir o que ser o produto e seus detalhes e o segundo dever trabalhar em cima destas informaes para gerar o produto final.
Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

Figura 1 - Viso do Escopo do Negcio

Normalmente, o escopo vem definido atravs de termos de negcio. Cabe aos desenvolvedores traduzirem isso para linguagem tcnica de forma transparente e assim, ser capaz de praticar sinergia para com o cliente. Para a definio do escopo do produto no contexto do negcio, essencial que seja definido um representante do cliente que tenha uma viso completa do negcio.

3.5.

ROI

O cliente deve sempre manter a sua viso de retorno de investimento sobre as aquisies que ele realiza. Isto no seria diferente para software. Por isso, cabe a equipe de desenvolvimento ajudar o cliente a definir o seu produto e desta forma, trabalhar para realizar este produto. Tambm cabe a equipe, informar ao cliente quando algo que ele venha a definir ou solicitar traga mais custos do que benefcios para o seu negcio. Todo este processo definido como ROI - Return Of Investiment (retorno sobre o investimento), que uma ferramenta de avaliao de desempenho sobre o investimento realizado. Atravs dela o cliente poder medir, junto com a equipe de desenvolvimento, os benefcios do desenvolvimento de um software para o seu negcio.

3.6.

Declarao de Viso

A viso do produto a primeira atividade que qualquer cliente ir realizar antes de solicitar o seu software. Esta viso se tornar a meta do projeto, que a equipe ir quebrar em objetivos menores. Isto em alto nvel far com que todos da equipe de desenvolvimento saibam qual o resultado esperado. Dever ser um documento sem ambiguidade e inteligvel para que toda a equipe possa compreender. Ser de grande utilidade a construo de um modelo do fluxo de informaes do negcio. Desta forma ser til, principalmente para a equipe, que poder utiliz-lo para saber como ir adequar o software a realidade do cliente.
Copyright 2012 Divus Tecnologia, todos os direitos reservados

10

Gesto de Projetos com SCRUM

Mais especificamente, o documento de viso do produto dever ser um documento com no mximo duas (02) folhas. Deve abranger as partes mais importantes do produto e dever ser gerado pelo cliente ou representante deste. Podemos fazer uso tambm de outras ferramentas para descrever a viso do produto, como por exemplo, a Modelagem de Mapas Mentais. Este consiste de um diagrama contendo o objetivo, uma estrutura de funcionalidades, metas no funcionais, critrios de sucesso e uma descrio superficial das tecnologias e arquitetura do projeto.

Figura 2 - Exemplo de Mapa Mental

3.7.

Estimativa Inicial

No momento da definio do software, o cliente dever realizar a priorizao das funcionalidades que o produto ir conter. Isto significa que o cliente em conjunto com a equipe dever realizar uma lista de todas as funcionalidades e a ordem de classificao quanto a sua importncia para o negcio. Isso ir auxiliar a equipe no planejamento do desenvolvimento do software. As funcionalidades tambm podero ser agrupadas ou ento ordenadas em uma s lista, que ser considerada o principal documento para construo do software. Toda a equipe ir se basear nesta lista, pois esta define os objetivos da equipe para o alcance da meta final (que o software construdo). Para esta estimativa inicial, no necessrio definir valores para cada funcionalidade (ou requisito). Apenas ser definida uma ordem de prioridade a partir da viso do cliente.

4. Diferencial do Scrum
Copyright 2012 Divus Tecnologia, todos os direitos reservados

11

Gesto de Projetos com SCRUM

O Scrum como qualquer outra ferramenta de gesto de projetos, tem como propsito ajudar no desenvolvimento do software de forma mais eficiente e eficaz. Mais por que o Scrum se destaca das outras? Isto ser explicado nas prximas sees, onde sero abordados a histria, as caractersticas que tornaram este framework muito popular no campo do desenvolvimento de software e que hoje j se estende para outras reas.

4.1.

Histria

Abaixo um histrico resumido da elaborao do framework Scrum: Em 1986 Hirotaka Takeuchi e Ikujiro Nonaka descreveram uma nova abordagem para o desenvolvimento de produtos em que todas as fases do processo e a equipe trabalham juntos em diferentes fases; Na dcada de 90, a metodologia Scrum foi introduzida em algumas companhias, como por exemplo, Easel Corporation onde Ken Schwaber trabalhava. Neste mesmo ano Jeff Sutherland, John Scumniotales e Jeff McKenna chamaram pela primeira vez este processo de Scrum; Em 1995 Ken Schwaber e Jeff Sutherland descreveram e apresentaram para o pblico.

4.2.

Como Ganhar essa Vantagem Competitiva

A primeira coisa que devemos observar a forma como a equipe est trabalhando. Visualizar os pontos fracos, para identificar se este processo realmente ir ajudar a permanecer no mercado. Isto necessrio para que no afete a rentabilidade da empresa. Vale ressaltar que esta avaliao do processo atual da empresa muito importante, pois o que se tem falado at o momento e tambm depois s far sentido, se realmente o processo da empresa precisar ser melhorado. Isto foi o mesmo sentimento que motivou h muito tempo atrs a criao do Manifesto gil. Este material foi compilado a partir das boas experincias e resultados positivos em diversos tipos de projetos. As empresas que ainda possuem a viso antiga, de que focar em processo e documentao a nica forma de melhorar o trabalho, esto tendo que rever seus conceitos para poder acompanhar o mercado e se tornar competitivas. A agilidade no desenvolvimento de software, est se tornando cada vez mais um grande diferencial no mercado de software, pois com a velocidade das informaes o software est cada vez mais se tornando parte essencial para o negcio.

Copyright 2012 Divus Tecnologia, todos os direitos reservados

12

Gesto de Projetos com SCRUM

4.3.

E na prtica, como isso funciona?

Tudo isso muito bom, parece ser a salvao das indstrias de software. Mas o que realmente pode-se constatar que essa maravilha toda no to fcil de implantar ou trazer resultados em curto prazo. Alm das prticas e processos das metodologias geis, ainda h o fator humano envolvido. Muitas vezes a implantao pode levar muito tempo ou at mesmo ficar invivel devido a cultura da empresa e das pessoas envolvidas. importante lembrar, que as metodologias geis so uma filosofia, uma forma de trabalho bem diferente do modelo tradicional, que vai depender das atitudes dos envolvidos no projeto para que este venha a ter sucesso. Atualmente muitas empresas conseguiram implantar e adequar o framework aos seus projetos, gerando timos resultados. Mas h outras que ainda no conseguiram e ainda lutam para quebrar paradigmas antigos que atrapalham muito esta nova forma de trabalho. Por isso muito importante que esta filosofia seja seguida desde a alta direo at o desenvolvedor, para que todos possam ganhar com esta nova forma de abordagem de desenvolver software.

5. O SCRUM 5.1. O que SCRUM

O scrum no uma metodologia, no uma nova tecnologia, no uma ferramenta e nem um cheklist de avaliao de processo. Trata-se apenas de um framework, que baseia-se em um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto (Certified Scrum Master, 2009). Mas tambm deve ser considerada, uma filosofia de trabalho que envolve a atitude das pessoas envolvidas no projeto. Algumas caractersticas do Scrum: Processo emprico de gerenciamento e controle; Deve-se praticar a inspeo e adaptao em loops de feedbacks; Baseia-se na filosofia de entregas frequentes de funcionalidades com valor para o cliente; Escalvel a projetos distribudos, grandes e largos; Extremamente simples, mas resistente. O scrum fundamentado na teoria de controle de processos empricos, que emprega uma abordagem iterativa e incremental para aperfeioar a previsibilidade e controlar riscos. Trs pilares sustentam qualquer implementao de controle de processos empricos: Transparncia, Inspeo e Adaptao.
Copyright 2012 Divus Tecnologia, todos os direitos reservados

13

Gesto de Projetos com SCRUM

Primeiro pilar a TRANSPARNCIA Este pilar informa que todo o processo que afeta o resultado deve transcorrer de forma transparente, principalmente para aqueles que realizam a gesto. Alm da transparncia este processo deve ser conhecido para que qualquer inspeo no processo possa ser facilmente visto todos os pontos. Segundo pilar a INSPEO Este pilar informa que devem ser realizadas inspees com frequncia suficiente para que variaes inaceitveis do processo possam ser detectadas, ou seja, qualquer ponto de melhoria deve ser visualizado e corrigido o mais breve possvel. Terceiro pilar a ADAPTAO Este pilar informa que caso seja encontrado algum ponto do processo fora dos limites aceitveis e que o produto resultante ser inaceitvel, dever ser ajustado o mais breve possvel para minimizar desvios posteriores. Conforme o framework Scrum, este possui trs pontos de inspeo e adaptao. A primeira a reunio diria que utilizada para avaliar o progresso do projeto em direo Meta da Sprint e tambm se pode realizar adaptaes que otimizem o valor do prximo dia de trabalho. Em seguida temos a reunio de Reviso da Sprint e de Planejamento da Sprint que so utilizadas para inspecionar o progresso em direo meta da verso. Por ltimo temos a reunio de Retrospectiva da Sprint, que tem o objetivo de avaliar e revisar a Sprint passada, para definir as adaptaes que tornaro a prxima mais produtiva e gratificante.

O framework Scrum formado pelo Time e outros papis (que veremos em seguida), eventos com duro fixa (conhecidos como Time-Boxes), os artefatos e regras.

Figura 3 - Viso Geral do Processo Scrum

O Time do Scrum projetado para ser eficiente, tanto na sua produtividade quanto a sua flexibilidade. Por este motivo, este time deve ser interdisciplinar, auto-organizado e que saiba trabalhar em iteraes.
Copyright 2012 Divus Tecnologia, todos os direitos reservados

14

Gesto de Projetos com SCRUM

Neste time os principais papis so: Scrum Master: Responsvel por garantir que todas as regras e atividades do scrum sejam seguidas e sejam entendidos por todos os envolvidos; Product Owner: Responsvel por definir as entregas e por maximizar o valor do trabalho do time; Time: Responsvel por executar o trabalho propriamente dito.

Geralmente o Time formado por desenvolvedores com todas as habilidades necessrias que iro garantir que todos os requisitos definidos na Sprint iro gerar um pedao potencialmente entregvel em relao ao produto final. Quanto a sua gesto de linha temporal, o scrum emprega eventos com durao fixa (time-boxes) para criar uma regularidade. Mas dentro desta durao fixa, temos os principais elementos de inspeo do Scrum dentro da linha de tempo do projeto que so: a Sprint, a Reunio Diria, a Reviso da Sprint e a Retrospectiva da Sprint. J os artefatos que o Scrum trabalha so: Product Backlog, Sprint Backlog, Burndown da Sprint e um Burndown do Projeto.

5.2.

Papis

Dentro do scrum, o time formado pelos seguintes papis: Scrum Master, Product Owner e pelo Time. Dentro deste contexto temos antes que explicar qual a viso do framework scrum em relao a todos estes papis. Primeiramente vamos observar a figura abaixo:

Figura 4 - Histria do comprometimento x envolvimento

Como observamos, dentro do scrum temos aqueles papis que so os comprometidos e os que so apenas envolvidos. Como papel de comprometido, ou seja, aqueles que iro se comprometer com os

Copyright 2012 Divus Tecnologia, todos os direitos reservados

15

Gesto de Projetos com SCRUM

resultados e objetivos a serem alcanados tem o Time scrum. O restante apenas envolvido no projeto. Por isso dizemos que no projeto scrum, temos os Porcos e as Galinhas. Com este conceito definido, pode-se dizer que as Galinhas no podem dizer aos Porcos como estes devem fazer seu trabalho.

5.2.1.ScrumMaster
o principal responsvel por garantir que todos do time estejam aderindo aos valores do scrum, como as prticas e regras. Ele tambm o responsvel por ajudar a organizao e o time na adoo do framework. Deve ter como viso a educao do time scrum no seu treinamento quanto ao scrum, levando-o a ser mais produtivo e a desenvolver produtos com maior qualidade. O ScrumMaster deve ajudar o time a ser autogerenciado e interdisciplinar. Como princpio o ScrumMaster no gerencia o time, pois este deve ser auto-organizvel. Alm destes pontos descritos anteriormente, o ScrumMaster deve ser um lder/facilitador, pois atua fortemente na remoo dos impedimentos e principalmente protege o time das interferncias externas para que a meta de entrega seja alcanada.

Figura 5 ScrumMaster deve atuar como facilitador

interessante notar que o ScrumMaster trabalha junto aos clientes e gerentes da organizao para auxiliar na preparao e identificao de um Product Owner. O ScrumMaster facilitar o trabalho do Product Owner e tambm servir ao time de forma que o mesmo esteja protegido durante uma Sprint.

5.2.2.Product Owner
a pessoa responsvel pela gesto do Product Backlog (que ser falado nas prximas sees), por garantir valor ao trabalho do time e por garantir o retorno sobre o investimento do projeto. Este

Copyright 2012 Divus Tecnologia, todos os direitos reservados

16

Gesto de Projetos com SCRUM

deve manter o backlog atualizado e disponibilizar a todos os envolvidos para que estes saibam onde devem chegar e quais itens so prioritrios.

Figura 6 - Responsvel pela Gesto do Product Backlog

O product owner deve ser uma pessoa escolhida pelo cliente, mas jamais dever ser um grupo ou comit. Isto no quer dizer que se o cliente define um grupo, este no possa influenciar ou apoiar o product owner, mas s quem pode mudar a prioridade de um requisito o Product Owner. Como sugesto, pode ser um Gerente de Produto ou ento um Gerente da funo de negcios, por estar mais prximo do cliente. Um ponto importante para o sucesso do product owner em um projeto scrum que toda organizao deve respeitas as decises feitas pelo product owner.

5.2.3.Time
o responsvel por dividir o product backlog em incrementos de funcionalidades potencialmente entregveis em cada Sprint. A viso de cada membro do time de ser interdisciplinar, ou seja, devem possuir o conhecimento necessrio para criar um incremento de trabalho.

Figura 7 - Time Interdisciplinar Copyright 2012 Divus Tecnologia, todos os direitos reservados

17

Gesto de Projetos com SCRUM

Apesar de em muitos casos as pessoas do time atuarem em atividades especializadas como, por exemplo, programao, arquiteto de software, projetista de banco de dados, analista de requisitos e outros, o mais importante que estes saibam pegar um requisito e transform-lo em um produto utilizvel, mesmo que isso signifique ter que atuar em outra atividade. Os membros do time que no se adequam a este tipo de filosofia no conseguem adaptar-se ao time. No h ttulos em time, no diviso por funes todos so iguais, ou seja, muitas vezes um analista de requisitos ter que testar ou at mesmo programar (claro isso ir requerer que este relembre a programa ou at mesmo desenvolva esta habilidade.). O time deve ser auto organizvel, ou seja, nem mesmo o scrum master pode dizer como o time deve trabalhar para transformar o product backlog em incrementos entregveis. Isto algo que o time ter que fazer sozinho. Isto fica mais fcil ao aplicar a habilidade de cada membro em cima do product backlog e com isso sabero o que ser necessrio fazer para realizar as entregas. Isto leva o time a melhorar a sua eficincia e eficcia. Em um time scrum, o nmero ideal de pessoas so sete (07) e mais ou menos duas (02). Caso o time possua menos de cinco pessoas, isto pode causar menor interao entre as pessoas do time levando a um menor ganho de produtividade. Mais do que o limite superior (de sete mais duas pessoas) tambm no bom, pois isto causar grandes problemas em coordenar este time muito grande.

5.3.

Gerenciamento de Escopo e Valor Agregado ao Negcio

Para o projeto Scrum, um dos artefatos mais importantes o Product Backlog que rene a lista de requisitos de forma priorizada realizada pelo Product Owner (como dito anteriormente). Para a composio deste artefato, o ideal usar as prticas da engenharia de requisitos. Com as metodologias geis, atravs da sua abordagem simples e enxuta dos requisitos, pode ajudar na especificao e definio dos requisitos, j que este framework incentiva a comunicao atravs de um texto claro e usando uma linguagem nica de negcios. Uma das ferramentas utilizadas pelo scrum a estria de usurio (user story). Esta ferramenta oriunda da metodologia XP utilizado para elicitao dos requisitos e sua estrutura a seguinte: Como um(a) <PAPEL> gostaria /devo de <FUNO> para/por <VALOR DE NEGCIO> . Abaixo vejamos alguns exemplo:

Como supervisor eu gostaria de autorizar um desconto em uma venda.

Como um instrutor eu devo apontar a lista de presena dos alunos para manter as informaes do treinamento atualizadas.

Copyright 2012 Divus Tecnologia, todos os direitos reservados

18

Gesto de Projetos com SCRUM

Depois de identificado estes requisitos estes devero ser reunidos e priorizados no Product Backlog. Este artefato representar a viso do produto e assim, o time poder estabelecer uma estratgia para as entregas. A priorizao dos itens do Product Backlog sero definidos atravs de uma nota numrica que definido pelo Product Owner. Esta pontuao definida a partir da sua viso de importncia para o negcio. Abaixo veremos um exemplo de um Product Backlog: Item Como candidato gostaria de visualizar os cursos disponveis pela instituio Como candidato gostaria de fazer minha inscrio no vestibular. Como candidato gostaria de emitir o boleto para pagamento das taxas de inscrio no vestibular. Valor de Negcio 100

80 60

5.4.

Gerenciamento do Tempo

O principal paradigma oferecido pelo framework scrum o conceito de TimeBox. Ele funciona como uma caixa de tempo em vrios nveis (dirio, semana e mensal) e est presente em praticamente todas as sees de trabalho do scrum. Estes eventos de durao fixa no scrum so a Sprint, a Reunio de Planejamento da Sprint, a Reviso da Sprint, a Restrospectiva da Sprint e a Reunio Diria. Dentre estes eventos o que melhor representa o TimeBox o Sprint, pois uma iterao que ser realizada vrias vezes durante o projeto, com o principal objetivo de entregar algo potencialmente usvel ao seu final.

5.5.

Fluxo de Trabalho

O fluxo de trabalho do scrum oferece um processo bem simples de entender. Porm o mais difcil implementar este processo, pois incide na mudana de cultura da empresa onde se est adotando o scrum. Abaixo uma viso de todo o framework.

Copyright 2012 Divus Tecnologia, todos os direitos reservados

19

Gesto de Projetos com SCRUM

Figura 8 - Framework Scrum na viso geral

5.6.

Conceito de Sprint

A Sprint um timebox de uma (1) a quatro (4) semanas de durao no qual o time do projeto ir produzir uma parte do produto definida pelo cliente. Cada Sprint deve ter uma meta especfica que represente o desejo do cliente em incremento de software para aquele timebox especfico e os membros do time do Sprint so os responsveis por estimar os itens que compe o desejo do cliente e dar a palavra final do que ser possvel ser desenvolvido naquele timebox. Com isso a Sprint uma iterao. Durante a Sprint o ScrumMaster garante que no ser feito nenhuma mudana que possa afetar a meta do Sprint. Tanto a composio do time quanto as metas de qualidade que devem permanecer constantes durante a Sprint. As sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade de cancelar uma Sprint, embora ele possa fazer sob a influncia de partes interessadas e do ScrumMaster. Em geral, uma Sprint deve ser cancelada se ela no fizer mais sentido dadas as circunstncias atuais. A partir do momento que uma Sprint cancelada, todos os itens do Product Backlog que foram completados so revisados. Eles so aceitos se representarem um incremento potencialmente entregvel. O restante dos itens volta para o product backlog com as estimativas iniciais.

Copyright 2012 Divus Tecnologia, todos os direitos reservados

20

Gesto de Projetos com SCRUM

5.7.

Sprint Planning Meeting

A Reunio de Planejamento da Sprint (Sprint Planning Meeting) quando a iterao planejada. fixada em oito (08) horas de durao para uma Sprint de um ms. Para Sprints mais curtas, aloca-se para essa reunio aproximadamente 5% do tamanho total da Sprint e consiste de duas partes. Estas duas reunies so facilitadas ou lideradas pelo ScrumMaster. Na primeira reunio, que tem durao de quatro (04) horas, o Product Owner apresenta os itens de maior valor de negcio para o time, o time ir estimar o tamanho/complexidade desses itens e decidido o que ser feito na Sprint. Todos os itens de backlog tem sua estimativa de esforo definidas atravs de uma tcnica chamada de planning poker. Esta tcnica consiste em definir em conjunto (time) o esforo necessrio para realizar certa atividade em horas.

Figura 9 - Baralho de Planning Poker

A segunda reunio, que tambm de durao de quatro (04) horas, quando o time entende como desenvolver essa funcionalidade de incremento do produto durante a Sprint, para cada item o time ir criar tarefas que o time entende que precisa realizar para completar o item de backlog. Estas duas reunies podem ser dividas em o qu? e como?, ou seja, a primeira reunio ir se definir o que ser realizada na Sprint que se inicia. Este um trabalho em conjunto com o time e o product owner. O ScrumMaster apenas o facilitador da reunio. Se for o primeiro Sprint, o item que deve ser utilizado nesta reunio o product backlog. Se for o segundo Sprint em diante deve-se utilizar alm do product backlog, a capacidade do time em desenvolver as tarefas em um Sprint (quantos itens possvel realizar) e tambm o histrico de desempenho (velocidade). Na segunda parte da reunio o time ira tratar da questo do como desenvolver os itens selecionados e transform-los em um incremento pronto. Neste momento, enquanto o time projeta como sero realizado os itens, o time identifica as tarefas necessrias para realizar cada item do Sprint. Estas tarefas devem ser decompostas para serem realizadas em menos de um dia e aps a concluso destas atividades que ir converter os itens do product backlog em pedaos funcionais do produto final. Ao final teremos uma lista das tarefas do Sprint que sero chamados de Sprint Backlog.

Copyright 2012 Divus Tecnologia, todos os direitos reservados

21

Gesto de Projetos com SCRUM

O Product Owner est presente nas duas reunies, e se o time identificar nestas reunies que h trabalho de mais ou de menos, ele deve renegociar com o Product Owner. O time tambm pode convidar outras pessoas para participarem da reunio para fornecer conselhos tcnicos ou sobre o domnio da questo.

5.7.1.Daily Scrum Meeting

Na Reunio Diria do Scrum (Daily Scrum Meeting) o time se encontra para uma reunio de 15 minutos e deve ser feita sempre no mesmo horrio e local. Durante a reunio, que conduzida pelo ScrumMaster, cada membro deve responder a trs perguntas: O que fizemos de ontem para hoje? O que iremos realizar de hoje para amanh? Existe algum impedimento?

As reunies dirias melhoram a comunicao, eliminam outras reunies, ajudam a identificar e remover impedimentos para o desenvolvimento do Sprint, ressaltam e promovem a tomada rpida de decises e melhoram o nvel de conhecimento de todos acerca do projeto. O ScrumMaster deve garantir que o time realize a reunio e responsvel por conduzir a reunio. Deve ensinar o time a manter a reunio em curta durao, reforando as regras e garantindo que as pessoas falem brevemente. Deve ser o facilitador da reunio. A reunio diria no para reportar status e sim, uma forma de inspecionar o progresso do time em direo meta do Sprint. Essa reunio fundamental para inspecionar e adaptar o processo Scrum.

5.7.2.Sprint Review Meeting

A Reunio de Reviso do Sprint (Sprint Review Meeting) o evento realizado ao final da Sprint. Para Sprints de um ms, a reunio dever ter uma durao de quatro (04) horas e para Sprint mais curtos a reunio no deve tomar mais do que 5% do tempo total do Sprint. Durante a reviso da Sprint o time apresenta o que foi realizado e desenvolvido durante a Sprint para o Product Owner e tambm outros envolvidos (Stakeholders, caso haja necessidade). uma reunio informativa e tambm neste momento os stakeholders podem sugerir novos itens de backlog. Nesta reunio inclui pelo menos os seguintes itens: O Product Owner identifica o que foi feito e o que no foi feito durante a Sprint. O Time demonstra o trabalho que est pronto e responde a questionamentos. O Product Owner discute o Product Backlog da maneira como ele se encontra. Ele faz projees de datas de concluses provveis a partir de vrias hipteses de velocidade. Em
Copyright 2012 Divus Tecnologia, todos os direitos reservados

22

Gesto de Projetos com SCRUM

seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relao ao que fazer em seguida. A Reviso da Sprint fornece vrias entradas valiosas para as prximas reunies de Planejamento de Sprints.

5.7.3.Sprint Retrospective Meeting

A Reunio de Retrospectiva da Sprint (Sprint Retrospective Meeting) realizada aps a reunio de reviso da Sprint e antes da prxima reunio de planejamento da Sprint. Nesta reunio com durao fixa em trs (03) horas, o ScrumMaster encoraja o time a revisar, dentro do modelo de trabalho e das prticas do processo Scrum, o seu desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima Sprint. A finalidade desta reunio inspecionar como ocorreu a ltima Sprint em se tratando de pessoas, das relaes entre elas, dos processos e ferramentas. nesta reunio que o time tem a chance de refletir o que aconteceu na Sprint que passou e responder as seguintes questes: O que funcionou bem?, O que no funcionou bem? e O que pode ser melhorado?. neste ponto que entra a inspeo da adoo do processo. Ao final da reunio o time deve ter identificado medidas de melhoria factveis de se implementar na prxima Sprint. Estas mudanas se tornam a adaptao para a inspeo emprica.

5.8.

Visibilidade, Inspeno e Adaptao

O Scrum se apoia em trs pilares (como j foi dito na seo 5.1 O que SCRUM) para realizar entregas constantes: Visibilidade, Inspeo e Adaptao. Dentre estes, o mais interessante dentro do processo Scrum e que realmente traz uma mudana forte no cotidiano a visibilidade. Com isso uma das principais misses do Scrum tornar visvel para a equipe e tambm outros interessados como est o progresso e quais os problemas que precisam ser resolvidos para melhorar os resultados. Para isso, o Scrum oferece algumas opes muito interessantes para estimular uma comunicao mais direta e simplificada dentro de um projeto. A partir deste ponto necessrio observar o desafio cultural para promover as melhorias nas atitudes de cada membro do time, visto que agora qualquer pequena variao do projeto ser percebida dentro de uma Sprint. Dessa forma, uma das principais ferramentas para promover essa visibilidade o famoso KanBan (quadro de atividades), que uma herana muito interessante que as metodologias geis tiveram do Pensamento Lean. Dentre outras coisas, essa ferramenta estimular psicologicamente atitudes auto organizadas para puxar itens para a produo e tornar visvel o seu progresso ou qualquer impedimento durante o trabalho. Abaixo um exemplo de quadro KanBan: 23

Copyright 2012 Divus Tecnologia, todos os direitos reservados

Gesto de Projetos com SCRUM

Figura 10 - Exemplo de um quadro KanBan

Outra ferramenta interessante e tpica do Scrum o grfico de Burndown, que mostra quando de valor de negcio, tamanho e esforo j foram realizados (entregues) durante a Sprint e do projeto inteiro. Abaixo uma imagem do Burndown:

Figura 11 - Grfico de Burndown do Projeto

5.9. Ajudando o Trabalho da Equipe atravs da Remoo Contnua de Impedimentos

Copyright 2012 Divus Tecnologia, todos os direitos reservados

24

Gesto de Projetos com SCRUM

Como natural na rea de Tecnologia da Informao, vivemos em um universo de problemas. Mas Scrum tem uma maneira muito interessante de tratar estes problemas. Isto tambm pode ser visto de outra forma, como impedimentos que atuam como barreiras para que o trabalho iniciado no v adiante. Estes impedimentos podem ser de diversas naturezas como, por exemplo, questes tcnicas, polticas e pessoais. O tratamento destes impedimentos baseado em um dos princpios do modelo Toyota que estimula o controle visual para permitir que qualquer problema esteja visvel dentro do processo. Desta forma, atravs deste controle visual (como mostrado no KanBan), o ScrumMaster poder exercer umas das suas responsabilidades que de remover os obstculos ou impedimentos. Isto no significa que ele vai sempre saber como remover estes impedimentos, mas ele o responsvel por buscar meios necessrios para remoo destes.

5.10.

Definio de Pronto

O Scrum, como framework gil, estimula fortemente que se use o conceito de Pronto para nortear quando os itens de uma Sprint esto realmente prontos e dentro da qualidade desejada para o produto gerado. importante compreender que essa definio de pronto fortemente desenvolvida quando se usa, junto ao Scrum, alguma metodologia que oferea prticas fortes de engenharia como XP ou FDD. No desenvolvimento de produtos, afirmar que a funcionalidade est pronta pode levar algum a presumir que ela est, pelo menos, codificada, refatorada, que tenha passado por testes unitrios, que tenha sido feito o build e que tenha passado por testes de aceitao. Outros podem presumir que apenas o cdigo tenha sido desenvolvido. Se ningum sabe qual a definio de pronto, os outros dois pilares do controle de processos empricos no funcionam. Quando algum descreve algo como pronto, todos devem entender o que pronto significa. Pronto define o que o Time quer dizer quando se compromete a aprontar um item de Backlog do Produto em uma Sprint. Alguns produtos no contm documentao, de forma que sua definio de pronto no inclui documentao. Um incremento completamente pronto inclui toda a anlise, projeto, refatoramento, programao, documentao e testes para o incremento e todos os itens do Backlog do Produto no incremento. Os testes incluem testes de unidade, de sistema, de usurio e de regresso, bem como testes no-funcionais como de performance, de estabilidade, de segurana e de integrao. Pronto inclui tambm qualquer internacionalizao necessria, alm disso, Pronto significa que o Product Owner pode utilizar de alguma forma o item. Alguns Times ainda no so capazes de incluir em sua definio de pronto tudo o que necessrio para a implantao. Isto deve estar claro para o Product Owner. Esse trabalho restante dever ser feito antes que o produto possa ser implantado e utilizado.
Copyright 2012 Divus Tecnologia, todos os direitos reservados

25

Gesto de Projetos com SCRUM

5.11.

Melhoria Contnua

De acordo com o manifesto gil: Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz e ento ajusta seu comportamento de acordo. Isso significa que em pequenos ciclos o time aprende sobre seus erros e acertos para gerar melhoria na forma de trabalho do prximo ciclo. Atravs desta idia, que na agilidade chamamos de visibilidade, inspeo, e adaptao, temos uma base slida, com muita sinergia histrica e prtica para a aplicao do ciclo PDCA (Plan, Do, Check e Action) nas atividades de Planejamento, Execuo, Verificao e Aes corretivas ou preventivas dentro de projetos de desenvolvimento de software. Esse ciclo PDCA efetivo num projeto gil (isso inclui Scrum), pois h um planejamento a cada Sprint e a cada dia de trabalho de um time. Para assegurar esse ciclo, tambm fazemos uma verificao constante em busca de melhoria no produto e no processo (forma de trabalho) a cada dia e ao final de cada Sprint.

6. Outros Conceitos
Abaixo sero descritos mais conceitos importantes para o conhecimento da gesto de projetos com Scrum. Estes conceitos ajudaro a entender melhor a filosofia por trs da ideia do framework scrum.

6.1.

PDCA

O ciclo PDCA, ciclo de Shewhart ou ciclo de Deming, um ciclo de desenvolvimento que tem foco na melhoria contnua. O PDCA foi idealizado por Shewhart e divulgado por Deming, quem efetivamente o aplicou. Inicialmente deu-se o uso para estatstica e mtodos de amostragem. O ciclo de Deming tem por princpio tornar mais claros e geis os processos envolvidos na execuo da gesto, como por exemplo, na gesto da qualidade, dividindo-a em quatro principais passos. O conceito do Ciclo evoluiu ao longo dos anos vinculando-se tambm com a idia de que, uma organizao qualquer, encarregada de atingir um determinado objetivo, necessitava planejar e controlar as atividades a ela relacionadas. O ciclo comea pelo planejamento, em seguida a ao ou conjunto de aes planejadas so executadas, checa-se se o que foi feito estava de acordo com o planejado, constantemente e repetidamente (ciclicamente), e toma-se uma ao para eliminar ou ao menos mitigar defeitos no produto ou na execuo. Os passos so os seguintes:
Copyright 2012 Divus Tecnologia, todos os direitos reservados

26

Gesto de Projetos com SCRUM

Plan (planejamento): Deve-se estabelecer uma meta ou identificar o problema (um problema tem o sentido daquilo que impede o alcance dos resultados esperados, ou seja, o alcance da meta); analisar o fenmeno (analisar os dados relacionados ao problema); analisar o processo (descobrir as causas fundamentais dos problemas) e elaborar um plano de ao. Do (execuo): Deve-se realizar e executar as atividades conforme o plano de ao. Check (verificao): Deve-se monitorar e avaliar periodicamente os resultados alcanados, avaliar processos e resultados, confrontando-os com o planejado, objetivos, especificaes e estado desejado, consolidando as informaes, eventualmente confeccionando relatrios. Act (ao): Deve-se agir de acordo com o avaliado e de acordo com os relatrios, eventualmente determinar e confeccionar novos planos de ao, de forma a melhorar a qualidade, eficincia e eficcia, aprimorando a execuo e corrigindo eventuais falhas.

6.2.

Kanban

Kanban uma expresso japonesa com origem nos cartes utilizados nas empresas japonesas para solicitar componentes a outras equipes da mesma linha de produo, e que designa um mtodo de fabricao em srie, desenvolvido pela Toyota Motor Company, aplicado aos processos de aprovisionamentos, produo e distribuio, seguindo os princpios do Just-in-Time (JIT). Podemos dizer que o mtodo Kanban um mtodo que determina a produo a partir da procura: de fato, o ritmo de produo determinado pelo ritmo de circulao de Kanbans, o qual, por sua vez, determinado pelo ritmo de sada dos produtos juntamente com o fluxo de produo. Objetivos do mtodo Kanban Podemos identificar como principais objetivos do mtodo Kanban os seguintes itens: Regular internamente as flutuaes da procura e o volume de produo em cada seo de forma a evitar a transmisso e ampliao dessas flutuaes; Minimizar as flutuaes dos estoques do produto acabado com o objetivo de reduzir os custos de estocagem; Descentralizar a gesto da fbrica, criando condies para que as chefias diretas desempenhem um papel de gesto efetiva da produo e dos estoques; Produzir as quantidades solicitadas no momento em que so solicitados.

Aplicao do mtodo Kanban Pelas suas caractersticas, o mtodo Kanban apenas pode ser aplicado em sistemas de produo repetitiva, em que os produtos so padronizados e a produo relativamente estvel, sendo obrigatrio que o processo de produo esteja organizado em srie. 27 Copyright 2012 Divus Tecnologia, todos os direitos reservados