APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO DE PROJETOS DE SISTEMAS
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 4,350 views

 

Statistics

Views

Total Views
4,350
Views on SlideShare
4,347
Embed Views
3

Actions

Likes
3
Downloads
181
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO DE PROJETOS DE SISTEMAS Document Transcript

  • 1. 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 2RESUMOO surgimento de metodologias ágeis está contribuindo para ajudar equipes dedesenvolvimento de software a responder, de forma eficaz e efetiva, às constantes mudançasdo mercado atual. Uma das possibilidades de uso, neste contexto, refere-se à combinaçãoScrum e Kanban para o gerenciamento de projetos de sistemas. Neste sentido, este estudoexplicita 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 ebibliográfica, com abordagem qualitativa. Os entendimentos literários indicam que, ascontribuições do Scrum e Kanban, combinadas, favorecem a melhoria dos processos degerenciamento e de desenvolvimento, e podem ser adotadas por equipes, visto que ambosapresentam características adaptativas e são baseados no desenvolvimento iterativo eincremental, possibilitando, dessa forma, trazer mudanças consideráveis. Ressalta-se que, aocombinar 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.ABSTRACTThe emergence of agile methodologies is contributing to help software development teams torespond efficiently and effectively to changing market today. One of the possibilities of use inthis context refers to the combination of Scrum and Kanban for the project managementsystems. Thus, this study clarifies the contributions of this combination, with their differencesand similarities, as well as the odds for their use. This is a descriptive and literature, withqualitative approach. The literary understandings indicate that the contributions of Scrum andKanban, combined, favor the improvement of management processes and development, andcan be taken by teams as they both have adaptive characteristics and are based on iterativeand incremental development, enabling thus bring considerable changes. It should be noted1 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 emEmpreendedorismo na Engenharia pela Universidade Federal de Santa Catarina e graduação em Agronomia pelaUniversidade Federal do Ceará. Professora da Universidade Federal do Ceará e Coordenadora Adjunta do Cursode Sistemas de Informação da Faculdade Christus.
  • 2. 2that by combining Scrum and Kanban, the Organization will not be free of all problems, butface them becomes a challenge, especially for teams.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 projetosde desenvolvimento de sistemas, pode não atender às expectativas de sucesso, tornando-senecessárias, adaptações. Uma destas refere-se à combinação com Kanban. No contexto do mercado globalizado, em que as Organizações enfrentam crescentesexigências de produtividade e de competitividade, a busca por processos mais ágeis, e queagregam maior valor aos produtos, tem sido o foco constante do gerenciamento de projetos. Portanto, evidencia-se a busca por metodologias que contribuam para superar osatrasos, os custos, os prazos extrapolados, a baixa qualidade para, consequentemente, ter ocliente 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 fasedo planejamento, da execução ou, simplesmente, do acompanhamento. Diante desse quadro, apresenta-se a necessidade de frameworks para auxiliar ogerenciamento, 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 doprocesso de produção, visando, entre outras funcionalidades, maximizar a frequência e arapidez de entrega dos produtos desenvolvidos. Considerando as possibilidades de realizar combinações e adequações entre Scrum eKanban é que surgiu o interesse pelo assunto. Do contato com a temática, apresentou-se uma possibilidade de utilização prática naatividade profissional, exercida em uma empresa têxtil, sendo os softwares desenvolvidosinternamente para atender às necessidades da empresa. Vislumbra-se, portanto, a implantação
  • 3. 3futura da metodologia do Scrum, consciente de que, para tanto, existe a necessidade deadequação, utilizando como aporte o Kanban. Diante do exposto, este estudo tem como questão norteadora: quais as contribuiçõesda aplicação de uma metodologia ágil, combinando Scrum e Kanban no gerenciamento deprojetos de desenvolvimento de sistemas? É relevante apontar o que consta na literatura, acerca das possibilidades deadaptações na utilização do Scrum no gerenciamento de projetos de desenvolvimento desoftwares, que, combinado com Kanban, possa solucionar problemas quando da utilizaçãoexclusiva do Scrum. A pesquisa tem como objetivo geral explicitar as contribuições da aplicação de umametodologia ágil, combinando Scrum e Kanban, no gerenciamento de projetos dedesenvolvimento de sistemas; e, tem, como objetivo específico, estudar, para identificar comoa aplicação de uma metodologia ágil, combinando Scrum e Kanban, pode contribuir nogerenciamento de projetos de desenvolvimento de sistemas. O pressuposto é de que, a utilização do Scrum e do Kanban promova melhortransparência do andamento dos projetos desenvolvidos, contribuindo para a motivação e omaior comprometimento da equipe, favorecendo a inspeção contínua, proporcionando umamaior facilidade de adaptações durante o processo de desenvolvimento. Diante do exposto, considera-se que, a estrutura do presente artigo é composta por 5seções, nas quais, na seção 1, tem-se a introdução, que enfatiza a problematização, asjustificativas, 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 deprojetos, sistemas Scrum e Kanban, e as diferenças e as similaridades entre estes; a seção 3apresenta a metodologia da pesquisa, ressaltando-a quanto aos objetivos, aos procedimentos, eà abordagem; a seção 4 corresponde à análise dos resultados obtidos, englobando orepositório Scrum Backlog, iterações em time-box, mudanças dentro de uma iteração, quadropara acompanhamento de tarefas, equipes multifuncionais, e ainda, estimativas e velocidadeno Scrum e no Kanban; e, a última seção traz as considerações finais da pesquisa, destacandoos 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 suaelaboração.
  • 4. 42 REFERENCIAL TEÓRICO2.1 Evolução no gerenciamento de projetos O gerenciamento de projetos de desenvolvimento de software baseava-se emmetodologias tradicionais, conhecidas como pesadas ou orientadas para documentação.Dentre as metodologias tradicionais, está o modelo clássico ou sequencial, que apresentaetapas, 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 dedesenvolvimento de sistemas até a década de 90. (SOARES, 2004) O autor afirma, ainda, que, a partir desse período, alguns contrapontos foramlevantados 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, aoinvés do modelo clássico em grandes projetos de software, por considerá-lo um modelo queapresenta menores riscos e maiores possibilidades de sucesso. Conforme Sato (2007, p. 2), os esforços voltados para definição de processos emétodos mais burocráticos e rigorosos não foram suficientes para resolver a „crise dosoftware‟, 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 surgirampara tentar superar esses desafios. Na ocasião, dezessete especialistas em processos dedesenvolvimento de software, entre eles, Schwaber e Beedle (2002), que representavam omé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 SoftwareDevelopment Manifesto (2001, s.p.), em que alguns princípios passaram a ser valorizados, taiscomo: “Indivíduos e interações [...]; Software em funcionamento [...]; Colaboração com ocliente [...]; Responder a mudanças [...]” sem, no entanto, descartar os processos e asferramentas, a documentação, a negociação e o plano. O Manifesto Ágil (2001) apresenta princípios que estão relacionados à satisfação docliente; à flexibilidade para mudanças nos requisitos; com frequência menor nos períodos deentrega do software; trabalho diário e conjunto de pessoas relacionadas ao negócio e aos
  • 5. 5desenvolvedores; 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; ritmoconstante e sustentável; agilidade, considerando excelência técnica e bom design;simplicidade; equipe auto gerenciável, de onde surgem os melhores requisitos, arquiteturas edesign; reflexão da equipe sobre seu próprio trabalho, sistematicamente. Os princípios citados favorecem mais o dinamismo do processo, conferindo maiormotivação para a equipe e, ao mesmo tempo, fornecendo informações precisas sobre oprojeto, tanto para a equipe como para o cliente. Os princípios e valores do Manifesto Ágil fazem parte de uma forma de pensar dodesenvolvimento de software, isto é, engloba abordagens específicas, diferentes ideias,comunidade e lideranças, em que, cada comunidade, mesmo formando grupos distintos, segueos mesmos princípios, sendo comum a relação de troca de conhecimentos e práticas entrevá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 KenSchwaber, Jê Sutherland, e Mike Beedle, tendo como principal característica a capacidade dese concentrar “nos aspectos gerenciais do processo de desenvolvimento de software, semdeterminar como a equipe executa as tarefas de programação”. Tal abordagem propicia aauto-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 parasuportar o desenvolvimento de produtos complexos desde o início dos anos 90”. Acrescentamainda que, o Scrum “não é um processo ou técnica para construir produtos, é mais umframework, 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 parao 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 é essencialpara o sucesso e uso do Scrum”. (idem)
  • 6. 6 Teoricamente o Scrum baseia-se no empirismo, isto é, no conhecimento que advémda experiência concreta e que, para os autores, orientam a tomada de decisão, bem como, seutiliza de uma abordagem iterativa e incremental, visando o aperfeiçoamento daprevisibilidade e o controle dos riscos. Enumera, ainda, três pilares de sustentação para “aimplementaçã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 noespaço de tempo entre 15 e 30 dias, sendo denominadas de Sprints. A dinâmica de Sprints seconfigura da seguinte forma: no início, para estimar e definir a meta do Sprint e das tarefasnecessárias (Backlog), ocorre uma reunião de planejamento, depois da qual a equipe inicia odesenvolvimento 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 ScrumFonte: 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 umpapel fundamental na equipe, isto é, ele é o responsável por ensinar e acompanhar autilizaçã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 ter3 O Product Owner (dono do produto ou cliente) “deve garantir que o produto atenda aos anseios dopatrocinador do projeto, priorizar quais funcionalidades devem ser entregues e quais agregam mais valor aoprojeto. Para exercer tal função, o dono do produto deve possuir a visão do mesmo, sendo responsável peloretorno sobre o investimento do projeto”. (KATAYAMA, 2010, p. 89)
  • 7. 7uma visão geral, acompanhando o desenvolvimento e esclarecendo as dúvidas que porventurapossam surgir, sem, no entanto, alterar o escopo. (KATAYAMA, 2010) Outro aspecto é que, para assegurar que os itens do backolog não mudem após oplanejado, considerando que alterações no ambiente de negócios podem exigir mudanças nosrequisitos, o dono (ou demandante) do produto tem a opção de cancelar o Sprint e realizaroutra 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 umSprint”. Além disso, também provê um mecanismo de adaptação e correção para osrequisitos. (KATAYAMA, 2010, p. 90) O autor afirma que o acompanhamento diário, durante o Sprint, deve-se efetivar pormeio das nomeadas Reuniões em pé (stand-up meetings), isto é, a equipe se reúnerapidamente, de modo a sincronizar o trabalho, quando, então, cada membro descreve o queproduziu entre um encontro e outro, bem como, aponta para o que pretende realizar e enumeraos problemas enfrentados, de forma que toda a equipe descubra, de antemão, seus obstáculosem potencial, ao mesmo tempo em que compartilham conhecimentos. Concluído o Sprint, na reunião de revisão, o trabalho é apresentado ao dono doproduto, 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 seutrabalho, identificando as oportunidades e os principais pontos de melhoria no próximoSprint. (KATAYAMA, 2010)2.3 Sistema Kanban Kanban, literalmente, significa “cartão visual”. O Sistema Kanban é um método deproduçã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 demateriais 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 pelosMé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.
  • 8. 8 Kniberg e Mattias (2009, p.25) definem as práticas do Kanban, resumidamente, eexemplificam, conforme se observa na figura 2: 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 nogerenciamento 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.
  • 9. 9 As diferenças entre Scrum e Kanban, segundo Kniberg e Mattias (2009), podem serresumidas, conforme se apresenta no quadro 1.Quadro 1- Diferenças entre Scrum e Kanban SCRUM KANBAN Iteraçõ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 Compromisso opcional. específica de trabalho para esta iteração. Usa a velocidade como padrão métrico Usa o Lead time como padrão métrico para o planejamento e melhoria de para o planejamento e melhoria de processos. processos. Equipes multifuncionais prescritas. Equipes multifuncionais opcionais. Equipes de Especialistas autorizada. Os itens devem ser divididos para que Nenhum tamanho especial de item é possam ser concluídos dentro de 1 sprint 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 Pode adicionar novos itens sempre que uso houver capacidade disponível O sprint backlog é de uma equipe Quadros Kanban podem ser especifica compartilhados por várias equipes ou individualmente Possui 3 papéis (Product Não discrimina nenhum papel Owner/ScrumMaster/Team) Um quadro Scrum é reiniciado entre cada Um quadro Kanban continua sprint 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áriassituações: o cliente deseja nova funcionalidade, porém, o prazo entre um Sprint e outro nãopermite, posto que, no Scrum, Sprints ocorrem no espaço de tempo entre 15 e 30 dias. Talespera 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 oua mudanças de prioridade do projeto, favorece a combinação de técnicas das duas
  • 10. 10metodologias. Como exemplo, cita-se a observação de Silva et al (2012, s.p), que relatam adificuldade de medir a capacidade de atendimento da equipe e respeitar o que foi acertado noSprint. 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 bastanteadaptativas, sendo possível combiná-los, mesmo considerando que o Scrum é mais prescritivoque 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 doproblema, 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 apresentapara a realização desse estudo.
  • 11. 114 RESULTADOS DA PESQUISA A aplicação de uma metodologia ágil, combinando Scrum e Kanban nogerenciamento de projetos de desenvolvimento de sistemas, favorece o gerenciamento dosprojetos, na medida em que beneficia o aprendizado, ajudando a superar desafios, motivandoas equipe e contribuindo para a satisfação do cliente. Percebe-se que, os resultados apresentados mostram variados processos e técnicas nogerenciamento e desenvolvimentos de produtos, bem como, apresenta o Kanban como ummétodo baseado em controles visuais do fluxo do trabalho, ao mesmo tempo em que sãoapontadas as diferenças e similaridades entre Scrum e Kanban. Consideram-se as possibilidades de combinação entre ambos, como decorrentes dacaracterística flexível do Kanban, como alternativa, quando as prescrições do Scrum não sãopossíveis. Portanto, a dinâmica do uso combinado Scrum e Kanban facilitam as adaptações nocontexto em que as mudanças são constantes. No Scrum, os requisitos são escritos como estórias dos usuários, armazenadas em umrepositório chamado backlog. Estas estórias são selecionadas na reunião de planejamento paraformarem 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 ofuncionamento do Scrum.Figura 3 - Ciclo de desenvolvimento no ScrumFonte: Autoria própria.
  • 12. 124.1 Scrum Backlog Alguns aspectos relacionados ao Scrum Backlog precisam ser considerados, quandoda quebra de itens, em pedaços menores, para se adequar ao Sprint. Kniberg e Mattias (2009, p. 57) disciplinam que, uma equipe Scrum se comprometesomente com “os itens que julguem poder terminar dentro de uma iteração (baseado noconceito de “Done”)”. Quando o item é grande demais para caber em um Sprint, a equipe e o ProductOwner deverão encontrar formas de quebrá-lo até que ele se encaixe. Quando os itens tendema ser grandes, as iterações, consequentemente, tendem, também, a se tornarem maiores (nãomaiores do que 4 semanas). A figura 4 mostra esse contexto.Figura 4 - Itens são quebrados para caberem dentro do SprintFonte: Kniberg e Mattias (2009, p. 57) Numa equipe Kanban, os membros procuram minimizar o tempo de execução ebuscam equilibrar o fluxo, de modo que, criam, indiretamente, um incentivo para quebraritens em partes relativamente menores. Vale ressaltar que, não há regra explícita que indique quais itens devam ser pequenoso suficiente para caber em um determinado período de tempo, podendo ocorrer que, “Em ummesmo quadro nós podemos ter um item que irá levar 1 mês para ser concluído e outro itemque 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. 13 Apesar de Scrum ter como fundamento essencial a quebra de tarefas, para auxiliar noseu comprometimento no Sprint, podem existir tarefas que tem uma duração maior que otempo de um Sprint, e, nesse caso, a equipe pode optar por usar o Kanban, onde não existenenhuma regra que obriga que tarefas caibam em um Sprint, observando os limites de cadaetapa 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 emcadência única, caso a equipe tenha como opção aceitar itens com tamanhos diversos. Nestecaso, 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 serescolhida, sendo recomendado, no entanto, manter a mesma duração por algum período, nosentido de estabelecer uma cadência. A princípio, é criado um plano de iteração, definido pela equipe, onde umdeterminado número de itens do Product Backlog é selecionado, tomando, como base, asprioridades definidas pelo Product Owner, bem como, fundamentado na quantidade de itensque 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 partesinteressadas. “Em seguida, a equipe faz uma retrospectiva para discutir e melhorar seuprocesso” (KNIBERG; MATTIAS, 2009, p. 34). Neste sentido, considera-se que, o “Scrum é uma única cadência de tempo fixo quecombina 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 escolhadas atividades de planejamento, a melhoria do processo e a entrega do produto serem feitasem períodos regulares („release toda segunda‟), ou por demanda („release sempre que se tiveralgo ú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) eorientada para eventos (figura 8).
  • 14. 14Figura 6 - Equipe Scrum utiliza cadência únicaFonte: 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-sereunião de planejamento. A cada quatro semanas, acontece a reunião de retrospectiva paraajustar e buscar melhorias no processo. (KNIBERG; MATTIAS, 2009, p. 36)Figura 7 - Equipe utiliza três cadênciasFonte: Kniberg e Mattias (2009, p. 36). Na figura 8, o autor apresenta cadência mais orientada para eventos, iniciando-secom 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 mesmoproblema por duas vezes. Outra iniciativa é se fazer uma retrospectiva, mais aprofundada, naquarta semana. (KNIBERG; MATTIAS, 2009, p. 37)Figura 8 - Equipe com cadência orientada para eventosFonte: Kniberg e Mattias (2009, p. 36).
  • 15. 154.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 Sprintatual, mas, poderá ser adicionada no Product Backlog e, caso seja prioritário para o ProductOwner, deverá ser adicionada no próximo Sprint. Isso justifica o fato de que, “Sprints dotamanho certo dão ao time tempo focado suficiente para conseguir fazer alguma coisa,enquanto ainda permitem que o Product Owner gerencie e atualize prioridades comperiodicidade regular”. (KNIBERG; MATTIAS, 2009, p. 51) No caso de uma equipe de Kanban, a mudança poderá ocorrer, devendo ser posta aatividade na coluna “não iniciada”, contanto que, obedecidos os limites por coluna (conformeo 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 deresposta) é medido pelo tempo de tomar o item inserido. Tal procedimento baseia-se “noprincípio de „um item fora = um item dentro‟ (controlado pelos limites de trabalho emandamento)”. (KNIBERG; MATTIAS, 2009, p. 52) O tempo de resposta em Scrum é calculado através da média da metade da duraçãodo Sprint. “O Product Owner não pode alterar o quadro Scrum quando a equipe já estivercomprometida 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 bementender”. (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 existiammuitas incertezas e imprevisibilidade. Nesses casos, não há como evitar demandas nãoprogramadas. O motivo pelo qual o fluxo de Scrum não seguia normalmente era a grande
  • 16. 16quantidade 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 noSprint, assim como, no Kanban, utiliza-se o quadro Kanban, ambos com o intuito de controlaro 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 noalgarismo “2”, posto na coluna “andamento” do Kanban, significando que „não pode havermais de 2 itens nesta coluna ao mesmo tempo‟. Na coluna “em execução”, não há, no Scrum, regra que determine quantas atividadespodem ocorrer simultaneamente, no entanto, como a iteração tem um escopo fixo, no exemploacima, fica limitado a quatro. Conclui-se que, o Scrum, indiretamente, limita as atividades em andamento, ao passoque, o Kanban limita diretamente. A prática tem mostrado às equipes Scrum que não é umaboa 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ãoem curso. Caso as equipes limitem as atividades na referida coluna, o quadro Scrum passa a seconfigurar em quadro Kanban, significando que “equipes Scrum podem usar um quadroKanban para gerenciar suas tarefas”. (KNIBERG; MATTIAS, 2009, p. 38)
  • 17. 17 Silva et al (2012) relatam a dificuldade no uso do quadro Scrum, sem limitar aquantidade de tarefas na coluna “verificar”, que acarretava um atraso na liberação de outrasfuncionalidades, comprometendo, assim, o ritmo e a frequência de entregas. Quando a equipepassa a limitar um determinado estado do fluxo, equipes de Scrum passam a usar o quadroKanban.4.4 Equipes multifuncionais Quanto às equipes, estas podem ser multifuncionais, sendo esta uma característica doScrum, ao passo que é opcional, no Kanban. As características de uma equipe multifuncionalrequer que todos os membros tenham as habilidades necessárias para completar todos os itensconstantes 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 mesmosomente poderá ser feita por membros da equipe, haja vista que se trata de uma ferramenta (oquadro) que orienta o gerenciamento do compromisso assumido pela equipe no SprintPlanning, diferentemente do Kanban, em que o quadro de atividades não é “propriedadeexclusiva” de uma única equipe, estando relacionado, não especificamente às atividades deuma 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 deatividades de uma equipe multifuncional do Kanban, da mesma forma como ocorre no Scrum.
  • 18. 18No 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). Umasobreposição de competências é observada, ao mesmo tempo em que poderá haver umdeslocamento de um membro da equipe de desenvolvimento, objetivando agilizar a entrega. Pressupõe-se que, em Kanban é necessário estabelecer regras básicas, determinandoquem e como deve ser usado o quadro de atividades. Essas regras devem ser experimentadasaté que o fluxo seja aperfeiçoado. (KNIBERG; MATTIAS, 2009, p. 56) Compreende-se, portanto, que o papel das equipes, multifuncionais ou não, requercompromisso, para que o fluxo de trabalho aconteça satisfatoriamente, dentro do previsto e doque 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 secomprometem realizar. A segunda (velocidade) é a medida da capacidade (quantidade decoisas) que pode ser entregue por Sprint, calculada “somando o tamanho de cada itemconcluído ao final de cada Sprint”. Os doutrinadores orientam que a equipe deve tomarconhecimento da velocidade, permitindo, dessa forma, fazer previsões de entregas maispróximas da realidade. Em Kanban, fazer estimativa é opcional. “Algumas equipes optam por fazerestimativas e medir a velocidade assim como no Scrum. Outras equipes escolhem pular asestimativas, mas tentam quebrar cada item em itens menores de aproximadamente do mesmotamanho – desta forma eles podem medir a velocidade simplesmente em termos de quantositens 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. Elesnão lhe dizem tudo o que você precisa fazer, eles apenas lhes oferecem algumas restrições eorientações.” (KNIBERG; MATTIAS, 2009, p. 28) Há, portanto, inúmeras formas e técnicas de planejamento de entregas e degerenciamento de compromissos para o modelo Kanban, devendo ser escolhida a que melhorse enquadre ao contexto, não havendo técnica específica ou obrigatória a ser seguida.
  • 19. 19CONSIDERAÇÕES FINAIS Através deste estudo, buscou-se explicitar as contribuições da aplicação de umametodologia ágil, combinando Scrum e Kanban no gerenciamento de projetos dedesenvolvimento de sistemas, visto que, tal medida favorece a melhoria no gerenciamento dosprojetos, ao passo que motiva a equipe, trazendo um maior comprometimento de todos paralograr êxito. Outro aspecto a se considerar, analisado nesta combinação, é que permite ainspeçã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 sendorelevante para o gerenciamento de projetos de sistemas, uma vez que Kanban se apresenta deforma muito flexível e, por isso, é uma alternativa, quando as prescrições do Scrum não sãopossíveis. No decorrer deste artigo, foram apresentados aspectos relacionados à evolução nogerenciamento do projeto, desde quando o desenvolvimento de software baseava-se emmetodologias tradicionais até a utilização de metodologias ágeis para superar problemas nodesenvolvimento de software. Outro ponto abordado refere-se à apresentação do Scrum, definindo-o comoframework, em que é possível utilizar variados processos e técnicas no gerenciamento edesenvolvimentos 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 oacompanhamento do tempo de execução da tarefa. Ao apresentar tais aspectos, são apontadas as diferenças e similaridades entre Scrume 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 acombinação pode ser realizada, identificando as possibilidades de melhoria e sucesso para asequipes, seja de gerenciamento ou de desenvolvimento. Os resultados apontam que, as exigências atuais do mercado de sistemas, cada vezmais complexos, em um curto espaço de tempo, e compatíveis com os requisitos, que sãoalterados constantemente, levaram as empresas a adotarem combinações que possibilitem
  • 20. 20reduzir o tempo de entrega e os custos, em um contexto que não está livre de muitosproblemas. Para que a combinação se apresente apropriada é preciso conhecer o funcionamentodo Scrum e do Kanban, bem como, saber como se deve usar o Scrum com Kanban, admitindoo Scrum Backlog, as iterações em time-box, as mudanças dentro de uma iteração, o quadro deacompanhamento de tarefas, as equipes multifuncionais, a estimativa e a velocidade. A combinação Scrum com Kanban pode ser adotada por equipes, pois ambasapresentam características adaptativas, e são baseados no desenvolvimento iterativo eincremental, possibilitando, dessa forma, trazer mudanças significativas, tais como, adiminuição do número de reclamações, a superação dos pontos de gargalos e a melhoria naqualidade do serviço. Ressalta-se que, ao combinar Scrum e Kanban, a organização não estará isenta detodas as dificuldades, mas, enfrentá-los, passa a ser um desafio, sobretudo de equipes.REFERÊNCIASAGILE 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 nodesenvolvimento de software. 2010. 114 p. Dissertação (Mestrado em Ciência daComputaçã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. 2012LARMAN, Craig. Agile and iterative development: a manager‟s guide. Boston,Massachusetts:Addison-Wesley Professional, 2003.
  • 21. 21NEVES, José Luiz. Pesquisa qualitativa: características, usos e possibilidades. Cadernos dePesquisas 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ívelem:<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. Osbenefícios do uso de Kanban na gerência de projetos de manutenção de software. BeloHorizonte, 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 parao Desenvolvimento de Software. Unipac - Universidade Presidente Antônio CarlosFaculdade 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.