Análise Comparativa entre Metodologias Ágeis Kanban e Scrum Aplicada a Ambiente de Inovação Tecnológica

3.143 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
6 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.143
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
148
Comentários
0
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Análise Comparativa entre Metodologias Ágeis Kanban e Scrum Aplicada a Ambiente de Inovação Tecnológica

  1. 1. 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 Recife 2013
  2. 2. 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 Recife 2013
  3. 3. 3 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 Recife diogodrsa@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
  4. 4. 4 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
  5. 5. 5 em ambientes de muita incerteza. As startups não sabem ao certo quem são seus clientes ou 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.
  6. 6. 6 1.2 Justificativa 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>
  7. 7. 7 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, 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
  8. 8. 8 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 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.
  9. 9. 9 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
  10. 10. 10 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 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
  11. 11. 11 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 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:
  12. 12. 12 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.
  13. 13. 13 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.
  14. 14. 14 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. 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:
  15. 15. 15 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.
  16. 16. 16  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.  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
  17. 17. 17 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. 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.
  18. 18. 18 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).
  19. 19. 19 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
  20. 20. 20 mais transparente, exposição de gargalos, filas, variabilidade e desperdícios. (ANDERSON, 2010). 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>
  21. 21. 21 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,
  22. 22. 22 outras buscam investimentos de membros da família ou investidores anjos, 45% das startups 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.
  23. 23. 23 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.
  24. 24. 24  Velocidade 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.
  25. 25. 25  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 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
  26. 26. 26 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 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. D RUCKER, 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.
  27. 27. 27 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 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.

×