Gerenciamento Ágil de Projeto de Software Yvson Paulo Nascimento Ferreira¹, Cleide Tavares Bittencourt Santos¹ ¹Universidade do Estado da Bahia, Campus II. yvpaulo@yahoo.com.br, cleidetb2002@yahoo.com.br Resumo: Ao longo do tempo o desenvolvimento de software evoluiu acompanhando e impulsionando o próprio desenvolvimento da humanidade, a maneira de desenvolver também teve que evoluir para acompanhar esse desenvolvimento, várias metodologias foram então criadas e recriadas nesse intervalo de tempo, e para acompanhar tanta evolução surgem as metodologias ágeis, e é sobre essas metodologias e como as equipes de desenvolvimento de software podem utiliza-las de forma realmente ágil que esse artigo se propõe a discorrer. Palavras chaves: Metodologia, Ágil, Equipes de Desenvolvimento, Software Abstract: Over this time the development of software monitoring and driving the development of humanity itself, the way to develop also had to evolve to keep up with this development, many methodologies were then created and recreated in this meantime, and to follow much evolution agile methodologies came up, and it is about these methodologies and how the software development teams can use them really fast so that this article intends to discuss. Keywords: Methodology, Agile, Development Team, Software 1. Introdução O século 21 é marcado pelo grande avanço tecnológico e pela grande velocidade da criação, tratamento e transmissão das informações que essa tecnologia proporcionou, toda essa velocidade aparentemente acelerou o mundo, pois as pessoas não querem esperar por nada, esperar 2 minutos para abrir um site na internet é considerado um absurdo, esperar um dia para receber uma mensagem pelo correio eletrônico é intolerável, esperar um ano para ter um novo sistema de informação sem defeito e que atenda as necessidades de uma empresa pode significar desde a perda de clientes até a falência de uma empresa. Nos primórdios do desenvolvimento de sistemas informatizados tais problemas ficaram bem visíveis, pois não existia uma metodologia para desenvolver softwares. Grande parte dos desenvolvedores usavam a filosofia de fazer e depois concertar, além de que não existiam ferramentas apropriadas para teste de software, bem como prevalecia a imagem do programador solitário, porém os erros na fase de desenvolvimento acarretaram problemas que só cresciam com o passar do tempo e
o aumento do uso de sistemas informatizados nas empresas o que acarretou uma verdadeira crise do software, com programas defeituosos cuja manutenção era complicada, cara e demorada. Surgiram então os primeiros ensaios de metodologias conhecidos como métodos convencionais e mais tarde as metodologias estruturadas que davam muita ênfase a documentação, passando do nada do planejamento para a excessiva documentação, por isso tais metodologias ficaram conhecidas como metodologias pesadas ou orientadas a documentação. Tais metodologias surgiram em um contexto de desenvolvimento baseados nos velhos mainframes e terminais burros, onde ainda era dada pouca ênfase ao planejamento e praticamente não existiam ferramentas de apoio ao desenvolvimento como depuradores e analisadores de software, por conta disso o software tinha que ser todo documentado e planejado antes de ser implementado. As metodologias tradicionais foram muito úteis em seu tempo e um grande avanço, porem nos ligeiros tempos atuais elas causam muitas vezes um verdadeiro emperramento no processo quando utilizadas na integra, não agradando aos apressados clientes e suas necessidades urgentes. Por conta de tanta pressa as equipes de desenvolvimento têm que ser cada vez mais ágeis, ágeis para desenvolver, para testar, para implantar e sobretudo agradar os clientes satisfazendo suas necessidades. Para tanto as técnicas de gerencia de projeto utilizadas têm que se adaptar aos tempos atuais, nesse cenário surge a proposta de desenvolvimento com metodologias ágeis com o intuito de dar conta do recado, porem o que são realmente essas metodologias e como implementá-las no gerenciamento de projetos tornando uma equipe de projetos realmente ágil? O problema supracitado nos leva a considerar as seguintes hipóteses: Devido as incompatibilidades das metodologias tradicionais frente aos desafios atuais para as equipes de projeto e a flexibilidade das metodologias ágeis pode-se dizer que as metodologias ágeis constituem um passo importante para responder os dilemas atuais do desenvolvimento de software; A implantação de metodologias ágeis em equipes de projeto de software proporciona aumento da produtividade e qualidade no desenvolvimento de software; Graças a estrutura dessas metodologias que se baseiam no ciclo de vida interativo incremental acabam proporcionando a equipe e ao cliente uma avaliação mais precisa do progresso do desenvolvimento;
2. Breve histórico do desenvolvimento de software. Desde quando foi construído o primeiro computador até os dias atuais o potencial dessa nova tecnologia para auxiliar os seres humanos nas mais diversas áreas parece não parar de crescer, com tal evolução tanto da parte física, hardware, quanto da parte logica, software, do computador as complexidades dessa tecnologia também aumentaram. Desde o início do desenvolvimento de software prevalece o princípio codificar e concertar (Fowler) o que acaba tornando essa atividade bastante caótica principalmente quando o software é escrito sem nenhum planejamento, isso faz com que a medida que o sistema vai crescendo fique cada vez mais difícil ou até impossível a incorporação de novas funcionalidade. Defeitos subsequentes se tornam cada vez mais dominantes e cada vez mais difíceis de serem eliminados. Um sinal típico de um sistema desse tipo é uma longa fase de testes depois que o sistema está "pronto". Esta longa fase de testes entra em confronto direto com o cronograma, pois testes e depuração são atividades cujos tempos são impossíveis de serem estimados (Fowler). 2.1 Criação da Engenharia de Software. Como o software se tornava cada vez mais importante chegando ao ponto de seu funcionamento correto ou incorreto ser a diferença entre a vida e a morte de pessoas surgiu então a Engenharia de Software no intuito de disciplinar o seu desenvolvimento. A Engenharia de software é uma disciplina que reúne metodologias, métodos e ferramentas a ser utilizadas, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software. O objetivo da Engenharia de software é auxiliar no processo de produção de software, de forma que o processo dê origem a produtos de alta qualidade, produzidos mais rapidamente e a um custo cada vez menor. A Engenharia de software segue o conceito de disciplina na produção de software, fundamentado nas metodologias, que por sua vez seguem métodos que utilizam de ferramentas automáticas para englobar as principais atividades do processo de produção(leite). 2.2 As Primeiras Metodologias
Mas a Engenharia de Software não surgiu do dia para noite com uma solução mágicas para o problemas de desenvolvimento, e ao longo de seu percurso várias metodologias foram empregadas. As primeiras a serem adotadas ficaram conhecidas como metodologias tradicionais ou pesadas tendo o modelo clássico como seu principal representante. É um modelo em que existe uma sequência a ser seguida de uma etapa a outra. Cada etapa tem associada ao seu término uma documentação padrão que deve ser aprovada para que se inicie a etapa imediatamente posterior. De uma forma geral fazem parte do modelo Clássico as etapas de definição de requisitos, projeto do software, implementação e teste unitário, integração e teste do sistema, operação e manutenção (Soares). Esse modelo que também ficou conhecido como modelo cascata foi um grande passo, porém apresentou seus problemas como sua inflexibilidade na divisão do projeto em fases distintas, o que dificulta possíveis alterações que são comuns no desenvolvimento de um projeto. (Soares) Outra característica problemática dessas metodologias foram as documentações excessivas. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros [Royce (1970)]. Na época, o custo de fazer alterações e correções era muito alto, uma vez que o acesso aos computadores eram limitados e não existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Por isso o software era todo planejado e documentado antes de ser implementado(soares). Vários estudos foram realizados para verificar a viabilidade dessas metodologias no desenvolvimento de software e seus resultados não foram animadores. Segue um trecho deste estudo segundo Soares(2010): Em um estudo realizado no Reino Unido com 1.027 projetos de TI, foi identificado que apenas 13% deles não falharam (THOMAS, 2001). Em outra pesquisa realizada com aproximadamente 23.000 projetos de software, mostrou-se que em 1998 26% dos projetos foram concluídos dentro do prazo, orçamento e escopo, 46% tiveram de sofrer algum tipo de alteração para serem concluídos (aumento de orçamento, prazo ou redução de escopo) e 20% dos projetos falharam (JOHNSON et. al, 1998). 3. O Manifesto Ágil. Apesar dos problemas, a revolução tecnológica continuou avançando, principalmente com o surgimento da internet, o que alavancou ainda mais esse
avanço. A dependência da humanidade dos softwares e os constantes problemas no seu desenvolvimento motivaram um grupo de dezessete pessoas, referências mundiais em desenvolvimento de software, a se reunirem em novembro de 2001 para entre outras coisas discutirem como reverter a situação. Dessa reunião surgiu um documento que ficou conhecido como o Manifesto Ágil. Neste texto são encontrados princípios básicos das metodologias ágeis tais como: indivíduos e interações são mais importantes que processos e ferramentas. software funcionando é mais importante do que documentação completa e detalhada. colaboração com o cliente é mais importante do que negociação de contratos. adaptação a mudanças é mais importante do que seguir o plano inicial. É importante frisar que O Manifesto Ágil não rejeita os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária quando comparado com os indivíduos e interações, com o software estar executável, com a colaboração do cliente e as respostas rápidas a mudanças e alterações.(manifesto Ágil). Esses fatores proporcionam dinamismo para o desenvolvimento, motivação para o time e informações mais precisas sobre a verdadeira situação do projeto para o cliente (Sato). As metodologias ágeis não são uma teoria fundamentada sobre o assunto, mas sim um conjunto de práticas que giram ao redor dos princípios acima. Essas metodologias são altamente adaptativas, mas as principais práticas são conhecidas como Scrum(1986), Crystal Clear, Programação extrema (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (1995). 4. Principais Métodos Ágeis Existe uma palavra que esta profundamente ligada com a metodologia ágil, e a palavra é adaptabilidade, isto é fácil de entender visto que a proposta ágil é atender clientes com necessidades em constante mudança, tendo isto em vista fica claro que as metodologias ágeis não poderia ser um arcabouço fechado de técnicas,
mas como foi relatado anteriormente trata-se de um conjunto de praticas, tais práticas surgiram não apenas fruto de teorização, mas das necessidades encontradas em projetos de desenvolvimento, como também foi mencionado anteriormente vários conjuntos de práticas que se encaixavam na metodologia ágil foram agrupadas e receberam nomes específicos, desses nomes serão apresentadas abaixo algumas características principais de dois deles, o XP e o Scrum, por serem os mais utilizados atualmente. 4.1 Extreme Programming (XP) XP é uma metodologia baseada em valores e práticas criada por Kent Baeck em 1996 durante o projeto Daimler-Chrysler que consistia em um projeto de folha de pagamento que já havia fracassado utilizando outras metodologias. XP foi uma das primeiras metodologias ágeis que teve sucesso, fez tanto sucesso que alguns confundem Modelagem Ágil com XP. XP é uma metodologia ágil, mas as metodologias ágeis são muito mais do que XP. Um dos fatores de sucesso do XP se deve ao alto grau de satisfação do cliente e cliente satisfeito é um dos melhores indicativos de sucesso no projeto, isso ocorre porque essa metodologia foi criada para produzir o software que o cliente precisa quando ele é necessário. Além disso, XP possui uma natureza simples e objetiva por se basear em práticas que já provaram sua eficiência em diversos projetos de desenvolvimento de software, essas práticas têm como objetivo entregar funcionalidades de forma rápida e eficiente ao cliente. Outro fator de sucesso é que XP foi criado considerando que mudanças são inevitáveis e que devem ser incorporadas constantemente. Existe uma pergunta no XP cuja resposta é a base dessa metodologia, a pergunta é: Se todos na equipe se concentrarem naquilo que é realmente importante para a equipe, em que devem se concentrar? A resposta são os valores do XP: Simplicidade Comunicação Feedback Coragem
Simplicidade: Foi observado que muitas funcionalidades implementadas em um software são pouco utilizadas, então XP diz, faça somente o necessário, tente sempre desenvolver as soluções mais simples. Comunicação: A comunicação é a chave para o sucesso, deve existir um canal aberto de comunicação entre a equipe de desenvolvimento e os usuários. Esse canal de comunicação preferencialmente será o diálogo cara a cara, o uso de e-mail ou de telefone deve ser evitado para minimizar os ruídos da comunicação. Feedback: Quanto mais cedo se descobre um problema, menos prejuízo ele pode causar, por isso existem testes constantes na menor quantidade de funcionalidades possível, os programadores devem escrever casos de testes e os clientes obtêm feedbacks através de testes funcionais criados para todas as estórias. Coragem: É preciso de coragem para mudar o código ou jogá-lo fora quando o mesmo está funcionando e o cliente pede para fazer alguma modificação que tornaria o projeto mais adequado para ele, porém esse é o preço a ser pago se XP quer realmente ser aberto a mudanças. Nem só com valores se faz XP. De acordo com o Professor Wilson C. Savegnago os valores indicam o propósito, aquilo em que se acredita, a razão pela qual as pessoas agem de certa forma. Práticas, por sua vez, são as ações. Normalmente são específicas, enquanto princípios são genéricos e mais vagos. Princípios, por sua vez, procuram clarificar os valores dentro do contexto de desenvolvimento de software. Essa tríade valores-princípios-práticas traduz o XP. Princípios existem para servir de ponte entre valores e práticas. Princípios servem como guias que se aplicam a um domínio específico. XP possui práticas que consistem no núcleo principal do processo e que foram criadas com base nos ideais pregados pelos valores apresentados anteriormente. Tais práticas representam o que a equipe fará diariamente quando usar o XP, a aplicação dessas práticas depende da situação, se a situação muda, pode-se selecionar práticas diferentes para abordar essas condições. Algumas delas são explanadas abaixo. Cliente presente: O cliente tem um papel importante dentro de um projeto XP já que ele conduz o desenvolvimento escrevendo as estórias(casos de uso simplificados) e priorizando-as.
O jogo do planejamento: O planejamento de um release e das iterações é feito com base nas estórias e conta com a colaboração de toda a equipe de desenvolvimento, inclusive o cliente. No jogo, as estórias são estimadas para que o cliente conheça o custo da sua implementação. Stand up meeting: Reuniões curtas, feitas geralmente pela manhã com todos em pé onde se avalia o trabalho do dia anterior e se prioriza as atividades do dia. Programação em pares: Todo o código produzido em XP é escrito por um par de programadores, que possuem papéis distintos, sentados lado-a-lado e olhando para o computador. Um parceiro será responsável pela codificação e pensará nos algoritmos e na lógica de programação. O outro parceiro observa o código produzido e tenta pensar mais estrategicamente em como melhorá-lo e tornálo mais simples, além de apontar possíveis erros e pontos de falha. Além disso, as duplas são constantemente trocadas e os papéis também com o objetivo de que todos os membros da equipe possam ter conhecimento sobre todas as partes do sistema. Desenvolvimento orientado a testes: Os testes em XP são feitos antes da programação. Existem dois tipos de teste: teste de unidade e teste funcional. Os testes de unidade são feitos para verificar tudo que possa dar errado. Não é preciso escrever testes de unidade para todos os métodos. Os testes unitários são automatizados, e toda vez que o programador escrever código, ele irá verificar se o sistema passa em todos os testes. Os testes funcionais são usados para verificação, junto ao cliente, do sistema como um todo. Os testes servem como um mecanismo para assegurar que o sistema está sempre rodando livre de erros, e também servem para dar feedback aos programadores e clientes sobre as falhas encontradas. Refatoramento: São constantes melhorias no projeto do software para aumentar sua capacidade de se adaptar a mudanças. O refatoramento consiste em aplicar uma série de passos, para melhorar o projeto do código existente, tornando-o mais simples e melhor estruturado, sem alterar sua funcionalidade. Propriedade coletiva do código: A propriedade coletiva encoraja a equipe inteira a trabalhar mais unida em busca de qualidade no código fazendo melhorias e refatoramentos em qualquer parte do código o a qualquer tempo. A princípio podese pensar que esta prática possa gerar problemas, mas como todos devem respeitar um padrão de codificação e devem realizar todos os testes para verificação de erros
esta atividade é feita de uma forma controlada e pode ser facilitada com o uso de uma ferramenta de controle de versão. Releases pequenos: Cada release deve ser tão pequeno quanto possível (dois ou três meses), contendo os requisitos mais importantes para o negócio. Isso possibilita ter releases frequentes o que resulta em maior feedback para clientes e programadores, facilitando o aprendizado e a correção dos defeitos do sistema. Ritmo sustentável: 40 horas semanais, nada de fazer hora extra. Integração contínua: O código das funcionalidades implementadas pode ser integrado várias vezes ao dia. Testes são rodados a cada integração. Padrões de codificação: Como XP prega a propriedade coletiva de código, onde todos podem alterar e fazer refatoramento de qualquer parte do código a qualquer momento, então é mais do que necessário que se tenha padrões de codificação. O objetivo é que todos programem da mesma forma, facilitando o entendimento do código e as alterações. 4.2 Scrum É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. (Ken Schwaber e Jeff Sutherland). O Scrum em alguns aspectos se assemelha ao XP, porem enquanto XP está mais voltado para a programação, Scrum está mais ligado a gerencia do projeto. O cliente também tem um papel fundamental no Scrum, é ele quem decide o que deve ser feito, de maneira semelhante a XP são escritas estórias que se limitam a uma funcionalidade do sistema, estas estórias depois são estimadas em valor de negocio pelo cliente, e em valor de esforço para a equipe, o que vai ditar quais estórias são feitas primeiro é o valor que o cliente deu, assim as estórias com valores mais altos são feitas primeiro, a equipe porem define quantas estórias podem fazer em um Sprint (iteração de duração fixa), assim a cada Sprint um determinado grupo de funcionalidades que são de maior importância para o cliente vão sendo concluídas, cada iteração tem um objetivo bem definido e deve produzir uma versão potencialmente entregável (Dias, 2010) do software. Essas estórias iniciais são escritas em uma reunião denominada Story Writting Workshop, nessa primeira reunião, a partir da quantidade de histórias dadas pelo cliente e pela estimativa da equipe, pode-se ter uma boa ideia de quanto tempo
durará o projeto e o custo do mesmo em horas trabalhadas. Mas como Scrum também é aberto a mudanças essa estimativa pode e normalmente vai sofrer alterações, contudo como o cliente faz parte da equipe ele ficará imediatamente a par de quanto custará determinada mudança requerida por ele. Nesta primeira reunião a equipe também começara a conhecer o negócio do cliente e suas necessidades, também poderá ter uma primeira visão do que será o produto e até dar sugestões ao cliente, nesta ocasião também será criado o Backlog, ou seja o conjunto de funcionalidades que definirá o escopo inicial do projeto. Alguns papéis também devem ser definidos no Scrum, um papel de grande importância é o Scrum Master, normalmente um membro da equipe com bastante experiência, ele conduzirá as reuniões, não como um ditador, mas como um moderador, ele também não é exatamente o gerente de projeto, mas ele tomará a frente da equipe servindo muitas vezes de escudo entre a equipe e as interferências externas. Ele deverá providenciar o ambiente e as melhores condições possíveis para que a equipe desenvolva sem interrupções, também garantirá que a equipe se adeque aos valores e praticas do Scrum, ele não gerencia a equipe, pois a mesma deve ser auto gerenciável. O próximo passo no Scrum é a Reunião de planejamento, nesta as estórias são melhor detalhadas pelo cliente e é feita uma reestimativa do que foi apresentado, o objetivo do Sprint é definido pela equipe que assume um compromisso de entrega com o cliente. Uma segunda reunião de planejamento ainda deve ser realizada, nesta reunião as estórias são decompostas em uma lista de tarefas chamada de Backlog do Sprint, a equipe então se auto organiza e se responsabiliza pelo trabalho contido no Backlog. Após a decomposição as tarefas são estimadas em horas. Uma definição de pronto é dada para cada conjunto de funcionalidades para garantir que o Sprint Backolg satisfaça o cliente. Depois do planejamento vem a execução ou fase de implementação onde os requisitos são transformados em produtos com base nos artefatos e informações obtidas, se surgir alguma duvida o cliente deve ser imediatamente chamado. Nesta fase deve haver reuniões diárias onde o quadro de acompanhamento é atualizado e informam brevemente seus problemas e seu progresso, as Stand Up Meeting são usadas assim como no XP.
Em seguida a implementação é realizada uma Review para entrega do produto onde o cliente identifica o que foi feito e o que não foi, a equipe então discute sobre o que ocorreu bem durante o Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos. A revisão fornece boas entradas para as reuniões de planejamento de Sprints que virão. Por fim uma retrospectiva é feita com o objetivo de aprender com o que foi vivido e analisar o que foi feito corretamente para repetir e debater o que não funcionou bem para corrigir. São definidas ações corretivas e as mesmas são priorizadas e prazos são definidos para essas correções. Assim em um ciclo iterativo incremental as etapas do Scrum vão sendo repetidas até a finalização do projeto. 5. METODO DE PESQUISA Para esta pesquisa foi utilizado o estudo de natureza bibliográfica para fundamentação teórica e exploratória para estudo de campo, onde através do levantamento de dados foi possível identificar os fatores que influenciam o sucesso de equipes de projetos que utilizam metodologias ágeis. A metodologia utilizada para esta pesquisa foi de Amostra Não-Probabilística por escolha, na qual os elementos da amostra foram escolhidos por esperar que possam responder adequadamente aos objetivos da pesquisa. Os dados foram coletados através de um estudo de caso realizado em uma Empresa Junior denominada TecnoSystem que é uma empresa junior do curso de Analise de Sistemas da UNEB Campus II. O universo considerado para este projeto foi de equipes de projetos que atuam com desenvolvimento de software em empresas juniores. O acompanhamento de uma projeto na empresa Junior escolhida para este estudo de caso proporcionou argumentos que serviram de base para expor as contribuições que o gerenciamento ágil de software oferece para o bom andamento da equipe e sucesso no projeto de desenvolvimento de software.
6. Estudo de caso Para melhor entender a aplicação do gerenciamento ágil em equipes de desenvolvimento de Software e analisar os resultados de sua aplicação foi realizado um estudo de caso em uma Empresa Junior. Essa empresa foi selecionada pela facilidade de acesso as informações e por se tratar de uma empresa que apesar de ser uma empresa Junior, esta em constante crescimento e tem uma boa aceitação na prestação de serviços de TI na cidade. O projeto selecionado para realizar este estudo foi o desenvolvimento de um sistema para uma empresa que trabalha com concursos públicos, esse sistema atenderia a empresa viabilizando a inscrição on-line dos candidatos, bem como proporcionar aos mesmos acesso as informações do concurso, por sua vez os administradores do sistema poderiam obter informações gerenciais dos concursos e alimentar as informações do sistema. Esse projeto era divido em duas partes bem distinta, a primeira deveria ser o desenvolvimento de um sistema WEB para inscrição e um sistema desktop para informações gerenciais. A equipe contava com quatro colaboradores e dispunham de um prazo restrito, pois o sistema deveria estar pronto até a abertura do próximo concurso que a empresa realizaria. Como agravante a situação a equipe era inexperiente nas linguagens de programação que seriam utilizadas neste projeto e em desenvolver em equipe, no início a equipe não estava utilizando nenhuma metodologia formal, por conta desses agravantes os prazos não estavam sendo cumpridos e o cliente não estava satisfeito com o resultado do sistema desenvolvido. Nesse contexto a equipe foi submetida a uma mudança na sua forma de trabalho, passando a adotar práticas ágeis de desenvolvimento, foi utilizado uma mescla das práticas do Scrum e do XP. Do Scrum aproveitou-se as reuniões diárias com apresentação dos resultados e dificuldades anteriores, bem como as reuniões de planejamento, determinou-se também os Sprints, foi utilizado um software on-line que serviu para escrever as estórias e como quadro de organização do Scrum. O cliente passou a ter participação mais ativa no projeto sendo consultado a cada passo do desenvolvimento, também passou a ter feedbacks mais transparentes do andamento do projeto, inclusive sobre os novos prazos que foram estabelecidos juntamente com ele.
Do XP aproveitou-se a programação em pares, essas práticas ajudaram a equipe a ter um maior foco no projeto, e produzir mais, não apenas mais rápido, mas com melhor qualidade e de acordo as expectativas do cliente; Em resumo, com o emprego de práticas ágeis foi observado que a confiança do cliente na equipe de desenvolvimento aumentou e a autoestima da equipe também cresceu, o sistema começou a ser entregue de acordo as especificações do cliente e nos prazos estabelecidos. 7. Conclusão Este artigo abordou algumas características da Modelagem Ágil de Software e o seu emprego no gerenciamento de equipes de projeto, sendo que foi primeiramente relatado o contexto histórico em que surgiu essa metodologia para em seguida falar resumidamente sobre as principais práticas ágeis. Um estudo de caso foi realizado para observar os resultados do gerenciamento ágil em uma equipe de desenvolvimento. Algo que deve ser destacado dessa observação é que além do emprego dessas técnicas terem revitalizado o projeto e ter dado um direcionamento correto à equipe alinhando seus esforços aos interesses do cliente, essa equipe não era uma equipe experiente em desenvolvimento, pois era composta de graduandos que participavam de uma Empresa Junior e na literatura utilizada para formulação desse artigo existia sempre a observação falando sobre o uso das técnicas ágeis em equipes experientes. Mas através deste estudo pode ser observado que com algumas adaptações, tais práticas podem ser usadas em equipes menos experientes e com um grau de sucesso satisfatório. Outra conclusão é que as técnicas ágeis ajudam a equipe a focar mais nos fatores principais do projeto e proporcionam a mesma um plano de trabalho bem definido, também foi observado que o papel do Scrum Master nessa equipe foi de fundamental importância para a revitalização do projeto, a disciplina que as metodologias ágeis impõem a equipe permitiu que a equipe acelerasse o ritmo e a programação em par ajudou a encontrar soluções eficientes para as funcionalidades e apesar da equipe estar estudando e desenvolvendo conseguiu confeccionar um produto que agradou o cliente.
Concluído pôde-se observar que o gerenciamento ágil de software não é uma fórmula mágica que resolve qualquer problema, e também não se resume em um conjunto fechado de regras inflexíveis, mas sim um conjunto de valores, princípios e práticas que podem ser adaptadas para a realidade das equipes de desenvolvimento e de seus projetos, essas práticas ainda podem ser mescladas e reorganizadas ganhado uma nova dinâmica, contudo ainda se mantendo dentro dos princípios e valores da metodologia ágil, mas tais práticas exigem um grande esforço da equipe em se adaptar a essa realidade que muitas vezes difere totalmente do paradigma tradicional de desenvolvimento. Referência bibliográfica: DIAS, Sérgio Almeida. Gestão de Projetos de Software. Disponível em http://www.sergiodias.inf.br/engenharia-de-software/gestao-de-projetos-de-software. Acessado em 18/05/2010 Fowler, Martin. A Nova Metodologia. Disponível em: http://simplus.com.br/artigos/anova-metodologia/. Acessado em: 18/11/2010. FRANCO, Eduardo, Aplicando a Gestão Ágil de Projetos para o Desenvolvimento de Novos Produtos na Industria de Software. In ENEGEP. 26, 2006. Fortaleza, CE. LANDIM, Henrique, Scrum. In: LINGUAGIL. 2, 2010,Salvador. Leite, Alessandro Ferreira. Metodologia de Desenvolvimento de Software. Disponível em: http://www.devmedia.com.br/articles/post-1903-metodologia-dedesenvolvimento-de-software. Acessado em: 16/05/2010. Manifesto Ágil. Disponível em http://manifestoagil.com.br, acessado em 18/11/2010. PEREIRA, Paulo. Metodologias Ágeis. Recife: C.E.Z.A.R, 2008. 47, color. Sato, Danilo Toshiaki. Uso eficaz de métricas em métodos ágeis de desenvolvimento de software. Instituto de Matemática e Estatística da Universidade de São Paulo. 155 pgs. SOARES, Michel dos Santos Soares. Artigo Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software.Disponível em http://www.eps.ufsc.br/disserta99/selner/cap3.html. Acessado em 18/11/10