Metodologias Ágeis

INSTITUTO FEDERAL DEEDUCAÇÃO, CIÊNCIA E TECNOLOGIATOCANTINSCampus Araguaína

Metodologias Ágeis

DESENVOLVIMENTO ÁGIL APLICADO AOS PROJETOS DE SOFTWARE

ANA PAULA ALVES DE LIMA

2Técnicas e Projeto de Sistemas – Técnico Subsequente


Por que ser ágil?• Crescentes pressões do mercado por:

• Inovação, • Produtividade (prazos cada vez mais curtos),• Flexibilidade,• Melhoria no desempenho/qualidade dos projetos

de desenvolvimento de SW

• O ágil surgiu dado a necessidade de melhorarmos a forma como estamos desenvolvendo SW e nosso foco principal é satisfazer o cliente.



Quem usa isso?



História• 75 anos atrás

• IIDD – Desenho e desenvolvimento interativo e incremental• Aumentar satisfação do cliente• Evitar o desencorajamento da Gestão

• Década de 80• Aprimoramento da Engenharia de Software• Diversificação das linguagens de programação

• Década de 90• Maturação dos processos de desenvolvimento de Software• Semente dos modernos processos de Desenvolvimento Ágil

• 2001 - 17 especialistas se reúnem nos EUA para discutir modernas formas de se desenvolver Software• Estabelecida a Aliança Ágil• Manifesto Ágil

• Princípios comuns compartilhados por todos os métodos de sucesso aplicados pelos especialistas durante suas carreiras



Disponível em agilemanifesto.org



Guarda Chuva Ágil





Por que usar?



Por que usar?• Dos 63% restantes:

• 2/3 possuem problemas• Estouro de Prazo• Não atendem as necessidades• Estão cheio de defeitos

• 1/3 é um total fracasso• Cancelado/engavetado• Nunca colocado em produção ou utilizado pelo cliente

• Dos casos de sucesso, em geral apenas 20% das funcionalidades são realmente úteis.



Por que usar?• Suposições de início de projeto

• Os requisitos são 100% conhecidos e foram minuciosamente detalhados

• O Desenvolvedor sabe construir• Nada irá mudar ao longo do caminho

• Realidade que deve ser observada :• “Um processo rígido ou resistente a mudanças produz produtos

medíocres. Os clientes podem até receber o que eles solicitaram primeiramente, mas é esse o produto que eles realmente querem logo quando eles o recebem? Coletando todos os requisitos no início e escrevendo-os sobre pedra, o produto é condenado a ser tão bom quanto a idéia inicial, ao invés de ser o melhor uma vez que as pessoas aprendem ou descobrem como fazer melhor.” [Jeff Sutherland]

• Idéias, novas tecnologias e opções surgem no decorrer do projeto. Desta forma uma nova idéia não deveria ser mau vista pela equipe/gestor.

• Sim, as coisas mudam durante o caminho





SCRUM


Por que Scrum?“O Scrum não é um processo previsível, ele não define o quefazer em todas as circunstâncias” KEN SCHWABER (2004)

É um framework ágil leve que gerencia e controla o desenvolvimento do software aumentando a produtividade e reduzindo o tempo para obter excelentes resultados;

• Bastante objetivo • Papéis e Responsabilidades bem definidas• Fácil adaptação• Curva de aprendizado baixa• Não é um processo previsível• É um framework, um conjunto de práticas

O Scrum não vai dizer exatamente o que fazer, não irá resolvertodos os seus problemas, mas com certeza os problemas serão mais facilmente identificados.



Elementos do Scrum – EQUIPE DE ATÉ 6 PESSOAS

PAPÉIS• Product Owner• Scrum Master• Time

REUNIÕES ou CERIMÔNIAS• Sprint Planning • Daily Scrums• Sprint Review• Sprint Retrospective

ARTEFATOS• Product Backlog• Sprint Backlog• Burndown Chart



O que é Sprint• No Scrum, os projetos são divididos

em ciclos (tipicamente mensais) chamados de Sprints.

• O Sprint representa um tempo definido dentro do qual um conjunto de atividades deve ser executado.

• O trabalho é dividido em iterações, que no Scrum são chamadas de Sprints e geralmente duram de 2 a 4 semanas.





Papéis• Product Owner (PO)

• Define as funcionalidades do produto

• Define as datas dos releases

• Responsável pelo retorno do investimento (ROI) do projeto

• Prioriza as funcionalidades de acordo com seu valor de negócio

• Ajusta o product backlog a cada sprint, se necessário.

•Pode ser o representante de um cliente, ou o próprio cliente.



Papéis• Time

• Multi-disciplinar, com 7 (+-2) membros

• Define o Sprint e define como será feito o trabalho

• Tem o direito de fazer o que estiver ao seu alcance para alcançar o Sprint

• Auto-gerenciado: o time se organiza e se gerencia

• Demonstra o que foi feito para o Product Owner ao fim de cada Sprint



Papéis• Scrum Master • Responsável pelo processo,

incluindo a realização do Daily Scrum e datas e horários das reuniões

• Remove os impedimentos

• Garante que o time está sempre funcionando e produtivo

• Facilita a cooperação entre todos os membros do time

• Protege o time das interrupções externas



Reuniões - Sprint Planning• Sprint Planning

• Daily Scrum

• Sprint Review

• Sprint Retrospective

PLANEJAMENTO

• Entendimento do Escopo• Estimativas de complexidade• Definição do Sprint


Sprint Planning

O Sprint Planning Meeting é uma reunião na qual estãopresentes o Product Owner, o Scrum Master e todo o Time,bem como qualquer pessoa interessada que estejarepresentando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Ownerdescreve as funcionalidades de maior prioridade para aequipe. A equipe faz perguntas durante a reunião de modoque seja capaz de quebrar as funcionalidades em tarefastécnicas, após a reunião. Essas tarefas irão dar origem aoSprint Backlog.

Coletivamente, o Time e o Product Owner definem umobjetivo para o Sprint, que é uma breve descrição daquiloque se tentará alcançar no Sprint. O sucesso do Sprint seráavaliado mais adiante no Sprint Review Meeting em relaçãoao objetivo traçado para o Sprint.



• Sprint Planning

• Daily Scrum

• Sprint Review


3 PERGUNTAS

1. O que foi feito desde o último DS? 2. O que será feito hoje? 3. O que esta impedindo?

• Peer-pressure (em pé)• Máximo de 15 minutos• Comprometimento

Reuniões – Daily Scrum



• Sprint Planning

• Daily Scrum

• Sprint Review


DEMONSTRAÇÃO

• Apresentação das funcionalidades• Aceitação do Product Owner

Reuniões – Sprint Review



• Sprint Planning

• Daily Scrum

• Sprint Review

• Sprint Retrospective REVISÃO

• O que foi bom?• O que pode ser Melhorado?

Reuniões – Sprint Retrospective



Artefatos• Product Backlog

• Sprint Backlog

• Burndown Chart

http://www.flickr.com/photos/evandroflores/2060263276/in/set-72157603278334133/


Product Backlog

•O Backlog do Produto é uma lista contendo todas as

funcionalidades desejadas para um produto. O conteúdo desta

lista é definido pelo Product Owner.

•O Product Backlog não precisa estar completo no início de um

projeto. Pode-se começar com tudo aquilo que é mais óbvio em

um primeiro momento.

•Com o tempo, o Backlog cresce e muda à medida que se

aprende mais sobre o produto e seus usuários.

•A partir dele origina-se o Backlog do Sprint que é o que será feito

naquela tarefa.


Quadro de Acompanhamento – Sprint Backlog



Burn Down Chart• O Burndown é um simples gráfico, com dois eixos X e Y,

baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.


XP(EXTREME PROGRAMMING)

Pós-Graduação em Engenharia de Software

Metodologias Ágeis

Indivíduos e interações ao invés de processos e ferramentas

Software executável ao invés de documentação.

Colaboração do cliente ao invés de negociação de contratos.

Respostas rápidas a mudanças ao invés de seguir planos.

Software – Aperto de mãoCliente – Um abraçoGarra – GargalhadaBem Vindos - Palmas

O Garotinho chamado CLIENTE



O que é o XP?Metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90.

Produzidos em menos tempo e de forma mais econômica que o habitual.

Criar sistemas de melhor qualidade.

Identificou o que tornava simples e o que dificultava o desenvolvimento de software.



Como fazer?Pequeno conjunto de valores e práticas

• A Programação Extrema é uma das metodologias ágeis mais conhecidas e utilizadas na atualidade.

•Desenvolvidas para:• Equipes médias e pequenas

(2 a 12 pessoas);Baseada em cinco valores, alguns princípios e várias práticas que ocorrem no decorrer das atividades;



Comunicação

Coragem

Feedback

Respeito

Simplicidade



Comunicação

VS

Para que um projeto seja um sucesso é necessário muita interação entre as equipes:

programadores, clientes e treinador;



Coragem“A única constante em um projeto de

software é a mudança”

Alterar um código em produção sem causar bugs, com agilidade, exige

muita coragem e responsabilidade;



FeedbackQuanto mais cedo descobrimos um problema, menos prejuízos ele pode causar

As respostas às decisões tomadas devem ser rápidas

e visíveis.



RespeitoDá sustentação a todos os

demais valores

Todos têm a sua importância

dentro da equipe e devem ser

respeitados e valorizados.



SimplicidadeApenas aquilo que é claramente necessárioÉ um dos valores mais importantes. Normalmente o que o cliente quer é mais simples.

Papéis



ProgramadoresTreinador (ou coach)Acompanhador (ou

tracker)Cliente

Papéis...



ProgramadoresFoco central da metodologia, mas sem hierarquia.



Treinador (coach)Pessoa com experiênciano time, é responsável por lembrar aos outros das práticas e valores do XP.



Acompanhador (tracker)

Responsável por trazer informações que mostrem o andamento do projeto que ajudem a tomar decisões de implementação.



Cliente

O Cliente faz parte da equipe!!

Práticas



TestesRefatoração

Programação Pareada (em pares)Propriedade ColetivaIntegração ContínuaSemana de 40 horas

Cliente junto aos desenvolvedoresPadronização do código

Práticas...



TestesDesenvolvimento orientado a TestesOs testes devem ser escritos antes do desenvolvimento.



RefatoraçãoConjunto de técnicas para simplificar, melhorar o código!



Programação em Pares

Enquanto um programador digita, o outro observa, pensa em melhorias, alternativa.



Propriedade ColetivaO código é de todos e ninguém precisa de permissão para modificá-loNão pertence a um único programador.



Integração Contínua

Depois de testada, cada nova funcionalidade deve ser imediatamente sincronizada entre todos os desenvolvedores.



Semana de 40 horas

Trabalhar com qualidade

Programação não rende se o programador não estiver descansado e disposto.



Cliente juntoO cliente não é alguém de fora e sim um membro da equipe.



PadronizaçõesSe o time seguir padrões pré-definidos de codificação, mais fácil será manter e entender o que já está feito, reforçando a comunicação.



58

Métodos Ágeis Mais Conhecidos• FDD (Feature Driven Development):

• Metodologia ágil de desenvolvimento de software guiado por funcionalidades;

• Metodologia que combina as melhores práticas do gerenciamento ágil de projetos com abordagens completas para ES orientada por objetos;

• Seu lema é: "Resultados frequentes, tangíveis e funcionais."

TÉCNICAS E PROJETO DE SISTEMAS – TÉCNICO SUBSEQUENTE



ATIVIDADES• 1) Quais são as principais metodologias

ágeis? Cite três.• 2) Defina o que Scrum.• 3) Quais os principais elementos do

Scrum.• 4) O que é o XP?• 5) Quais seus valores;• 6) Cite os papeis da equipe;• 7) Cite as práticas.

Documents

Metodologias Ágeis