Engenharia de Software:
Metodologias Ágeis
...
Pasqueline Dantas
Metodologias tradicionais
Fluxo do processo
Seqüência de atividades que geram artefatos até
se atingir o objetivo do projeto
Idéia inicial: receita de bolo
“Se seguirmos todos os passos, o projeto terá sucesso” Foco está no processo
Hoje
Tem-se mudado o foco para pessoas
Agilidade
O que é agilidade?
Habilidade de entregar em um tempo curto algo de valor para o cliente
É preciso parar de tentar evitar mudanças
Metodologias ágeis
Coleção de práticas
“Filosofia” onde muitas “metodologias” se encaixam
Definem um conjunto de atitudes e não um processo
prescritivo
Metodologias ágeis
Reação às metodologias tradicionais
“Manifesto ágil“ (2001)
Princípios
Indivíduos e interações são mais importantes que
processos e ferramentas
Software funcionando é mais importante que
documentação completa
Colaboração com o cliente é mais importante que
negociação com contratos
Adaptação às mudanças é mais importante que seguir
Características gerais
Procuram minimizar riscos desenvolvendo
software em pequenos espaços de tempo
(iterações)
Cada iteração é como um pequeno projeto
Objetivo de cada iteração
produzir componentes de software
Arquitetura vai sendo desenhada a partir da refatoração
dos componentes
Enfatizam comunicação “cara a cara” em
Comparação entre
abordagens
Métodos Preditivos Métodos Adaptativos
Ênfase: planejamento de ações
em detalhe
Ênfase: mudanças e suas
conseqüentes adaptações
Equipe: sabe que funcionalidades
e tarefas farão nas etapas seguintes no processo de desenvolvimento
Equipe: não sabe o que irá fazer a
médio e longo prazo
Mudanças: podem obrigar a
refazer todo o planejamento
Mudanças: conseqüências e
problemas são encarados à medida que eles chegam
Iteração: definida por objetivo Iteração: curta, de tempo fixo, em
Conceitos equivocados
Métodos ágeis são geralmente comparados a
metodologias orientadas ao “planejamento”
Mas não são orientadas à predição
Geralmente associado ao estilo “cowboy”
Em geral, requer mais disciplina que metodologias
preditivas
É uma metodologia à parte
Descrevem práticas, “atitudes” e princípios
Críticas
Não provê documentação necessária
Dificuldades “após o projeto”
Funciona apenas para equipes experientes
Práticas disciplinadas e rigorosas
Pouca atenção ao projeto de software
Arquitetura é definida “de baixo pra cima”
Requer uma grande mudança cultural na
organização para ser adotado
Quando usar...
Metodologias ágeis Metodologias preditivas
Projetos pouco críticos Projetos altamente crítico
Equipe experiente Equipe iniciante
Com mudanças constantes Com poucas mudanças
Pequena equipe (≤ 10 ) Equipes maiores ( ≥ 20)
Equipe co-localizada Equipe distribuída
eXtreme Programming
XP - valores
Metodologia baseada em um conjunto de práticas e
valores (feedback, comunicação, simplicidade, coragem)
Feedback
Cliente aprende com o sistema que utiliza e re-avalia suas
necessidades, ele realimenta a equipe com as necessidades que serão implementadas
Mecanismo para que o cliente direcione suas atenções para
aquilo que irá gerar mais valor
Comunicação
Mais direta e eficaz: face-a-face
XP - valores
Simplicidade
Implementar apenas aquilo que é suficiente para atender as
necessidades do cliente
Problemas são os de hoje!
Coragem
Acreditar nas práticas Mudanças profundas
Manter o sistema simples
permitir que o cliente priorize as funcionalidades desenvolver em pares
investir tempo em refatoramento e testes estimar diante do cliente
expor seu código para outras pessoas
abrir mão da documentação que serve como defesa propor contratos de escopo variável
A importância da presença
do cliente...
Tradicionalmente...
Delega-se ao cliente a tarefa de manifestar
suas necessidades e a equipe de
implementar
Distanciamento entre eles
No XP, a visão é bem diferente...
Cliente deve está presente no dia-a-dia do
projeto, literalmente
A sua participação viabiliza a simplicidade do
processo
As estórias...
Funcionalidades = estórias
Convite ao diálogo
desenvolvedores precisam entender melhor as estórias,
evitando as especulações
Assim que implementadas devem ser mostradas
ao cliente – feedback (detalhes podem ser adicionados)
Quanto mais rápido o feedback, mais rápido será o
Por que é difícil ter o cliente?
Indisponibilidade para estar presente
Sempre ocupado
Cultura <-> mudança
Comum considerar que a presença não é recomendável Convencer o cliente da sua importância no projeto
Algumas técnicas
Sala de guerra com o cliente (empresa-cliente disponibiliza
uma sala para o projeto: um representante do cliente será deslocado para lá)
Sala de guerra em outro prédio Reuniões freqüentes (semanais)
Uso de mecanismos síncronos de comunicação. E-mail só em
Cliente ausente
O que fazer se o cliente não estiver presente?
Provavelmente, XP não é a metodologia mais adequada Desenvolvedores devem evitar
Decidir pelo cliente - Gente técnica toma decisões técnicas e
gente de negócio toma decisões de negócio!
Inventar "coisas legais" para colocar no software. Quem sabe o
que é "legal" é o cliente
Decidir em que ordem as estórias serão implementadas. Eles
podem alertar o cliente quanto a dependências entre estórias que podem afetar a ordem e podem pedir para colocar as de mais alto risco na frente.
Decidir que funcionalidade cortar quando prazos podem
estourar. Quem sabe o que tem menos Business Value e pode ser cortado é o cliente.
XP - práticas
1.
Cliente Presente
Conduz o desenvolvimento de acordo com o
feedback do sistema
É ativo no processo de desenvolvimento
No levantamento das estórias Na realização das estimativas Priorização
Testes de aceitação: definindo e executando
XP - práticas
2.
Jogo do planejamento
Reunião onde o cliente avalia as funcionalidades
e as prioriza
Projeto dividido em “partes menores”
Diferentes oportunidades de se reunir para revisar o
planejamento
Funcionalidades descritas em pequenos cartões –
chamadas de estórias
No jogo, as estórias são estimadas para que o
cliente conheça o custo da sua implementação Estimativas são feitas usando uma unidade especial
XP - práticas
3.
Stand up meeting
Reuniões a cada manhã que avaliam o trabalho
do dia anterior e priorizam as atividades do dia
Reunião rápida e objetiva: membros ficam de pé
Útil para que todos tenham uma idéia do
andamento e progresso da implementação das estórias
XP - práticas
4.
Programação em pares
Implementação do código ocorre em pares
Código revisado permanentemente
Nivelamento de competências: uniformidade
Aprendizado
XP - práticas
5.
Desenvolvimento guiado por testes
Testes para cada funcionalidade antes da
codificação
Bom porque...
Aprofundam o entendimento das necessidades do
cliente – aprimora a análise
Se preocupam com as interfaces externas dos
métodos/classes antes da codificação – melhora o projeto
XP - práticas
6.
Refatoramento (refactoring)
Técnica de melhoramento de código, sem adição
de novas funcionalidades
Para o sistema crescer incrementalmente deve
ser fácil de ser compreendido
Reforça a existência dos testes Refina a arquitetura
XP - práticas
7.
Código coletivo
Sistema é segmentado em partes
Cada par de desenvolvedores é responsável por
uma delas
Todos têm acesso as todas as partes e podem
alterar aquilo que julgarem importantes sem a autorização de alguém
XP - práticas
8. Código padronizado
Endentação: mesma largura de tabulação, mesmo
posicionamento de chaves
Uso de letras maiúsculas e minúsculas Comentários: procure evitá-los
Uso de nomes: não defina por conveniência!
9. Design simples
10. Metáfora
Mecanismo usado para transmitir idéias complexas de
forma simples. Uso de uma linguagem simples entre equipe e cliente
XP - práticas
11. Ritmo sustentável
40 horas semanais
Nada de fazer hora extra!
12. Integração contínua
A incorporação de uma funcionalidade pode afetar outras
que estavam funcionando
Garante funcionamento harmonioso
Os pares integram o seu código ao dos demais várias vezes
ao dia
Testes são executados a cada integração
Diminui a probabilidade de pequenos problemas se tornarem
XP - práticas
13.
Releases curtos
Equipe produz um conjunto reduzido de
funcionalidades e coloca em produção
rapidamente de modo que o cliente já possa utilizar o software no dia-a-dia
Papéis
Cliente
Quem define os requisitos (em geral, um usuário)
Gerente
Facilitador do projeto
Testador
Define os critérios de aceitação junto ao cliente Não deve participar do desenvolvimento
Desenvolvedor
Responsável pela análise, projeto e implementação
Rastreador ou documentador
Coleta sinais do projeto (métricas) - Avalia desempenho Pode ser um desenvolvedor
Técnico (Coach ou líder)
Especialista do processo. Dá suporte técnico à equipe. Garante o
cumprimento das práticas do processo
O sentido do jogo
XP planeja para assegurar que a equipe esteja
trabalhando naquilo que irá gerar maior valor para o cliente
Acontece diversas vezes durante o projeto: mudança de
prioridades e adequação de novos requisitos
Todas as estórias são registradas em cartões
Escritas sempre pelo cliente. Não existe formato definido. Deve-se respeitar o espaço do cartão (10 linhas)
Interessante escrever os cartões porque...
O cliente é forçado a pensar nas funcionalidades
Vínculo psicológico – responsabilidade sobre aquilo que está
pedindo
Estórias
Algumas estórias...
Apresente ao cliente as 10 tarifas mais baratas para uma
determinada rota
Para cada conta, computar o saldo fazendo a adição de
todos os depósitos e subtração de todas as deduções
A tela de login deve permitir que o usuário pule o login.
Neste caso, o usuário entrará no sistema como guest
O usuário deve poder alterar o seu perfil (email, senha,
primeiro, ultimo nome). Dois campos de senha para confirmação
Depois de levantadas, os desenvolvedores escolhem
Estórias e tarefas
Acontece de algumas estórias consumirem muito
tempo (uma ou mais semanas)
Neste caso, a estória é dividida em tarefas que são mais
uma vez distribuídas em novos cartões
As estimativas
Necessárias para que o cliente priorize as estórias
Qual é o custo previsto para cada uma delas?
No XP uma unidade de medida diferente é utilizada
As estimativas não se baseiam em tempo previsto já que
isso acaba causando distorções.
A mudança de prioridade de uma estória pode acarretar
atividades extra
Ao invés de horas, ou dias, a medida utilizada é o DIA IDEAL DE
DESENVOLVIMENTO: se eu tiver o dia todo para implementar a estória, quantos dias levarei para finalizá-la?
O dia ideal de um par de desenvolvedores é chamado
O ponto
Usado para estimar e acompanhar as
estórias
Simplifica a comunicação
Semântica pode mudar de projeto para projeto
Mas deve ser compreendida por todos
Como utilizá-lo?
No canto superior esquerdo do cartão define-se as
estimativas
No canto direito a quantidade real de pontos
Estimar... uma tarefa difícil!
Estimativas
Por comparação
A base de experiência: estórias que já foram
implementadas
Em equipe
Conhecimentos acumulados pela equipe aproximam mais
as estimativas da realidade
Cliente presente
Durante as estimativas as dúvidas que surgem podem ser
esclarecidas pelo cliente, evitando que premissas equivocadas sejam assumidas
Planejamento dos releases
As entregas sempre são incrementais: projeto é
quebrado em releases
Releases são curtos, em torno de 2 meses e possuem
tamanho fixo
Como planejar?
1. Cliente define os objetivos de cada release
R1: processamento de compras on-line ...
2. A equipe informa ao cliente quantos pontos é capaz de
implementar
Serve como base para escolher as estórias mais prioritárias
3. Cliente distribui as estórias para o release – não é
necessário escrever todas as estórias
Planejamento das iterações
Releases são quebrados em iterações
Pequeno espaço de tempo dedicado para a implementação
de um conjunto de estórias
Iterações: 1-3 semanas, 2 semanas é mais usual O tamanho da iteração é fixo
Se preciso, o tamanho do escopo pode ser alterado
Planejamento da iteração visa definir as estórias a
serem implementadas (cliente)
A equipe precisa definir a velocidade da iteração (VI)
VI = quantos pontos podem ser implementados na iteração Como calcular?
Projeto R5 R4 R3 R2 R1 2 meses
Velocidade da iteração
Cenário
Tamanho da iteração = 2 semanas (10 dias úteis) 3 pares de desenvolvedores
Desconto
2 dias - planejamento + encerramento da iteração
Dias úteis = 8
1 par/dia = ponto
1 par em 8 dias = 8 pontos x (3 pares) = 24 Velocidade da iteração = 24 pontos
Velocidade da iteração
A equipe é capaz de implementar 24 pontos
a cada iteração
Teoricamente, porque ao longo do projeto parte
da equipe pode assumir outras atividades: um teste de desempenho
Finalizando as estórias, os pares devem
acompanhar o número de pontos consumidos
Essa quantidade corresponde a velocidade da iteração
porque é esse número que será fornecido para a próxima iteração
Se a equipe implementou as estórias em um número
menor de pontos?
Encerramento da
iteração/release
Último dia é reservado para a reunião de
encerramento
O cliente executará todos os testes de aceitação Validação do sistema
Se necessário, mudanças podem ser feitas,
reparos podem ser importantes
Depois da última iteração do release
O sistema posto em produção
Desenvolvimento guiado
por testes...
Testes
Todo mundo sabe que é importante mas ninguém
quer fazer!
Consome muito tempo do desenvolvimento – se der
tempo.... É chato, não é valorizado até o usuário reclamar!
Aprendizado está relacionado ao tempo do feedback
Se os testes são feitos durante o desenvolvimento, o
desenvolvedor tem como saber o que causou o erro, não repetindo-o mais.
Prevenir ou remediar?
Desenvolvimento x Depuração
Custos aumentam em função do tempo gasto para encontrar o
Testes
Tornam o desenvolvimento mais barato
Expõe o defeito assim que ele entra no sistema Fornece pistas...
XP e os testes
Sempre gerados em primeiro lugar
De unidade: verificação sobre cada classe do sistema De aceitação: sobre cada estória
Quando fazer testes de unidade?
Antes da implementação, sempre!
Se a interface de um método não estiver totalmente clara Necessidade de fazer refatoramento
Se um problema é encontrado em um código já escrito:
isolamento
Automatizando um teste
Classes que testam outras classes (1-1)
Todos os testes devem estar reunidos em
uma classe especial responsável por
executar as verificações
Testes de classe isolados não são eficientes!
Teste de unidade
O cliente definiu uma estória que se refere a
validação de um número de inscrição
estadual
Qual deve ser o primeiro passo do
desenvolvedor?
Entender a interface do método
O que deve ser passado como parâmetro, o que é
retornado na saída?
Criando uma classe de teste
Estenda a classe junit.framework.TestCase
Sua subclasse de TestCase deverá
simplesmente invocar os testes na ordem
que você desejar
Adota-se como padrão para o nome da classe de
teste o uso do sufixo "Tester" após o nome da classe que esta sendo testada
Ao executar o JUnit, as expectativas são
package testes;
import dominio.InscricaoEstadual; import junit.framework.TestCase;
public class InscricaoEstadualTest extends TestCase {
final public void testIsValid() {
boolean b = InscricaoEstadual.isValid("81501319"); assertEquals(true,b);
} }
A classe em Java
A classe Java InscricaoEstadual oferece uma
interface simples Método IsValid
para testar se o número de inscrição estadual
informada é válida.
Regra de negócio:
o número informado deve conter 8 dígitos
Se o resto da divisão por 11 for menor ou igual a 1
(um), então o dígito verificador será = 0. Se não, o dígito será 11 menos o resto.
Mais testes... Testes de
aceitação
Testes de aceitação (TA)
Importante que se verifique se as classes
envolvidas em uma estória estão se
relacionando corretamente
TA procuram simular a interação do usuário com o
sistema e verificar se o seu comportamento está correto
É um roteiro que possui um conjunto de
respostas esperadas
Para a estória existe um passo-a-passo, cada ação
Testes de Aceitação
Quem cria?
Cliente + testador
Quando são escritos?
Antes da implementação das estórias No primeiro dia da iteração Dos roteiros Caminhos válidos, exceções, peculiaridades
Estória Vizualizar itens do carrinho de
compras
Num Ação Resposta
1 Entrar no site Visualizar o carrinho Exibir msg: “Carrinho de compras vazio” 2 Adicionar o produto “Pendrive 512” Visualizar o carrinho Exibir: Pendrive 512- 1 unid. – R$ 70,00 3 Adicionar o produto “Notebook Acer” Visualizar o carrinho Exibir: Pendrive 512- 1 unid. – R$ 70,00 Notebook Acer – 1 unid. – R$ 2.600,00
Ambiente de trabalho
Ambiente
Mesas
Permitir o trabalho em pares
Células de trabalho: desaconselhável
Equipamentos
Máquinas com muito processamento fazem diferença na
produtividade
Telefone e comida
Mural
Paredes servem como canal de comunicação
Cartões: não-iniciados, em andamento, finalizados
Documentação
Estórias
Testes de aceitação e unidade
Javadoc
Diagrama de classes
Modelo de dados
Processos de negócio
Manual do usuário
Primeiros dias usando XP...
1a iteração é a mais crítica
Organizar a infra-estrutura sem afetar a velocidade do
desenvolvimento
Administrar as expectativas negativas da equipe e
ansiedade do cliente
Estimar sem ter um histórico
Infra-estrutura
Ambiente de desenvolvimento (IDE) - Eclipse
Code completion, assistente de importação, code inspection,
refatoramento
Ferramenta de build – Ant Controle de versão – CVS Ferramentas de teste
