Laboratório de Desenvolvimento de
Aplicações com Métodos Ágeis
Aula
Introdução Processos e Métodos Ágeis
Pós-Graduação
Engenharia de Software
Prof. Dr. Rogério Augusto Rondini rarondini.paradygma@gmail.com
Aula 01
Introdução a Processos de
Desenvolvimento
Modelos Cascata e Iterativos
RUP
Manifesto Ágil
XP
Processos
●
Conjunto de atividades realizadas
durante o desenvolvimento de
software
●
Duas grandes categorias de
processos
–
Cascata
Cascata
●
Modelo sequencial linear
ENGENHARIA DE SISTEMAS/ ESPECIFICAÇÃO DE REQUISITOS ENGENHARIA DE SISTEMAS/ ESPECIFICAÇÃO DE REQUISITOS PROJETO PROJETO ANÁLISE ANÁLISE CODIFICAÇÃO CODIFICAÇÃO MANUTENÇÃO MANUTENÇÃO TESTE TESTE
Iterativos
●
Vantagens
–
Tolerância às mudanças de
requisitos
–
Elementos de software integrados
progressivamente
RUP
●
Processo Iterativo e Incremental
●
Conta com um conjunto de atividades
bem definidas...
–
com artefatos de entrada e saída
–
dependência em relação à ordem
de execução
–
Descrição de como as atividades
RUP - Fases
Fase de Iniciação (concepção)
Especifica a visão do produto final.
Objetivos Principais:
Estabelecer o escopo do software do projeto;
Discriminar os casos de uso críticos do sistema, os
principais cenários de operação;
Estimar o custo do projeto inteiro;
Estimar riscos em potencial;
RUP - Fases
Fase de Elaboração
Planeja as atividades necessárias e recursos exigidos. Especifica as características e projeta a arquitetura. Objetivos Principais:
Assegurar que a arquitetura, os requisitos e os planos
sejam estáveis o suficiente e que os riscos sejam
suficientemente diminuídos a fim de determinar com
segurança o custo e a programação para a conclusão do desenvolvimento;
Produzir um protótipo evolutivo dos componentes; Estabelecer um ambiente de suporte.
RUP - Fases
Fase de Construção
Constrói o produto.
Objetivos Principais:
Atingir a qualidade adequada com rapidez e eficiência;
Atingir as versões úteis (alfa, beta e outros versões de
teste) com rapidez e eficiência;
Concluir a análise, o design, o desenvolvimento e o teste
de todas as funcionalidades necessárias;
Decidir se o software, os locais e os usuários estão prontos
RUP - Fases
Fase de Transição
Entrega, treina, apóia e mantém o produto.
Objetivos Principais:
Testar para validar o novo sistema em confronto com as
expectativas do usuário;
Testar em operação paralela relativa a um sistema legado
que está sendo substituído;
Converter bancos de dados operacionais; Treinar usuários e equipe de manutenção;
RUP - Disciplinas
Disciplina de Modelagem de Negócios
Objetivos Principais:
Entender a estrutura e a dinâmica da organização na qual
um sistema deve ser implantado;
Entender os problemas atuais da organização-alvo e
identificar as possibilidades de melhoria;
Assegurar que os clientes, usuários e desenvolvedores
RUP - Disciplinas
Disciplina de Requisitos
Objetivos Principais: Estabelecer e manter concordância com os clientes e outros
envolvidos sobre o que o sistema deve fazer;
Oferecer aos desenvolvedores do sistema uma compreensão
melhor dos requisitos do sistema;
Definir as fronteiras do sistema (ou delimitar o sistema); Fornecer uma base para planejar o conteúdo técnico das
iterações;
Fornecer uma base para estimar o custo e o tempo de
desenvolvimento do sistema;
RUP - Disciplinas
Disciplina de Análise e Design
Objetivos Principais:
Transformar os requisitos em um projeto do sistema a ser
criado;
RUP - Disciplinas
Disciplina de Implementação
Objetivos Principais:
Definir a organização do código em termos de subsistemas
de implementação organizados em camadas;
Implementar classes e objetos em termos de componentes;
RUP - Disciplinas
Disciplina de Teste
Objetivos Principais:
Localizar e documentar defeitos na qualidade do software;
Avisar de forma geral sobre a qualidade observada no
software;
Validar as funções do software conforme projetadas;
Verificar se os requisitos foram implementados de forma
RUP - Disciplinas
Disciplina de Implantação
Objetivo Principal:
Descrever as atividades que garantem que o produto de
RUP - Disciplinas
Disciplina de Gerência de Configuração e Mudança
Objetivo Principal:
Controlar mudanças feitas nos artefatos de um projeto e
RUP - Disciplinas
Disciplina de Gerência de Projeto
Objetivos Principais:
Fornecer um suporte para gerenciar projetos de software
e gerenciamento de risco;
Fornecer diretrizes práticas para planejar, montar a
RUP - Disciplinas
Disciplina de Ambiente
Objetivo Principal:
Descrever as atividades para o desenvolvimento das
diretrizes de suporte de um projeto. A meta das atividades dessa disciplina é oferecer à organização o ambiente de desenvolvimento de software — processos e ferramentas — que dará suporte à equipe de desenvolvimento.
RUP
Benefícios
Como todo processo iterativo, o RUP suaviza os riscos e é
maleável a mudanças que possam ocorrer;
O processo do modelo RUP possui uma ferramenta de apoio
também chamada RUP, que pode ser configurada de acordo com a necessidade de cada empresa .
Problemas
Complexidade de suas fases e fluxos;
Indispensáveis para os profissionais capacitados no
Manifesto Ágil
●
Em 2001, Kent Beck e 16 outros notáveis da
indústria de software, conhecidos como Aliança
Ágil, assinaram o Manifesto para o
Desenvolvimento Ágil de Software (
http://agilemanifesto.org/
ou
Manifesto Ágil
1) Indivíduos e interação entre eles mais que processos e ferramentas
2) Software em funcionamento mais que documentação abrangente
3) Colaboração com o cliente mais que negociação de contratos
4) Responder a mudanças mais que seguir um plano
Estamos descobrindo maneiras melhores de desenvolver
software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
Os 12 princípios
●Satisfação do cliente por meio de entrega
contínua
●Modificação de requisitos são bemvindas
●Entrega de software funcionando
frequentemente
●Pessoal de negócio e desenvolvedores
trabalhando juntos
●Indivíduos motivados
Os 12 princípios
●Conversa face a face para levantar
informações
●Software funcionando como medida de
progresso
●Ritmo constante de desenvolvimento
sustentável
●Excelência técnica
Os 12 princípios
●
Equipes autoorganizadas
●
Equipe reflete sobre como se tornar mais
efetiva, então sintoniza e ajusta
Alguns processos
●
Extreme Programing (XP)
●
Família Crystal
●
Scrum
●
Feature Driven Development (FDD)
XP
●Valores
–Comunicação
–Simplicidade
–Feedback
–Coragem
XP
●Práticas
Processo de
Planejamento
(“Planning Game”)
Releases Curtos
Metáfora
Projeto(Design)
Simples
Testes
Refactoring
Programação em Pares
Propriedade Coletiva do
Código
Integração Contínua
Semana de 40 Horas
On-Site Customer
(Cliente sempre presente)
On-Site Customer
Um cliente deve estar sempre presente, ajudando a equipe a
responder questões, resolver disputas e colocar pequenas prioridades em tarefas.
Pode-se dizer que um cliente é muito caro para se disponibilizar
para a equipe de desenvolvimento.
Gerentes devem dizer o que tem mais valor: o software estar pronto
mais cedo ou o trabalho de uma ou duas pessoas.
Segundo o Standish CHAOS Report de 1998 os principais fatores
de sucesso para um projeto são o envolvimento do usuário, suporte dos executivos e objetivos de negócio claros (50% de importância, em conjunto).
Releases Curtas
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.
Se iterações curtas são boas(como reconhecido por Fred
Brooks), elas serão feitas bem pequenas - alguns dias,
semanas ou um mês por vez é melhor que seis meses ou um ano com antecedência.
Releases Curtas
dia
Planning Game
A XP trabalha com dois níveis de planejamento.
Planejamento do release: Cliente propõe “user stories”(estórias) e
os desenvolvedores avaliam sua dificuldade através de semanas ideais.
Planejamento de iteração: 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.
Cada iteração é feita como uma “timebox”. Caso não se consiga
implementar todas as funcionalidades requeridas, as que sobrarem são colocadas na próxima iteração. Nunca se atrasa um
“milestone”(marco).
O cliente pode mudar suas prioridades de requisitos a cada
iteração que passa. Como elas são curtas(média de duas semanas) isso garante que mudanças são incorporadas tranqüilamente.
Metáfora
A metáfora é um meio de ajudar a todos(clientes e
desenvolvedores) a compreender melhor o objetivo e propósito do produto sendo criado.
Pode ser considerado como a arquitetura de um sistema, vista
como uma análise de domínio. Desse modo, pode-se construir entidades de software com alta coesão e baixo acoplamento entre si.
Se arquitetura é importante, todos irão trabalhar definindo-a e
Design Simples
Muitos projetos têm requisitos vagos e o futuro, como se sabe, é
incerto. Além disso, mudar de idéia em um produto de software é muito fácil para os clientes(e natural).
Portanto, conclui-se que colocar funcionalidades com base em
especulações é inútil e pode causar o perigoso “feature creep”.
Se a simplicidade está na ordem do dia, sempre teremos um
sistema com o design mais simples que possa suportar suas funcionalidades correntes.
Refactoring
Uma prática desenvolvida por Martin Fowler. Busca melhorar o
design e a arquitetura de código OO já existente. Combate a entropia do software.
XP prega o refactoring contínuo e constante.
Problemas mais comuns: código duplicado, métodos longos,
lista de parâmetros longos, grandes “switches”, comentários estranhos.
Se design é bom, ele fará parte do dia-a-dia do desenvolvimento
Testes
Parte fundamental da XP. Aumenta a confiança dos
desenvolvedores e dos clientes. Os testes agem como uma ótima documentação do código em produção.
Test-driven development!!! Desenvolvedores criam testes de
unidade automatizados antes de codificar uma funcionalidade.
Clientes(com o apoio de pessoal de testes) criam os testes de
aceitação para cada user story que entra numa iteração.
Se testes são bons, os desenvolvedores vão testar sempre
(testes de unidade) e antes de criar o código. Até mesmo os clientes irão testar (testes de aceitação).
Programação em Pares
Todo o design e código é feito sempre por duas pessoas agindo
como um par.
Os pares são dinâmicos. Um trabalho taticamente e outro
estrategicamente. Ambos trocam de papéis regularmente.
Os pares não são fixos. Cada membro da equipe irá com certeza
trabalhar com todos os outros pelo menos uma vez durante o projeto.
Se revisões e inspeções de código são boas, elas serão feitas o
Prop. Coletiva Código
Módulos não são “propriedade” de nenhum desenvolvedor.
Todo desenvolvedor da equipe tem o direito de checar um
módulo e modificá-lo.
O código é propriedade da equipe. Dessa maneira, todos os
Integração Contínua
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.
Se integração de código é importante, ela será feita várias vezes
Semana de 40 horas
Tempo de trabalho extra é um sintoma claro de problemas em
um projeto.
A regra da XP é simples: nunca mais de uma semana de tempo
extra de uma vez.
Se problemas graves são detectados, a iteração ou o release
são replanejados.
Trabalho extra é mal pois irá destruir: a equipe, o design, o
código, o produto final. Muito trabalho extra causa stress e diminui a produtividade e a qualidade do trabalho.
Padrões de Codificação
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.
Limitações
Equipes grandes e/ou espalhadas em locais distintos. A XP
preza a comunicação como princípio fundamental. Isso se complica na situação acima.
Projetos onde existe código legado difícil de ser modificado ou
controlado.
Projetos aonde o feedback é lento. Por exemplo: processo de
compilação-linkagem-build-teste que demoram muito tempo; dificuldade em se criar testes de unidade e de aceitação.
Podem ser utilizadas outras metodologias ágeis, como a FDD,
ASD ou Crystal para projetos com equipes maiores ou uma adaptação do modelo de desenvolvimento open source para equipes geograficamente distribuídas.
