1

APLICAÇAO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO DE PROJETOS DE SISTEMAS

Luiz Carlos Monteiro Lopes Filho1

Profa. Dra. Valneide Cabral 2

RESUMO

O surgimento de metodologias ágeis está contribuindo para ajudar equipes de desenvolvimento de software a responder, de forma eficaz e efetiva, às constantes mudanças do mercado atual. Uma das possibilidades de uso, neste contexto, refere-se à combinação Scrum e Kanban para o gerenciamento de projetos de sistemas. Neste sentido, este estudo explicita as contribuições dessa combinação, apresentando suas diferenças e similaridades, bem como as probabilidades quanto à sua utilização. Trata-se de uma pesquisa descritiva e bibliográfica, com abordagem qualitativa. Os entendimentos literários indicam que, as contribuições do Scrum e Kanban, combinadas, favorecem a melhoria dos processos de gerenciamento e de desenvolvimento, e podem ser adotadas por equipes, visto que ambos apresentam características adaptativas e são baseados no desenvolvimento iterativo e incremental, possibilitando, dessa forma, trazer mudanças consideráveis. Ressalta-se que, ao combinar Scrum e Kanban, a Organização não estará isenta de todos os problemas, mas, enfrentá-los passa a ser um desafio, sobretudo de equipes.

Palavras-chave: Engenharia de software. Metodologias ágeis. Combinação Scrum e Kanban. Projetos de sistemas.

ABSTRACT

The emergence of agile methodologies is contributing to help software development teams to respond efficiently and effectively to changing market today. One of the possibilities of use in this context refers to the combination of Scrum and Kanban for the project management systems. Thus, this study clarifies the contributions of this combination, with their differences and similarities, as well as the odds for their use. This is a descriptive and literature, with qualitative approach. The literary understandings indicate that the contributions of Scrum and Kanban, combined, favor the improvement of management processes and development, and can be taken by teams as they both have adaptive characteristics and are based on iterative and incremental development, enabling thus bring considerable changes. It should be noted that by combining Scrum and Kanban, the Organization will not be free of all problems, but face them becomes a challenge, especially for teams.

1 Graduado em Ciências da Computação pela Universidade Fortaleza2 Mestre em Informática pela Pontifícia Universidade Católica do Rio de Janeiro, especialização em Empreendedorismo na Engenharia pela Universidade Federal de Santa Catarina e graduação em Agronomia pela Universidade Federal do Ceará. Professora da Universidade Federal do Ceará e Coordenadora Adjunta do Curso de Sistemas de Informação da Faculdade Christus.

2

Keywords: Software engineering. Agile methodologies. Combining Scrum and Kanban. Project management systems.

1 INTRODUÇÃO

Para as Organizações, a aplicação exclusiva do Scrum, no gerenciamento de projetos

de desenvolvimento de sistemas, pode não atender às expectativas de sucesso, tornando-se

necessárias, adaptações. Uma destas refere-se à combinação com Kanban.

No contexto do mercado globalizado, em que as Organizações enfrentam crescentes

exigências de produtividade e de competitividade, a busca por processos mais ágeis, e que

agregam maior valor aos produtos, tem sido o foco constante do gerenciamento de projetos.

Portanto, evidencia-se a busca por metodologias que contribuam para superar os

atrasos, os custos, os prazos extrapolados, a baixa qualidade para, consequentemente, ter o

cliente satisfeito.

Tais problemas são a realidade de muitos projetos de desenvolvimento de softwares.

Provavelmente, tais sintomas consistam em reflexos de projetos mal gerenciados, seja na fase

do planejamento, da execução ou, simplesmente, do acompanhamento.

Diante desse quadro, apresenta-se a necessidade de frameworks para auxiliar o

gerenciamento, sendo o Scrum e Kanban demonstrados como opções.

O Scrum se concentra nos aspectos gerenciais do desenvolvimento de software, com

ênfase na autogestão (auto-organização) da equipe, sendo definido como um framework,

capaz de suportar o desenvolvimento de produtos que apresentam mais complexidade,

podendo combinar várias técnicas e processos ágeis.

O sistema Kanban é um método de produção que se baseia em controles visuais do

processo de produção, visando, entre outras funcionalidades, maximizar a frequência e a

rapidez de entrega dos produtos desenvolvidos.

Considerando as possibilidades de realizar combinações e adequações entre Scrum e

Kanban é que surgiu o interesse pelo assunto.

Do contato com a temática, apresentou-se uma possibilidade de utilização prática na

atividade profissional, exercida em uma empresa têxtil, sendo os softwares desenvolvidos

internamente para atender às necessidades da empresa. Vislumbra-se, portanto, a implantação

3

futura da metodologia do Scrum, consciente de que, para tanto, existe a necessidade de

adequação, utilizando como aporte o Kanban.

Diante do exposto, este estudo tem como questão norteadora: quais as contribuições

da aplicação de uma metodologia ágil, combinando Scrum e Kanban no gerenciamento de

projetos de desenvolvimento de sistemas?

É relevante apontar o que consta na literatura, acerca das possibilidades de

adaptações na utilização do Scrum no gerenciamento de projetos de desenvolvimento de

softwares, que, combinado com Kanban, possa solucionar problemas quando da utilização

exclusiva do Scrum.

A pesquisa tem como objetivo geral explicitar as contribuições da aplicação de uma

metodologia ágil, combinando Scrum e Kanban, no gerenciamento de projetos de

desenvolvimento de sistemas; e, tem, como objetivo específico, estudar, para identificar como

a aplicação de uma metodologia ágil, combinando Scrum e Kanban, pode contribuir no

gerenciamento de projetos de desenvolvimento de sistemas.

O pressuposto é de que, a utilização do Scrum e do Kanban promova melhor

transparência do andamento dos projetos desenvolvidos, contribuindo para a motivação e o

maior comprometimento da equipe, favorecendo a inspeção contínua, proporcionando uma

maior facilidade de adaptações durante o processo de desenvolvimento.

Diante do exposto, considera-se que, a estrutura do presente artigo é composta por 5

seções, nas quais, na seção 1, tem-se a introdução, que enfatiza a problematização, as

justificativas, os objetivos gerais e específicos, as hipóteses, bem como, a estrutura do estudo;

a seção 2 trata da fundamentação teórica, que aborda a evolução no gerenciamento de

projetos, sistemas Scrum e Kanban, e as diferenças e as similaridades entre estes; a seção 3

apresenta a metodologia da pesquisa, ressaltando-a quanto aos objetivos, aos procedimentos, e

à abordagem; a seção 4 corresponde à análise dos resultados obtidos, englobando o

repositório Scrum Backlog, iterações em time-box, mudanças dentro de uma iteração, quadro

para acompanhamento de tarefas, equipes multifuncionais, e ainda, estimativas e velocidade

no Scrum e no Kanban; e, a última seção traz as considerações finais da pesquisa, destacando

os pontos significativos, onde são demonstradas as respostas aos problemas configurados,

bem como a confirmação, ou não, dos objetivos.

No final do Artigo em pauta tem-se, ainda, as referências utilizadas para a sua elaboração.

4

2 REFERENCIAL TEÓRICO

2.1 Evolução no gerenciamento de projetos

O gerenciamento de projetos de desenvolvimento de software baseava-se em

metodologias tradicionais, conhecidas como pesadas ou orientadas para documentação.

Dentre as metodologias tradicionais, está o modelo clássico ou sequencial, que apresenta

etapas, tais como: definição de requisitos, projeto do software, implementação e teste unitário,

integração e teste do sistema, operação e manutenção. Esse modelo dominou a forma de

desenvolvimento de sistemas até a década de 90. (SOARES, 2004)

O autor afirma, ainda, que, a partir desse período, alguns contrapontos foram

levantados por pesquisadores, dentre estes, Brooks (1987, apud SOARES, 2004) que,

defendeu ser impossível especificar totalmente um software antes do início de sua construção,

bem como, Gilb (1999, apud SOARES, 2004) que defendeu o uso do modelo incremental, ao

invés do modelo clássico em grandes projetos de software, por considerá-lo um modelo que

apresenta menores riscos e maiores possibilidades de sucesso.

Conforme Sato (2007, p. 2), os esforços voltados para definição de processos e

métodos mais burocráticos e rigorosos não foram suficientes para resolver a ‘crise do

software’, que apresentava, entre outros, os seguintes sintomas: sistemas mal construídos,

software sem garantia e projetos fracassados.

Na última década, as metodologias ágeis de desenvolvimento de software surgiram

para tentar superar esses desafios. Na ocasião, dezessete especialistas em processos de

desenvolvimento de software, entre eles, Schwaber e Beedle (2002), que representavam o

método Scrum, e Beck (1999), com o Extreme Programming (XP), firmaram a Aliança Ágil,

da qual emergiu o Manifesto Desenvolvimento Ágil de Software, Agile Software

Development Manifesto (2001, s.p.), em que alguns princípios passaram a ser valorizados, tais

como: “Indivíduos e interações [...]; Software em funcionamento [...]; Colaboração com o

cliente [...]; Responder a mudanças [...]” sem, no entanto, descartar os processos e as

ferramentas, a documentação, a negociação e o plano.

O Manifesto Ágil (2001) apresenta princípios que estão relacionados à satisfação do

cliente; à flexibilidade para mudanças nos requisitos; com frequência menor nos períodos de

entrega do software; trabalho diário e conjunto de pessoas relacionadas ao negócio e aos

5

desenvolvedores; motivação e confiança na equipe, bem como ambiente e suporte favorável;

comunicação face a face; funcionamento do software como parâmetro de progresso; ritmo

constante e sustentável; agilidade, considerando excelência técnica e bom design;

simplicidade; equipe auto gerenciável, de onde surgem os melhores requisitos, arquiteturas e

design; reflexão da equipe sobre seu próprio trabalho, sistematicamente.

Os princípios citados favorecem mais o dinamismo do processo, conferindo maior

motivação para a equipe e, ao mesmo tempo, fornecendo informações precisas sobre o

projeto, tanto para a equipe como para o cliente.

Os princípios e valores do Manifesto Ágil fazem parte de uma forma de pensar do

desenvolvimento de software, isto é, engloba abordagens específicas, diferentes ideias,

comunidade e lideranças, em que, cada comunidade, mesmo formando grupos distintos, segue

os mesmos princípios, sendo comum a relação de troca de conhecimentos e práticas entre

várias delas. (SATO, 2007, p. 10)

2.2 Sistema Scrum

O Scrum é um método que foi desenvolvido nas décadas de 1980 e 1990, por Ken

Schwaber, Jê Sutherland, e Mike Beedle, tendo como principal característica a capacidade de

se concentrar “nos aspectos gerenciais do processo de desenvolvimento de software, sem

determinar como a equipe executa as tarefas de programação”. Tal abordagem propicia a

auto-organização da equipe, bem como, permite que haja integração com outras metodologias

ágeis. (KATAYAMA, 2010, p. 89)

Os criadores do Scrum o definem como sendo “[...] um framework estruturado para

suportar o desenvolvimento de produtos complexos desde o início dos anos 90”. Acrescentam

ainda que, o Scrum “não é um processo ou técnica para construir produtos, é mais um

framework, dentro do qual se pode empregar processos e técnicas variadas”, tornando “[...]

clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos”,

visando melhorá-las. (SCHWABER; SUTHERLAND, 2011, p.3)

Referidos autores apresentam ainda, componentes e regras, como fundamentais para

o uso do Scrum, que “consiste nas equipes [...], papéis, eventos, artefatos e regras associados”,

entretanto, cada “componente do framework serve a um propósito específico e é essencial

para o sucesso e uso do Scrum”. (idem)

6

Teoricamente o Scrum baseia-se no empirismo, isto é, no conhecimento que advém

da experiência concreta e que, para os autores, orientam a tomada de decisão, bem como, se

utiliza de uma abordagem iterativa e incremental, visando o aperfeiçoamento da

previsibilidade e o controle dos riscos. Enumera, ainda, três pilares de sustentação para “a

implementação de um controle de processo empírico: transparência, inspeção e adaptação”.

(SCHWABER; SUTHERLAND, 2011, p. 3)

No que se refere às iterações do Scrum, estas são propostas, para que ocorram no

espaço de tempo entre 15 e 30 dias, sendo denominadas de Sprints. A dinâmica de Sprints se

configura da seguinte forma: no início, para estimar e definir a meta do Sprint e das tarefas

necessárias (Backlog), ocorre uma reunião de planejamento, depois da qual a equipe inicia o

desenvolvimento do produto, em um período que pode variar entre uma a quatro semanas,

conforme se demonstra na figura1.

Figura 1 - Exemplo de um processo Scrum

Fonte: Agilecoaching (2012).

Visando evitar que instabilidades e fatores externos afetem o desempenho da equipe,

de modo a mantê-la centrada no objetivo, um personagem denominado Scrum Master tem um

papel fundamental na equipe, isto é, ele é o responsável por ensinar e acompanhar a

utilização do Scrum. Para tanto, é exigido dele conhecimentos sobre o processo e o produto,

inclusive, para orientar na tomada de decisão do Product Owner3. Este, por sua vez, deve ter

3 O Product Owner (dono do produto ou cliente) “deve garantir que o produto atenda aos anseios do patrocinador do projeto, priorizar quais funcionalidades devem ser entregues e quais agregam mais valor ao projeto. Para exercer tal função, o dono do produto deve possuir a visão do mesmo, sendo responsável pelo retorno sobre o investimento do projeto”. (KATAYAMA, 2010, p. 89)

7

uma visão geral, acompanhando o desenvolvimento e esclarecendo as dúvidas que porventura

possam surgir, sem, no entanto, alterar o escopo. (KATAYAMA, 2010)

Outro aspecto é que, para assegurar que os itens do backolog não mudem após o

planejado, considerando que alterações no ambiente de negócios podem exigir mudanças nos

requisitos, o dono (ou demandante) do produto tem a opção de cancelar o Sprint e realizar

outra reunião de planejamento. Neste caso, “o Scrum mantém a visão geral da produtividade,

que seria prejudicada caso requisitos pudessem ser modificados e adicionados durante um

Sprint”. Além disso, também provê um mecanismo de adaptação e correção para os

requisitos. (KATAYAMA, 2010, p. 90)

O autor afirma que o acompanhamento diário, durante o Sprint, deve-se efetivar por

meio das nomeadas Reuniões em pé (stand-up meetings), isto é, a equipe se reúne

rapidamente, de modo a sincronizar o trabalho, quando, então, cada membro descreve o que

produziu entre um encontro e outro, bem como, aponta para o que pretende realizar e enumera

os problemas enfrentados, de forma que toda a equipe descubra, de antemão, seus obstáculos

em potencial, ao mesmo tempo em que compartilham conhecimentos.

Concluído o Sprint, na reunião de revisão, o trabalho é apresentado ao dono do

produto, para analisar se os itens atendem suas necessidades e se a meta foi atingida.

Na reunião de retrospectiva, realizada após cada entrega, a equipe deve avaliar seu

trabalho, identificando as oportunidades e os principais pontos de melhoria no próximo

Sprint. (KATAYAMA, 2010)

2.3 Sistema Kanban

Kanban, literalmente, significa “cartão visual”. O Sistema Kanban é um método de

produção, baseado em controles visuais Kanban, usado na metodologia Manufatura Lean,

criando um fluxo contínuo de materiais, com o objetivo de evitar a superprodução de

materiais e de ter um controle visual do que está sendo produzido e em qual sequência.

(SPEAR; BOWEN, 1999)

Os diversos princípios e práticas baseadas nesta metodologia foram absorvidos pelos

Métodos Ágeis, tendo sido criado o método Lean Software Development, por Poppendieck

(2006), que adaptaram e resumiram os conceitos de Lean para o desenvolvimento de software.

Kniberg e Mattias (2009, p.25) definem as práticas do Kanban, resumidamente, e

exemplificam, conforme se observa na figura 2:

8

Visualize o fluxo de trabalho - Divida o trabalho em partes, escreva cada item em um cartão e coloque na parede. - Use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho. Limite o trabalho em progresso (WIP - work in progress) – associe limites explícitos para quantos itens podem estar em progresso em cada estado do fluxo de trabalho. Acompanhe o tempo de execução da tarefa (tempo médio para completar um item, algumas vezes chamado de “tempo de ciclo”), otimize o processo para tornar o tempo de execução o menor e mais previsível possível.

Figura 2 - Exemplo de quadro Kanban simples, com os limites em vermelho.

Fonte: Kniberg e Mattias (2009, p.26)

2.4 Diferenças e Similaridades entre Scrum e Kanban

Para apresentar as possibilidades de uso da combinação Scrum e Kanban no

gerenciamento de projetos, é preciso conhecer, primeiramente, o que ambas têm em comum.

Neste sentido, as similaridades entre Scrum e Kanban, segundo Kniberg e Mattias

(2009) são:

ambos são Lean e Agile; ambos usam controle de cronograma; ambos limitam atividades em andamento; ambos usam transparência para direcionar a melhoria do processo; ambos concentram-se na entrega de software que funcione, o mais rápido possível

e frequentemente; ambos são baseados em equipes auto-organizáveis; ambos exigem que o trabalho seja dividido em partes; e, em ambos, o planejamento de release é continuamente otimizado, baseado em

dados (velocidade / tempo de execução) empíricos.

As diferenças entre Scrum e Kanban, segundo Kniberg e Mattias (2009), podem ser

resumidas, conforme se apresenta no quadro 1.

9

Quadro 1- Diferenças entre Scrum e Kanban

SCRUM KANBANIterações Timeboxed prescritas. Iterações Timeboxed opcionais. Pode ter

cadência separada para o planejamento, release e melhoria de processos. Pode ser orientada para eventos, em vez de Timeboxed.

Equipe compromete-se a uma quantidade específica de trabalho para esta iteração.

Compromisso opcional.

Usa a velocidade como padrão métrico para o planejamento e melhoria de processos.

Usa o Lead time como padrão métrico para o planejamento e melhoria de processos.

Equipes multifuncionais prescritas. Equipes multifuncionais opcionais. Equipes de Especialistas autorizada.

Os itens devem ser divididos para que possam ser concluídos dentro de 1 sprint

Nenhum tamanho especial de item é prescrito

Gráfico Burndown Nenhum tipo específico de diagrama é prescrito

WIP limitado indiretamente (por sprint) WIP limitado diretamente (por situação do fluxo de trabalho)

Estimativa prescrita Estimativa opcional Não poderá adicionar itens à iteração em uso

Pode adicionar novos itens sempre que houver capacidade disponível

O sprint backlog é de uma equipe especifica

Quadros Kanban podem ser compartilhados por várias equipes ou individualmente

Possui 3 papéis (Product Owner/ScrumMaster/Team)

Não discrimina nenhum papel

Um quadro Scrum é reiniciado entre cada sprint

Um quadro Kanban continua

Prescreve um product backlog priorizado Priorização é opcionalFonte: Kniberg e Mattias (2009, p.81)

O uso da combinação do Scrum com Kanban pode ser justificado em várias

situações: o cliente deseja nova funcionalidade, porém, o prazo entre um Sprint e outro não

permite, posto que, no Scrum, Sprints ocorrem no espaço de tempo entre 15 e 30 dias. Tal

espera pode levar à insatisfação do cliente. Neste caso, justifica-se a utilização de Kanban,

visto que demanda o mínimo de tempo de espera para que nova funcionalidade seja aceita.

Um cenário, onde o Sprint é constantemente alterado, devido a correções de erros ou

a mudanças de prioridade do projeto, favorece a combinação de técnicas das duas

metodologias. Como exemplo, cita-se a observação de Silva et al (2012, s.p), que relatam a

dificuldade de medir a capacidade de atendimento da equipe e respeitar o que foi acertado no

Sprint.

10

Outro problema encontrado nesta abordagem foi a impossibilidade de se realizar um acompanhamento efetivo para as tarefas extras. A real capacidade da equipe de atender essas solicitações e a priorização pelo cliente se tornava complicada, uma vez que a maioria das demandas chegava com prioridade alta. Sendo assim, a equipe acabava parando o desenvolvimento do que tinha sido planejado para dar uma resposta rápida ao cliente que, devido ao sistema estar em produção, não tinha como esperar uma próxima iteração para a equipe planejar e iniciar essas atividades. Na maioria dessas demandas extras era essencial a realização do trabalho operacional do cliente. Diante disso, as metas dos sprints continuavam não sendo atingidas.

Em situações de contingências (eventualidades, tais como doenças, afastamentos,

etc), o planejamento realizado no Sprint pode ser comprometido, levando a ajustes, ou, até

mesmo, inviabilizando os planos, acarretando frustações na equipe e insatisfação do cliente.

No Kanban, o planejamento foca a necessidade mais imediata.

As características dessas duas metodologias residem no fato de ambas serem bastante

adaptativas, sendo possível combiná-los, mesmo considerando que o Scrum é mais prescritivo

que o Kanban. (KNIBERG; MATTIAS, 2009)

3 METODOLOGIA

Este estudo se caracteriza, quanto aos objetivos, como uma pesquisa descritiva;

quanto aos procedimentos, como uma pesquisa bibliográfica; e, quanto à abordagem do

problema, apresenta-se como uma pesquisa qualitativa.

Sobre a conjectura atinente, Neves (1996, p. 1) afirma que a pesquisa qualitativa:

[...] costuma ser direcionada, ao longo de seu desenvolvimento; além disso, não busca enumerar ou medir eventos e, geralmente, não emprega instrumental estatístico para análise dos dados; seu foco de interesse é amplo e parte de uma perspectiva diferenciada adotada pelos métodos quantitativos. Dela faz parte a obtenção de dados descritivos mediante contato direto e interativo do pesquisador com a situação objeto de estudo.

Portanto, compreende-se que a abordagem qualitativa é a que melhor se apresenta

para a realização desse estudo.

4 RESULTADOS DA PESQUISA

11

A aplicação de uma metodologia ágil, combinando Scrum e Kanban no

gerenciamento de projetos de desenvolvimento de sistemas, favorece o gerenciamento dos

projetos, na medida em que beneficia o aprendizado, ajudando a superar desafios, motivando

as equipe e contribuindo para a satisfação do cliente.

Percebe-se que, os resultados apresentados mostram variados processos e técnicas no

gerenciamento e desenvolvimentos de produtos, bem como, apresenta o Kanban como um

método baseado em controles visuais do fluxo do trabalho, ao mesmo tempo em que são

apontadas as diferenças e similaridades entre Scrum e Kanban.

Consideram-se as possibilidades de combinação entre ambos, como decorrentes da

característica flexível do Kanban, como alternativa, quando as prescrições do Scrum não são

possíveis. Portanto, a dinâmica do uso combinado Scrum e Kanban facilitam as adaptações no

contexto em que as mudanças são constantes.

No Scrum, os requisitos são escritos como estórias dos usuários, armazenadas em um

repositório chamado backlog. Estas estórias são selecionadas na reunião de planejamento para

formarem o escopo da iteração (sprint), composto por todas as estórias (quebra das tarefas)

que o desenvolvimento deverá entregar ao final da iteração. A figura 3 mostra o

funcionamento do Scrum.

Figura 3 - Ciclo de desenvolvimento no Scrum

Fonte: Autoria própria.

4.1 Scrum Backlog

12

Alguns aspectos relacionados ao Scrum Backlog precisam ser considerados, quando

da quebra de itens, em pedaços menores, para se adequar ao Sprint.

Kniberg e Mattias (2009, p. 57) disciplinam que, uma equipe Scrum se compromete

somente com “os itens que julguem poder terminar dentro de uma iteração (baseado no

conceito de “Done”)”.

Quando o item é grande demais para caber em um Sprint, a equipe e o Product

Owner deverão encontrar formas de quebrá-lo até que ele se encaixe. Quando os itens tendem

a ser grandes, as iterações, consequentemente, tendem, também, a se tornarem maiores (não

maiores do que 4 semanas). A figura 4 mostra esse contexto.

Figura 4 - Itens são quebrados para caberem dentro do Sprint

Fonte: Kniberg e Mattias (2009, p. 57)

Numa equipe Kanban, os membros procuram minimizar o tempo de execução e

buscam equilibrar o fluxo, de modo que, criam, indiretamente, um incentivo para quebrar

itens em partes relativamente menores.

Vale ressaltar que, não há regra explícita que indique quais itens devam ser pequenos

o suficiente para caber em um determinado período de tempo, podendo ocorrer que, “Em um

mesmo quadro nós podemos ter um item que irá levar 1 mês para ser concluído e outro item

que levará 1 dia”. (KNIBERG; MATTIAS, 2009, p. 58). A figura 5 determina essa vertente.

Figura 5 - Exemplo de tarefas de tamanho variado em Kanban.

Fonte: Kniberg e Mattias (2009, p. 58).

13

Apesar de Scrum ter como fundamento essencial a quebra de tarefas, para auxiliar no

seu comprometimento no Sprint, podem existir tarefas que tem uma duração maior que o

tempo de um Sprint, e, nesse caso, a equipe pode optar por usar o Kanban, onde não existe

nenhuma regra que obriga que tarefas caibam em um Sprint, observando os limites de cada

etapa do fluxo e o andamento dessas tarefas.

Ao final de cada Sprint é recomendado fazer um Sprint Review, Sprint Retrospective,

para, a partir daí, ser liberado um Release com as novas funcionalidades. Isso é realizado em

cadência única, caso a equipe tenha como opção aceitar itens com tamanhos diversos. Neste

caso, essa cadência passa a ser orientada a eventos.

4.2 Iterações em time-box

O Scrum baseia-se em iterações de tempo fixo, isto é, a duração da iteração pode ser

escolhida, sendo recomendado, no entanto, manter a mesma duração por algum período, no

sentido de estabelecer uma cadência.

A princípio, é criado um plano de iteração, definido pela equipe, onde um

determinado número de itens do Product Backlog é selecionado, tomando, como base, as

prioridades definidas pelo Product Owner, bem como, fundamentado na quantidade de itens

que a equipe considera possível entregar em uma iteração.

Durante a iteração, a concentração da equipe deve ser a entrega dos itens acordados.

Para finalizar a iteração, o código de trabalho é demonstrado pela equipe às partes

interessadas. “Em seguida, a equipe faz uma retrospectiva para discutir e melhorar seu

processo” (KNIBERG; MATTIAS, 2009, p. 34).

Neste sentido, considera-se que, o “Scrum é uma única cadência de tempo fixo que

combina três diferentes atividades: planejamento, melhoria de processo e (idealmente)

release”. Já no Kanban, “as iterações de duração fixa não são prescritas”, podendo a escolha

das atividades de planejamento, a melhoria do processo e a entrega do produto serem feitas

em períodos regulares (‘release toda segunda’), ou por demanda (‘release sempre que se tiver

algo útil a entregar’). (KNIBERG; MATTIAS, 2009, p. 34).

Pode-se ilustrar três tipos de cadências: única (figura 6), de três cadências (figura 7) e

orientada para eventos (figura 8).

Figura 6 - Equipe Scrum utiliza cadência única

14

Fonte: Kniberg e Mattias (2009, p. 35).

A figura 7 apresenta três cadências diferentes, para cada quatro semanas:

semanalmente é liberado tudo o que ficou pronto para o release. A cada duas semanas, faz-se

reunião de planejamento. A cada quatro semanas, acontece a reunião de retrospectiva para

ajustar e buscar melhorias no processo. (KNIBERG; MATTIAS, 2009, p. 36)

Figura 7 - Equipe utiliza três cadências

Fonte: Kniberg e Mattias (2009, p. 36).

Na figura 8, o autor apresenta cadência mais orientada para eventos, iniciando-se

com uma reunião de planejamento, sempre que é concluído o trabalho. Na medida em que há

um grupo de funcionalidades finalizadas e prontas para serem entregues, inicia-se um release,

bem como, sempre se inicia um círculo de qualidade quando a equipe se depara com o mesmo

problema por duas vezes. Outra iniciativa é se fazer uma retrospectiva, mais aprofundada, na

quarta semana. (KNIBERG; MATTIAS, 2009, p. 37)

Figura 8 - Equipe com cadência orientada para eventos

Fonte: Kniberg e Mattias (2009, p. 36).

15

4.2 Mudanças dentro de uma iteração

Os autores afirmam que, Scrum resiste às mudanças dentro de uma iteração, ou seja,

se uma atividade precisar ser adicionada, isso não poderá ser feito imediatamente no Sprint

atual, mas, poderá ser adicionada no Product Backlog e, caso seja prioritário para o Product

Owner, deverá ser adicionada no próximo Sprint. Isso justifica o fato de que, “Sprints do

tamanho certo dão ao time tempo focado suficiente para conseguir fazer alguma coisa,

enquanto ainda permitem que o Product Owner gerencie e atualize prioridades com

periodicidade regular”. (KNIBERG; MATTIAS, 2009, p. 51)

No caso de uma equipe de Kanban, a mudança poderá ocorrer, devendo ser posta a

atividade na coluna “não iniciada”, contanto que, obedecidos os limites por coluna (conforme

o caso), devendo a equipe continuar a trabalhar na atividade atual e na medida da capacidade,

e tomar o item que está no topo da coluna “não iniciado”.

Agindo assim, o tempo que demora a responder à mudança de prioridade (tempo de

resposta) é medido pelo tempo de tomar o item inserido. Tal procedimento baseia-se “no

princípio de ‘um item fora = um item dentro’ (controlado pelos limites de trabalho em

andamento)”. (KNIBERG; MATTIAS, 2009, p. 52)

O tempo de resposta em Scrum é calculado através da média da metade da duração

do Sprint. “O Product Owner não pode alterar o quadro Scrum quando a equipe já estiver

comprometida com determinados de itens na iteração”, ao passo que, em Kanban, é preciso

“definir as próprias regras básicas sobre quem tem permissão de modificar o que no quadro.

Normalmente, para o Product Owner, é reservada uma coluna do tipo ‘A Fazer’ ou ‘Done’ ou

‘Backlog’ ou, ainda, 'Proposta’ à esquerda, onde se pode fazer as modificações que bem

entender”. (KNIBERG; MATTIAS, 2009, p. 52)

Os doutrinadores consideram, no entanto, que:

[...] estas duas abordagens não são mutuamente exclusivas. Uma equipe Scrum pode decidir por deixar o Product Owner modificar as prioridades no meio do Sprint (ainda que isto devesse ser considerado normalmente uma exceção). E uma equipe Kanban pode decidir incluir restrições sobre quando as prioridades podem ser modificadas [...] [bem como] Uma equipe Kanban pode ainda decidir usar iterações com duração fixa e compromissos predefinidos, tal como em Scrum. (KNIBERG; MATTIAS, 2009, p. 52)

Silva et al (2012) afirmam que estavam lidando com sistemas legados, que existiam

muitas incertezas e imprevisibilidade. Nesses casos, não há como evitar demandas não

programadas. O motivo pelo qual o fluxo de Scrum não seguia normalmente era a grande

16

quantidade de demandas extras, urgentes e não planejadas, que surgiam no meio do Sprint.

Com isso, os recursos eram realocados, comprometendo o que havia sido planejado.

4.3 Quadro para acompanhamento de tarefas

Geralmente, no Scrum, usa-se o quadro para ilustrar as tarefas a serem executados no

Sprint, assim como, no Kanban, utiliza-se o quadro Kanban, ambos com o intuito de controlar

o fluxo de tarefas ao longo do processo, como mostra a figura 9 (KNIBERG; MATTIAS,

2009, p. 37).

Figura 9 - Exemplo de quadro Scrum e Kanban.

Fonte: Kniberg e Mattias (2009, p.37)

Kniberg e Mattias (2009, p.38) explicam que, na Figura 6, a diferença está apenas no

algarismo “2”, posto na coluna “andamento” do Kanban, significando que ‘não pode haver

mais de 2 itens nesta coluna ao mesmo tempo’.

Na coluna “em execução”, não há, no Scrum, regra que determine quantas atividades

podem ocorrer simultaneamente, no entanto, como a iteração tem um escopo fixo, no exemplo

acima, fica limitado a quatro.

Conclui-se que, o Scrum, indiretamente, limita as atividades em andamento, ao passo

que, o Kanban limita diretamente. A prática tem mostrado às equipes Scrum que não é uma

boa alternativa ter muitas atividades simultâneas na coluna “em execução”, assim como, tem-

se favorecido a cultura de não se iniciar outra atividade antes de finalizar aquelas que estão

em curso. Caso as equipes limitem as atividades na referida coluna, o quadro Scrum passa a se

configurar em quadro Kanban, significando que “equipes Scrum podem usar um quadro

Kanban para gerenciar suas tarefas”. (KNIBERG; MATTIAS, 2009, p. 38)

17

Silva et al (2012) relatam a dificuldade no uso do quadro Scrum, sem limitar a

quantidade de tarefas na coluna “verificar”, que acarretava um atraso na liberação de outras

funcionalidades, comprometendo, assim, o ritmo e a frequência de entregas. Quando a equipe

passa a limitar um determinado estado do fluxo, equipes de Scrum passam a usar o quadro

Kanban.

4.4 Equipes multifuncionais

Quanto às equipes, estas podem ser multifuncionais, sendo esta uma característica do

Scrum, ao passo que é opcional, no Kanban. As características de uma equipe multifuncional

requer que todos os membros tenham as habilidades necessárias para completar todos os itens

constantes na iteração. (KNIBERG; MATTIAS, 2009)

A visibilidade do quadro Scrum, conforme se apresenta na figura 10, é recomendada,

pois permite que seja visto por qualquer pessoa na Organização, porém, a edição do mesmo

somente poderá ser feita por membros da equipe, haja vista que se trata de uma ferramenta (o

quadro) que orienta o gerenciamento do compromisso assumido pela equipe no Sprint

Planning, diferentemente do Kanban, em que o quadro de atividades não é “propriedade

exclusiva” de uma única equipe, estando relacionado, não especificamente às atividades de

uma equipe, mas, ao fluxo de trabalho que envolve várias equipes. (KNIBERG; MATTIAS,

2009, p. 55)

Figura 10 - Exemplo de quadro Scrum, Kanban, multifuncionais ou não.

Fonte: Adaptado de Kniberg e Mattias (2009, p.56)

A figura 10 relaciona dois exemplos, sendo que, o primeiro mostra o quadro de

atividades de uma equipe multifuncional do Kanban, da mesma forma como ocorre no Scrum.

18

No exemplo 2, no que se refere ao quadro Kanban, o Product Owner define prioridades

(coluna 1), a equipe multifuncional de desenvolvedores realiza o desenvolvimento (coluna 2)

e testa (coluna 3), e a equipe especializada é responsável pela entrega (coluna 4). Uma

sobreposição de competências é observada, ao mesmo tempo em que poderá haver um

deslocamento de um membro da equipe de desenvolvimento, objetivando agilizar a entrega.

Pressupõe-se que, em Kanban é necessário estabelecer regras básicas, determinando

quem e como deve ser usado o quadro de atividades. Essas regras devem ser experimentadas

até que o fluxo seja aperfeiçoado. (KNIBERG; MATTIAS, 2009, p. 56)

Compreende-se, portanto, que o papel das equipes, multifuncionais ou não, requer

compromisso, para que o fluxo de trabalho aconteça satisfatoriamente, dentro do previsto e do

que foi assumido.

4.5 Estimativa e velocidade

No que pertine à prescrição de estimativas e velocidades, no Scrum, a primeira é

relacionada à quantidade de trabalho estimada para cada item, com os quais os membros se

comprometem realizar. A segunda (velocidade) é a medida da capacidade (quantidade de

coisas) que pode ser entregue por Sprint, calculada “somando o tamanho de cada item

concluído ao final de cada Sprint”. Os doutrinadores orientam que a equipe deve tomar

conhecimento da velocidade, permitindo, dessa forma, fazer previsões de entregas mais

próximas da realidade.

Em Kanban, fazer estimativa é opcional. “Algumas equipes optam por fazer

estimativas e medir a velocidade assim como no Scrum. Outras equipes escolhem pular as

estimativas, mas tentam quebrar cada item em itens menores de aproximadamente do mesmo

tamanho – desta forma eles podem medir a velocidade simplesmente em termos de quantos

itens foram concluídos por unidade de tempo”. (KNIBERG; MATTIAS, 2009, p. 60).

Vale ressaltar que, “Scrum e Kanban não são perfeitos tampouco completos. Eles

não lhe dizem tudo o que você precisa fazer, eles apenas lhes oferecem algumas restrições e

orientações.” (KNIBERG; MATTIAS, 2009, p. 28)

Há, portanto, inúmeras formas e técnicas de planejamento de entregas e de

gerenciamento de compromissos para o modelo Kanban, devendo ser escolhida a que melhor

se enquadre ao contexto, não havendo técnica específica ou obrigatória a ser seguida.

19

CONSIDERAÇÕES FINAIS

Através deste estudo, buscou-se explicitar as contribuições da aplicação de uma

metodologia ágil, combinando Scrum e Kanban no gerenciamento de projetos de

desenvolvimento de sistemas, visto que, tal medida favorece a melhoria no gerenciamento dos

projetos, ao passo que motiva a equipe, trazendo um maior comprometimento de todos para

lograr êxito. Outro aspecto a se considerar, analisado nesta combinação, é que permite a

inspeção contínua, facilitando as adaptações durante o processo de desenvolvimento.

É consenso na literatura consultada que a combinação de Scrum e Kanban vem sendo

relevante para o gerenciamento de projetos de sistemas, uma vez que Kanban se apresenta de

forma muito flexível e, por isso, é uma alternativa, quando as prescrições do Scrum não são

possíveis.

No decorrer deste artigo, foram apresentados aspectos relacionados à evolução no

gerenciamento do projeto, desde quando o desenvolvimento de software baseava-se em

metodologias tradicionais até a utilização de metodologias ágeis para superar problemas no

desenvolvimento de software.

Outro ponto abordado refere-se à apresentação do Scrum, definindo-o como

framework, em que é possível utilizar variados processos e técnicas no gerenciamento e

desenvolvimentos de produtos, bem como descreve as iterações.

O Kanban é, ainda, apresentado como um método que se baseia em controles visuais,

que possibilita visualizar o fluxo do trabalho, limitando-o em progresso e realizando o

acompanhamento do tempo de execução da tarefa.

Ao apresentar tais aspectos, são apontadas as diferenças e similaridades entre Scrum

e Kanban, a partir de quadro comparativo, no sentido de analisar as possíveis combinações,

principalmente pelo fato de ambos apresentarem características adaptativas.

A revisão sistemática das obras citadas está direcionada para compreender como a

combinação pode ser realizada, identificando as possibilidades de melhoria e sucesso para as

equipes, seja de gerenciamento ou de desenvolvimento.

Os resultados apontam que, as exigências atuais do mercado de sistemas, cada vez

mais complexos, em um curto espaço de tempo, e compatíveis com os requisitos, que são

alterados constantemente, levaram as empresas a adotarem combinações que possibilitem

20

reduzir o tempo de entrega e os custos, em um contexto que não está livre de muitos

problemas.

Para que a combinação se apresente apropriada é preciso conhecer o funcionamento

do Scrum e do Kanban, bem como, saber como se deve usar o Scrum com Kanban, admitindo

o Scrum Backlog, as iterações em time-box, as mudanças dentro de uma iteração, o quadro de

acompanhamento de tarefas, as equipes multifuncionais, a estimativa e a velocidade.

A combinação Scrum com Kanban pode ser adotada por equipes, pois ambas

apresentam características adaptativas, e são baseados no desenvolvimento iterativo e

incremental, possibilitando, dessa forma, trazer mudanças significativas, tais como, a

diminuição do número de reclamações, a superação dos pontos de gargalos e a melhoria na

qualidade do serviço.

Ressalta-se que, ao combinar Scrum e Kanban, a organização não estará isenta de

todas as dificuldades, mas, enfrentá-los, passa a ser um desafio, sobretudo de equipes.

REFERÊNCIAS

AGILE MANIFESTO [site]. [S.l.]. Manifesto para Desenvolvimento Ágil de Software, 2001.Disponível em: <http://agilemanifesto.org/>. Acesso em: 1 fev. 2012.

AGILE COACHING [site]. [S.l.]: Agile Coaching DK, 2012. Disponível em: <http://www.agilecoaching.dk>. Acesso em: 1 fev. 2012.

BECK, Kent. Extreme Programming Explained: Embrace Change. 2. ed (The XP Series). Boston, Massachusetts: Addison-Wesley Professional, 1999.

GIL, A. C. Como elaborar projetos de pesquisa. 5. ed. São Paulo: Atlas, 2010.

KATAYAMA, Eduardo Teruo. A contribuição da indústria da manufatura no desenvolvimento de software. 2010. 114 p. Dissertação (Mestrado em Ciência da Computação). Instituto de Matemática e Estatística da Universidade de São Paulo, São Paulo, 2010. Disponível em: <http://grenoble.ime.usp.br/~gold/orientados/dissertacao-EduardoKatayama.pdf>. Acesso em: 1 fev. 2012.

KNIBERG, H.; MATTIAS, S. Kanban e Scrum: obtendo o melhor de ambos. C4Media, 2009. 139 p. Disponível em: <http://www.infoq.com/br/minibooks/Kanban-Scrum-minibook>. Acesso em: 1 fev. 2012

LARMAN, Craig. Agile and iterative development: a manager’s guide. Boston, Massachusetts:Addison-Wesley Professional, 2003.

21

NEVES, José Luiz. Pesquisa qualitativa: características, usos e possibilidades. Cadernos de Pesquisas em Administração, São Paulo, v.1, nº3, 2º sem./1996. Disponível em: <http://www.ead.fea.usp.br/Cad-pesq/arquivos/C03-art06.pdf>. Acesso em: 02 fev. 2012.

POPPENDIECK, M.; POPPENDIECK, T. Implementing Lean Software Development: From Concept to Cash. Boston, Massachusetts: Addison-Wesley Professional, 2006.

SATO, D. T. Uso eficaz de métricas em métodos ágeis de desenvolvimento de software. 2007. Dissertação (Mestrado em Ciência da Computação). Universidade de São Paulo. Instituto de Matemática e Estatística. São Paulo, 2007. Disponível em: <www.teses.usp.br/teses/disponiveis/45/45134/tde-06092007-225914/>. Acesso em: 2 fev. 2012.

SCHWABER, Ken. SUTHERLAND, Jeff. The Scrum Guide. [S.l.], 2011. Disponível em:<http://www.Scrum.org/storage/Scrumguides/Scrum_Guide.pdf>. Acesso em: 2 fev. 2012.

SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. NJ: Prentice-Hall, 2002.

SILVA, Diogo Vinícius de S.; SANTOS, F. Alan de O.; SANTOS NETO, Pedro. Os benefícios do uso de Kanban na gerência de projetos de manutenção de software. Belo Horizonte, MG, 2012. VIII Simpósio Brasileiro de Sistemas de Informação (SBSI 2012)Trilhas Técnicas. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/sbsi/2012/0035.pdf>. Acesso em: 20 jun.2012.

SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete. Conselheiro Lafaiete, MG, 2004. Disponível em:<www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em: 2 fev. 2012.

SPEAR, S.; BOWEN, H.K.. Decoding the DNA of the Toyota production system. [S.l.]: Harvard Business Review, 77:96-108, 1999.