análise comparativa entre metodologias Ágeis kanban e scrum aplicada a ambiente de inovação...
Post on 05-Dec-2014
1.155 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related