INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA TOCANTINS Campus Araguaína Metodologias Ágeis DESENVOLVIMENTO ÁGIL APLICADO AOS PROJETOS DE SOFTWARE

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;




Feedback

Quanto 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




Programadores

Treinador (ou coach)

Acompanhador (ou tracker)

Cliente

Papéis...




Programadores

Foco 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




Testes

RefatoraçãoProgramação Pareada (em pares)

Propriedade Coletiva

Integração Contínua

Semana de 40 horas

Cliente junto aos desenvolvedores

Padronizaçã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á-lo

Nã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 junto

O 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

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA TOCANTINS Campus Araguaína Metodologias Ágeis DESENVOLVIMENTO ÁGIL APLICADO AOS PROJETOS DE SOFTWARE