Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software

Transcrição

1 Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Carolina Luiza Chamas Faculdade de Tecnologia da Zona Leste SP Brasil Leandro Colevati dos Santos Faculdade de Tecnologia da Zona Leste SP Brasil Resumo - Esse trabalho apresenta metodologias de desenvolvimentos de software baseados no manifesto ágil, como o Feature Driven Development, Ruby on Rails, extreme Programming e o Scrum. São apresentados os princípios de trabalho dessas metodologias, com enfoque na metodologia Scrum e a forma ideal de sua aplicação. É, nele, demonstrado, em um estudo de caso, com base em uma empresa que implementou, um projeto com a utilização do Scrum. O estudo de caso traz a análise da aplicação da metodologia, a verificação de sua correta aplicação, bem como aspectos gerenciais do projeto, utilizando a experiência da autora e algumas pesquisas. Palavras-chave: Metodologia Ágil, Scrum. Introdução As definições de desenvolvimento de software ágil evoluíram a partir da metade de da década de 90 como parte de uma reação contra métodos, de engenharia de software, considerados extremamentes rigidos quanto aos seus padrões, que, em algumas situações, não estavam mais atendendo as necessidades dos clientes e não era um processo claro para o cliente deixando-o inseguro quanto ao que seria entregue. O resultado é o surgimento das chamadas metodologias ágeis, que têm a proposta de aumentar o enfoque nas pessoas e não nos processos de desenvolvimento. Além disso, existe a preocupação de gastar menos tempo com documentação e mais com resolução de problemas de forma iterativa. O desenvolvimento ágil é particularmente adequado para equipes que têm que lidar com mudanças rápidas ou imprevisíveis nos requisitos. Os métodos ágeis de desenvolvimento de software surgiram como uma resposta às cobranças por inovação em prazos cada vez mais reduzidos, constantes necessidades de mudanças de requisitos e mal desempenho de grande parte dos projetos de desenvolvimento de software. Nesta época, as metodologias tradicionais começaram a ser questionadas devido ao grande volume de documentação, e um crescente número de organizações passou a adotar um ou mais métodos ágeis para produzir software com menos documentação, sob condições de mudanças rápidas e com foco na satisfação do cliente (MOL, 2007). A abordagem Scrum, para gestão de projetos ageis, apesar de utilizar um planejamento não-linear, está focada em agregar valor para o cliente. O objetivo desse trabalho é verificar se as causas de problemas, ou distorções, enfrentados em um projeto de desenvolvimento de sistemas que utiliza a metodologia Scrum, de uma empresa de desenvolvimento de softwares, são causados por falhas da metodologia, falta de comprometimento dos envolvidos ou de conhecimento dos colaboradores.

2 O objetivo desse artigo é demonstrar a comparação da teoria da metodologia SCRUM com a aplicação numa empresa multinacional de desenvolvimento e demonstrar, qualitativamente, que, mesmo aplicando a metodologia com falhas, é possível se obter o resultado esperado de um desenvolvimento com metodologia ágil. Para o desenvolvimento desse trabalho foi realizada pesquisas bibliográficas, através de livros, sites, artigos a fim de apresentar toda a parte conceitual de metodologias ágeis e, mais especificamente sobre a metodologia Scrum. Para o estudo de caso foram colhidos documentos utilizados no desenvolvimento de um projeto de desenvolvimento de software, utilizando Scrum, em uma empresa multinacional, da qual a autora do artigo participou, com a finalidade de minerar e analisar dados para realizar a investigação base desse trabalho, também se fez uma pesquisa com os profissionais envolvidos, a fim de verificar se a metodologia estava plenamente aplicada. Fundamentação Teórica Em novembro de 2001, programadores e consultores experientes que questionavam práticas tradicionais da Engenharia do Software e Gerência de Projetos se reuniram para discutirem suas experiências com metodologias ágeis. Dessa reunião, surge o Manifesto Ágil que define princípios e valores para as metodologias. As metodologias ágeis são conduzidas por esses princípios e valores que devem ser entendidos e aplicados por todos os profissionais presentes no desenvolvimento de software. Conforme o Manifesto Ágil(2011) existem 12 princípios para a utilização da metodologia ágil, sendo eles, a entrega adiantada e contínua de software de valor, aceitar mudanças de requisitos, mesmo no fim do desenvolvimento, entregar software funcionando com frequência, com preferência aos períodos mais curtos, Pessoas relacionadas a negócios e desenvolvedores trabalham em conjunto e diariamente, indivíduos motivados com ambiente e suporte necessário, conversa diretas entre os envolvidos, software funcional como medida primária de progresso, patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes, atenção à excelência técnica e bom design aumenta a agilidade, simplicidade, times auto organizáveis. Devem ser valorizados os indivíduos e as interações, em detrimento de processos e ferramentas, o software em funcionamento em detrimento da documentação abrangente, a colaboração com o cliente em detrimento da negociação de contratos e a resposta às mudanças em detrimento de um plano. SCRUM O Scrum foi criado por Jeff Sutherland, Ken Schwaber e Mike Beedle e tem como base 6 características (Schwaber, 2004, apud MARÇAL et al., 2007): Flexibilidade dos resultados, flexibilidade dos prazos, times pequenos, revisões frequentes, colaboração e Orientação a objetos. Seu nome surgiu da comparação entre desenvolvedores e jogadores de Rugby. Scrum é a denominação da rápida reunião que ocorre quando os jogadores de Rugby irão iniciar um lance. No Rugby, cada time age em conjunto, como uma unidade integrada, em que cada membro desempenha um papel específico e todos se ajudam em busca de um objetivo comum. Assim também são os times de desenvolvimento que adotam o processo Scrum. É uma metodologia ágil que permite o gerenciamento e controle no desenvolvimento de software através de práticas iterativas e incrementais. O Scrum teve como base as práticas de gerenciamento do Extreme Programming e no RUP (Rational

3 Unified Process), segundo Yoshima(2007) o Scrum produz os benefícios do desenvolvimento ágil com a vantagem de ser uma implementação simples, tem como foco o PDCA (Plan, Do, Check, Act), resultando na melhoria contínua. Obteve uma maior visibilidade nos últimos cinco anos nos projetos de desenvolvimento de software, enfatizando muitos benefícios, dentre estes podemos citar o comprometimento da equipe, motivação, colaboração, integração e compartilhamento de conhecimento, o que facilita em muito o gerenciamento e sucesso dos projetos. (Schwaber, 2004, apud Marçal et al., 2007). O Scrum faz uso de técnicas simples juntamente com o senso comum e experiências anteriores, que já foram testadas e aprovadas, conforme visto na Tabela 1. Tabela 1: Características da metodologia ágil Scrum. FONTE: (SAVOINE, et al.,2009, pg 05) adaptado pela autora Segundo Souza Neto(2010) o ciclo de vida do Scrum é baseado em três fases, como apresentado na Tabela 2. Pré-Planejamento (pre-game phase) Desenvolvimento (game phase) Pós- Planejamento (post-game phase) Tabela 2 Fases do Ciclo de Vida do Scrum Fase onde os requisitos são descritos e priorizados no Product Backlog, é feita a estimativa de esforço para cada requisito, definição da equipe, definição das ferramentas de desenvolvimento e estimativa de riscos do projeto; Desenvolvimento iterativo e incremental das funcionalidades do produto através de múltiplas Sprints, reuniões diárias e de revisão; Após a fase de desenvolvimento são realizadas reuniões com o objetivo de analisar o progresso do projeto e demonstrar o software atual para o Product Owner, aqui são feitas também as etapas de integração, testes e documentação. O Scrum tem como base iterações, chamadas de Sprints, que devem ter duração de 2 a 4 semanas (time-box), isso é importante para se conseguir medir o progresso, a produtividade da equipe no projeto e verificar se os requisitos exigidos estão sendo desenvolvidos, cada Sprint representa uma entrega de produto.

4 Dentro de um Sprint executa-se o framework do Scrum juntamente com o planejamento do Sprint, as reuniões diárias, a entrega do produto final do Sprint e a retrospectiva. É necessário respeitar o período de tempo do Sprint como uma regra inegociável. A quantidade de requisitos que serão implementados dentro de um Sprint é determinada pela equipe. Após estabelecer a duração do Sprint não se deve modificar a sua data final, pois esta determina a duração do projeto, outro fator importante para se manter o padrão de duração do Sprint é a relação de produtividade do time dentro do Sprint. A métrica de esforço para os itens já priorizados no Sprint é que determinarão se será possível medi-la para um mesmo time-box, o total de itens que foram finalizados por Sprint. Esta métrica é muito importante, e apenas será real se as Sprints forem de tamanhos iguais. Na execução do Sprint, o time realiza a alocação de recursos para cada tarefa, cada membro da equipe escolhe as tarefas que podem realizar e o time define a ordem e dependência de cada tarefa. O controle da disciplina é algo importante para o sucesso do time com o uso do Scrum. O time é considerado auto-gerenciável, e deve responder por si só. Em função disso, os membros do time devem definir as horas utilizadas em tarefas para que o valor de horas restantes seja calculado corretamente e o time possa verificar o seu progresso. Depois da estimativa refinada é possível calcular o total de horas necessário para realizar todas as tarefas. Deve-se deixar sempre uma folga, já que sempre podem aparecer surpresas. Deve-se lembrar que o Sprint possui um limite de horas disponível conhecido por LHS (Limite de Horas do Sprint). O Limite de Horas do Sprint (LHS) pode ser medido utilizando uma fórmula simples: LHS = (R x H) x D, onde: R = Total de recursos do time, H = Total de horas disponível para cada recurso, D = Total de dias úteis do Sprint. Papéis, Cerimônias e Artefatos Yoshima(2007) ressalta que o Scrum tem como base papéis e responsabilidades, que são mais abrangentes e tem como objetivo atingir o sucesso do projeto. O Scrum define basicamente três papéis: Product Owner, Scrum Master e Scrum Team. (Marçal et al., 2007) Segundo Marçal et al., 2007, o Product Owner é o dono do produto, cliente ou algum interessado do projeto, que representa os interesses de todos os envolvidos com o software. sua maior responsabilidade está relacionada aos ROI (Return on Investiment) do projeto, é o envolvido no projeto, responsável pela definição das características e funcionalidades do produto, cria uma visão única dos requisitos do sistema, por concentrar as informações oriundas dos envolvidos no projeto, prioriza as funcionalidades do projeto, conforme as necessidades dos usuários, realiza as solicitações de alterações para as próximas iterações e é responsável por aceitar ou rejeitar os resultados de cada iteração. O Scrum Master desempenha um papel de liderança, ele gerencia os interesses do Product Owner mediante o time. Na abordagem tradicional o gerente de projetos seria o Scrum Master.(Yoshima, 2007) São responsabilidades do Scrum Master, realizar a promoção da criatividade e conhecimento do time visando o aumento de produtividade, estimular comunicação e cooperação entre as pessoas do time, garantir que o projeto seja desenvolvido no prazo e custo, realizar reuniões de acompanhamento (Daily Scrum, Sprint, Review e Sprint

5 Retrospective), auxiliar o Product Owner, facilitar a colaboração entre as funções e áreas e eliminar os impedimentos do time, proteger o time de interferências externas, controlar as tarefas realizadas, em andamento, concluídas e o surgimento de novas tarefas, atualizar o Burndown Chart. Segundo Marçal et al. (2007), o Team pode ser definido como um grupo de pessoas cuja responsabilidade é o desenvolvimento das funcionalidades do projeto. Tem como principais características, a determinação de que o time deve ter conhecimento técnico e capacidade sobre todo o processo de desenvolvimento, ter entre 7 e 9 pessoas, fazer a seleção dos itens priorizados que serão executados durante cada iteração e a demonstração das funcionalidades do produto e os resultados obtidos ao Product Owner. São cerimônias do Scrum, o Sprint Planning, o Sprint Review, o Sprint Retrospective e o Daily Scrum Meetings Pode-se definir o Sprint Planning, como uma reunião onde todos os stakeholders envolvidos estão presentes para planejar o próximo Sprint, é a primeira reunião que ocorre, sendo dividida em duas partes, cada uma dela com um Time-Box de quatro horas. Na primeira parte o Scrum Master reúne-se com o Product Owner para verificar qual é o Product Backlog, focando no retorno sobre investimento do projeto. Na segunda parte, o Scrum Master se reúne com o time e com o Product Owner para realizar a escolha dos itens que irão compor o Sprint Backlog e seu planejamento, além disso, a equipe estima o Product Backlog, definindo complexidade e prazo das tarefas (Yoshima, 2007). Uma das principais atividades da reunião de planejamento do Sprint é a decisão de quais estórias serão incluídas no Sprint, ou seja, quais estórias do Product Backlog copiar para o Sprint Backlog. Antes de iniciar a reunião de planejamento é necessário ter definida a prioridade e estimativa do Backlog, para isto existem diversas técnicas como o Planning Poker. Segundo Cohn o Planning Poker é uma forma de estimativa em conjunto, que pode ser feita como um jogo. Todos os membros do time participam democraticamente com o objetivo de chegar a um consenso de estimativa, para cada item do Backlog. No jogo é selecionado o item de Backlog que o Product Owner e o time acreditam que seja o mais fácil de implementar e, a ele, é associado o menor número da sequência. Depois o próximo item é selecionado, e é comparado o seu grau de dificuldade com os dos itens já estimados. Nessa fase, cada participante da reunião seleciona uma carta, onde se acredita ter o grau de dificuldade associado ao item e o participante espera que todos os outros participantes terminem as suas seleções. Quando todos selecionaram as suas cartas, as mesmas são mostradas. E assim, havendo um consenso geral nas seleções feitas, o número da carta que corresponde ao tamanho é relacionado ao item. Se houver divergência, é necessário que os participantes expliquem os motivos de sua escolha, para que todos possam refletir e realizar a validação da sua escolha. Finalizada a discussão realiza-se uma nova rodada para que todos tenham a oportunidade de reavaliar seus julgamentos. Esse processo continua até que seja encontrado um consenso. É importante que exista um moderador para que as discussões sejam produtivas e não polemizadas. Esse ciclo é seguido até que todos os itens do Backlog sejam estimados. O Sprint Review é um ponto de inspeção importante do Scrum. Acontece no último dia do Sprint e representa o momento em que a equipe e o Scrum Master demonstram as funcionalidades implantadas ao Product Owner. Segundo Yoshima(2007) é muito importante no auxilio da correção de erros do projeto antes do início do novo Sprint. O Sprint Retrospective é a reunião realizada no final de cada Sprint para verificar seus pontos fortes e fracos, além disso, permite a definição de ações para manutenção dos pontos fortes e eliminação ou redução dos pontos fracos relatados.

6 O Daily Scrum Meeting é a reunião de acompanhamento diária com curta duração, geralmente quinze minutos, onde são discutidos três pontos: o que foi feito desde a última reunião (dia anterior), quais as dificuldades e os fatores de impedimento e o que precisa ser priorizado no dia que se inicia. Artefatos O Product Backlog é a lista de itens com prioridades definidas que incluem tudo o que precisa ser realizado, que possa ser associado com valor de negócio (Business Value), para a finalização do projeto, sejam requisitos funcionais ou não. Após o Product Backlog os itens devem ser priorizados. O Spring Backlog é uma lista de tarefas que o time (team) se compromete a fazer em um Sprint. O gráfico de Burndown, Burndown Chart, é o principal artefato para acompanhar o andamento do Sprint. É baseado nas atualizações diárias da equipe, com o status das tarefas, e no número de horas restantes para a conclusão de cada tarefa. A soma de horas das tarefas determina a quantidade de horas necessárias para finalizar o Sprint, e conforme as tarefas são concluídas, o gráfico vai decrescendo até atingir o número de horas zero. O eixo Y representa o número total de horas estimado para o Sprint e o eixo X os dias do Sprint, de acordo com o seu tamanho. Uma forma de controlar a execução dos itens do Sprint Backlog é fazendo um quadro de trabalho. O objetivo é organizar as atividades dos itens do Sprint Backlog em quatro estados: para fazer, em andamento, para verificar e concluído (Marçal et al.,2007). Estudo de Caso Esse artigo apresenta o acompanhamento de um desenvolvimento com metodologia ágil, numa multinacional de desenvolvimento de software, trazendo a comparação da teoria com o que se apresentava no dia-a-dia do desenvolvimento. O projeto tinha 3 equipes, 2 delas contendo entre 5 e 7 pessoas e a última 13 pessoas com diferentes níveis de conhecimento de estagiários a analistas sênior. Dessas três equipes, duas iniciaram o desenvolvimento sem aproveitamento de código e a última equipe realizou a manutenção e implementação de novas funcionalidades de um sistema existente. Inicialmente, as equipes de desenvolvimento tinham a pretensão da aplicação da metodologia de forma integral, de acordo com o descrito na teoria do Scrum. A pesquisa feita por Chamas(2011), demonstra que, para 60% dos envolvidos o conceito do Scrum foi sempre aplicado e 40% nem sempre era aplicado. No início do projeto, as equipes adotaram como o Sprint com dez dias, o Scrum sugere Sprints com 30 dias de duração. A pesquisa com os desenvolvedores demostrou que a duração escolhida ocasionou problemas, pois a duração era muito baixa para realizar a implementação das estórias e testá-las adequadamente para o Sprint Review. O Team era formado entre 5 a 13 pessoas o que está em desacordo com a recomendação do Scrum, onde o time deve ter entre 7 e 9 pessoas. O Scrum Master era um arquiteto de projetos, que assumiu este papel já no início da adoção da metodologia pela empresa. Por ter um perfil técnico, foi necessária a adaptação das funções desenvolvidas por ele, pois suas atribuições deixaram de ser fornecer soluções técnicas para os problemas que surgissem e passaram a ser ajudar e facilitar o dia-a-dia do time. Neste caso podemos dizer que a pesquisa aponta que a empresa, no inicio, não aplicava de maneira correta o conceito de Scrum Master, mas com o objetivo de utilizá-lo corretamente foram feitas as modificações necessárias.

7 Durante os primeiros meses de projeto, ao final de cada período de Sprint, ocorria a reunião de retrospectiva entre os membros de cada equipe, onde eram discutidos os principais aspectos, positivos e negativos, daquele Sprint, mas conforme a evolução do projeto e falta de tempo ela era realizada somente quando havia tempo hábil. No ultimo dia do período de Sprint, ocorria a apresentação das estórias do próximo Sprint, onde todos os membros da equipe, incluindo o Scrum Master e os arquitetos, participavam e tiravam dúvidas sobre o que precisava ser desenvolvido, se haveria algum impedimento e a viabilidade da realização da nova funcionalidade, a partir da estória que estava sendo apresentada pelo Product Owner. O Product Owner definia os itens que fariam parte do Product Backlog e os priorizava nessa reunião, dessa forma, a representação do papel está de acordo com aquilo que a metodologia propõe. O Product Backlog estava restrito ao Scrum Master, consequentemente, a equipe só tinha acesso a ele nas reuniões de planejamento, essa restrição gerava muitas dúvidas, que acabavam deixando a reunião mais longa, uma vez que o acesso antecipado ao Product Backlog poderia dirimir as dúvidas antecipadamente. O Planning Poker não era utilizado, pois no decorrer dos Sprints o time foi se dividindo para a realização das tarefas. Dessa forma não houve distribuição de conhecimento e nem todos do time conseguiam estimar uma hora correta para uma atividade. No início dos Sprints a equipe não tinha maturidade para estimar as atividades o que gerava, consequentemente, muitos atrasos, no entanto, com o passar do tempo e com ganho de experiência a equipe criou uma planilha para auxiliar as tarefas do Sprint para evitar esquecimento de atividades. As atividades para a realização das estórias contadas eram escritas em post-its e, também, dispostas em uma planilha que servia para controle de todos os membros do projeto, contendo o tempo planejado e o tempo real de sua execução, o seu tipo e o seu responsável e, também, a partir dela era gerado o Burndown, que era enviado todos os dias para a equipe e os líderes das outras equipes, onde mostrava a evolução do Sprint, os riscos e impedimentos. Logo após a apresentação das estórias, ocorria a reunião de aceite onde o Product Owner verificava tudo o que foi implementado, se o teste foi concluído 100% sem erros, se alguma funcionalidade não foi implementada e, também, era informado se havia algum Backlog. Verificou-se, com a pesquisa que as estórias que não eram aceitas pelo Product Owner se davam, essencialmente devido a falhas na documentação das regras de negócio e dos casos de uso. Nos dias do Sprint eram realizadas as reuniões diárias (Daily Meetings) que, de acordo com o processo Scrum, deveriam, de fato, ser realizadas todos os dias. A pesquisa demonstrou que no inicio estavam sendo feitas diariamente, posteriormente foram realizadas conforme a necessidade de alinhamento das tarefas. Em muitas Daily Meetings, alguns participantes faziam comentários além das três perguntas que deveriam ser respondidas, aumentando o tempo das reuniões. O projeto utilizava este gráfico Burndown, figura 1, para verificar possíveis atrasos, onde se a linha vermelha estiver ultrapassando a linha azul isso significa que algo não está de acordo com aquilo que foi planejado. Verificou-se que, nesse projeto, se utilizava uma lista de riscos onde eram definidos os tipos de riscos e as possíveis formas de mitigá-los. Essa também foi mais uma adaptação que a empresa aplicou na utilização da metodologia Scrum.

8 Figura 1 Burndown Chart FONTE: Do Autor De acordo com a observação do projeto, para a pesquisa, verificou-se que ocorria o desenvolvimento em pares, algumas vezes, aspecto da metodologia XP muitas vezes adaptada ao Scrum, que se dava quando o domínio sobre o problema não era total por somente uma pessoa, assim, fazia-se a junção de alguns membros da equipe para desenvolverem a funcionalidade. O projeto utilizou uma ferramenta que promovia a qualidade, o controle e a integração de todas as equipes envolvidas no projeto, trazendo recursos que ofereciam ao Scrum Master visualizar o andamento dos Sprints, controlar a qualidade do código e as maiores dificuldades encontradas com o controle de horas em atividades planejadas. Com a utilização dessa ferramenta, observou-se que o código fonte produzido no projeto atende critérios rígidos de qualidade estabelecidos em métricas padrões. A integração contínua promovida pela ferramenta de controle de versão (SVN) ocorria de forma automática, com o uso dessa prática era possível unir o trabalho da equipe de forma coesa, permitindo assim, além de centralização a armazenagem segura. O código fonte ficava disponível para qualquer desenvolvedor a qualquer momento. Como determinado pela metodologia, o ambiente de trabalho deve ser sempre o mais adequado para que a equipe possa desenvolver, então, a pesquisa também visou levantar algumas informações sobre esse aspecto. Um dos principais problemas levantados pela pesquisa foi o de comunicação. As equipes perderam um bom tempo sugerindo características e funções do sistema que o cliente não sabia como formular ou sequer havia imaginado. As horas de planejamento eram superiores às 4h sugeridas pela metodologia. Isso ocasionou muitas modificações no desenvolvimento dos Sprints que, muitas vezes, já estavam em andamento, o que causou grandes atrasos. Outro problema identificado foi a dificuldade do cliente em especificar suas necessidades. Com isso perceberam que é importante todos terem iniciativa para decidir o que é melhor para o projeto e saber tomar decisões. Por fim, a dificuldade da correção de bugs após a realização do teste integrado. Os pesquisados ressaltaram a importância de líderes técnicos na equipe para a padronização do sistema o que facilitaria a correção dos erros encontrados. Mesmo com a ferramenta que controlava a qualidade do código, o sistema era despadronizado, perdendo sua qualidade que por sua vez estendeu o tempo do projeto pela dificuldade de corrigir os erros. Na maioria das vezes a correção do erro era perdida devido a alterações realizadas para a correção de outro erro. Considerações Finais Esse artigo demonstra a aplicação da teoria da Metodologia SCRUM por uma empresa multinacional de desenvolvimento de software. É sabido que, pela teoria, a aplicação da metodoligia ágil visa excelência técnica, aumento de agilidade e

9 simplicidade, no entanto, para sua aplicação, é necessário aplicar uma série de regras e conceitos, como foi apresentado na Fundamentação Teórica. A pesquisa demosntra que, para aplicar as regras da metodologia SCRUM, existe a necessidade de uma equipe com maturidade, a partir do Scrum Master, pois, pequenos desacordos entre teoria e prática podem levar a atrasos, como o Scrum Master não ter um perfil gerencial e demorar em se adequar a suas funções. Outra falha, que leva a atrasos, identificada, foi a falta do Planning Poker, pois gerou defict de conhecimento e estimativas erradas de tempo de entrega. Por fim, uma análise qualitativa do Burndown Chart, permite verificar que, mesmo com todas as inconformidades com a teoria da metodologia, na maioria das vezes, não houve tanta diferença entre o esperado (linha azul do gráfico) com o obtido (linha vermelha), o que sugere que a metodologia, mesmo aplicada com falhas pode dar à equipe uma qualidade de desenvolvimento que se reflete nos resultados e na entrega do produto e, a continuidade da equipe na aplicação da metodologia para os próximos projetos, aumentando sua maturidade, possivelmente levará o resultado apresentado em Burndown Chart estar mais próximo do perfil esperado ou até abaixo. Bibliografia CHAMAS, C. L., Análise da aplicação da metodologia SCRUM, Trabalho de Conclusão de Curso, Informática para a Gestão de Negócios, Fatec Zona Leste, São Paulo, COHN, M., Agile Estimating and Planning, Prentice Hall, 2006, 330 p. MANIFESTO AGIL. Manifesto para o desenvolvimento ágil de software. Disponível em: < Acesso em: 28/02/ :13. MARÇAL,P.; PEREIRA, P.; TORREÃO, A. S., Entendendo Scrum para Gerenciar Projetos de Forma Ágil, Rio de janeiro, 2007 MOL, A.C. Uma discussão sobre os métodos ágeis de desenvolvimento de software. Minas Gerais: Monografia de Final de Curso Universidade Federal de Minas Gerais, SCHWABER, K., and BEEDLE, M., Agile Software Development With Scrum, Prentice Hall, SOUZA NETO, O. N., Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ageis., Trabalho de Conclusão de Curso(Bacharelado em Ciencias da Computacao) Centro de Ciencias Exatas e Tecnologia, Universidade, Belém, YOSHIMA, R. Gerenciamento de Projetos com Scrum Disponível em < Acesso em 15/02/2011, 20:00 Contato Carolina Luiza Chamas, Analista Programador Pleno em LocalCred R. Barão de Itapetininga, 275, São Paulo, SP. carolina.chamas@localcred.com.br