FATORES MOTIVACIONAIS PARA EVOLUO DO SCRUM AO KANBAN: ESTUDO DE CASO VIVENCIADO EM UM DATACENTER

ROBSON ANDERSON MARTINS DE SOUZA DO CARMO

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO CURSO DE PS GRADUAO MBA EM ENGENHARIA DE SOFTWARE

ORIENTADOR: RICARDO MAIA CISTER, MSC.

RIO DE JANEIRO 2011

ii

Carmo, Robson Anderson Martins de Souza do. Fatores Motivacionais Para Evoluo do Scrum ao Kanban: Estudo de Caso Vivenciado Em Um Datacenter. Rio de Janeiro, 2011.

vi, 32 f.: il. Monografia (MBA Em Engenharia de Software) Universidade Federal do Rio de Janeiro - UFRJ, Escola Politcnica, 2011. Orientador: Ricardo Maia Cister 1. Fatores Motivacionais Para Evoluo do Scrum ao Kanban: Estudo de Caso Vivenciado Em Um Datacenter. I. Ricardo Maia Cister, MSC. II. Universidade Federal do Rio de Janeiro. Instituto de Ps-Graduao em Administrao. III. MBA.

iii LISTA DE TABELAS

Tabela 1 - Exemplo de Product Backlog .................................................................................... 7 Tabela 2 - Quadro Comparativo Entre SCRUM e KANBAN ................................................. 12 Tabela 3 - Etapas do Desenvolvimento Utilizando Scrum ....................................................... 17 Tabela 4 - Benefcios da Adeso ao Modelo Kanban .............................................................. 26

iv LISTA DE FIGURAS

Figura 1 - Exemplo de Quadro Kanban ...................................................................................... 6 Figura 2 - Fases do SCRUM ...................................................................................................... 9 Figura 3 - Histrico da Organizao......................................................................................... 14 Figura 4 - Quadro DEV Utilizando SCRUM (utilizado pelo departamento) ........................... 17 Figura 5 - Fluxograma de Desenvolvimento Utilizando SCRUM ........................................... 18 Figura 6 - Fluxograma de Montagem do Sprint Backlog ......................................................... 19 Figura 7 - Quadro DEV Utilizando KANBAN (utilizado pelo departamento) ........................ 21 Figura 8 - Fluxograma de Desenvolvimento Utilizando KANBAN ........................................ 22

v RESUMO

Esse estudo de caso, busca realizar uma anlise dos fatores que contriburam para o departamento de desenvolvimento de software, de um dos mais renomeados datacenters do Brasil, evoluir o modelo de gerncia de desenvolvimento de software Scrum para o Kanban.

Scrum e Kanban so modelos de gerncia de desenvolvimento de software geis, cumprem os princpios e valores do Manifesto gil, no definem tcnicas ou ferramentas, mas a forma como a equipe deve se portar perante mudanas constantes nos requisitos do projeto.

A evoluo do modelo, ocorreu em razo do Scrum no ser gil e flexvel suficiente para suprir as demandas de software geradas pela estratgia de negcio da organizao e pelo Kanban suprir estas lacunas.

Palavras-chaves: Gerncia de Desenvolvimento de Software, SCRUM e KANBAN.

vi

AGRADECIMENTOS

Agradeo a Deus, pois sem Ele, no teria foras para essa longa jornada, aos meus professores e colegas de classe pelo eterno aprendizado, a minha me Rosangela Martins e irm Alba Martins que sempre me motivaram a seguir em frente, e especialmente minha esposa Perla Carmo, sempre compreensiva nos momentos mais tensos.

Agradeo as pessoas por mudar as coisas, por nunca faz-las serem da mesma forma, pois assim no teramos o que pesquisar, o que descobrir e o que fazer.

SUMRIO 1. 2. 2.1. 2.2. 2.3. 2.4. 3. 4. 4.1. 4.2. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.3.4. 5. 6. 7. 7.1. 7.1.1. 7.1.2. 7.1.3. INTRODUO ............................................................................................................. 2 REVISO DA LITERATURA .................................................................................... 4 A FILOSOFIA JUST IN TIME (JIT) ...................................................................................... 4 O KANBAN ....................................................................................................................... 5 O SCRUM .......................................................................................................................... 6 COMPARAO ENTRE SCRUM E KANBAN ....................................................................... 10 METODOLOGIA........................................................................................................ 13 ESTUDO DE CASO .................................................................................................... 14 BREVE HISTRICO E CARACTERSTICAS DA ORGANIZAO ........................................... 14 DESCRIO DO PROBLEMA ............................................................................................. 15 ANLISE DA SITUAO .................................................................................................. 16 CENRIO DE DESENVOLVIMENTO: UTILIZANDO O SCRUM......................................... 16 DIFICULDADES ENCONTRADAS AO UTILIZAR O SCRUM ............................................ 20 TRANSIO DO SCRUM PARA O KANBAN .............................................................. 20 CENRIO DE DESENVOLVIMENTO: UTILIZANDO O KANBAN ..................................... 25 CONCLUSES............................................................................................................ 27 REFERNCIAS BIBLIOGRFICAS ...................................................................... 30 ANEXOS ...................................................................................................................... 32 SISTEMAS UTILIZADOS PELO DEPARTAMENTO DE DESENVOLVIMENTO ......................... 32 DEVTRACKER (TELA DE EXECUES) ........................................................................ 32 DEVTRACKER (TELA DE PRIORIZAO DE SOLICITAO) .......................................... 32 REPORT DE ACOMPANHAMENTO DAS ATIVIDADES DO DEV....................................... 33

1. INTRODUO Para Zanatta, a partir da dcada de 90, onde ento usava-se vastamente modelos de gerncia de desenvolvimento de software "pesados", tipicamente baseados em cascata, houveram iniciativas para tornar a gerncia de software menos "burocrtica" e "lenta", destas surgiu o SCRUM. Um modelo baseado em iteraes, e em 2001 nasceu o Manifesto gil1, cujo intuito era entregar software que agregue valor de forma rpida e ser flexvel a mudanas.

Segundo Sabbagh e Garrido, no cenrio de negcios mundiais, as organizaes precisam evoluir cada vez mais rpido, para isto, primordial ter uma gerncia de software gil, eficaz e eficiente, entregando o software que a empresa precisa em um perodo de tempo e a um custo que sejam tangveis e que seja capaz de se adaptar a: requisitos volteis, baixo conhecimento do domnio de negcio pela equipe, mudanas de tecnologias, novas ferramentas, alteraes bruscas e rpidas no ambiente de negcios das empresas como novos concorrentes, produtos e modelo de negcios. Para estas necessidades, os modelos geis de gerncia de software2 conseguem se adaptar e atender as necessidades de tais organizaes.

Desta forma, este trabalho monogrfico busca analisar os fatores que contriburam para o departamento de desenvolvimento de software, de um dos mais renomados datacenters do Brasil, na evoluo do modelo de gerncia de software SCRUM para o Kanban, bem como, elucidar os cenrios vivenciados pela equipe de desenvolvimento utilizando os dois modelos.
1

Manifesto gil, uma declarao de princpios que fundamentam o desenvolvimento gil de software. Fonte: http://pt.wikipedia.org/wiki/Manifesto_%C3%A1gil . 2 Modelos geis de Gerncia de Software, um mtodo de determinar os requisitos de software e entrega de projetos de uma forma altamente flexvel e interativa. Fonte: http://en.wikipedia.org/wiki/Agile_management

Portanto, este trabalho monogrfico apresenta a seguinte diviso:

Na reviso da literatura abordamos os fundamentos da filosofia JIT e dos modelos SCRUM e Kanban.

No estudo de caso, elucidamos algumas estratgias de negcio, os cenrios vivenciados pela equipe de desenvolvimento ao utilizar cada modelo e as razes de evoluo.

Por fim, na concluso, ressaltamos os pontos conflitantes de cada modelo e benefcios da mudana de modelo.

2. REVISO DA LITERATURA

2.1. A Filosofia Just In Time (JIT) Em meados da dcada de 70, a japonesa Toyota Motor Company, forada pelo mercado automobilstico extremamente concorrente, inovou estabelecendo um novo conceito, o Just In Time. O qual busca a eliminao de desperdcios e consequente reduo de estoques a nvel zero. Esta mudana resultou em um novo sistema de produo, caracterizado por manufaturas enxutas, tambm conhecidas por: Sistema de Produo Enxuto ou Sistema Toyota de Produo, como visto em OHNO (1997).

OHNO, em Toyota de Produo (1997), explica:

Just in time significa que, em um processo de fluxo, as partes corretas necessrias montagem alcanam a linha de montagem no momento em que so necessrias e somente na quantidade necessria. Uma empresa que estabelea este fluxo, pode chegar ao estoque zero para produzir, de forma que cada processo receba o item exato necessrio, quando ele for necessrio, e na quantidade necessria.

O autor aponta, ainda, os dois pilares do sistema JIT, sendo o Kanban e a automao com toque humano, que chamada em japons de jidoka. Alm disso, SHINGO em Administrao da Produo (1996), considera "o Kanban como a ferramenta de controle que foi criada para maximizar o potencial do sistema Toyota".

2.2. O Kanban SLACK, em Administrao da Produo (2002), define o Kanban como sendo um mtodo de operacionalizar o sistema de planejamento e controle puxado, utilizando cartes com informaes dos materiais para realizar as operaes de movimentao e abastecimento, tornando em sua forma mais simples o jeito de um estgio cliente avisar seu estgio fornecedor sobre a necessidade de mais material a ser enviado. O termo Kanban, na traduo para o portugus significa carto ou sinal.

Henrik Kniberg e Mattias Skarin, em Kanban e Scrum obtendo o melhor dos dois (2009), define de forma prtica o Kanban em 3 etapas:

Visualizar o fluxo de trabalho:

o Dividir o trabalho em partes, escrever cada item em um carto e colar na parede.

o Usar colunas nomeadas para ilustrar onde cada item est no fluxo de trabalho.

Limitar o trabalho em progresso (WIP3) limites explcitos para quantos itens podem estar em progresso em cada estado do fluxo de trabalho.

Acompanhar o tempo de execuo da tarefa (tempo mdio para completar um item, algumas vezes chamado de tempo de ciclo").

Abaixo, um exemplo de quadro Kanban.

Figura 1 - Exemplo de Quadro Kanban Fonte: http://www.crisp.se/kanban

2.3. O Scrum Ken Schwaber e Jeff Sutherland (1993), motivados pela necessidade de encontrar uma metodologia que abordasse as dificuldades do desenvolvimento de software, de uma forma no tradicional, criaram a metodologia SCRUM. Que apresenta como principal objetivo:
3

Wip - WIP is Work In Progress. A work that has been started but not yet completed (acronym: WIP). In kanban, each column (Workflow Status) has a limit of allowed cards. Fonte: http://code.google.com/p/kanban-board/wiki/WIPLimits.

Entregar software com a maior qualidade possvel dentro de sries, compostas por pequenos intervalos de tempo chamados Sprints, que tem aproximadamente um ms de durao. (BEEDLE apud ZANATTA, 2004).

Ferreira et al (2005), caracteriza o SCRUM em 4 etapas bsicas:

o Backlog: lista de todas as funcionalidades a serem desenvolvidas durante o projeto. Tambm, para Spenassato (2005), tais funcionalidades so priorizadas de acordo com os usurios e interessados, e estimadas em termos de tempo e de custo pela equipe de desenvolvimento.

ID 1 2 3 4 5 6 7

Item de backlog Funcionalide AX Funcionalide BX Funcionalide CX Funcionalide DX Funcionalide EX Funcionalide FX Funcionalide GX

Valor de Negcio 100 700 600 1000 1500 100 800

Estimativa 5 5 1 13 13 2 2

Prioridade 140 120 77 77 62 50 50

Sprint 1 1 1 1 2 2 2

Tabela 1 - Exemplo de Product Backlog o Sprint: principal fase do SCRUM, onde so executadas as tarefas definidas do Produto Backlog para o sprint.

o Sprint Backlog: trabalho a ser desenvolvido no Sprint, de modo a gerar um produto que possa ser apresentado ao cliente. Deve ser desenvolvido de forma incremental, relativo ao Backlog anterior (se existir).

Uma vez o sprint iniciado, somente a equipe de desenvolvimento pode alterar esta lista, adicionando ou removendo atividades. (SPENASSATO, 2005).

Para Zanatta (2004), o Sprint Backlog extrai do Product Backlog, um conjunto de atividades para serem desenvolvidas. No feito o acompanhamento do tempo gasto com cada tarefa, mas um controle rigoroso do tempo restante para o cumprimento de cada meta.

o Scrum Meeting: reunies entre a equipe e o Scrum Master, cujo intuito externar entraves ao desenvolvimento do produto, podendo assim agir de forma eficiente na eliminao de tais barreiras.

Para Spenassato (2005), o SCRUM pode ser divido em trs fases, conforme figura ilustrativa a seguir:

Figura 2 - Fases do SCRUM Fonte: http://kosmaczewski.net/2006/12/28/scrum-software-development-process.

Conforme discorre SPENASSATO (2005), sobre as fases do SCRUM:

1) Pregame: nesta fase feito o planejamento e anlise de alto nvel e a arquitetura. A equipe define o escopo do projeto, os marcos, resultados e datas de entrega, realiza avaliao de risco e recebe aprovao e financiamento para o projeto, bem como a definio e reviso da arquitetura da soluo proposta.

2) Game: o desenvolvimento do sistema feito nesta fase, durante o que chamado de "Sprint", que o elemento central e mais caracterstico da metodologia Scrum. A Sprint um ciclo

10

iterativo de 1-4 semanas, durante o qual os desenvolvedores criam o produto do software. Diariamente, durante reunies de "5 minutos " a equipe se rene para coordenar as tarefas do dia.

3) Postgame: esta fase contm o encerramento do projeto, incluindo a preparao das entregas para a instalao dos testes de integrao e manuteno.

2.4. Comparao Entre Scrum e Kanban Henrik Kniberg e Mattias Skarin, em Kanban e Scrum obtendo o melhor dos dois (2009), apontam as seguintes similaridades e entre o Scrum e Kanban:

So Lean e Agile. Usam controle de cronograma. Limitam atividades em andamento. Usam transparncia para direcionar a melhoria do processo. Concentram-se na entrega de software que funcione, o mais rpido possvel e freqentemente.

So baseados em equipes auto-organizveis. Exigem que o trabalho seja dividido em partes. O planejamento de release continuamente otimizado, baseado em dados (velocidade / tempo de execuo) empricos.

11

E ainda, apontam as seguintes diferenas:

SCRUM Iteraes Timeboxed prescritas.

KANBAN Iteraes Timeboxed opcionais. Pode ter cadncia separada para o planejamento, release e melhoria de processos. Pode ser orientada para eventos, em vez de timeboxed.

Equipe compromete-se a uma quantidade especfica de trabalho para esta iterao. Usa a velocidade como padro mtrico para o planejamento e melhoria de processos. Equipes multifuncionais prescritas.

Compromisso opcional.

Usa o Lead time como padro mtrico para o planejamento e melhoria de processos. Equipes multifuncionais opcionais. Equipes de Especialistas autorizada.

Os itens devem ser divididos para que possam ser concludos dentro de 1 sprint. Grfico Burndown.

Nenhum tamanho especial de item prescrito. Nenhum tipo especfico de diagrama prescrito.

WIP limitado indiretamente (posprint).

WIP limitado diretamente (por situao do fluxo de trabalho).

Estimativa prescrita.

Estimativa opcional.

12

No poder adicionar itens iterao em uso.

Pode adicionar novos itens sempre que houver capacidade disponvel.

O sprint backlog de uma equipe especfica.

Quadros kanban podem ser compartilhados por vrias equipes ou individualmente.

Possui 3 papis (Product Owner / ScrumMaster No discrimina nenhum papel. / Team). Um quadro Scrum reiniciado entre cada sprint. Prescreve um product backlog priorizado. Priorizao opcional. Um quadro kanban continua.

Tabela 2 - Quadro Comparativo Entre SCRUM e KANBAN

13

3. METODOLOGIA O mtodo adotado o estudo de caso, possuindo como unidade de pesquisa o departamento de desenvolvimento de software, denominado DEV, de um do mais renomados datacenters do Brasil.

14

4. ESTUDO DE CASO

4.1. Breve Histrico e Caractersticas da Organizao A empresa nasce em 2005, no Rio de Janeiro, com a misso de prover servios gerenciados de infra-estrutura de TI de excelncia. Em 2007, funde-se com um segundo datacenter, objetivando consolidar a liderana de hosting gerenciado no Brasil. Desde ento, apresenta um crescimento anual cima de 30%, mantendo uma slida situao financeira. Em 2011 incorporada a um grupo americano, em uma transao de mais $ 120 milhes, passando a fazer parte do maior e mais moderno conglomerado de data centers mundial.

Figura 3 - Histrico da Organizao

15

4.2. Descrio do Problema A organizao estabeleceu como estratgica de negcios possuir um departamento de desenvolvimento (DEV) para suprir as necessidades do seu core businnes. Esta equipe desenvolve desde 2005, o PERSA, principal sistema utilizado pela empresa, integrando todos departamentos e equipes. Dentre os principais mdulos destaca-se: gesto de propostas comerciais e comisso, ativao de servios (ordem de servios), monitoramento de servios, knowledge base, controle de visita tcnica, faturamento e integrao com Dynamics AX, CRM, BSC e ativao de servidores virtuais. Apesar de existirem ofertas de softwares de cho de fbrica para datacenters no mercado, esta posio foi concebida pelos seguintes motivos:

Desenvolver um software totalmente voltado empresa.

A inexistncia do custo de licena por usurio.

Total integrao entre todos os mdulos, permitindo acompanhar a evoluo de um cliente desde o envio de uma proposta comercial at a sua ativao total.

Como em outros departamentos de desenvolvimento, no DEV, a gerncia de projetos informal e a fila de melhorias dos mdulos cresce com uma velocidade superior a capacidade de entrega. Por estes motivos, em Julho de 2009 foi implementado no departamento o SCRUM, utilizando SPRINT de 2 semanas, com os seguintes objetivos:

16

Transparecer para os gestores a priorizao da fila de backlog.

Apresentar maior transparncia aos lderes das atividades em execuo.

Ter um planejamento mnimo de 2 semanas das atividades a serem realizadas pelo departamento.

4.3. Anlise da Situao 4.3.1. Cenrio de desenvolvimento: utilizando o SCRUM Foi desenvolvido, como ferramenta auxiliar, o DevTracker, um novo mdulo do Persa, onde possvel controlar e acompanhar as solicitaes4, execues5 e status de todas atividades desenvolvidas. Como tambm, um quadro, onde colocado uma ficha com as solicitaes, priorizao e analista responsvel, chamado de Quadro DEV. Este quadro utilizado como ferramenta de acompanhamento de todas atividades em execuo do DEV durante um SPRINT.

SOLICITAO, corresponde a uma melhoria, correo ou nova funcionalidade a ser implementada no PERSA. As solicitaes so enviadas para o DEV atravs gerentes. 5 EXECUO, corresponde a um perodo de trabalho, de um dos colaboradores do DEV em uma solicitao.

17

Figura 4 - Quadro DEV Utilizando SCRUM (utilizado pelo departamento)

O fluxo das tarefas a serem executadas, de uma determinada solicitao, ocorre de acordo com a tabela abaixo, da esquerda para direita.

BackLog
Solicitaes previstas para serem iniciadas durante o sprint, ordenadas por prioridades.

Anlise
Anlise profunda da solicitao. verificado o impacto no sistema, escopo, prazos e interessados. Desta atividade gerado um DOC para o desenvolvedor executar a solicitao propriamente.

Desenvolvimento
Codificao da solicitao e execuo de testes.

Reviso
Reviso da codificao. verificado se os padres de desenvolvimentos foram observados. Caso haja oportunidade de melhoria a solicitao retorna ao desenvolvimento.

Homologao
Validao com o solicitante da entrega. criado um ambiente similar ao de produo, para que o cliente possa validar o que foi desenvolvido. Caso haja oportunidade de melhoria a solicitao retorna ao desenvolvimento.

Publicao
Preparao pacote publicao. do de

Publicado
Disponibilizao em ambiente de produo da funcionalida de.

Tabela 3 - Etapas do Desenvolvimento Utilizando Scrum

18

Tendo como representao o fluxograma:

Figura 5 - Fluxograma de Desenvolvimento Utilizando SCRUM

19

O Quadro DEV, atualizado a cada incio de SPRINT, a equipe realiza uma avaliao das solicitaes em backlog, d a cada solicitao sua pontuao e apresenta um grupo de solicitaes como sugesto de sprint backlog diretoria, aps aprovao, o quadro atualizado. Como resultado, temos previstas as atividades a serem desenvolvidas nas semanas seguintes (2 semanas).

Figura 6 - Fluxograma de Montagem do Sprint Backlog

20

4.3.2. Dificuldades Encontradas ao Utilizar o SCRUM A equipe DEV formada por: 2 analista juniores, 4 plenos, 2 seniores, 1 lder de equipe e 1 gerente. A organizao, possui poltica de vendas agressivas, concorrncia extremamente competitiva e uma equipe de desenvolvimento pequena, em vista os sistemas a serem mantidos e evoludos. Por estes motivos, frequente ocorrer a "repriorizao" do sprint backlog no decorrer do sprint, gerando insatisfao e frustrao por parte da equipe DEV, em decorrncia do esforo necessrio para construir o sprint backlog. No segundo semestre de 2009, ocorreram 3 cancelamos inteiros de sprints, alm dos cancelamentos parciais de solicitaes previstas para o sprint.

4.3.3. Transio do SCRUM para o KANBAN Como alternativa para resoluo dos problemas descritos acima, em Novembro/2010, o gerente da equipe DEV e o lder de equipe participaram de um treinamento sobre a evoluo do SCRUM para o KANBAN6. Deste treinamento, surgiu a iniciativa de evoluir o modelo de gerncia de desenvolvimento software SCRUM para o KANBAN que foi consumada em Janeiro/2011.

Do Scrum ao Kanban: Novas perspectivas em gesto gil de projetos de software. Maiores informaes em http://www.scrumban.com.br.

21

Novo quadro DEV, de acordo com o modelo Kanban:

Figura 7 - Quadro DEV Utilizando KANBAN (utilizado pelo departamento)

22

O fluxo de desenvolvimento mudou, tendo como resultado:

Figura 8 - Fluxograma de Desenvolvimento Utilizando KANBAN

23

Descrio das etapas:

Foco: Solicitaes que esto em foco, sero as prximas a serem priorizadas.

Priorizadas: Solicitaes que foram priorizadas pela diretoria em ordem de maior para menor importncia.

Anlise: verificado o impacto no sistema, escopo, prazos e interessados. Desta atividade gerado um DOC para o desenvolvedor executar a solicitao propriamente.

Reviso: verificado se o DOC de anlise foi devidamente preenchido, se as informaes esto claras e de acordo com os padres.

UX (user experience): analisada a tela a ser entregue, se for o caso, criado um prottipo de baixo nvel e homologado com o solicitante. Basicamente feita uma anlise da usabilidade da tela. Esta etapa dinmica, podendo ocorrer mesmo praticamente em qualquer etapa do processo de desenvolvimento.

Validao: Validao formal, pelo solicitante, do escopo, requisitos e datas da solicitao.

DEV: Codificao da solicitao e execuo de testes.

Testes: atualizado o DOC de anlise com classes de equivalncia de teste . Os testes so realizados pelo prprio desenvolvedor.

24

Reviso: verificado se os padres de desenvolvimentos foram observados. Caso haja oportunidade de melhoria a solicitao retorna ao

desenvolvimento.

Homologao: criado um ambiente similar ao de produo, para que o cliente possa validar o que foi desenvolvido. Caso haja oportunidade de melhoria a solicitao retorna ao desenvolvimento.

Publicao:

Solicitaes que esto aguardando serem publicados. S

possvel publicar qualquer melhoria no sistema em horrio no comercial e de segunda-feira quinta-feira. O intuito no ter nenhum tipo de interrupo em produo.

Publicaes da Semana: Relao de publicaes que foram disponibilizadas na semana.

25

4.3.4. Cenrio de desenvolvimento: utilizando o KANBAN Como resultante da adeso ao KANBAN, foram constados os seguintes benefcios:

Problema Tempo gasto de toda equipe para realizar a priorizao do sprint backlog

Soluo A priorizao da fila de solicitaes ocorre a qualquer momento, no gerando insatisfao por parte da equipe DEV, em vista, de no requerer esforo por parte desta, apenas do lder de equipe, do gerente e da diretoria

Sentimento de frustrao por parte da equipe, ao ter as atividades priorizadas serem canceladas. Cancelamento de uma solicitao

O sentimento de realizar um planejamento e ter as atividades previstas canceladas deixou de existir

Raramente h o cancelamento de uma solicitao em execuo. A priori, todas solicitaes

instanciadas devem ser concludas, somente aps a publicao, o analista pode iniciar outra solicitao da fila.

Excesso de tempo gasto em reunies

Foram extintas as reunies de incio e fim de sprint.

Alinhamento das atividades em

Foi mantida a reunio de stand-up meeting, para

26

desenvolvimento

alinhamento das atividades em desenvolvimento.

Permitir os gestores de outros departamentos acompanharem a evoluo das atividades em desenvolvimento e priorizao destas

Criamos um relatrio de acompanhamento das atividades do setor, disponvel para diretoria, desta forma, agilizando o processo de priorizao. Ver anexo 7.1.3 - report de acompanhamento das atividades do DEV.

Atualizar DevTracker para suportar o Kanban

O devtracker sofreu pequenas alteraes, no passando a especificar o sprint de execuo da solicitao e armazenando o histrico de

execues dirias. Ver anexo 7.1.1 - DevTracker.

Atualizar o Quadro DEV para o modelo Kanban

O quadro de acompanhamento das atividades do setor foi alterado, utilizamos tinta a base de ferro e ims para prender as solicitaes. Criamos uma rea para as solicitaes em foco e priorizadas.

Momento de atualizao do quadro DEV

A montagem do quadro DEV dinmica, no tendo um marco para a sua atualizao. A atualizao realizada pelo lder de equipe, gerente e diretoria. No criamos os indicadores de quantidade mnima e mxima para cada coluna do quadro (wip).

Tabela 4 - Benefcios da Adeso ao Modelo Kanban

27

5. CONCLUSES

No presente trabalho, realizou-se um estudo de caso, sobre a evoluo do Scrum para o Kanban, vivenciado no departamento de desenvolvimento de software de um dos mais renomados datacenters do Brasil. Foram apresentados cenrios resultantes aps aplicao de cada modelo, bem como os motivos que geraram a mudana de modelo.

Tornou-se perceptvel que o Kanban atende melhor as necessidades de desenvolvimento de software vivenciada pela organizao, em vista da agilidade, esforo necessrio para gerncia das atividades e principalmente por se adaptar as constantes mudanas vivenciadas pela empresa. Abaixo ressaltamos os pontos conflitantes de cada modelo:

Mudana de priorizao de solicitaes, precisando interromper todas atividades em andamento.

o SCRUM: Deve ser cancelado o sprint e criado um novo com as solicitaes priorizadas. Gera desmotivao por parte da equipe, em vista, o esforo necessrio por parte da equipe para montar o sprint backlog. Esta atividade envolve toda equipe e diretoria.

o KANBAN: Interrompe-se as atividades em andamento e inicia-se as novas j priorizadas pela diretoria, causando pouqussimo problemas

28

internos na equipe. Esta atividade envolve apenas o lder, gerente e diretoria.

"Repriorizao" de uma atividade em detrimento de uma priorizada, que no tenha sido instanciada por um analista.

o SCRUM: Deve ser alterado o sprint backlog. Alguma solicitao dever sair das previstas para entrar a nova.

o KANBAN: Nenhum impacto.

Acompanhamento das atividades em execuo.

o SCRUM: Nenhum impacto.

o KANBAN: Nenhum impacto.

Tempo gasto em reunies de planejamento.

o SCRUM: Possui 2 reunies longas, gasta-se em mdia 8 horas por quinzena de toda equipe, nas reunies de incio e fim de sprint.

o KANBAN: Inexistncia das reunies de incio e fim de sprint. Mantido apenas a reunio de stand up meeting, 15 minutos dirio de toda equipe.

Tempo de entrega de solicitao.

29

o SCRUM: As publicaes eram realizadas apenas as quintas-feiras, algumas vezes levando quase uma semana entre a finalizao de uma solicitao e sua publicao. Essa caractersticas no do SCRUM, mas havamos includa.

o KANBAN: As publicaes passaram a serem realizadas de segunda-feira quinta-feia, em horrio no comercial.

Devtracker.

o SCRUM: As execues eram limitadas ao sprint em que a atividade foi iniciada, caso no concluda no sprint, deveria ser criada uma nova instancia da atividade para o prximo sprint.

o KANBAN: Execues passaram a no ser limitadas por perodo de tempo.

Tendo em vista os pontos acima descritos, conclui-se que, para a realidade da organizao, o modelo de gerncia de software KANBAN possui um menor custo e mais flexvel que o SCRUM.

30

6. REFERNCIAS BIBLIOGRFICAS Fases do SCRUM. Disponvel em http://kosmaczewski.net/2006/12/28/scrum-softwaredevelopment-process. Acesso em 15 de Maio de 2011.

FERREIRA, Dcio et al. Um Modelo gil para Gesto de Projetos de Software. Artigo Cientfico. Universidade de Portugal, 2005.

Histrico da Alog Datacenters do Brasil. Disponvel em http://www.alog.com.br. Acesso em 15 de Maio de 2011.

KNIBERG H. e SKARIN M. Kanban e Scrum obtendo o melhor dos dois: C4Media, 2009.

Manifesto gil. Disponvel em http://pt.wikipedia.org/wiki/Manifesto_%C3%A1gil. Acesso em 30 de Julho de 2011.

Modelos geis de Gerncia de Software. Disponvel em http://en.wikipedia.org/wiki/Agile_management. Acesso em 30 de Julho de 2011.

Product BackLog. Disponvel em http://agilesoftwaredevelopment.com/blog/peterstev/figuring-out-business-value-planningpoker. Acesso em 08 de Maio de 2011.

OHNO, T. O Sistema Toyota de Produo: Alm da Produo em Larga Escala: Bookman, 1997.

Quadro Kanban. Disponvel em http://www.crisp.se/kanban. Acesso em 08 de Maio de 2011.

31 Stand Up Meeting. Disponvel em http://en.wikipedia.org/wiki/Stand-up_meeting. Acesso em 30 de Julho de 2011.

SHINGO, Shingeo. O Sistema Toyota de Produo do ponto de vista da Engenharia de Produo: Bookman, 1996. SABBAG, Rafael e GARRIDO, Marcos. Scrum e a Crise Mundial - Por que Scrum a melhor opo para projetos em tempos de crise. InfoQ: 2009. SLACK, N., CHAMBERS , S. e JOHNSTON, R. Administrao da Produo. 2 Edio: Atlas, 2002.

SPENASSATO, Jan. Uma anlise do mtodo gil Scrum sob a perspectiva do modelo CMMI nas reas de processo da categoria Engenharia. Universidade de Passo Fundo, 2005.

WIP - Work In Progress. Disponvel em http://code.google.com/p/kanbanboard/wiki/WIPLimits. Acesso em 30 de Julho de 20111.

ZANATTA, Alexandre. Scrum: uma proposta de extenso de um Mtodo gil para Gerncia e Desenvolvimento de Requisitos visando adequao ao CMMI Florianpolis, 2004. Dissertao de Mestrado em Cincia da Computao - Curso de PsGraduao em Cincia da Computao, Universidade Federal de Santa Catarina.

32 7. Anexos 7.1. Sistemas Utilizados Pelo Departamento de Desenvolvimento 7.1.1. DevTracker (Tela de Execues)

7.1.2. DevTracker (Tela de Priorizao de Solicitao)

33 7.1.3. Report de Acompanhamento das Atividades do DEV