Processos de
desenvolvimento de software
– Ciclos de vida – Processos
ágeis
2
Processos ágeis
"Manifesto Para o Desenvolvimento Ágil de Software“ reunião entre Kent Beck e 16 outros gurus da comunidade de desenvolvimento em 2001. Alternativas para melhorar produtividade de desenvolvimento de
software
Conjunto de princípios comuns em projetos de sucesso.
Não é contrário à solida prática da engenharia de software e pode ser aplicado como uma filosofia prevalecente a todo o trabalho
Ataca alguns pontos de deficiência dos modelos prescritivos: “a fragilidade das pessoas que
constroem o software”, grande variedade de estilos de trabalho e diferenças de habilidade,
Processos ágeis
Princípios básicos valorizados nas metodologias ágeis:
Indivíduos e interações entre eles, ao invés de processos e
ferramentas
Software funcionando ao invés de documentação
compreensiva e detalhada.
Colaboração com os clientes ao invés de negociação de
contratos.
Adaptação às mudanças ao invés de seguir um plano
inicial.
Processos ágeis
Cada vez mais empresas declaram que utilizam Processos ágeis: Será que são ágeis mesmo?
Nem todas empresas que utilizam processos realmente ágeis. Termo tem sido utilizado para qualquer projeto com iterações curtas.
Empresas têm sido pressionadas para produzir melhor e mais rápido então usam processos ágeis
Existem bons relatos sobre processos ágeis e poucos relatos de como deve ser reorganizada as equipes conforme o conceito do ágil em relação aos processo existentes anteriormente como por exemplo equipe de testes.
Quando deve ser usado o
desenvolvimento ágil?
O desenvolvimento ágil é particularmente indicado
em situações onde os requisitos são imprevisíveis ou
mudam rapidamente.
Ele funciona melhor para equipes pequenas (até 10
desenvolvedores) trabalhando no mesmo local.
Processos ágeis
Afinal o que é ágil?
Ivar Jacobson: “Uma equipe ágil é uma equipe esperta, capaz de responder adequadamente a modificações. Modificação é aquilo para o qual o desenvolvimento de software está focado,
modificações nos membros da equipe, modificações por causa de novas tecnologias, modificações de todas as especieis que podem ter impacto no produto ou no processo que cria o
produto”
Na visão de Ivar Jacobson, o acolhimento de modificações é o principal guia para a agilidade porém não só isso também engloba a filosofia apresentada no manifesto.
Processos ágeis
Manifesto com seus princípios para aqueles que querem
alcançar a agilidade:
Ter como maior prioridade satisfazer o cliente por meio
da entrega de software valioso.
Modificações de requisitos contínuas e mesmo que tardias
são bem-vindas e levam à competitividade para o cliente.
Entrega de software funcionando em períodos de duas
semanas a dois meses.
Evento ocorrido em 2001
WebSite: http://www.agilemanifesto.org
Processos ágeis
Manifesto com seus princípios para aqueles que querem alcançar a agilidade:
O pessoal de negócio e os desenvolvedores devem trabalhar
juntos diariamente durante todo o projeto.
Construção de projetos em torno de indivíduos motivados.
Forneça-lhes condições de trabalho e confie na entrega.
O métodos mais eficiente e efetivo de levar informação para a
equipe é a conversa face a face.
Software funcionando é a principal medida de progresso.
Promover o desenvolvimento sustentável, mantendo um ritmo
de produção.
Processos ágeis
Manifesto com seus princípios para aqueles que querem
alcançar a agilidade:
Atenção contínua à excelência técnica e ao bom projeto
facilita a agilidade.
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.
O que é um processo ágil?
É um processo que atenda a três suposições:
1- É difícil prever antecipadamente quais os requisitos que
vão persistir e quais serão modificados.
2- É difícil prever quanto o projeto é necessário antes que
a construção seja usada para comprovar o projeto
O que é um processo ágil?
É um processo que atenda a três suposições:
3- Análise, projeto, construção e testes não são tão
previsíveis como gostaríamos
Um processo ágil, portanto deve ser adaptável. Adaptado
incrementalmente requerendo o feedback do cliente de
forma contínua, influenciando as adaptações no
Fatores humanos
Características-chave de uma equipe ágil:
•
Competência:
• Talento inato, habilidades específicas relacionadas ao software e
conhecimento global do processo.
•
Foco comum
• Mesmo tendo vários papéis distintos todos devem estar focados na meta de entregar o incremento
•
Colaboração
• Na avaliação e analise das informações deve existir muita colaboração entre clientes, equipe e gerentes de negócio
•
Capacidade de tomada de decisão
Fatores humanos
Características-chave de uma equipe ágil:
•
Habilidade de resolver problemas vagos
• O gerente deve ter em mente que a equipe será frequentemente confrotada com problemas por modificações e ambiguidades e as lições aprendidas devem ser aproveitadas
•
Respeito e confiança mútua
• Uma equipe consolidada que exisge confiança e respeito
•
Auto-organização
• A equipe se organiza para o trabalho a ser feito, organiza o processo
para acomodar seu ambiente e organiza o cronograma de trabalho para entrega do incremento de software
•XP (eXtreme Programming)
•SCRUM
•ASD (Adaptive Software Development) ou DAS
Desenvolvimento adaptativo de software
•DSDM
( Dynamic Systems Development
Method) ou Método desenvolvimento
dinâmico de sistemas
•Família Crystal
•FDD (Feature-driven development) Desenvolvimento
guiado por características
A maioria dos autores participaram do manifesto ágil.
“Trata-se de uma metodologia ágil para
equipes pequenas e médias
desenvolvendo software com requisitos
vagos e em constante mudança”
O que é Extreme Programming
Trabalho pioneiro sobre o assunto escrito em 1999 por Kent Beck. • Usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento.
Identificou o que tornava simples e o que dificultava o desenvolvimento de software
• Inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades de arcabouço:
Planejamento Projeto
Codificação Teste
Uma das metodologias ágeis mais conhecida Produz software em pequenas iterações
Necessário a participação de um usuário com poder de decisão. Utiliza forma simples de planejamento do que entrará na próxima iteração.
Usuário define quais testes devem ser realizados para que o produto seja aceito.
Iteração dura tipicamente de 1 a 3 semanas
O desenvolvimento é dividido em liberações (toda
iteração resulta em uma liberação)
Programadores estimam o esforço
Clientes definem escopo e prazo com base nessa
estimativa
Programadores implementam apenas o que está no
escopo da iteração.
Uma iteração compreende um grupo de funções
chamadas de histórias de usuário.
Criação de um conjunto de histórias de usuário parecidas com casos de uso, mas com bem menos detalhes.
Cada estória é escrita em poucas linhas pelos clientes, que lhe
atribuem um valor, e deve poder ser implementadas em menos de três semanas.
Exemplo: “Quando a aplicação começa, o último documento em que o cliente estava trabalhando deve ser aberto automaticamente.”
A equipe XP e os clientes trabalham juntos para definir um plano que determina as estórias que serão desenvolvidas primeiro
levando em consideração valores e riscos.
Depois que o primeiro incremento é entregue, a equipe XP calcula a velocidade do projeto = número de histórias implementadas.
Ao longo do tempo, o cliente pode adicionar histórias, mudar o valor de uma história, subdividir histórias ou eliminá-las.
Segue o princípio KIS (keep it simple).
– Se restringe a implementar as histó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.
22
• 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 refabricação = modificar o sistema de tal modo que o comportamento externo não seja alterado, mas aperfeiçoe a estrutura interna.
– A refabricação ocorre durante a codificação.
23
•
Antes de partir para o código, a equipe deve desenvolver
testes unitários para verificar a funcionalidade que será
desenvolvida.
•
O código gerado vai sendo integrado imediatamente ao
trabalho de outros, o que ajuda a evitar problemas de
compatibilidade e interface.
24
•
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.
25
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 refabricação.
26
•
Testes de aceitação são especificados pelo cliente
(derivados das histórias do usuário) e focalizam nas
características e funcionalidades do sistema global.
– Devem ser automatizados e aplicados freqüentemente.
– O sistema só é considerado aceitável quando passar em
todos os testes de aceitação.
27
28
29
30
31
XP Papéis
•
Cliente
Define o que é o projeto e como deve ser desenvolvido, o termo de cliente pode não estar associado a uma pessoa individual, mas sim a um conjunto de pessoas que :
-> Define e dá prioridade as “user stories” -> Define requisitos do projeto
-> Descreve os testes que cada fase de desenvolvimento tem de passar antes de se passar à fase seguinte
XP Papéis
•
Treinador (Coach)
Orienta a equipe, tentado garantir que esta mantêm-se fiel à metodologia XP, para tal deve possuir os seguintes atributos
-> Grande compreensão da metodologia XP -> Sentido de liderança
-> Possuir grande conhecimento de programação orientada a objectos e de linguagens de programação
XP Papéis
•
Programador
São considerados o coração dos projetos XP, e estão presentes em todas as fases do desenvolvimento com a metodologia XP
-> Em conjunto com o cliente cria as User Stories -> Desenvolve código e testes
XP Papéis
•
Tester
Tem como objectivo realizar testes funcionais do projeto em
desenvolvimento, podendo esses testes serem efetuados junto do cliente, se o desenvolvimento foi efetuado corretamente existem poucas hipóteses de chegarem “bugs” graves a esta fase, pois o
código já se encontra testado a priori pelos programadores à medida que o vão escrevendo.
XP Papéis
•
Tracker
Cria estimativas de tempo sobre as User Stories e tarefas, verifica se o tempo gasto nas tarefas completas coincide com o previsto inicialmente, e vai atualizando o tempo total previsto para a duração do projeto. Tem ainda a responsabilidade de guardar um
histórico dos testes funcionais criando um registo dos problemas encontrados, assim como o número de classes métodos e linhas de código geradas.
•
Gerente
É a pessoa que lidera o projeto internamente e com o consumidor, e protege a equipe de interferências exteriores.
Muitas similaridades com o XP. O XP foca na
codificação SCRUM foca no planejamento.
Visa criar equipes auto-organizáveis
SCRUM
Definição informal:
Estratégia em um jogo de rugby onde
jogadores colocam uma bola quase perdida
novamente em jogo através de trabalho em
equipe.
Origens do SCRUM
•
Jeff Suttherland – jeffsutherland.com (Criador)
•
Ken Schwaber - www.controlchaos.com
•
Mike Beedle – www.mikebeedle.com (Principais
colaboradores)
•
Conferências
–
OOPSLA 96, PLoP 98
•
Inspiração
–
Desenvolvimento Iterativo e Incremental em empresas
O Scrum enfatiza o uso de padrões de processo que se mostraram efetivos para projetos com prazos apertados, requisitos mutantes e criticidade de negócio.
•
Backlog
•
Equipes
•
Sprints
•
Encontros Scrum
•
Revisões Scrum/Demos
Lista de todas as funcionalidades desejadas
É gerada incrementalmente
Começa pelo básico, o extra aparece com o tempo
Pode conter
Tarefas diretas, casos de uso e histórias (a la XP)
A lista é priorizada pelo dono do projeto
Cliente, depto de marketing, ...
Deve conter características que agreguem algum
valor de negócio ao produto
Novos requisitos aparecem quando o cliente vê o
produto
A arquitetura do sistema surge enquanto o projeto
surge e é refatorado
Sem nível hierárquico
Mas com várias especialidades os papéis podem se
alternar
Estão todos no mesmo barco
Geralmente equipes pequenas (até 10)
Comunicação é essencial
Encontro Scrum diário
Unidades básicas de tempo (até 30 dias)
Começa com um encontro Sprint
Tarefas do Backlog são priorizadas
A equipe seleciona tarefas que podem ser completadas durante o
Sprint
As mesmas podem ser quebradas para o Backlog do Sprint Cada tarefa recebe um responsável na equipe
Não há mudança nas tarefas durante o Sprint
•
Pequenos encontros diários da equipe
•
geralmente pela manhã
•
galinhas e porcos (só os porcos falam)
•
todos os porcos devem participar
•
Questões que aparecem devem ser resolvidas
durante o dia e não na reunião
•
Os encontros iniciais são geralmente mais
longos
Questões que devem ser respondidas por cada
porco:
1) O quê você fez ontem?
2) O quê você vai fazer hoje?
3) Quais os problemas encontrados?
Ajuda a manter as promessas
Evita: Como um projeto atrasa um ano?
Um dia por vez ...
Qualquer deslize pode ser corrigido de imediato
SCRUM – Encontro Scrum
•
Sempre o mesmo
local e hora
•
Pode ser o local de
desenvolvimento
•
Pessoas sentadas
ao redor de uma
mesa
•
A sala já deve estar
arrumada antes
•
Punições
(atrasos/faltas)
•
Todos devem
participar
•
Galinhas ficam na
periferia
•
Pode ser em pé
•
Sala bem equipada,
quadro branco, etc.
SCRUM – Revisão do Sprint
•
No final de cada Sprint é feita uma reunião com
todos os interessados
•
Geralmente
–
Na forma de demonstração
–
Informal (preparação rápida, sem projetor,..)
–
Deve ser o resultado natural de um Sprint
•
O projeto é comparado com os objetivos iniciais
do Sprint
SCRUM – Scrum Master
•
Faz com que a equipe viva os valores e
práticas de Scrum
•
Protege a equipe de:
–
Riscos e interferências externos
–
Excesso de otimismo
•
Resolve os problemas que aparecerem
–
logísticos
SCRUM – Scrum Master
•
Mantém o Backlog do Sprint
–
Tarefas completadas
–
Identifica eventuais problemas
Desenvolvimento Adaptativo de software
Adaptative software development – ASD
Foi proposto por Jim Highsmith como uma técnica para
construção de software complexos.
O apoio filosófico do ASD concentra-se na colaboração
humana e na auto-organização. A auto-organização
aparece quando agentes individuais independentes
cooperam para criar resultados emergentes. Um resultado
emergente é uma propriedade além da capacidade de
qualquer agente individual.
Ciclo de vida composto: Especulação,
colaboração e aprendizado
Especulação: iniciação do projeto e planejamento
adaptativo usndo informações como:
Declaração da missão pelo cliente
Restrições do projeto (ex. datas de entrega)
Requisitos básicos
Ciclo de vida composto: Especulação,
colaboração e aprendizado
Colaboração: pessoal motivado trabalha junto de
um modo que multiplica seus talentos e resultados
criativos.
• Abordagem colaborative recorrente
• Porem colaboração não é fácil e também não é
apenas comunicação
• Comunicar problemas e ou preocupações de um
modo que conduza a ação efetiva
Ciclo de vida composto: Especulação,
colaboração e aprendizado
Aprendizado: que pode ocorrer de três modos:
• foco nos grupos: feedback constante dos clientes
sobre os incrementos
• revisão técnicas formais: dos componentes visando a
qualidade e aprendizado
• pós-conclusão: cuidado com o desempenho e
processo para aperfeiçoar a abordagem
Método de desenvolvimento dinâmico de
sistemas
Dynamic Systems Development Method – DSDMOriginalmente baseada em "Desenvolvimento Rápido de
Aplicação" (RAD). DSDM é uma metodologia de
desenvolvimento iterativo e incremental que enfatiza o
envolvimento constante do usuário.
Seu objetivo é entregar softwares no tempo e com custo
estimados através do controle e ajuste de requisitos ao
longo do desenvolvimento.
Sugere filosofia emprestada de uma versão do
princípio de pareto: 80% de aplicação pode
ser realizada em 20% do tempo que levaria
para entregar 100% da aplicação
Sugerindo a cada iteração esse princípio
Ciclo de vida 3 ciclos iterativos diferentes
precedidos pelas atividades de “Estudo de
viabilidade” e de “Estudo de negócio”
Ciclos:
• Iteração do modelo funcional: produz protótipos incrementais que demostram a funcionalidade
• Iteração de projeto e construção: garatem que os
protótipos passaram pela engenharia e que agregam valor ao negócio
• Implementação: coloca no ambiente operacional, lembrando que o incremento pode não estar 100% Pode ser combinado com o XP combinando suas práticas
DSDM
Criado por Alistair Cockburn e Jim Highsmith a família Crystal de métodos ágeis
Conjunto de metodologias que os elementos centrais são comuns a todas, papéis, padrões de processos, produtos de trabalho e práticas.
A escolha da metodologia pode variar em relação ao tamanho do projeto (números de pessoas) e ambiente (criticidade do
projeto).
As metodologias Crystal compartilham a orientação humana tal como XP, porém é considerado menos disciplinado portando mais fácil as pessoas segui-la.
Grande importância às revisões no final das iterações, assim encorajando o processo a ser auto-melhorável
Desenvolvimento guiado por características, FDD Feature Driven Development
Concebido por Peter Coad, como modelo prático de processo OO e estendido por Stephen Palmer e John Felsing descrevendo um processo ágil e adaptativo para projetos.
No contexto do FDD uma característica “é uma função valorizada pelo cliente que pode ser implementada em duas semanas ou menos”
Ênfase na definição de características fornece benefícios:
• Pequenos blocos passíveis de entrega e mais fácil de
descrevê-las
• Mais fácil de organizar e agrupar hierárquicamente • Mais fáceis de inspecionar por ser pequenas
• O planejamento é guiado pelas características e não por
um conjunto de tarefas da ES. Gabarito para definir um característica:
<ação> o <resultado> <por|para|de|a> um <objeto> Em que objeto é “uma pessoa, lugar ou coisa”
Ex:
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
Agile Modeling – Modelagem ágil
• Uma metodologia de modelagem ágil, pode ser utilizada dentro de
metodologias ágeis mas também em metodologias prescritivas como o Unified Process.
• AM é uma coleção de práticas com princípios e valores que podem
ser aplicados no dia a dia, segundo Scott W. Ambler.
• AM não define procedimentos detalhados de como criar um modelo
e sim dá orientações de como o modelador poderá ser mais efetivo. Motivações principais:
1. O objeto principal de um projeto de software é o próprio software e não um grande conjunto de documentação sobre ele;
2. Um artefato é feito para permitir a comunicação e a troca de
informações entre a equipe e permitir a discussão e refinamento do modelo. Então, se um artefato não esta passando informação útil ao projeto, ele não cumpre seu objetivo.
Agile Modeling – Modelagem ágil Práticas fundamentais:
• Modelagem Iterativa e Incremental:
• Aplique o artefato correto(escolha o melhor modelo); • Crie vários modelos em paralelo(a melhor visão de cada
modelo);
• Modele em pequenos incrementos. • Trabalho em Equipe:
• Modelar com outras pessoas;
• Participação ativa do Stakeholder;
• Conhecimento coletivo (nunca deixe somente uma pessoa
dominar todo o processo, pois se a mesma sair da empresa, acabou o projeto);
• Exiba modelos publicamente (colocar em painéis, parede, etc.).
Agile Modeling – Modelagem ágil Práticas fundamentais:
• Simplicidade:
• Crie conteúdo simples (melhor um modelo com erros que
consiga passar o conteúdo que o modelo sintaticamente correto);
• Descreva modelos simples;
• Use a ferramenta mais simples. • Validação:
• Considere a testabilidade; • Prove com código.
Vantagens
Equipes pequenas Auto-gerenciável Integração contínua
Desenvolvimento voltado para testes Participação do usuário.
Redução dos riscos do não entendimento de um requisito.
Desvantagens e ou críticas
Falta de processo bem definido.
Preferência de comunicação face-a-face
Usuário pode não estar disponível para ajudar o tempo todo. Pode ser difícil demonstrar progresso.
Falta de estrutura e documentação necessárias
Somente trabalhar com desenvolvedores de nível sênior Requer a adoção de muita mudança cultural
Poder levar a maiores dificuldades nas negociações contratuais
