Aulas-gil

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Desenvolvimento Ágil
Diana Braga
1
Bibliografia
Roger Pressman (Cap. 4)
Sommerville (Cap. 17)
2
ANOS 80
Ausência de metodologias de desenvolvimento
Programação procedural e estruturada
Programas são: sequência, decisão e iteração
3
ANOS 90
Linguagem UML
Processos unificados (UP)
Metodologias Orientadas a Objetos
Fases bem definidas e controladas
Analogia com a Engenharia Civil
4
Manifesto Ágil
2001
Envolvidos (Aliança Ágil)
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
5
5
Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
6
6
O que é o desenvolvimento ágil?
É uma filosofia e um conjunto de diretrizes que encorajam
A entrega incremental do software logo de início
Equipes de projeto pequenas e motivadas
Métodos informais de comunicação ao invés de documentos escritos
Enfatizar a entrega em contraposição à análise e ao projeto
Adotar o cliente como parte da equipe
7
7
Quando deve ser usado o
desenvolvimento ágil?
O desenvolvimento ágil é particularmente indicado em situações onde os requisitos são imprevísiveis ou mudam rapidamente
Ele funciona melhor para equipes pequenas (até 10 desenvolvedores) trabalhando no mesmo local
8
8
Doze princípios da agilidade
Ter como maior prioridade satisfazer o cliente por meio da entrega de software
Modificações contínuas são bem-vindas e levam à competitividade para o cliente
Entrega de software funcionando em períodos de duas semanas a dois meses
O pessoal de negócio e os desenvolvedores devem trabalhar juntos diariamente
Construção de projetos em torno de indivíduos motivados e talentosos
Usar métodos informais de comunicação como conversar pessoalmente
9
9
Doze princípios da agilidade
 Software funcionando é a principal medida de progresso
 Promover o desenvolvimento sustentável, mantendo um ritmo de produção
 Atenção contínua à excelência técnica e ao bom projeto
Simplicidade é essencial
As melhores arquiteturas, requisitos e projetos surgem de equipes auto-organizadas
A equipe deve, em intervalos regulares, refletir sobre como se tornar mais efetiva
10
10
O que é um Processo Ágil?
É um processo que atende a três suposições-chave sobre a maioria dos projetos de software
É difícil prever antecipadamente quais requisitos de software e prioridades do cliente vão persistir e quais serão modificadas
É difícil prever o quanto de projeto é necessário antes que a construção seja usada para comprovar o projeto
Análise, projeto, construção e testes não podem ser tão bem planejados como gostaríamos
Dessa forma, como criar um processo que possa gerenciar a imprevisibilidade?
Adaptação do processo
Mas o processo ágil deve ser adaptável incrementalmente (evitar a adaptação contínua sem progresso)
11
11
Fatores humanos
Características-chave de uma equipe ágil
Competência
Foco comum
Colaboração
Capacidade de tomada de decisão
Habilidade de resolver problemas vagos
Respeito e confiança mútua
Auto-organização
Organização do trabalho a ser feito
Organização do processo para melhor acomodar o ambiente local
Organização do cronograma para conseguir a melhor entrega do incremento 
12
12
Modelos De Processo Ágeis
Extreme Programming (XP)
Desenvolvimento Adaptativo de Software (DAS)
Método de Desenvolvimento Dinâmico de Sistemas (DSDM)
Scrum
Crystal
Desenvolvimento Guiado por Características (FDD)
Modelagem Ágil (AM)
13
13
eXtreme Programming
14
Extreme Programming (XP)
Kent Beck
Estados Unidos, 1999
15
XP é leve
XP é focado no desenvolvimento de software
XP se adapta bem a requisitos vagos e que mudam rapidamente
15
Extreme Programming (XP)
Trabalho pioneiro sobre o assunto escrito em 1999 por Kent Beck
Usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento
Inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades de arcabouço
 Planejamento
 Projeto
 Codificação
 Teste
16
16
Ciclo Semanal
Jogo do Planejamento
17
17
XP - Planejamento
Clientes escrevem estórias
Estórias são escritas na linguagem natural
Estórias exprimem o comportamento de uma Funcionalidade geral
Exemplo
Realizar cadastro de Usuário no sistema. O sistema deverá armazenar nome, telefone e e-mail. O sistema deverá permitir listagem, edição e exclusão.
18
18
XP - Planejamento
Todos fazem estimativas para todos as estórias
As estimativas são individuais
Estimativas do tempo
19
XP - Planejamento
Cliente Prioriza as histórias
Responsabilidade nas mãos do cliente
Limite máximo de estórias de acordo com as estimativas feitas
Construção de tarefas
Exemplo
História: Realizar cadastro de Usuário no sistema. O sistema deverá armazenar nome, telefone e e-mail. O sistema deverá permitir listagem, edição e exclusão.
Tarefas
Modelagem do banco de dados
Criar Interface
Criar listagem
Criar exclusão 
Criar edição
20
Limite máximo??? Slide 24
20
XP - Projeto
Segue o princípio KIS (Keep It Simple)
Se restringe a implementar as estórias de usuário
Usa cartões CRC (Class-Responsability-Colaborator) para identificar e organizar as classes que são relevantes para o incremento atual
Se um problema de projeto difícil é encontrado, o XP recomenda a criação de uma solução de ponta para diminuir o risco
Solução de ponta = um protótipo operacional daquela parte do projeto, que depois será descartado
O XP encoraja a refactoring (refatoração) = modificar o sistema de tal modo que o comportamento externo não seja alterado, mas aperfeiçoe a estrutura interna
21
21
XP - Projeto
Cartão CRC (Classe Responsabilidade Colaboração)
22
22
XP - Projeto
Refatoração [Fowler, 2000]
Processo de modificar um sistema de software de tal modo que ele não altere o comportamento externo do código, mas aperfeiçoe a estrutura interna
23
23
XP - Codificação
Antes de partir para o código, a equipe deve desenvolver testes unitários para verificar a funcionalidade que será desenvolvida
A programação é feita em pares
Isso fornece um mecanismo de solução de problemas e de garantia de qualidade em tempo real
Uma pessoa pensa nos detalhes do código enquanto a outra garante as normas de codificação e que o código gerado vai se encaixar no resto do sistema
O código gerado vai sendo integrado imediatamente (integração contínua) ao trabalho de outros, o que ajuda a evitar problemas de compatibilidade e interface e fornece um ambiente de “teste de fumaça”
24
24
Programação aos pares
Um digita, outro revisa
Redução de bugs
Disseminação do conhecimento
Pressão do par
Simplicidade
Velocidade
25
XP - Codificação
25
XP - Codificação
Mova as pessoas pelo projeto
26
26
Ambiente de Trabalho
“Se você não tiver um ambiente razoável para trabalhar, seu projeto não terá sucesso” (Kent Beck)
Quadro branco
Post-it
Cadeiras giratórias
Jogos
Comida e café
Folhas em branco
27
XP - Codificação
27
XP - Teste
Os testes unitários são criados de tal forma que eles possam ser automatizados, e aplicados diariamente
O XP usa uma estratégia de teste de regressão: testes são aplicados de novo mesmo que anteriormente eles não tenham apresentado problema
Isso permite a refactoring
Os testes de integração e validação do sistema podem ocorrer diariamente
Testes de aceitação são especificados pelo cliente (derivados das estórias do usuário) e focalizam nas características e funcionalidades do sistema global
28
28
29
Reuniões diárias
30
Aprovação do cliente
31
Retrospectiva
31
Será que Entendi?
Imagine que você trabalha em uma empresa que utiliza o XP como modelo de desenvolvimento e você viu que um determinado código pode ser melhorado. Como você deve agir: deve pedir permissão por escrito ou verbal para alterar o código??
32
Exercícios
Metodologias Ágeis
São mais adaptativas que preditivas
São mais orientadas a pessoas que orientadas a processos
33
33
Exercícios
Explique a fase de planejamento do XP.
34
34
Exercícios
Explique a fase de planejamento do XP.
35
35
Valores do XP
1. Comunicação
2. Simplicidade
3. Feedback
4. Coragem
5. Respeito
36
Comunicação
Várias práticas do XP promovem uma maior comunicação entre os membros da equipe
A comunicação não é limitada por procedimentos formais. Usa-se o melhor meio possível, que pode ser
Uma conversa ou reunião informal
Um e-mail, um bate-papo, um telefonema
Diagramas, se necessário (pode, mas não precisa, ser UML)
O próprio código
"Estórias" elaboradas pelo usuário-final
Preferência à comunicação mais ágil
Telefonema melhor que e-mail
Presença física melhor que comunicação remota
Código auto-explicativo melhor que documentação escrita
37
Simplicidade
XP incentiva ao extremo práticas que reduzam a complexidade do sistema
A solução adotada deve ser sempre a mais simples que alcance os objetivos esperados
Use as tecnologias, design, algoritmos e técnicas mais simples que permitirão atender aos requerimentos do usuário-final
Design, processo e código podem ser simplificados a qualquer momento
Qualquer design, processo ou código criado pensando em iterações futuras deve ser descartado
38
O Usuário muitas vezes pede uma solução din^amica, real time, mas, na verdade, algo estático resolveria o problema dele
38
Feedback
Várias práticas do XP garantem um rápido feedback sobre várias etapas/partes do processo
Feedback sobre qualidade do código (testes de unidade, programação em pares, posse coletiva)
Feedback sobre estado do desenvolvimento (estórias do usuário-final, integração contínua, jogo do planejamento)
Permite maior agilidade
Erros detectados e corrigidos imediatamente
Requisitos e prazos reavaliados mais cedo
Facilita a tomada de decisões 
Permite estimativas mais precisas
Maior segurança e menos riscos para investidores
39
Coragem
Testes, integração contínua, programação em pares e outras práticas do XP aumentam a confiança do programador e ajudam-no a ter coragem para
Melhorar o design de código que está funcionando para torná-lo mais simples
Jogar fora código desnecessário
Investir tempo no desenvolvimento de testes
Mexer no design em estágio avançado do projeto
Pedir ajuda aos que sabem mais
Dizer ao cliente que um requisito não vai ser implementado no prazo prometido
Abandonar processos formais e fazer design e documentação em forma de código
40
Respeito
Respeito é um valor que dá sustentação a todos os demais
Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se importarem uns com os outros
41
41
Papéis no XP
Cliente
É ele que escreve as estórias, avalia as novas funcionalidades entregues, dá feedback rapidamente, solicita ou aprova mudanças
42
42
Papéis no XP
Desenvolvedores
Constroem o sistema
Não tem uma hierarquia nos desenvolvedores
Não há uma equipe de testes, são os desenvolvedores que fazem os testes
43
43
Papéis no XP
Coach
Desenvolvedor experiente
Identifica as habilidades da equipe
Lembra as regras de XP
Eventualmente faz programação em pares
Seu papel diminui com o tempo
Não desenha a arquitetura
44
44
Papéis no XP
Tracker
Coleta estatísticas e as exibe
Mantém histórico do progresso
Alguns exemplos: número de estórias implementadas, número de testes, numero de classes e linhas de código
45
Práticas do XP
46
12 Práticas XP
Planejamento: evidencia o que há de emergencial para o desenvolvimento
Como é feito?
Desenvolvimento de software é um diálogo constante entre pessoal de negócio e pessoal técnico
As pessoas de negócio não podem tomar essas decisões no vácuo. Elas precisam do pessoal técnico para decidir sobre: estimativas, conseqüências técnicas, processo de desenvolvimento do produto, cronograma detalhado
Cliente propõe “user stories”(estórias) e os desenvolvedores avaliam sua dificuldade
Cada iteração irá durar de uma a três semanas
Cada release pode ter várias iterações
Cada uma delas irá implementar algumas estórias definidas para o release
47
47
12 Práticas XP
Entregas freqüentes: a entrega de pequenas implementações funcionais visa a constante aprovação do software e a incorporação rápida de mudanças por parte dos contratantes através do feedback
Cada release deve ser tão curto quanto possível, contendo os requisitos de negócio de maior valor para o cliente
O release deve fazer sentido como um todo
Não deve existir um release com metade de um requisito (o que não faz sentido)
Releases Curtos promovem o desenvolvimento iterativo e incremental
48
48
12 Práticas XP
Metáfora: são as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o desenvolvimento do software
Porquê utilizar?
A metáfora é um meio de ajudar a todos (clientes e desenvolvedores) a compreender melhor o objetivo e propósito do produto sendo criado
49
49
12 Práticas XP
Projeto simples: o programa desenvolvido pelo método XP deve ser o mais simples possível e satisfazer os requisitos atuais
50
50
12 Práticas XP
Testes: busca a validação do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando primeiramente os testes unitários
XP valoriza o desenvolvimento dirigido por testes
São automatizados, executados o tempo todo
51
51
12 Práticas XP
Programação em pares: dois desenvolvedores trabalham em um único computador. O desenvolvedor que está com o controle do teclado e do mouse implementa o código, enquanto o outro observa o trabalho, buscando encontrar erros sintáticos e semânticos e buscando uma forma de se otimizar o que está sendo implementado pela sua dupla
“Um” pelo preço de “Dois”??
Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos
52
52
12 Práticas XP
Refatoração: quando se percebe que é possível simplificar o módulo atual sem perder nenhuma funcionalidade
Propriedade coletiva: o código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode fazer alguma melhoria, pode fazê-lo, desde que valide as mudanças. A propriedade coletiva é uma segurança ao projeto caso algum dos membros deixe a equipe
Módulos não são “propriedade” de nenhum desenvolvedor
Todo desenvolvedor da equipe tem o direito de checar ummódulo e modificá-lo
O código é propriedade da equipe 
53
53
12 Práticas XP
Integração contínua: é a prática de interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos
Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem, porque fica óbvio quem deve fazer as correções quando os testes falham, a última equipe que integrou código novo ao software
Código é integrado e testado depois de algumas horas(no máximo no final de cada dia)
No final de um episódio de desenvolvimento, o código é integrado e todos os casos de teste devem rodar a 100%
Essa técnica já existe há tempos e foi conhecida como “daily builds and smoke tests”, largamente utilizada na Microsoft
54
54
12 Práticas XP
40 horas de trabalho semanal: caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido com melhor planejamento ou outra atitude, não com horas extras
Cliente presente: a participação do cliente durante todo o desenvolvimento do projeto é essencial. O cliente deve estar sempre disponível para elucidar
questões acerca de requisitos, evitando atrasos e até mesmo construções erradas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento
55
55
12 Práticas XP
Código padrão: padronização na arquitetura do código, para que este possa ser compartilhado entre todos os programadores
Cada equipe deve possuir padrões de codificação que serão usados por todos
Idealmente, serão decididos por consenso
Cada um dos padrões deve ter o claro objetivo de ajudar a melhorar a comunicação da equipe
Todos devem concordar em utilizá-los
56
56
Exercícios
( ) Agilidade não é nada mais do que a capacidade de uma equipe de projeto tem para responder rapidamente às mudanças.
( ) Em processos de software ágil a maior prioridade é satisfazer o cliente através da entrega do software o mais rápido possível e continuada.
( ) Não é possível construir software que atenda às necessidades dos clientes hoje e apresente as características de qualidade que lhe permita ser estendido depois.
( ) Todos os modelos de processos ágeis estão em conformidade com um maior ou menor grau aos princípios estabelecidos no "Manifesto para Desenvolvimento Ágil de Software"
57
Exercícios
( F ) Agilidade não é nada mais do que a capacidade de uma equipe de projeto tem para responder rapidamente às mudanças.
( V ) Em processos de software ágil a maior prioridade é satisfazer o cliente através da entrega do software o mais rápido possível e continuada.
( F ) Não é possível construir software que atenda às necessidades dos clientes hoje e apresente as características de qualidade que lhe permita ser estendido depois.
( V ) Todos os modelos de processos ágeis estão em conformidade com um maior ou menor grau aos princípios estabelecidos no "Manifesto para Desenvolvimento Ágil de Software"
58
Exercícios
Which of the following is not necessary to apply agility to a software process?					
	A)	Eliminate the use of project planning and testing	
	B)	Only essential work products are produced	
	C)	Process allows team to streamline tasks	
	D)	Uses incremental product delivery strategy	
59
streamline = alterar para simplificar 
59
Exercícios
Which of the following is not necessary to apply agility to a software process?					
	A)	Eliminate the use of project planning and testing	
	B)	Only essential work products are produced	
	C)	Process allows team to streamline tasks	
	D)	Uses incremental product delivery strategy	
60
Exercícios
How do you create agile processes to manage unpredictability?					
	A)	Requirements gathering must be conducted very carefully	
	B)	Risk analysis must be conducted before planning takes place	
	C)	Software increments must be delivered in short time periods	
	D)	Software processes must adapt to changes incrementally	
	E)	both c and d	
61
gathering = Recolhimento de requisitos, acumulação
61
Exercícios
How do you create agile processes to manage unpredictability?					
	A)	Requirements gathering must be conducted very carefully	
	B)	Risk analysis must be conducted before planning takes place	
	C)	Software increments must be delivered in short time periods	
	D)	Software processes must adapt to changes incrementally	
	E)	both c and d	
62
Exercícios
Which of the following traits need to exist among the members of an agile software team?					
	A)	Competence	
	B)	Decision-making ability	
	C)	Mutual trust and respect	
	D)	All of the above	
63
Exercícios
Which of the following traits need to exist among the members of an agile software team?					
	A)	Competence	
	B)	Decision-making ability	
	C)	Mutual trust and respect	
	D)	All of the above	
64
Exercícios
What are the four framework activities found in the Extreme Programming (XP) process model?					
	A)	analysis, design, coding, testing	
	B)	planning, analysis, design, coding	
	C)	planning, analysis, coding, testing	
	D)	planning, design, coding, testing	
65
Exercícios
What are the four framework activities found in the Extreme Programming (XP) process model?					
	A)	analysis, design, coding, testing	
	B)	planning, analysis, design, coding	
	C)	planning, analysis, coding, testing	
	D)	planning, design, coding, testing	
66
Exercícios
Segundo o XP, o que significa o termo “solução de ponta”?
O que é refatoração?
Escreva uma estória de usuário XP que descreva a características “Favoritos”, que está disponível na maioria dos navegadores Web.
67
67
SCRUM
68
http://www.slideshare.net/serge_rehem/scrum-em-15-minutos
69
Scrum
Scrum é um processo para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita freqüência (considera antecipadamente a existência do caos)
A metodologia é baseada em princípios semelhantes aos de XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos, e iterações curtas para promover visibilidade para o desenvolvimento
70
70
Scrum
71
Scrum
Durante o sprint, os itens em pendência a que as unidades de trabalho do sprint se destinam são congelados (isto é, não são introduzidas as modificações durante o sprint)
Backlog (lista de pendências): uma lista priorizada de requisitos ou características do projeto que fornecem valor de negócio para o cliente. Itens podem ser adicionados à pendência a qualquer momento
Demo: entrega o incremento de software ao cliente de modo que a funcionalidade implementada possa ser demonstrada e avaliada pelo cliente
72
72
Papéis
73
Estórias de Usuário
User Stories
–Como um <ator>, eu gostaria de <ação>, para <motivo>
Atributos
Tamanho (pontos, dias ideais),Valor de negócio, Condições de satisfação
74
Exemplos de User Stories
75
Detalhes e condições de satisfação
76
Story Points
O tamanho de uma User Story
Influenciado por
O quanto difícil é a Story
Qual o tamanho do trabalho
Série de Fibonacci 
1,2,3,5,8,13,21,…
Comparação relativa
77
77
Story Points
Usualmente, para cada story do backlog deverá ser atribuído um valor da série aproximada de Fibonacci (1,2,3,5,8,13,21,…), por exemplo 
Essa atribuição deve ser feita pelo time e não por uma única pessoa 
Para começar a pontuar as stories de um product backlog, pega-se a story que o time julga ser a de menor esforço e atribui pontuação 2
As demais stories deverão seguir uma pontuação relativa a essa primeira
78
78
Story Points
Vantagens
Foco em estimativa relativa
Performances individuais diferentes
Um problema inerente da abordagem homem/dia é que essa medida depende do desempenho de quem está executando
Os indivíduos diferem em know-how, experiência, competência, etc
Foco em tamanho/esforço e não em duração
79
79
Story Points
Desvantagens
Medida não universal
Medir em pontos é uma coisa muito particular e subjetiva, o seu significado acaba fazendo sentido apenas para um time em um determinado projeto
Isso pode atrapalhar ao se juntar grupos diferentes em um mesmo projeto com um product backlog em comum
80
80
Story Points
Desvantagens
Desconforto inicial de alguns
Pode ser difícil convencer algumas pessoas
Especialmente porque todos sabem que ao final os pontos vão se transformar em estimativas de tempo
Após algumas poucas sprints, cria-se uma noção intuitiva de pontos
Ao ser confrontado com uma nova story, os indivíduos do time já começam a pensar se ela custa oito ou cinco pontos e não se vai durar x ou y dias
81
81
Tempo Ideal
Quanto tempo algo iria demorar se
Você trabalhasse apenas nisso
Sem interrupção de tempo
Tudo que você precisa estará disponível
O Tempo ideal de uma partida de futebol Americano seria de 60 minutos
Quatro tempos de 15 minutos
O tempo total porém leva mais de 3 horas
82
Planning Poker
Método ágil para estimativas, descrito inicialmente por James Grenning em 2002 e depois popularizado por Mike Cohn no seu livro Agile Estimating and Planning
Para "jogar" o Planning Poker precisamos apenas de uma lista de backlog e um baralho
O baralho, geralmente composto por cartas que possuem
uma sequência Fibonacci ou uma sequência similar (0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 50, 80 ,100, ?), uma carta opcional com um sinal de interrogação,..
Por que não utilizar a sequência de números naturais?
Para que serve o zero e o ponto de interrogação?
83
83
Planning Poker
O jogo começa após as explicações feitas pelo Product Owner, onde todos os membros discutem para chegar a um entendimento do problema
É importante frizar que os membros do time devem estimar todo o trabalho relacionado ao item do backlog, e não apenas a sua parte especifica
Por exemplo, o testador não deve só se preocupar com os testes
84
84
Planning Poker
Cada membro da equipe, pega uma carta que acha que corresponde com os Story points e depois que todos escolheram suas cartas, tem inicio a rodada
85
Membro do time
Rodada 1
Rodada 2
Maria
80
50
Carlos
21
34
João
34
50
Rafael
50
34
Rita
50
50
85
Velocidade
Para fazer um release plan, precisamos saber ou ter uma idéia da Velocidade
3 formas de termos a Velocidade
Média das Velocidades anteriores
Faça 1 ou 2 Sprints e veja o que temos
Faça uma previsão
86
Sprint Backlog
87
Parei a aula aqui
87
Sprint Burndown
Permite medir o progresso
Mostra a quantidade de trabalho restante no Sprint a cada dia
Atualizado a cada dia pelos membros do time
88
88
Sprint Planning
Reunião de planejamento da sprint
PO explica a meta e resume o product backlog
Time faz as estimativas
Time seleciona as estórias para a sprint
Deve dar ao time informações suficientes para que eles possam trabalhar na sprint
O Product Owner já priorizou as estórias, ele ainda precisa participar desta reunião?
89
Escopo
Estimativa
Importância
89
Sprint Planning
Como o time decide quais estórias incluir na sprint?
Como o Product Owner pode afetar em quais estórias devem ser feitas na sprint?
90
Daily Scrum Meeting
91
Sprint Review
A equipe apresenta os resultados obtidos durante o Sprint
Normalmente assume a forma de uma demonstração de novas funcionalidades
Informal
O time inteiro participa
92
92
93
Desenvolvimento Adaptativo de Software (DAS)
94
94
Desenvolvimento Adaptativo de Software (DAS)
Iterativo e incremental
Voltado para a construção de sistemas e softwares complexos
Concentra-se na colaboração humana e na auto-organização da equipe
Cliente sempre presente
Desenvolvimento de aplicações em conjunto (Joint Application development – JAD)
95
95
Desenvolvimento Adaptativo de Software (DAS)
O ASD possui ciclos de 3 fases
96
96
Desenvolvimento Adaptativo de Software (DAS)
Especular (Speculate)
Fixa prazos e objetivos
Define um plano baseado em componentes
Colaborar (Collaborate)
Construção concorrente de vários componentes
Pessoal trabalhando colaborativamente multiplica os resultados
Aprender (Learn)
Repetitivas revisões de qualidade e foco na demostranção das funcionalidades desenvolvidas (Learning loop)
Presença do cliente e especialistas do domínio
Os ciclos duram de 4 a 8 semanas
97
97
Especulação
O projeto é iniciado
Planejamento do ciclo adaptativo é conduzido
Declaração da missão feita pelo cliente
Restrições do projeto
Requisitos básicos
Definição de ciclos de versão (incrementos)
98
Colaboração
Não é somente pela Comunicação
Não é somente pelo Trabalho em Equipe
Não é uma rejeição ao indidualismo
É acima de tudo uma questão de confiança
Precisam confiar umas nas outras
Criticar sem animosidade
Ajudar sem ressentimentos
Trabalhar tão duro ou mais duro do que costumam
Ter um conjunto de habilidade para contribuir com trabalho em mãos
Comunicar problemas e/ou preocupações de um modo que conduza a ação efetiva
99
99
Aprendizado
As equipes DAS aprendem de 3 modos
Foco no grupos
Usuários fornecem feedback sobre os incrementos, indicando se o produto está ou não satisfazendo a necessidade do negócio
Revisões técnicas formais
Os membros da equipe DAS revisam os componentes de SW que são desenvolvidos, aperfeiçoando a qualidade e aprendendo à medida que prosseguem 
Pós conclusão
A equipe cuida do seu próprio desempenho e processo
100
100
Método de Desenvolvimento Dinâmico de Sistemas (DSDM)
101
101
Método de Desenvolvimento Dinâmico de Sistemas (DSDM)
Fornece um arcabouço para construir e manter sistemas que satisfazem às restrições de prazo apertadas por meio do uso de prototipagem incremental em um ambiente controlado de projeto
Sugere uma filosofia uma versão modificada do princípio de Pareto
Princípio de Pareto (Vilfredo Pareto): Ao estudar a distribuição de renda da Itália, constatou que 80% da riqueza dos italianos pertenciam a 20% da população
DSDM: 80% de uma aplicação pode ser entregue em 20% do tempo
102
102
Método de Desenvolvimento Dinâmico de Sistemas (DSDM)
O ciclo de vida DSDM define três ciclos iterativos diferentes, precedidos por duas atividades adicionais de ciclo de vida
Estudo de viabilidade: estabelece requisitos básicos e restrições, e viabilidade do uso do DSDM ao projeto
Estudo do negócio: estabelece requisitos funcional e de informação
Iteração do modelo funcional: protótipo evolutivo inicial para prover rápido feedback do cliente
Iteração de projeto e construção: revisita e refina os protótipos
Implementação: coloca o “protótipo operacionalizado” no ambiente operacional
103
103
Método de Desenvolvimento Dinâmico de Sistemas (DSDM)
104
104
Desenvolvimento Guiado por Características
105
105
Desenvolvimento Guiado por Características
Feature Driven Development (FDD)
Processo ágil e adaptativo que pode ser aplicado a projetos de software de tamanho moderado e grande
No contexto do FDD, uma característica é uma função valorizada pelo cliente que pode ser im­plementada em duas semanas ou menos 
As características podem ser organizadas em um agrupamento hierárquico relacionado ao negócio
Planejamento de projeto, cronogramação e monitoração são guiados pela hierarquia de características em vez de por um conjunto de tarefas de engenharia de software arbitrariamente adotado
106
106
Desenvolvimento Guiado por Características 
Característica
<ação> o <resultado> <por/para/de/a> um <objeto>
Adiciona o produto a um carrinho de compras
Exibe as especificações técnicas de um produto
Armazena as informações de remessa para um cliente
Conjunto de características
<verbo no gerúndio (ação)> um <objeto>
Fazendo uma venda de produto
107
107
Desenvolvimento Guiado por Características
Define cinco atividades de arcabouço "colaborativas“ (em FDD elas são denominadas "processos")
108
108
Modelagem Ágil
109
109
Modelagem Ágil
Scott Ambler
A Modelagem Ágil (AM) é uma metodologia baseada na prática, para modelagem e documentação efetiva de sistemas baseados em software
Colocado simplesmente, Modelagem Ágil é uma coleção de valores, princípios e práticas de modelagem de software que podem ser aplicados a um projeto de desenvolvimento de software de modo efetivo e leve
Os modelos ágeis são mais efetivos do que os modelos tradicionais, porque eles são apenas suficientemente bons, eles não precisam ser perfeitos
110
110
Modelagem Ágil
Princípios
Modelar com uma finalidade (meta)
Usar modelos múltiplos (usar um subconjunto daqueles que agregam valor)
Viajar leve (guarde apenas os modelos essenciais, descarte os não mais necessários)
O conteúdo é mais importante que a representação (o modelo não precisa estar sintaticamente perfeito)
Conhecer os modelos e as ferramentas que você usa para criá-los
Adaptar localmente
111
111
Modelagem Ágil
http://www.agilemodeling.com/
112
Exercícios
What are the three framework activities for the Adaptive Software Development (ASD) process model?					
	A)	analysis, design, coding	
	B)	feasibility study, functional model iteration, implementation	
	C)	requirements gathering, adaptive cycle planning, iterative development	
	D)	speculation, collaboration, learning	
113
Exercícios
What are the three framework activities for the Adaptive Software
Development (ASD) process model?					
	A)	analysis, design, coding	
	B)	feasibility study, functional model iteration, implementation	
	C)	requirements gathering, adaptive cycle planning, iterative development	
	D)	speculation, collaboration, learning	
114
Exercícios
The Dynamic Systems Development Method (DSDM) suggests a philosophy that is based on the Pareto principle (80% of the application can be delivered in 20% of the time required to build the complete application).					
	A)	True	
	B)	False	
115
Exercícios
The Dynamic Systems Development Method (DSDM) suggests a philosophy that is based on the Pareto principle (80% of the application can be delivered in 20% of the time required to build the complete application).					
	A)	True	
	B)	False	
116
Exercícios
In Feature Driven Development (FDD) a "feature" is a client-valued function that can be delivered in two months or less.					
	A)	True	
	B)	False	
117
Exercícios
In Feature Driven Development (FDD) a "feature" is a client-valued function that can be delivered in two months or less.					
	A)	True	
	B)	False	
118
Exercícios
Agile Modeling (AM) provides guidance to practitioner during which of these software tasks?					
	A)	Analysis	
	B)	Design	
	C)	Coding	
	D)	Testing	
119
	E)	both a and b	
119
Exercícios
Agile Modeling (AM) provides guidance to practitioner during which of these software tasks?					
	A)	Analysis	
	B)	Design	
	C)	Coding	
	D)	Testing	
	E)	both a and b	
120
120
Exercícios
Which is not one of the key questions that is answered by each team member at each daily Scrum meeting?					
	A)	What did you do since the last meeting?	
	B)	What obstacles are you encountering?	
	C)	What is the cause of the problems you are encountering?	
	D)	What do you plan to accomplish at the next team meeting?	
121
Exercícios
Which is not one of the key questions that is answered by each team member at each daily Scrum meeting?					
	A)	What did you do since the last meeting?	
	B)	What obstacles are you encountering?	
	C)	What is the cause of the problems you are encountering?	
	D)	What do you plan to accomplish at the next team meeting?	
122
Conclusões
A escolha da metodologia mais adequada para o desenvolvimento de software em uma organização, levando em consideração os inúmeros fatores envolvidos, não é uma tarefa trivial
Por outro lado, é um fator preponderante para o sucesso da organização!!
Embora um bom processo não possa garantir o sucesso de um projeto, certamente a adoção de um processo inadequado pode comprometê-lo
123
Próxima Aula...
124
“O que ouço, esqueço. O que vejo, lembro. O que faço, entendo” 
(Provérbio Chinês)
125
Próxima Aula...
Dinâmica sobre SCRUM
Definir equipes
Scrum Master
Product Owner
Team
126
Equipes
126