Desenvolvimento gil de software (do ingls Agile software development) ou Mtodo gil um conjunto de metodologias de desenvolvimento de software.

. O desenvolvimento gil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos deengenharia de software. Introduo Existem inmeros frameworks de processos para desenvolvimento de software. A maioria dos mtodos geis tenta minimizar o risco pelo desenvolvimento do software em curtos perodos, chamados de iterao, os quais gastam tipicamente menos de uma semana a at quatro. Cada iterao como um projecto de software em miniatura de seu prprio, e inclui todas as tarefas necessrias para implantar o mini-incremento da nova funcionalidade: planejamento, anlise de requisitos, projeto, codificao, teste e documentao. Enquanto em um processo convencional, cada iterao no est necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software gil busca a capacidade de implantar uma nova verso do software ao fim de cada iterao, etapa a qual a equipe responsvel reavalia as prioridades do projecto. Mtodos geis enfatizam comunicaes em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo gil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessrias para terminar o software: no mnimo, os programadores e seus clientes (clientes so as pessoas que definem o produto, eles podem ser os gerentes, analistas de negcio, ou realmente os clientes). Nesta sala devem tambm se encontrar os testadores, projectistas de iterao, redactores tcnicos e gerentes. Mtodos geis tambm enfatizam trabalho no software como uma medida primria de progresso. Combinado com a comunicao face-a-face, mtodos geis produzem pouca documentao em relao a outros mtodos, sendo este um dos pontos que podem ser considerados negativos. recomendada a produo de documentao que realmente ser til. [editar]Princpios Os princpios do desenvolvimento gil valorizam:

Garantir a satisfao do consumidor entregando rapidamente e continuamente softwares funcionais; Softwares funcionais so entregues frequentemente (semanas, ao invs de meses); Softwares funcionais so a principal medida de progresso do projecto; At mesmo mudanas tardias de escopo no projecto so bem-vindas.

Cooperao constante entre pessoas que entendem do 'negcio' e desenvolvedores; Projetos surgem atravs de indivduos motivados, entre os quais existe relao de confiana. Design do software deve prezar pela excelncia tcnica; Simplicidade; Rpida adaptao s mudanas; Indivduos e interaes mais do que processos e ferramentas; Software funcional mais do que documentao extensa; Colaborao com clientes mais do que negociao de contratos; Responder a mudanas mais do que seguir um plano.

O Scrum um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento gil de software. Apesar de a palavra no ser um acrnimo, algumas empresas que implementam o processo a soletram com letras maisculas como SCRUM. Isto pode ser devido aos primeiros artigos de Ken Schwaber, que capitalizava SCRUM no ttulo. Scrum no um processo prescribente, ou seja, ele no descreve o que fazer em cada situao. Ele usado para trabalhos complexos nos quais impossvel predizer tudo o que ir ocorrer. Apesar de Scrum ter sido destinado para gerenciamento de projetos de software, ele pode ser utilizado em equipes de manuteno de software ou como uma abordagem geral de gerenciamento de projetos/programas. Caractersticas Scrum um esqueleto de processo que contm grupos de prticas e papis pr-definidos. Os principais papis so: 1. o ScrumMaster, que mantm os processos (normalmente no lugar de um gerente de projeto) 2. o Proprietrio do Produto, ou Product Owner, que representa os stakeholders e o negcio 3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a anlise, projeto, implementao, teste etc.

Cada sprint uma iterao que segue um ciclo (PDCA) e entrega incremento de software pronto. Um backlog conjunto de requisitos, priorizado pelo Product Owner (responsvel pelo ROI e por conhecer as necessidades do cliente); H entrega de conjunto fixo de itens do backlog em srie de interaes curtas ou sprints; Breve reunio diria, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm chamado de Standup Meeting ou Daily Meeting, j que os membros da equipe geralmente ficam em p para no prolongar a reunio). Breve sesso de planejamento, na qual os itens do backlog para uma sprint (iterao) so definidos; Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

O Scrum facilitado por um Scrum Master, que tem como funo primria remover qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas), mas atua como um mediador entre a equipe e qualquer influncia desestabilizadora. Outra funo extremamente importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint. Scrum permite a criao de equipes auto-organizadas, encorajando a comunicao verbal entre todos os membros da equipe e entre todas as disciplinas que esto envolvidas no projeto. Um princpio chave do Scrum o reconhecimento de que desafios fundamentalmente empricos no podem ser resolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem emprica, aceitando que o problema no pode ser totalmente entendido ou definido, focando na maximizao da habilidade da equipe de responder de forma gil aos desafios emergentes. Uma das grandes vantagens do Scrum, porm, que no tem abordagem "receita de bolo" do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade atravs da aplicao de uma srie de processos prescritos. [editar]Product backlog e Sprint backlog Um backlog uma lista de itens priorizados a serem desenvolvidos para um software. O Product backlog mantido pelo Product Owner e uma lista de requisitos que tipicamente vm do cliente. OProduct Owner pode alter-lo a

qualquer momento, desde que os itens alterados no estejam na sprint. O Sprint backlog uma interpretao do Product backlog e contm tarefas concretas que sero realizadas durante o prximo sprint para implementar alguns dos itens principais no Product backlog. O Product backlog e o sprint backlog so, ento, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nvel e o segundo contendo informaes sobre como a equipe ir implementar os requisitos do produto. [editar]Planejamento de sprint Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe ir trabalhar durante o prximo sprint. O Product Owner mantm uma lista priorizada de itens debacklog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe ento planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto so ento destrinchados em tarefas que se tornam o backlog do sprint. [editar]Reunies Daily Scrum Cada dia durante o sprint, uma reunio de status do projeto ocorre. Isso chamado de "scrum dirio", ou "de p o dia". Esta reunio tem diretrizes especficas: A reunio comea precisamente no momento. Todos so bem-vindos, mas apenas "poucos" podem falar. O encontro timebox e dura 15 minutos. A reunio deve acontecer no mesmo local e mesma hora todos os dias Durante a reunio, cada membro da equipe responde a trs perguntas: - O que voc tem feito desde ontem? - O que voc est planejando fazer hoje? - Voc tem algum problema impedindo voc de realizar seu objetivo? papel do ScrumMaster para facilitar a resoluo desses impedimentos. Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a reunio possa durar menos de 15 minutos. Reunio de Planejamento da Sprint No incio do ciclo de sprint (a cada 7-30 dias), um "Sprint Planning Meeting" realizado. Selecione o trabalho que est a ser feito. Prepare o Sprint Backlog que detalha o tempo que levar para fazer esse trabalho, com toda a equipe. Identificar e comunicar o quanto o trabalho susceptvel de ser feito durante o sprint atual. Limite de tempo - Primeiras quatro horas = Team Product Owner: dilogo

para priorizar o Product Backlog. - Prximas quatro horas = Team apenas: hash de um plano para a Sprint, resultando na Sprint Backlog. No final de um ciclo de sprint, so realizadas duas reunies: a "Sprint Review Meeting" e do "Sprint Retrospective". Reunio de Reviso da Sprint: - Rever o trabalho que foi concludo e no concludo. - Apresentar o trabalho realizado para os interessados (ou "a demo"). Um trabalho incompleto no pode ser demonstrado. Retrospectiva da Sprint: - Todos os membros da equipe refletem sobre a sprint passada. - Faa melhorias contnuas de processos. Duas questes principais so feitas na retrospectiva do sprint: O que correu bem durante a corrida? O que poderia ser melhorado na prxima sprint?