C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE

Diogo Dostoiévsky Robespierre de Sá

ANÁLISE COMPARATIVA ENTRE METODOLOGIAS ÁGEIS KANBAN E SCRUM APLICADA A AMBIENTE DE INOVAÇÃO

TECNOLÓGICA

Recife2013

DIOGO DOSTOIÉVSKY ROBESPIERRE DE SÁ

ANÁLISE COMPARATIVA ENTRE METODOLOGIAS ÁGEIS KANBAN E SCRUM APLICADA A AMBIENTE DE INOVAÇÃO

TECNOLÓGICA

Artigo apresentado ao programa de pós-graduação em Gestão Ágil de Projetos do Centro de Estudos e Sistemas Educacionais do Recife – C.E.S.A.R, como requisito para a obtenção do título de Especialista em Engenharia de Software com ênfase em Gestão Ágil de Projetos. 

Orientação: Prof. Felipe Furtado

Recife2013

ANÁLISE COMPARATIVA ENTRE METODOLOGIAS KANBAN E SCRUM APLICADA A AMBIENTES DE INOVAÇÃO TECNOLÓGICA

Diogo Dostoiévsky Robespierre de Sá

C.E.S.A.R – Centro de Estudos e Sistemas Avançados do Recifediogodrsa@gmail.com

Resumo. O presente trabalho tem como objetivo efetuar uma análise comparativa entre as metodologias Kanban e Scrum aplicadas a ambientes de inovação tecnológica, especificamente em modelo de empresa startup de tecnologia. Esse modelo de empresa acaba por sofrer com recurso financeiro e humano limitado, geralmente se acumula mais de um papel na execução do projeto e onde mesmo sendo bons técnicos, nem todos possuem um perfil de gerenciamento e precisam até certo ponto exercer esse papel de forma autogerenciável para otimizar a construção do produto ou serviço.

Palavras chaves: Kanban; Scrum; Inovação Tecnológica; Startup.

1. Introdução

As técnicas de trabalho vêm evoluindo e se moldando constantemente de acordo com novos

paradigmas. Com a migração do processo de produção industrial para a economia baseada em

conhecimento foram surgindo novos modelos de negócio e a necessidade de colaboração e

adaptação cada vez mais rápida aos contextos propostos de inovação. Esta transformação

favoreceu o conhecimento como fator decisivo no competitivo ambiente corporativo, onde o

conhecimento deve ser adaptado para criação de produtos e serviços que ao quebrarem

paradigmas e gerarem dinheiro tornam-se inovações, apresentando um diferencial no

mercado. (ARMAND, 2002).

O processo de inovação não está diretamente atrelado a nenhuma metodologia, assim

como a própria etimologia da palavra faz referência a mudança, novo ou recente, ou seja, não

determina que siga diretrizes previamente estabelecidas (DOMINIQUE; DE LA MOTHE,

2001), mas uma metodologia ou combinação de duas ou mais permitem que uma ideia

inovadora, possa tomar forma ou se tornar concreta com maior agilidade e maior agregação

de valor ao negócio do cliente devido a uma melhor gestão ou controle do que é feito, através

de experiências constatadas em projetos anteriores, nas quais determinadas metodologias ou

3

práticas ágeis, disponível em: <http://www.versionone.com/pdf/7th-Annual-State-of-Agile-

Development-Survey.pd>, foram utilizadas e se obteve mais casos de sucesso em diversas

empresas.

Na figura abaixo é apresentado um indicador de casos de sucesso e falhas na adoção

de metodologias ágeis e de modelo cascata ou modelo tradicional de gestão do

desenvolvimento de software no ano de 2012.

Figura

Figura 01 : Representação da porcentagem de suceso, falhas e mudanças em projetos ágeis e cascata.

Fonte: http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall

O modelo de negócio ou empreendedorismo denominado startup, definido por Eric

Ries (2012) como, “uma startup é uma instituição humana projetada para criar novos

produtos e serviços sobre condições de extrema incerteza”, em outras palavras uma startup

representa bem o empreendedorismo na era do conhecimento, onde este conhecimento é

aplicado na quebra de paradigmas ou mudança cultural através do surgimento de um produto

ou serviço que tenha impacto relevante na vida das pessoas e que essas se tornem clientes da

empresa fornecedora desse produto ou serviço.

Segundo Eric Ries (2012), em épocas anteriores era divulgado que um bom plano,

associado a uma estratégia sólida e uma pesquisa de mercado era sinônimo de sucesso, a

aplicação dessa teoria ao modelo de empresa startup não funcionou, pois startups trabalham

em ambientes de muita incerteza. As startups não sabem ao certo quem são seus clientes ou

4

qual será o estado final comercial de seu produto ou serviço. A medida que o mundo fica

mais incerto, fica mais difícil prever o futuro. Planejamento e previsão são melhores

aproveitados ou aplicados quando há um histórico operacional longo e estável, em um

ambiente relativamente estático, o que de fato não é a natureza de uma startup. Alguns

indivíduos que falharam com formato de gerenciamento antigo, começam a achar que a falta

de gerenciamento é a resposta, porém a medida que o projeto cresce tende a ficar caótico,

enquanto as metodologias ágeis podem ser de melhor aplicação nesse contexto de incerteza,

devido a sua natureza de maior facilidade em adaptação e iteração (SHORE; WARDEN,

2007), auxiliando no sucesso do projeto.

1.1 Objetivos

Nesta seção será apresentado os objetivos específicos e gerais do presente trabalho.

1.1.1 Objetivo Geral

Análise dos conceitos das metodologias Kanban e Scrum, visando efetuar um comparativo

das duas metodologias, tendo como embasamento princípios e práticas aplicadas ao contexto

de startups de inovação tecnológica na área de software.

1.1.2 Objetivo Específico

Apresentar principais conceitos sobre Kanban e Scrum;

Analisar e apresentar como as metodologias e filosofias em questão podem ajudar no

desenvolvimento de uma empresa startup de tecnologia;

Contribuir com a orientação de empreendedores de empresas startup que pretendem

abordar a filosofia ágil de gestão de projetos com Kanban e Scrum.

1.2 Justificativa

5

David Skok empreendedor da Matrix Partners em seu artigo denominado: “Por que as

startups falham?” disponível em http://www.forentrepreneurs.com/business-models/why-

startups-fail/, classifica os motivos de uma startup falhar da seguinte forma:

1. Problemas com o marketing;

2. Modelo de negócio falho;

3. Time de gerencimento fraco;

4. Inabilidade em lidar com dinheiro;

5. Produto com problemas;

Em paralelo ao contexto desafiador da administração do negócio de empreendimentos

startup, existe o contexto de gerenciamento do desenvolvimento de software que é tão

desafiador quanto. Segundo a organização IEEE, organização que estabelece padrões para

formatos de computadores e dispositivos, os problemas mais comuns no desenvolvimento de

software, são:

1. Objetivos de projetos não realistas;

2. Estimativas imprecisas de recursos necessários;3. Requisitos de sistema mal definidos;

4. Relatórios fracos do status do projeto;

5. Riscos não gerenciados

6. Comunicação falha entre clientes, desenvolvedores e usuários;

7. Uso de tecnologias não maduras;

8. Inabilidade em lidar com a complexidade do projeto;

9. Práticas de desenvolvimentos pouco eficientes;

10. Gerente de projetos fraco;

11. Políticas das partes interessadas;

12. Pressões comerciais.

<disponível em http://spectrum.ieee.org/computing/software/why-software-fails>

Diante de um contexto complexo de negócio e gerenciamento do

desenvolvimento de software, uma empresa startup e sua equipe para sobreviver no

mercado, deve buscar ser flexível, multitarefa, persistente, criativa, comunicativa,

6

objetiva, proativa e bem gerenciada, (JESSICA, 2007), entregando um produto ou

serviço de qualidade, dentro dos prazos estimados e sempre com o menor custo possível

(AMARAL, 2004).

Um bom modelo de negócio pode ajudar no sucesso de um empreendimento

(PIGNEUR; RAPHAEL; BONELLI, 2013), mas antes de existir a negociação de um

produto ou serviço, existe a construção dos mesmos em uma realidade onde os recursos

humanos e financeiros são reduzidos no início da operação e pode haver necessidade de

acúmulo de papéis, sendo assim, uma gestão otimizada da construção do software se torna

uma peça importante no sucesso do empreendimento.

O relatório CHAOS MANIFESTO do ano de 2013, contém indicadores gerados a

partir de uma base de dados de projetos que são armazenados desde 1985 pelo The Standish

Group. A figura abaixo mostra o índice de falhas, sucesso e mudanças nos projetos de 2004

até 2012.

Figura 02: Representação da evolução dos casos de sucesso,

falhas e mudanças do ano de 2004 até 2012.

Fonte: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf

A partir do relatório do CHAOS Manifesto, é possível visualizar que a taxa de sucesso

dos projetos vem crescendo, enquanto a taxa de mudanças vem caindo e a taxa de falha se

encontra relativamente estável. Essa melhora no índice de sucesso dos projetos, pode ser

explicada através do relatório Annual State Of Agile Development Survey, onde indicadores

mostram que uma gestão otimizada pode ser conseguida através da adoção de metodologias

ágeis em substituição ou adaptação ao PMBOK (VERSIONONE, 2011).

Na figura abaixo é possível visualizar a listagem das melhorias que as metodologias

ágeis proporcionaram à gestão do projeto, salientando que para 79% dos participantes da

7

pesquisa foi alcançado um melhor alinhamento entre TI e os objetivos de negócio, ou seja, a

melhor gestão da construção do produto ou serviço favoreceu a melhoria ou manutenção do

negócio.

Figura 03: Representação das melhorias conseguidas

Com a implantação das metodologias ágeis.

Fonte: <http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf>

Na figura abaixo é demonstrado quais as metodologias foram mais utilizadas pelos

participantes da pesquisa, sendo as mais utilizadas a metodologia Scrum, Kanban e suas

derivadas.

8

Figura 04: Ranking das metodologias ágeis mais utilizadas.

Fonte: <http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf>

1.3 Estrutura do Artigo

O arquivo está estruturado em 4 partes, com a 1ª seção abordando a introdução do trabalho,

falando sobre a temática abordada, justificativa para adoção das metodologias ágeis em vez

do PMBOK em empresas Startup de tecnologia e objetivos gerais e específicos do presente

trabalho. A 2ª seção aborda o modelo tradicional de gestão (PMBOK), RUP, conceito de

metodologia ágil e as metodologias SCRUM e Kanban. A 3ª seção é realizado um

comparativo entre as metodologias SCRUM e Kanban aplicados ao ambiente de empresas

9

Startup. A 4ª seção se encontra as conclusões sobre o comparativo do presente

trabalho.

2. Revisão do Estado da Arte

Nesta seção é apresentado o embasamento teórico do modelo tradicional de gerenciamento de

desenvolvimento de software, abordando o PMBOK e o RUP, em seguida é apresentado o

conceito de metodologia ágil e as metodologias ágeis SCRUM e Kanban.

2.1 Modelo Tradicional de Gerenciamento do Desenvolvimento de Software

O gerenciamento de projeto é considerado como um processo de planejamento, organização,

monitoramento, controle e encerramento, além disso, para ter sucesso é necessário que o

gerenciamento tenha foco nas pessoas, produto, processo e projeto. O gerente que esquecer

que engenharia de software lida com humanos, irá falhar. (PRESSMAN, 2009)

Uma falha significa custo, uma das maneiras de se procurar evitar a falha é efetuar um

bom planejamento e documentação antes de se iniciar o desenvolvimento de software. Sendo

esse um dos motivos para a existência de extensas documentações detalhadas, planejamento

extenso e etapas bem delimitadas (PRESSMAN, 2009).

O modelo de gerenciamento tradicional se caracteriza pela grande documentação

necessária antes de iniciar a produção, um modelo mais vertical de hierarquia para tomadas

de decisão e controle do projeto bem centralizado. Esse modelo de gerenciamento em relação

ao projeto ágil, se sobressai quando, os projetos são muito grandes e podem contar com um

bom histórico, devido a documentação.

2.1.1 PMBOK (Project Management Body of Knowledge)

Na cidade de Montreal, Canadá, em 1976 surgiu a ideia de que práticas de gerenciamento de

projetos deveriam ser documentadas com fim de aumentar a excelência na prática do

gerenciamento de projetos. Após a diretoria do PMI (Project Management Institute) provar o

projeto de documentação e ser feito um trabalho ao longo de 11 anos, surgiu o versão do

PMBOK (Project Management Body of Knowledge) em 1987, dividindo as áreas de

10

conhecimento em: gerenciamento do escopo, tempo, custos, qualidade, recursos humanos e

comunicação. O PMBOK se tornou um guia para a área de gerenciamento de projetos, um

conjunto de boas práticas, descrevendo normas, métodos, processos e práticas estabelecidas.

A quarta edição trouxe nove disciplinas: gerenciamento de integração, escopo, tempo, custos,

qualidade, recursos humanos, comunicação, riscos e aquisições.

Analisando o PMBOK versão 4 como um conjunto de boas práticas, chama atenção

para as características individuais de cada projeto. Uma boa prática é um consenso da

aplicação correta de certas habilidades, ferramentas e técnicas, resultando em uma maior

chance de sucesso do projeto, não significando que aplicando a boa prática seja determinante

para o sucesso do projeto, a organização ou equipe de gerenciamento do projeto é quem são

responsáveis por analisar o contexto e definir quais práticas podem ter melhor resultado

quando aplicadas (PROJECT MANAGEMENT INSTITUTE, 2008).

O PMBOK tem como núcleo a boa gestão de um ou mais projetos, definindo um

projeto, como o esforço temporário empreendido para criar um produto, serviço ou resultado

exclusivo, embora cada projeto tenha suas peculiaridades o que o torna exclusivo, alguns

elementos durante o desenvolvimento do projeto tendem a ser repetitivos. A característica

temporária do projeto, não necessariamente define um projeto sendo de curto prazo de

duração, mas como definição de um período de início e fim, ressaltando também a

característica da natureza exclusiva de um projeto, causando incerteza quanto aos produtos,

serviços e resultados e sendo o projeto com atribuições de tarefas novas para a equipe, a

exigência de um maior cuidado no planejamento, podendo envolver mais de um indivíduo ou

instituições (PROJECT MANAGEMENT INSTITUTE, 2008).

O processo de gerenciamento é realizado através da aplicação e integração de 47

processos na 5ª versão do PMBOK (PROJECT MANAGEMENT INSTITUTE, 2013),

agrupados em 5 grupos que são apresentados na figura abaixo:

11

Figura 5 : Visão Dinâmica dos 5 grupos do PMBOK.Fonte: < http://blog.mundopm.com.br/2013/03/14/47-processos-do-pmbok-5/>

2.1.2 RUP

O Rational Unified Process é um processo de engenharia de software que utiliza uma

abordagem orientada a objetos e notação UML. Foi elaborado pela Rational Software

Corporation, empresa que posteriormente foi comprada pela IBM, a qual renomeou o

processo para IBM Rational Unified Process (IRUP), Kruchten (1999), porém o termo mais

divulgado ao se falar sobre este processo, faz referência a abreviação da primeira

nomeclatura, RUP.

O RUP é conhecido como modelo tradicional de desenvolvimento, para Larman

(2007), o perfeito exemplo de uma sequência linear da estratégia mais comum para uma falha

total do RUP é seguir o modelo cascata, da seguinte forma:

1. Tentar definir e manter a maioria dos requerimentos.

2. Fazer um design detalhado baseado nos requerimentos.

3. Implementar com base no design;

4. Integração, teste de sistema e deployment.

12

O Krutchen (1999) caracteriza o RUP como tendo um alto nível de customização e

devido a grande abordagem do framework RUP, essa customização se torna complexa, sendo

recomendada apenas para grandes equipes e projetos. O RUP tem uma função de suporte ao

gerenciamento de projetos e preconiza a produção de software de alta qualidade, atendendo as

necessidades dos usuários finais, prazo e orçamento. Shuja (2007), por sua vez afirma que

para isso o RUP apoiou-se nas melhores práticas, criadas, analisadas e aplicadas na indústria

de software.

Práti cas adotadas pelo RUP:

1. Desenvolvimento de software iterativo (melhor adequação a mudanças).

2. Gerenciamento de requisitos (identificar e especificar as necessidades do usuário

final).

3. Uso de arquitetura baseada em componente (visando reuso de componentes).

4. Modelagem visual de software (abstração do modelo de negócio, por meio de

UML).

5. Verificação da qualidade do software (planejamento, projeto e execução de

testes).

6. Controle de alteração no software (controle, rastreamento e monitoração de

mudanças).

Segundo Cottrell (2004) o relacionamento do RUP com o PMBOK se dá da seguinte

forma:

1. O PMBOK descreve diretrizes de melhores práticas na indústria, enquanto o RUP

influencia o time de desenvolvimento de software a utilizar as melhores práticas da

indústria.

2. O PMBOK descreve um clico de vida genérico, enquanto o RUP descreve um clico de

vida genérico para o desenvolvimento de software, dentro de um ciclo de vida de projeto.

3. O PMBOK descreve diretrizes para qualquer tamanho de projeto, enquanto o RUP

pode ser adaptado para qualquer tamanho de projeto.

Na versão 7.0 do RUP as melhores práticas, obtiveram um foco maior no negócio,

tornando o RUP um framework mais genérico e capaz de suportar o desenvolvimento ágil.

13

1. Adaptar o processo (identificar quanto processo é necessário ao projeto);

2. Balancear as prioridades dos investidores (compreender e priorizar os requisitos

conforme as necessidades de negócios);

3. Colaborar através de equipes (comunicação e ambientes de colaboração);

4. Demonstrar valor iterativamente ( feedback inicial e contínuo, adaptar os planos,

gerenciar alterações);

5. Elevar o nível de abstração (reduzir a complexidade e a quantidade de documentação

por meio de reutilização de recursos existentes);

6. Focalizar continuamente na qualidade (testes, integração contínua, automação de

testes incremental).

2.2 Modelo Ágil de Desenvolvimento de Software

Um método ou processo é uma forma de trabalhar, alguns são bem prescritivos outros são ad

hoc e informais. Métodos ágeis são processos que seguem a filosofia ágil de

desenvolvimento, consistido de elementos chamados práticas, uma parte das práticas adotadas

nas metodologias ágeis já existiam a algum tempo, mas foram adicionadas características da

filosofia ágil, descartando o excesso e misturando com novas ideias, resultando em algo

simples e poderoso. Um conjunto de práticas pré-estabelecidas e seguidas determina uma

metodologia que pode já ter sido catalogada na literatura ou não (SHORE; WARDEN, 2008).

Motivados pela observação de que alguns times de desenvolvimento de software em

diversas empresas estavam ficando sufocados em processos que não paravam de crescer, uma

equipe de especialistas da indústria de software autodenominados Agile Alliance,

estabeleceram em um encontro no ano de 2001 os valores e princípios que poderiam permitir

as equipes desenvolverem e a responderem as mudanças de forma rápida. (MARTIN, 2006).

Esse manifesto está exposto abaixo:

14

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas,Software em funcionamento mais que documentação abrangente,Colaboração com o cliente mais que negociação de contratos,Responder a mudanças mais que seguir um plano,Ou seja, mesmo havendo valor nos itens à direita,valorizamos mais os itens à esquerda.(Disponível em: <http://agilemanifesto.org/iso/ptbr/>).

Ser ágil ou trabalhar com metodologia ágil é mais complexo do que seguir um

processo. Desenvolvimento ágil é uma filosofia, uma maneira de pensar sobre gerenciamento

e desenvolvimento.

O manifesto ágil é seguido por 12 princípios, relacionados a seguir:

Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua

de software de valor.

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis

se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

Entregar software funcionando com freqüencia, na escala de semanas até meses, com

preferência aos períodos mais curtos.

Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e

diáriamente, durante todo o curso do projeto.

Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e

suporte necessário, e confiar que farão seu trabalho.

O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um

time de desenvolvimento, é através de uma conversa cara a cara.

Software funcional é a medida primária de progresso.

Processos ágeis promovem um ambiente sustentável. Os patrocinadores,

desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos

constantes.

15

Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e

otimizam seu comportamento de acordo.

2.2.1 Scrum

O Scrum é um framework para gerenciamento e desenvolvimento de software, podendo

também ser adaptado para outros tipos de projetos. Todas as práticas do Scrum tem como

base um processo iterativo e incremental Schwaber (2004). Essas práticas são executadas por

um time de Scrum que possui como característica ser multidisciplinar, composto pela figuras

do product owner, time de desenvolvedores e do ScrumMaster.

O product owner possui a responsabilidade de transferir ou traduzir as

necessidades de negócio e priorizar as atividades a fim de garantir o retorno do investimento,

esse papel pode ser feito tanto por uma pessoa da equipe, quanto pelo cliente. O ScrumMaster

tem o papel de líder-servidor, uma pessoa que procura resolver os impedimentos e que o

Scrum seja executado corretamente. O time de desenvolvedores é constituído por pessoas

com habilidades diversas alinhadas com a necessidade do projeto.

O processo Scrum tem início com a visão do que deve ser desenvolvido, o

ProductOwner produz o Product Backlog, posteriormente, essa lista de

requerimentos(Product Backlog) é colocada em ação em Sprints. Uma Sprint tem duração de

1 à 4 semanas e cada Sprint é iniciada com um Sprint Planning Meeting, no qual o time e o

Product Owner definem quais serão os itens desenvolvidos no próximo Sprint, essa reunião

não pode durar mais do que 8 horas. Cada reunião de Sprint é dividida em duas partes de 4

horas cada, a primeira parte o Product Owner demostra a lista de requisitos para a equipe,

onde o time pode questionar sobre a lista do Product Backlog e seleciona quais os itens ou

requisitos que possuem o maior potencial de entrega com sucesso ao final do Sprint. A

segunda parte da reunião de Sprint é quando de fato o Sprint foi iniciado, por ter como

princípio uma equipe autogerenciável, o time de desenvolvimento faz o planejamento da

Sprint e o resultado desse planejamento é uma lista de atividades denominada Sprint Backlog.

16

Durante o Sprint, todos os dias durante 15 minutos a equipe se reune, em uma reunião

chamada Daily Scrum, no qual existem 3 perguntas que todos devem realizar e responder: “O

que você fez? O que você pretende fazer? Quais os impedimentos?”. A proposta dessa

reunião é sincronizar o time para que o projeto siga ao caminho do sucesso. No final da

Sprint acontece a Sprint Review, uma reunião de 4 horas na qual a equipe apresenta o que foi

produzido ao Product Owner e a outras pessoas participantes do projeto, seguidamente o

ScrumMaster realiza a reunião de Sprint Retrospective, uma reunião de retrospectiva da

Sprint com duração de 3 horas, onde o time revisa o processo da metodologia e suas práticas,

com fim de tornar a equipe mais eficiente no próximo Sprint. (SCHWABER, 2004).

Figura 6: Representação do ciclo do framework Scrum.Fonte: <http://www.temperies.com.ar/imgs/scrumLifecycle.gif>

Como forma de registrar as tarefas de forma visual, no Scrum é utilizado um quadro

como sinalizador de status das tarefas.

17

Figura 7: Representação de um quadro Scrum.Fonte: <http://imasters.com.br/wp-content/uploads/2013/01/scrumBoard1.jpg>

2.2.2 Kanban

No Japão, período pós-guerra mundial, a Toyota que é uma empresa da área de

indústria automotiva, desenvolveu o Sistema Toyota de Produção (TPS) ou Lean

Manufacturing, procurando aumentar a eficiência da linha de produção, eliminando os

desperdícios.Uma das ferramentas que surgiram do Sistema Toyota de Produção se chama

Kanban (ANDERSON, 2010).

.O Kanban é uma ferramenta que no seu formato tradicional serve para controle de

produção através de cartões sinalizadores, o kanban traduzido da língua japonesa como

quadro visual ou cartão visual, comumente chamado de kanban de produção. No

desenvolvimento de software o Kanban tem o mesmo propósito do kanban de produção,

limitar o trabalho em progresso, aprimorar a produção e mostrar a evolução de forma visual,

sendo os cartões sinalizadores de itens a serem trabalhados com base em práticas Lean

(ANDERSON, 2010).

18

A adaptação do Kanban da indústria de manufatura para a indústria de software é

atribuído a David Anderson (ANDERSON, 2010), que no ano de 2002 notou que a área,

equipe ou setor de TI estava à mercê de outros departamentos, a fim de minimizar essa

dependência elabora duas perguntas buscando através das respostas, a solução dessa

dependência. As perguntas foram:

Como proteger minha equipe da demanda incessante de negócio e alcançar o

que a comunidade ágil chama de ritmo sustentável?

Como adotar uma abordagem ágil em toda empresa e superar inevitáveis

resistências a mudanças?

Para descobrir a resposta para suas perguntas, David Anderson, testou, errou e falhou

diversas vezes em diversas organizações, até que em 2007 conseguiu ter sucesso na empresa

Corbis. Ele notou que implantar uma metodologia de desenvolvimento com alto grau de

prescrição, na maioria das vezes não funcionava e que era necessária certas adaptações de

acordo com as necessidades e realidades de diferentes projetos. A partir dessa premissa, foi

adaptado o Kanban para o desenvolvimento de software (ANDERSON, 2010).

Existem 5 pontos essências do método Kanban:

1. Visualizar o fluxo de trabalho;

2. Limitar a quantidade de trabalho em andamento;

3. Medir e otimizar o fluxo de trabalho;

4. Tornar explícitas as políticas do processo;

5. Gerenciar quantitativamente.

O Kanban propõe que todo o trabalho esteja visível para toda equipe, através de um

quadro onde é possível indicar quais os trabalhos estão sendo executados, os trabalhos que

estão aguardando inicialização, os trabalhos finalizados, validando se esses trabalhos estão

respeitando o limite informado de trabalho em progresso para cada fase e o gerenciamento do

lead-time, que é o tempo que a atividade leva do início da execução até sua finalização. David

Anderson afirma que aparentemente isso não impacta o desempenho, cultura, capacidade e

maturidade de uma equipe ou organização, mas acaba afetando através de pequenas melhorias

no decorrer do processo, o que é chamado de cultura Kaizen, mesmo o Kanban não tendo um

processo muito prescritivo e nem descrever papéis, o Kanban acaba permitindo um processo

mais transparente, exposição de gargalos, filas, variabilidade e desperdícios. (ANDERSON,

2010).

19

No Kanban existe uma peculiaridade em relação à metodologia tradicional de

desenvolvimento, na qual através do conceito de tarefa puxada, os integrantes não ficam

esperando a demanda chegar, ao invés disso, os requisitos são adicionados a lista de backlog e

puxados pelos integrantes da equipe a medida que as atividades são liberadas para próximas

fases do processo , sendo assim os integrantes se tornam livres para iniciar uma nova tarefa,

que pode ser priorizada ou não. Outra característica é que no Kanban não existe uma

prescrição para estimativa, o gerente que resolver aplicar o Kanban, pode escolher qual

estimativa seria a ideal (ANDERSON, 2010).

. O quadro de atividades é um elemento muito importante no Kanban, porém o

David Anderson alerta que apenas um quadro com tarefas, não exatamente é um quadro

Kanban, se o Kanban não for aplicado corretamente, é apenas um quadro com tarefas. Não

existe uma especificação formal de onde e como deve ser um quadro Kanban, sendo

importante que o painel seja visível por todos, agindo como um elemento sinalizador,

podendo ser em uma porta, janela, parede, quadro, etc. Exemplo de um quadro Kanban

simples, esse quadro não é um modelo fixo, podendo ter linhas e colunas alterados de acordo

com a necessidade (ANDERSON, 2010).

.

Figura 8: Representação de um quadro Kanban.Fonte: <http://blog.crisp.se/henrikkniberg/images/KanbanVsScrumCoverPic.jpg>

20

Na exemplificação do quadro, os bonecos são os integrantes da equipe atuando em

determinada tarefa, os cartões retangulares são as próprias tarefas e os números no topo das

colunas são os WIP (Work In Progress) que indica a capacidade de produção.

3. O processo de inovação e a aplicação do Scrum e Kanban à empresas Startup.

O Standish Group passou muitos anos na avaliação de centros de desenvolvimento de

inovação em software em todo o mundo. Suas pesquisas demonstraram que um centro de

desenvolvimento otimizado, deveria ter em torno de 25 pessoa, no mínimo, e não mais que 75

pessoas, salientando que isso é apenas uma diretriz e não uma regra, além do estabelecimento

de 4 dogmas que deveriam ser seguidos por um centro de inovação em software.

(VERSIONONE, 2011)

Níveis : trata-se de um filtro de projetos de 4 fases, onde projetos que forem eleitos

para seguir no processo de desenvolvimento, descem pelo funil de inovação e os que

não forem, permanecem no nível que se encontram;

Orçamento Breadbasket: Um fundo monetário para uso comum com o propósito de

viabilizar oportunidades de negócio, descobertas ou especificações sem ter que

comprometer um ou mais projetos;

Otimização: Priorização de projetos e requisitos de forma rápida e fácil;

Processo ágil: O processo ágil tem como base o desenvolvimento iterativo, onde

requisitos e desenvolvimento de soluções por times autogerenciados e

multifuncionais, favorecendo uma entrega rápida.

Um centro de inovação pode ser compreendido como uma empresa estabelecida com

foco em inovação, tanto como um ambiente ou ecossistema que propiciam a iniciação de

negócios inovadores. Um dos desafios enfrentados por uma empresa de inovação é que a

quantidade ideal relatada pelo Standish Group não reflete a realidade das empresas Startup,

segundo levantamento realizado em 2011 pela empresa Focus.com, empresa americana com

foco em redes sociais. (THENEXTWEB, 2011).

A partir desse levantamento foi possível demonstrar que o tamanho médio de uma

empresa startup é de 2 pessoas, apenas 20% das Startups analisadas tinham mais de 2 pessoas

na equipe, mais de 85% mantém a empresa através de economias e serviços de consultoria,

outras buscam investimentos de membros da família ou investidores anjos, 45% das startups

21

irão fechar as portas antes de 6 meses e os problemas mais comuns que estão enfrentando de

um total de 100%, são: 50% estão com problemas no desenvolvimento, 30% estão

estrangulados com o prazo e 20% com problemas em marketing e vendas. (FALCONER,

2013).

Os indicadores da pesquisa realizada pela Focus.com, mostram que exceto o problema

de capital e recursos humanos reduzidos, as dificuldades que merecem atenção são os

problemas de desenvolvimeto que atinge metade das empresas pesquisadas e a questão de

prazos comprometidos, dois itens diretamente ligados à gestão de projetos e primordial para a

geração de capital para a empresa. Uma empresa que não possui produto ou serviço para

negociar e sem dinheiro para manter o desenvolvimento ou melhoria dos mesmos, terá como

consequencia à falência.

O fato do Standish Group indicar a gestão ágil como um dos dogmas de sucesso para

empresas de inovação, é reforçado por uma pesquisa realizada pela Version One, onde é

indicado que a maioria das instituições que foram pesquisadas, afirmaram ter conseguindo

melhorias ou maior grau de sucesso nos seus projetos. Um indicador que merece destaque

quando se fala em um contexto de empresa startup é o índice de 70% das empresas afirmando

que a adoção das metodologias ágeis resultaram em uma conclusão mais rápida do projeto.

Como já citado, a conclusão rápida e com qualidade de um projeto em uma empresa

startup é um fator de relevância para a sobrevivência do negócio, já que a partir disso poderá

ser gerado capital para a empresa. As metodologias ágeis viabilizam isso promovendo certas

propriedades, como:

O escopo é definido em formato de mais alto nível, com requisitos priozidados e definidos de forma.

Cronograma orientado a entregas em curto prazo, variando geralmente de 2 a 4 semanas.

Rapidez na incorporação de alterações, permitindo um melhor controle.

Programação em pares, testes incrementais e refatoração.

Análise de risco constante. Comunicação colaborativa.

Confiança nos membros da equipe, como um time colaborativo.

Maior iteração entre os stakeholders para alinhamento constante do que se deseja e do que está ou será construído.

Plano de projeto evolutivo e gerente do projeto com um papel de facilitador.

22

Essas propriedades que estão alinhadas com o manifesto ágil, possuem peculiaridades

de implantação dependendo de qual metodologia ágil o gerente ou equipe escolher como

modelo para gestão do projeto. A empresa Version One, destacou as metodologias ágeis

Kanban, Scrum e suas derivadas, como as metodologias de maior adesão entre as empresas

pesquisadas.

O Scrum e Kanban possuem certas similaridades, como a utilização de pull

schedulling, utilização de WIP, uso de transparência para melhoria do processo, foco em

entrega software de forma rápida e frequente, ambas possuem equipes autoorganizadas, o

trabalho é dividido em partes e possuem melhorias contínuas de velocidade na entrega de

artefatos, porém obviamente existem práticas divergentes das duas metodologias que são

caracterizadas basicamente pelo nível de prescrição que são aplicadas.

O nível de prescrição se mostra importante de acordo com o perfil de cada equipe,

quanto maior o nível de prescrição, mais disciplina é necessária. Em uma empresa startup um

integrante ou mais pode não ter um perfil tão disciplinado ou a realidade da empresa dificulta

a adoção de uma metodologia mais prescritiva, como no caso de integrantes que possuem

trabalhos paralelos ao foco da empresa startup, podendo ocasionar impacto negativo caso

escolha adotar o Scrum como metodologia, pois o mesmo não sendo executado conforme

prescreve o framework, deixa de ser Scrum, sendo preferível a adoção do Kanban nestes

casos por ser menos prescritivo. Nas próximas linhas do presente trabalho é apresentada

algumas diferenças do Scrum e o Kanban, citando ocasiões em que determinada prática se

encaixa de melhor forma na realidade de uma equipe inserida em um contexto comum de

empresa startup, pouco recurso financeiro e humano.

Timebox

O Scrum estabelece iterações com timebox prescritas, ou seja, existe um tempo

preestabelecido para a execução de cada atividade planejada, o Kanban por outro lado já

permite a utilização ou não de timebox. A opção de não utilização de timebox facilita o

andamento do projeto, quando a equipe do projeto é demasiadamente pequena, ocasionando

um acúmulo maior de papéis, em contrapartida um timebox permite saber o quê é possível

entregar e quando.

Velocidade

23

O Scrum estabelece a velocidade como referência de métrica para melhoria do processo,

medido através do tempo gasto para a conclusão do Sprint, em contrapartida o Kanban

estabelece o Lead Time, o tempo gasto desde o início da execução atividade até a sua

finalização.

Equipe e papéis

No Scrum a equipe deve ser essencialmente multifuncionai, contendo integrantes que

exerçam 3 diferentes papéis. Um integrante como Product Owner, outro como ScrumMaster e

o time de desenvolvimento. Em um contexto que se enquadra a maioria das startups, a

aplicação dessa diretriz proposta pelo Scrum se torna complicada, devido aos recursos

humanos serem reduzidos, por outro lado o Kanban permite a opção da equipe ser

multidisciplinar ou não, além de não prescrever papéis, permitindo uma maior flexibilidade

de atuação dos integrantes da equipe de uma empresa startup de acordo com a necessidade e

aptidão de cada um.

Tamanho de item

No Scrum os itens podem ser divididos para que possam estar completos dentro de uma

sprint, enquanto no Kanban nenhum tamanho de item é prescrito.

Indicador de progresso

O Scrum prescreve o gráfico de burndown como indicador de progresso, no caso do Kanban

nenhum diagrama em particular é indicado, geralmente é utilizado a quantidade de cartões ou

postits na parte de finalizado e nas fases anteriores a de finalização para verificar qual o

andamento das atividades.

WIP

O Scrum estabelece um WIP indireto através da definição do Sprint e nenhuma alteração

poderar ser feita em um Sprint em andamento, no caso do Kanban o WIP é limitado pelo

estado do fluxo de trabalho e pode haver itens novos quando houver capacidade.

Estimativa

O Scrum prescreve a estimativa, no Kanban a estimativa é opcional. O problema de não haver

uma estimativa é que as atividades podém demorar a serem executadas e finalizadas, pois a

24

equipe pode acabar não se comprometendo com um prazo para finalização, esse problema

depende do nível de maturidade e comprometimento da equipe.

Divisão de responsabilidades

No Scrum um Sprint Backlog pertence a um time específico, no Kanban um kanban board

pode ser compartilhado por múltiplos times ou pessoas. No Kanban a responsabilidade é

compartilhada, podendo integrantes assumirem a responsabilidades de executar determinada

tarefa a partir do momento que o mesmo tem disponibilidade para isso.

Board ou painel

Um Scrum board é reiniciado em toda Sprint ao contrário do Kanban, onde o painel

permanece o mesmo.

Priorização

O Scrum prescreve a priorização em um product backlog, no caso do Kanban essa priorização

é opcional. A priorização é uma atividade interessante quando é alinhado com o cliente quais

os itens são de maior agregação de valor ao negócio se forem entregues mais rapidamente ou

quais funcionalidades seriam interessanes disponibilizar mais rapidamente para os

consumidores. No caso do lançamento do produto após finalização por completo, a equipe

pode usar outros critérios para prioziar como por exemplo, facilidade de implementação ou

até mesmo não escolher priorizar, executando as atividades que desejarem executar.

4. Conclusões

Este trabalho analisou conceitos básicos de gestão tradicional de projetos e gestão ágil

de projetos, efetuando uma comparação entre as metodologias ágeis Scrum e Kanban. Graças

ao estudo foi possível avaliar o motivo que faz as metodologias ágeis estarem mais alinhadas

com o cerne das empresas startup do que a gestão tradicional, devido ao nível e facilidade de

adaptação exigida nos projetos desafiadores e inovadores que se propõe uma empresa startup,

em um contexto menos prescritivo ou mais dinâmico de desenvolvimeto de sistemas a

ferrameta kanban se torna interessante ou de melhor aplicação em relação ao Scrum, já que

esse último exige que diversos passos sejam fielmente executados, devendo ter o cuidado de

25

aplicar a metodologia Kanban corretamente, para não se tornar apenas um quadro com post-

its e em caso de insucesso, culpar a ferramenta pelo resultado.

5 Referências

ANDERSON, D. Kanban: Successful Evolutionary Change for Your Technology Business. Seattle: Blue Hole Press. 2010.

COTTRELL, Bill. Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOK. Disponível em: < <http://www.ibm.com/developerworks/rational/library/4763.html#author1> Acessado em 10 set. 2013.

DRUCKER, Peter F. Knowledge Work; Executive Excellence, Provo: APR, 2000.

FALCONER, Joel. The anatomy of a startup, illustrated. Disponível em: http://thenextweb.com/entrepreneur/2011/05/05/the-anatomy-of-a-startup-illustrated/#!phAZo. Acesso em 09 nov. 2013.

KRUCHTEN, P. The Rational Unified Process: an introduction. Boston: Addison-Wesley, 1999.

LARMAN, Craig. Utilizando UML Padroes - uma introdução a análise e ao projeto orientados. Porto Alegre: São Paulo: Bookman, 2007.

Manifesto para o desenvolvimento ágil de software. Disponível em : <http://agilemanifesto.org/iso/ptbr/>. Acesso em: 10 out. 2013.

MARTIN, R. C., MARTIN, Micah. Agile Principles, Patterns, and Practices in C# . Usa: Prentice Hall – 2006

PRESSMAN, Roger. Software Engineering: A Practitioner's Approach. McGraw-Hill Science/Engineering/Math. 2009.

PROJECT MANAGEMENT INSTITUTE. PMBOK : Guia do conhecimento em gerenciamento. 4.ed. São Paulo:  Saraiva, 2008.

PROJECT MANAGEMENT INSTITUTE. PMBOK : Guia do conhecimento em gerenciamento. 5.ed. São Paulo:  Saraiva, 2012.

RIES, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Business, 2011.

SHORE, James; WARDEN, Shade. The Art of Agile Development.  O'Reilly Media, 2007

26

SHUJA, A. K., KREBS, Jochen. IBM Rational Unified Process Reference and Certification Guide: Solution Designer (RUP) -. Indiana: IBM Press. 2008.

THE STANDISH GROUP. Chaos manifesto 2013.Disponivel em:< http://versionone.com/assets/img/files/ChaosManifesto2013.pdf> Acesso em 09 nov. 2013.

 

27