SCRUM com Equipes Inexperientes

Transcrição

1 SCRUM com Equipes Inexperientes Cicero Tadeu Pereira Lima França 1, Antonio de Barros Serra 2, Robério Gomes Patricio 3, Isydório Alves Donato 4 Resumo A constante busca dos projetos de TI por um produto final de melhor qualidade leva a criação de novos métodos e estratégias, ou a releituras dos já existentes. A procura por eficácia e eficiência fez surgir dois grupos bem definidos, os ágeis e os não ágeis. Apesar de diferentes, os dois grupos têm a idéia comum que o SCRUM só pode ser utilizado por equipes experientes. Este artigo apresenta um estudo de caso que permite a reavaliação desta idéia, pois relata um projeto real, desenvolvido por uma equipe inexperiência no desenvolvimento de projetos de TI e na utilização do SCRUM. Palavras-chave Agile Alliance, Modelagem Ágil, framework, SCRUM. A I. INTRODUÇÃO busca constante por resultados eficazes de maneira eficiente é uma realidade em projetos de desenvolvimento na área de TI. Alguns defendem que para um desenvolvimento eficaz e eficiente o escopo, prazos e custos devem estar bem definidos. Outros rebatem apresentando que eficácia e eficiência não dependem desses parâmetros. Existem diversas metodologias e framework para o desenvolvimento de projetos na área de TI. Na atualidade existem dois grandes grupos que alocam essas metodologias e frameworks. O primeiro grupo é voltado para um desenvolvimento mais interativo, permitindo o contato e intervenção dos Stakeholders em vários momentos do projeto. As pessoas que pertencem a esse grupo são denominadas de ágeis. O segundo grupo de desenvolvimento tem o foco no escopo, com processos, prazos e custos bem determinados. As intervenções e feedbacks dos Stakeholders são menores. As pessoas desse grupo são designadas de não ágeis. Os dois grupos apresentam idéias e conceitos com bons fundamentos teóricos e práticos, que provam a eficácia e eficiência. Mas apesar do distanciamento dos dois grupos, algumas idéias infundadas de um grupo conseguem passam para o outro grupo de maneira transparente. A idéia que apenas equipes experientes podem utilizar o SCRUM é comum aos dois grupos. A base desta idéia vem do pensamento que uma equipe só consegue ser auto-gerenciável se seus componentes tiverem experiência tanto no framework quanto nas ferramentas utilizadas. Este artigo apresenta um estudo de caso que leva a repensar esta idéia, uma vez que é relatado um estudo de caso onde a equipe não tinha experiência no uso do framework SCRUM e nas ferramentas utilizadas no projeto. Apesar da equipe ter recebido suporte de pessoas mais experiente no inicio, mais de 80% do projeto foi desenvolvido por uma equipe inexperiente. A aceitação e uso das boas práticas, valores e princípios recomendadas pelo SCRUM levou a equipe ao autogerenciamento de maneira natural. As duas características mais fortes da equipe foram o comprometimento e a humildade. Estas duas características ajudaram a equipe a ganhar experiência no decorre do projeto. II. SCRUM O termo SCRUM foi apresentado ao desenvolvimento de software por Takeuchi e Nonaka no artigo escrito por eles em Com o título The new product development game O novo jogo de desenvolvimento de produtos, este artigo foi publicado na Harvard Bussiness Review. Jeff Sutherland é um dos criadores do SCRUM e era VP da Easel Corporation em 1994, quando introduziu algumas das práticas do SCRUM com base neste artigo. [1]. Jeff Sutherland também foi influenciado pelo artigo do projeto Borland Quattro Pro, por ter sido o projeto mais produtivo documentado até então. Esse projeto introduziu as reuniões diárias dentro do projeto de software. Em 1995 Jeff Sutherland junto com Ken Schwaber formalizaram o SCRUM. O termo SCRUM não foi criado por nenhum dos citados até agora nesta seção. SCRUM é termo usado no jogo de Rugby para as reuniões que os jogadores fazem para planejar a próxima jogada. A idéia de se utilizar o SCRUM num projeto é que, assim como no Rugby, a equipe deve traça o plano para a próxima jogada, mas tendo em mente a visão de longo prazo. O SCRUM é um framework baseado nos princípios e valores da Agile Alliance. Ele tenta lidar com novas exigências de forma mais eficiente, aumentando a motivação da equipe e melhorando a comunicação entre a equipe e o cliente. O SCRUM apresenta processos leves de gerenciamento e controle de projetos de software, mas no SCRUM não existe o papel do gerente de projeto, a equipe do projeto tem que ser autogerenciável. O SCRUM é baseado no desenvolvimento iterativo e incremental. Com esta abordagem busca-se produzir versões 1 Faculdade de Juazeiro do Norte (FJN), Juazeiro do Norte, Ceará, Brasil, prof.tadeupereira@gmail.com 2 Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE), Fortaleza, Ceará, serra@ifce.edu.br 3 Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE), Crato, Ceará, roberiogomes@ifce.edu.br 4 Faculdade de Juazeiro do Norte (FJN), Juazeiro do Norte, Ceará, Brasil, isydorio@gmail.com

2 funcionais em intervalos de tempo pequenos e regulares, apresentando ao cliente o retorno financeiro dos seus investimentos. Também é objetivo do SCRUM empregar a lei do menor esforço, descoberta pelo economista italiano Vilfredo Pareto ( ). A lei do menor esforço baseia-se no princípio de que 80% do valor do produto vêm de 20% dos seus recursos. Desta maneira é possível criar um produto, de maneira iterativa, que tenha 20% dos recursos do software na parte inicial do projeto. Essa lei permite ao cliente obter um retorno mais cedo do valor investido no projeto. O SCRUM é um processo utilizado para manter o foco na entrega do maior valor de negócio no menor tempo possível, permitindo a inspeção rápida e contínua do software que está sendo produzido, e avaliando as necessidades do negócio para determinar a prioridade do desenvolvimento. A equipe de desenvolvimento tem que se auto-organizar para definir uma estratégia que entregue as funcionalidades de maior prioridade exigida pelo negócio. A. O Framework SCRUM A Fig. 1 ilustra o funcionamento do framework SCRUM. Figura 1. Framework SCRUM Fonte: Mountan Goat Software Para entender a Fig. 1 é necessário conhecer algumas definições, começando por Sprint. Um Sprint é uma iteração composta por duas a quatro semanas, nesse período a equipe de desenvolvimento deve concentrar-se na realização das funcionalidades definidos para a iteração atual. As funcionalidades definidas para o Sprint deve ser projetadas, implementadas e testadas até a conclusão do Sprint. No decorre do Sprint a equipe não pode ser incomodada, nem deve haver solicitação de mudanças nas funcionalidades incluídas no Sprint. Na Fig. 1 o Sprint é representado pela seta maior apontando no sentido anti-horário. O Product Backlog é a lista dinâmica de itens do projeto, a qualquer momento itens existentes podem ser eliminados e novos itens podem ser adicionados. Os itens com prioridade maior têm suas entregas antecipadas, e a cada nova entrega, esses itens são progressivamente refinados. Os itens de menor prioridade são, intencionalmente, colocados no final da lista. O Sprint Backlog é uma sub-lista de itens retirada do Product Backlog. Os itens do Sprint Backlog são escolhidos pela equipe que se compromete em concluir as tarefas listadas no Sprint Backlog até o final do Sprint. Os itens do Sprint Backlog são divididos em tarefas detalhada. A equipe deve trabalhar de forma colaborativa para completar os itens do Sprint Backlog. O Daily Scrum Meeting é a reunião diária que os membros da equipe fazem, esta reunião deve durar no máximo quinze minutos. O propósito do Daily Scrum Meeting é manter a equipe informada sobre o progresso e dificuldades dos seus membros. Cada membro da equipe deve responder três perguntas: (i) O que você fez desde o último Daily Scrum Meeting? (ii) O que você vai fazer até o próximo Daily Scrum Meeting? Quais obstáculos impediram ou impedem a realização do seu trabalho? O Potentially Shippable representa o que pôde ser entregue ao cliente no final do Sprint. Mas a real liberação das funcionalidades ou produtos só é feita pelo cliente, ele é quem decide o que realmente pode ser liberado. B. Papeis no SCRUM Os papeis definidos pelo SCRUM são Product Owner (Dono do Produto), Scrum Master (Mestre Scrum) e Team (Time). O Product Owner representa os interesses do cliente e garante que o Team trabalhe com a perspectiva de negócio correta. Ele é responsável por definir as funcionalidades do produto, decidir datas de lançamento e conteúdo, avaliar a rentabilidade do produto, priorizar funcionalidades de acordo com o valor de mercado, rever e ajustar funcionalidade e prioridades, aceitar ou rejeita o resultado dos trabalhos entregues pelo Team, e conseguir verba para o projeto. Esse papel pode ser assumido pelo cliente, mas também pode ser um membro da organização que tenha o conhecimento abrangente sobre marketing e processos de negócios. O Scrum Master ocupa uma posição de treinador, fixador e porteiro. É responsável por remover todos os possíveis impedimentos. Dedica-se constantemente em garantir as melhores condições possíveis de trabalho para o Team. O Scrum Master deve estar presente nas reuniões diárias e garantir que o Team seja perturbado o mínimo de vezes possíveis. Também é responsável pela aplicação dos valores e práticas do SCRUM por parte do Team, e garante a colaboração entre os diversos papéis e funções do projeto. O Team tem entre cinco e nove pessoas, elas devem ser autogerenciáveis, auto-organizadas e multifuncionais (programadores, testadores, desenvolvedores de interfaces, etc.). Os membros do Team decidem como o trabalho será organizado e como as atribuições serão distribuídas, mas não deve haver funções predefinidas. Os membros do Team devem ser capazes de trocar tarefas no decorrer trabalho, não impedindo que membros sejam especialistas em um determinado tópico. C. Cerimônias do SCRUM As cerimônias do SCRUM são fases e protocolos que devem ser seguidos para que o projeto possa ser entregue de maneira eficaz e eficiente. O Planejamento do Sprint é a primeira cerimônia a ser realizada. Para [2] O propósito da reunião de planejamento do Sprint é dar à equipe informação suficiente para trabalhar em paz por algumas semanas, e para dar ao Product Owner confiança suficiente para deixá-los fazendo isto. O planejamento deve levar em consideração o Product Backlog. Com base nos itens do Product Backlog a equipe deve avaliar as regras do negócio, o produto atual, a tecnologia a ser usada,

3 o estado atual do produto e a capacidade da equipe em atender os itens do Product Backlog. Após levantar essas informações a equipe deve definir o objetivo do Sprint, criando um plano que determine como chegar ao objetivo, selecionando os itens do Product Backlog que farão parte do Sprint Backlog e definindo a quantidade de horas que o Sprint Backlog terá. A Revisão do Sprint acontece no final de cada Sprint. Nesta reunião a equipe deve apresentar os resultados obtidos ao Product Owner e aos Stakeholders. A equipe demonstra as novas funcionalidades e obtêm um feedback do trabalho realizado, determinando os objetivos da próxima iteração. A reunião permite avaliar periodicamente o valor de negócio produzido, além de permitir avaliar a qualidade e as capacidades das funcionalidades produzidas. Na Retrospectiva do Sprint a equipe deve avaliar o processo de trabalho, levando em conta o framework e as boas práticas do SCRUM. É preciso ser avaliado o que deu certo durante o Sprint e o que pode ser melhorado para o próximo. A retrospectiva tem como resultado ações a serem executadas no próximo Sprint para melhorar o processo. A Reunião Diária também é uma cerimônia do Scrum. D. Artefatos do SCRUM Fazem parte dos artefatos do SCRUM o Product Backlog, o Sprint Backlog e o Burndown Chart. Tanto o Product Backlog quanto o Sprint Backlog já foram apresentados, mas serão reforçadas suas características. No Product Backlog é mantida uma lista com todas as funcionalidades desejadas pelo cliente. O cliente atribui um peso a cada item de acordo com as suas necessidades ou necessidades dos usuários. O Product Owner é responsável por priorizar os itens. As priorizações dos itens podem ser modificadas a cada Sprint concluído. No Sprint Backlog cada membro do Team escolhe em que vai trabalhar, nenhum membro do Team deve atribuir trabalho a outro membro. Cada membro mantém atualizada a estimativa de conclusão do trabalho que está realizando. A adição, exclusão ou mudança de tarefas podem ser feitas por qualquer membro do Team. Tarefas não claras devem ser subdivididas e seu tempo deve ser repensado. A medida que os requisitos vão se tornando mais claros, devem ser atualizados os trabalhos a serem feitos. O Burndown Chart é um gráfico que permite a equipe acompanhar constantemente o processo do projeto, comparando o progresso atual com o que foi planejado. O gráfico mostra se o Sprint será concluído no tempo previsto, caso seja observado alguma distorção, o Team reavalia suas ações e propõem mudanças visando o sucesso do Sprint. Os Burndown Charts dos Sprints passados servem de subsídios para a previsão de Sprints atuais e futuros. Esta ferramenta é simples e ideal para instigar a conversa e facilitar a investigação. III. ESTUDO DE CASO Com a necessidade de ter um site mais dinâmico e integrado as redes sociais, o Geopark Araripe procurou ajuda para refazer não apenas o layout do site oficial, mas também criar um site que pudesse propiciar um dinamismo maior na inclusão, alteração e exclusão de notícias, eventos, fotos, etc. Neste processo de buscar um parceiro da área de TI, o Geopark Araripe encontrou a CASSIC ( com.br) que, através de seus diretores, aceitou desenvolver o produto almejado pelo Geopark Araripe. A equipe montada para desenvolver o projeto foi composta por alunos de uma instituição de ensino superior. Esta equipe utilizou o framework Scrum durante todo o projeto. A. Inicio do Projeto O projeto foi iniciado com uma reunião, onde estavam presentes interessados do lado do cliente (Geopark Araripe) e do lado da equipe de desenvolvimento (CASSIC). Nesta primeira reunião o cliente colocou seus desejos, e com a ajuda da equipe de desenvolvimento o cliente começou a separar o que era necessidade do que era pretensão. Por fim foi escolhido um responsável para fazer a ligação entre a equipe CASSIC e o Geopark Araripe, este papel foi conferido a um membro do cliente. Numa segunda reunião foi explicado ao cliente que a equipe iria utilizar o framework SCRUM, sendo explicados os papeis, cerimoniais e artefatos que fazem partes desse framework. Após a explicação um membro do cliente adotou o papel de Product Owner e o um membro da equipe de desenvolvimento aceitou o papel de Scrum Master. Com os papeis definidos, o Product Owner definiu as funcionalidades e seus valores de negócios, além de priorizar as funcionalidades que deveriam ser entregues. Também foi decidido que outros dois membros da equipe de desenvolvimento fariam parte do projeto, mas apenas como consultores, não interferindo diretamente no projeto. Por fim foi definido o Team e decidido que os Sprints seriam de dez dias úteis, mas em cada dia útil apenas quatro horas seriam destinadas ao projeto, uma vez que todos os membros do Team eram estudantes universitários. B. O Team O Team foi composto inicialmente por cinco pessoas, no segundo Sprint uma sexta pessoa entrou. Mas no terceiro Sprint duas pessoas abandonaram o projeto por não terem absorvido os princípios e valores do SCRUM, essas duas pessoas não apresentaram comprometimento nem com o projeto nem com o Team. Todos os membros do Team tinham em comum o fato de serem alunos do curso superior de Sistema de Informação da Faculdade de Juazeiro do Norte (FJN), e o fato de nunca terem desenvolvido nenhum projeto de desenvolvimento fora do ambiente acadêmico. C. Primeiro Sprint O primeiro Sprint foi iniciado no dia 29 de março de 2010 com data prevista para conclusão no dia 09 de Abril de No Planejamento do Sprint o Team criou o Sprint Backlog com dois itens retirados do Product Backlog. O primeiro item tinha doze tarefas e o segundo três. Apesar da inexperiência do Team, foi possível entregar as funcionalidades do primeiro Sprint graças ao autogerenciamento e comprometimento da maior parte dos componentes. A Reunião Diária ajudou a realinhar as

4 estratégias sempre que foi necessário, mantendo a equipe focada no objetivo. Na Revisão do Sprint foi apresentado ao Product Owner os resultados obtidos no Sprint. O Product Owner deu o seu feedback, aprovando o que foi entregue e solicitando a continuação do projeto. Na Retrospectiva do Sprint foi avaliado o que deu certo e o que deu errado durante o Sprint, também foi reforçado o comprometimento do Team com o projeto e com as práticas do SCRUM. Mas apesar de todo o envolvimento da maior parte do Team e dos Stakeholders, além do incentivo e apoio de outros membros do projeto, os próprios componentes do Team apresentaram descontentamento com o comportamento de alguns dos seus integrantes. Este descontentamento foi colocado por parte do Team aos dois consultores, que por sua vez sugeriram dar uma nova oportunidade aos mesmos no novo Sprint. A sugestão foi prontamente atendida. D. Segundo Sprint Entre o primeiro e segundo Sprint houve um recesso de dois dias, sendo assim o segundo Sprint teve inicio no dia 14 de Abril de 2010 com finalização prevista para o dia 27 de Abril de No segundo Sprint um novo membro foi aprovado e incorporado ao Team. O Sprint Backlog montado no Planejamento do Sprint compreendia quatro itens do Product Backlog. Dois itens tinham apenas uma tarefa, o terceiro item era composto por duas tarefas e o quarto item composto por três tarefas. As Reuniões Diárias foram mantidas, mesmo sem a presença constante de dois componentes. Mas apesar das reuniões e esforços, no final do Sprint o Team deixou de entregar duas tarefas. Mesmo sem ter concluído todas as tarefas, na Revisão do Sprint foi apresentado ao Product Owner os resultados obtidos pelo Sprint, este por sua vez aprovou o que foi entregue e novamente solicitou a continuação do projeto. Na Retrospectiva do Sprint foi colocado o que deu certo e o que havia falhado. Também foi colocado na retrospectiva o não comprometimento dos dois membros do Team e que este comportamento afetou o Sprint. Foi exposto que embora todos conhecessem os valores e princípios do SCRUM, os dois membros estavam ignorando esses valores e princípios. Por fim, foi levantada a pontualidade e presença de todos os membros do Team no inicio das tarefas e nas Reuniões Diárias. E. Terceiro Sprint Novamente houve um recesso de dois dias entre os Sprints. O terceiro Sprint iniciou no dia 03 de Maio de 2010 com previsão de finalização para o dia 14 de Maio de A partir deste Sprint o Team contava com apenas quatro componentes, os outros dois que não haviam se comprometido abandonaram de vez o projeto. Outra alteração importante foi a mudança do Scrum Master, este papel foi passado a um dos membros do Team. Com a mudança este componente faria parte do Team e também seria o Scrum Master. O antigo Scrum Master foi integrado ao grupo de consultores do projeto. No Planejamento do Sprint foi definido que o Sprint Backlog seria composto por quatro itens do Product Backlog. O primeiro item era composto por apenas uma tarefa, o segundo item continha onze tarefas, o terceiro item contava com quatro tarefas e o quarto item com nove tarefas. Além das novas tarefas, foram incluídas as duas tarefas inacabadas do Sprint anterior. Com o Team unido e totalmente comprometido, as Reuniões Diárias passaram a ser decisivas para finalizar as tarefas até o final do Sprint. Apesar de todo o comprometimento e esforços, o Team não concluiu três das vinte e sete tarefas. Estes números foram apresentados na Revisão do Sprint, além dos resultados obtidos no Sprint, para que o Product Owner ficasse ciente do andamento do projeto. O Product Owner não se mostrou preocupado e solicitou a continuação uma vez que, apesar do atraso, o projeto estava dentro do prazo de entrega. A Retrospectiva do Sprint mostrou que o Team havia sido audacioso, e por este motivo não foi possível entregar todas as tarefas. Mas apesar desta falha, os acertos foram bem maiores que nos outros dois Sprints, parte devido ao aprendizado adquirido, parte devido ao comprometimento e esforços de todos os componentes remanescentes do Team. F. Quarto Sprint O quarto Sprint foi inicializado no dia 17 de Maio de 2010 e com finalização prevista para o dia 28 de Maio de O Sprint Backlog definido a partir do Planejamento do Sprint continha doze itens do Product Backlog. Mais uma vez o Team criou um Sprint ousado, pois os dozes itens eram compostos por trinta e seis tarefas, além das três tarefas não cumpridas no Sprint anterior, mas eles estavam bastante comprometidos e envolvidos, desta maneira o Sprint Backlog foi fechado com os doze itens e as trinta e nove tarefas. A medida que aconteciam as Reuniões Diárias foi ficando claro que não seria possível entregar alguns itens e tarefas devido motivos variados. Um item, com duas tarefas, relacionado a integração com uma rede social não seria entregue devido problemas com a API (Application Programming Interface Interface de Programação de Aplicativo) de integração disponibilizada pela rede social ser complexa. Na Revisão do Sprint foi apresentando ao Product Owner os resultados obtidos no Sprint, também foi informado que além das duas tarefas do item de integração com a rede social, outras quatro tarefas não foram concluídas, sendo que duas das tarefas dependiam de ações do cliente para que o Team as concluísse. A apresentação do Sprint foi concluída com a solicitação do Team para criar um Sprint apenas de correções de erros. A solicitação foi bem aceita e aprovada pelo Product Owner. Na Retrospectiva do Sprint o Team apresentou o que havia dado certo, mas se concentrou em como evitar finalizar o Sprint com tarefas inacabadas. Após discutir o que havia dado erro, dois pontos foram apresentados como responsáveis pelas tarefas inacabadas: Não houve tempo suficiente para estudar a API de integração com a rede social devido o excesso de tarefas do Sprint. A dependência de ações do cliente no Sprint é um ponto crítico que deve ser mais bem gerenciado pelo Team.

5 G. Sprint de Correções de Erros Na Revisão do Sprint anterior o Product Owner concordou com a instituição de um Sprint para correções de erros. Antes de iniciar este Sprint houve um recesso de dois dias. O Sprint teve inicio no dia 02 de Junho de 2010, com finalização prevista para o dia 07 de Junho de Nenhum item do Product Backlog foi incluído no Sprint Backlog, o único item existe era o de correções de erros. Este item continha vinte e oito tarefas. Foram mantidas as Reuniões Diárias e no final do Sprint vinte e cinco das vinte e oito tarefas haviam sido concluídas. O que foi um resultado bom, pois 89% dos erros foram corrigidos num Sprint de quatro dias. Os resultados foram apresentados ao Product Owner durante a Revisão do Sprint. O Product Owner informou que o Team deveria apresentar o produto a vários Stakeholders num evento que aconteceria na sede do Geopark Araripe. Na Retrospectiva do Sprint o Team analisou os acertos e erros do Sprint, discutiram o que poderia ser feito para aprimorar os processos adotados e minimizar os erros e dificuldades encontrados. H. Sem Sprint e Sem Entregas Após o Sprint de correções de erros o Team combinou que terminaria as tarefas restantes do Product Backlog, mas não existiu o Planejamento do Sprint, apenas uma promessa do Team que os itens restantes e suas tarefas seriam feitas. Ficou combinado desta maneira, porque os itens restantes e suas tarefas eram menores do que os existentes nos Sprint Backlog anteriores. Assim, sem um Sprint planejado, as Reuniões Diárias foram negligenciadas e até desconsideradas. Sem planejamento, o Team não se comprometeu da maneira como aconteceu anteriormente. Como estava existindo problemas com o servidor que iria hospedar o site, o Product Owner não cobrou as tarefas pendentes ao Team. Até a penúltima semana de Julho de 2010 a equipe ainda não havia concluído as tarefas pendentes. Neste ponto os consultores do projeto pediram ao Team para retomarem as boas práticas dos SCRUM. I. Sprint Final Com o intuito de concluir as tarefas inacabadas, o Team iniciou o Sprint final no dia 26 de Julho de 2010 com previsão para o dia 30 de Julho de No Planejamento do Sprint, os três itens que ainda existiam no Product Backlog foram incluídos no Sprint Backlog. Esses itens eram compostos por sete tarefas. As Reuniões Diárias voltaram a acontecer, o comprometimento e a interações entre os membros do Team voltaram a existir. Na Revisão do Sprint foi apresentando ao Product Owner os resultados obtidos no Sprint, ficando acertado que nesse ponto o projeto estava concluindo, e que seria iniciada a fase de manutenção do produto. Na Retrospectiva do Sprint o Team analisou os acertos e erros, fazendo um levantamento sobre o que poderia ser aperfeiçoado em projetos futuros. III. CONCLUSÃO A utilização da modelagem e frameworks ágeis algumas vezes é criticada, pois é colocado que uma equipe só consegue pôr os princípios e valores ágeis em prática quando a equipe é auto-gerenciável, e para uma equipe ser auto-gerenciável ela precisa ser experiente. Este estudo de caso mostrou que o auto-gerenciamento pode ser conseguido através do real compromisso de todos que fazem parte do projeto. A experiência pode ser adquirida com o tempo, mas passar por dificuldades de maneira eficaz e eficiente só é possível com a seriedade e união dos envolvidos na equipe. Outro ponto a ser mencionado é a importância em transformar o conhecimento dos valores e princípios ágeis em ações reais. Pessoas que conhecem os princípios e valores ágeis, mas não aceitam passar por mudanças, por incapacidade de mudar ou por falta de humildade, transforma o conhecimento em demagogia inútil. Conhecer todos os aspectos de um assunto de nada serve se não for possível aplicá-los de maneira correta e coerente. Para quem acompanhou o estudo de caso de perto percebeu que: A suplantação do EU em pró do NÓS foi o principal responsável pelo sucesso do projeto. Humildade e união foram mais importantes que conhecimentos preexistentes. O SCRUM também funciona com equipes inexperientes. REFERÊNCIAS [1] MARTINS, José Carlos Cordeiro. Técnicas para Gerenciamento de Projetos de Software, Rio de Janeiro, Brasport, [2] KNIBERG, Henrik. Scrum e XP direto das Trincheiras: Como nós fazemos Scrum, Agosto de [3] AMBLER, Scott W. Modelagem Ágil: Práticas eficazes para a Programação Extrema e o Processo Unificado. Porto Alegre, Bookman, [4] BECK, Kent. Programação Extrema Explicada: Acolha as Mudanças. Porto Alegre, Bookman, [5] BERKUN, Scott. A Arte do Gerenciamento de Projetos. Porto Alegre, Bookman, [6] MARTINS, José Carlos Cordeiro. Técnicas para Gerenciamento de Projetos de Software. Rio de Janeiro, Brasport, [7] SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo, Pearson Addison Wesley, 2007.