|
1
|
|
|
2
|
- Vinicius Manhaes Teles, Extreme Programming, Novatec Editora
- Agile Software Development
- Scrum and XP from the Trenches
- Martin Fowler, Analysis Patterns - Reusable Object Models,
Addison-Wesley,1997
- Martin Fowler, Refatoração - Aperfeiçoando o projeto de código existente,
Ed Bookman
|
|
3
|
|
|
4
|
- Introdução
- Processo Unificado
- Manifesto Ágil
- XP
- DSDM
- SCRUM
- FDD
- Lean Software
- CONCLUSÃO
|
|
5
|
|
|
6
|
- Ainda vivemos em crise?
- Crise do Software = Conjunto de problemas enfrentados ao longo do
desenvolvimento.
- Problemas na Definição, Construção, Implantação, Manutenção.
- Foco no objetivo principal do desenvolvimento:
- Desenvolver o produto que atenda as necessidades do cliente e seja
entregue no prazo, com o custo e o nível de qualidade desejado.
|
|
7
|
- As estatísticas da Scientific American [filho, 2000] mostram que o tempo
realizado dos projetos de software excede em 50% o tempo planejado no
cronograma do projeto.
- O Standish Group relatou em 1994 [Standish, 1994] que apenas 16% dos
projetos de software atingem o seu objetivo dentro do cronograma e do
orçamento previstos.
- Os dados de 2001 do Standish Goroups [Standish, 2001] mostram as
seguintes estatísticas:
- 27% dos projetos de software são finalizados no tempo e custos
previstos;
- 40% dos projetos são cancelados antes de finalizarem;
- 42% dos projetos não apresentam as funcionalidades propostas
originalmente;
- 50% dos projetos custam em média 108% a mais da estimativa original.
|
|
8
|
- Cabe salientar que ocorreu uma melhoria nas estatísticas de projetos que
terminam dentro do prazo (cronograma) e orçamento previstos do Standish
Group de 1994 (16%) para 2001 (27%).
- O CHAOS Report [Standish, 2003] apresentou os seguintes dados:
- apenas 34% dos projetos são bem sucedidos;
- 15% dos projetos foram completados;
- apenas 52% das características e funcionalidades são entregues no
produto.
- Problemas:
- Dificuldade de corrigir defeitos quando o sistema cresce.
- Longa fase de debug/teste depois do sistema estar “completo”
(debug/teste é impossível de orçar)
|
|
9
|
|
|
10
|
- Olhando o cenário a nossa volta
|
|
11
|
|
|
12
|
- Não existe uma solução mágica e única, mas sim um conjunto de práticas
reconhecidamente eficientes.
- Desenvolvimento Incremental, Refinamento de Requisitos e Prototipação
Rápida, BONS PROJETISTAS...
- Melhorar a qualidade do software implica na melhoria do processo pelo
qual o mesmo é produzido.
- Assumir práticas de sucesso
- Garantir que estas práticas serão seguidas durante o desenvolvimento
- Ser fácil de seguir
- Evoluir com o aprendizado do grupo
- Na indústria atual, dois extremos foram definidos:
- Processos Monumentais X Hacking
|
|
13
|
- Objetivo:
- Previsibilidade,
- Comando e Controle
- Abordagem:
- Planejamento detalhado (“Engenharia” de software),
- Fases seqüenciais de processo (cascata, “cascatinha”)
- Artefatos de uma fase para a seguinte (“Fábrica de Software”)
- Problemas:
- burocracia à mais tarefas
para um resultado
- não adaptabilidade à
realidade (prazo, escopo, processo, pessoas) difere do
planejado/documentado
|
|
14
|
- A Decepção da UML
- Análise essencial dizia o QUE fazer, COMO fazer e QUANDO
- Quando surge a UML, o mercado queria um substituto para a Análise
Essencial
- UML é uma linguagem e não um processo. Ela fornece os elementos, mas
não define QUANDO usar
- O mercado rejeitou a UML por não compreendê-la
- RUP, XP são processos que se utilizam da UML
|
|
15
|
|
|
16
|
- Pressman (1995) destaca que, ainda que várias definições tenham sido
dadas à ES, todas reforçam a exigência da disciplina de engenharia no
desenvolvimento de software. Abrange um conjunto de três elementos
fundamentais:
- métodos, ferramentas e procedimentos.
- Desenvolvimento de Software é
Ciência ou Arte?!?
|
|
17
|
- Os métodos detalham "como fazer" para se construir o software.
- As ferramentas proporcionam apoio automatizado ou semi-automatizado aos
métodos.
- Os procedimentos constituem o elo de ligação que mantém juntos os
métodos e suas ferramentas, e possibilita um processo de desenvolvimento
claro, eficiente, visando garantir ao desenvolvedor e seus clientes a
produção de um
software de qualidade.
|
|
18
|
- Qual é a nossa missão?
- Desenvolver Software:
- Atendendo a todas as necessidades de todos os envolvidos
- Com o nível de qualidade esperado por nossos clientes
- Dentro do Prazo
- Dentro do Orçamento
|
|
19
|
|
|
20
|
- É necessário fazer uma análise de requisitos profunda e detalhada antes
de projetar a arquitetura do sistema.
- É necessário fazer um estudo minucioso e elaborar uma descrição
detalhada da arquitetura antes de começar a implementá-la.
- É necessário testar o sistema completamente antes de mandar a versão
final para o cliente.
|
|
21
|
|
|
22
|
|
|
23
|
- A atitude dos desenvolvedores de software seria completamente diferente:
- Tomaríamos as grandes decisões o mais tarde possível.
- Implementaríamos agora somente o que precisamos agora.
- Não implementaríamos flexibilidade desnecessária (não anteciparíamos
necessidades).
|
|
24
|
- Orientação a Objetos: facilita e cria oportunidades para mudanças.
- Técnicas de Refatoramento.
- Testes automatizados: nos dão segurança quando fazemos mudanças.
- Prática / cultura de mudanças: aprendemos técnicas e adquirimos
experiência em lidar com código mutante.
|
|
25
|
- Engenharia civil:
- Projeto (10 % do esforço): difícil de estimar
- Construção (90 %): planejamento detalhado
- Desenvolvimento de software
- Projeto (85 %)
- Codificação (15 %)
- Questões
- Decisões de design são feitas na codificação.
- “Construção” em software é automatizável ?
- Engenharia de Software ?
|
|
26
|
|
|
27
|
|
|
28
|
|
|
29
|
- RUP - Rational Unified Process
|
|
30
|
- Características:
- É um processo de Engenharia Software
- É um framework de processo
- É um produto
- Compatibilidade total com a UML
- Captura práticas consagradas no desenv de software:
- Desenvolver software iterativamente
- Gerenciar Requisitos
- Usar arquiteturas baseadas em componentes
- Modelar o software visualmente
- Verificar a qualidade do software continuamente
- Controlar mudanças no software
|
|
31
|
- Concepção
- Definição do Caso de Negócio do Projeto
- Definição do Escopo
- Verificação da Viabilidade do Projeto
- Elaboração
- Análise do Domínio do Problema
- Estabelecimento da Arquitetura do Sistema
- Construção
- Desenvolvimento Iterativo e Incremental
- Foco na Implementação e nos Testes
- Transição
- Entrega do Software para os Usuários
- Ajustes do Produto
|
|
32
|
- Algumas questões
- Como definir uma instância ideal do RUP para minha empresa?
- E em pequenas e médias empresas?
- Que pontos podem ser considerados a essência do RUP?
- Solução
- Utilizar os valores e princípios dos Processos Ágeis como maneira para
definir uma instância ideal do RUP.
|
|
33
|
|
|
34
|
- From www.agilealliance.org: We are uncovering better ways of developing
software by doing it and helping others do it. Through this work we have
come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- That is, while there is value in the items on
- the right, we value the items on the left more.
- agilemanifesto.org
|
|
35
|
- “Descobrimos melhores maneiras de desenvolver software fazendo-o e
ajudando os outros a fazê-lo. Através deste trabalho passamos a
valorizar”
- Indivíduos e iteração mais que processos e ferramentas
- Software que funciona mais que documentação detalhada.
- Colaboração do cliente mais que negociações contratuais.
- Responder às mudanças mais que seguir um plano.
- “Isto é, enquanto há um certo valor nos ítens do lado direito,
valorizamos mais os do lado esquerdo”
- Ref: http:// www.agilealliance.org
|
|
36
|
- Artigo de Martin Fowler (1999)
- Em muitos casos, as metodologias rigorosas não funcionam direito.
- Manifesto Ágil (2001)
- Pessoas mais que processos e ferramentas
- Software funcionando mais que documentação
- Colaboração mais que contratos
- Lidar com as mudanças mais que seguir planos
|
|
37
|
- Crystal Family
- Adaptive Software Development (ASD)
- SCRUM
- Feature-Driven Development (FDD)
- Dynamic System Development Method (DSDM)
- eXtreme Programming (XP)
- Agile Modeling (AM)
- Instância do RUP para XP
|
|
38
|
|
|
39
|
|
|
40
|
- Problemas:
- Planejamento/estimativas sobre atividades de design são muito
arriscadas
- (ficam lindas no Microsoft Project J)
- Expectativa/prioridades do cliente
- Mudanças nos negócios:
- nem o cliente controla (concorrência, legislação, ambiente econômico)
|
|
41
|
- Problemas
- Depender de premissas difíceis de ocorrerem
- Usar metodologias preditivas quando não dá (neurose newtoniana)
- Achar que você trabalha na NASA (cargo cult)
|
|
42
|
- Feedback
- Implementações que funcionam (ou não) ligam o desconfiômetro.
- Cliente experimenta com versão limitada (mas funcional) do software.
- No documento ficou lindo J,
mas na hora de implementar...L
- Iterações curtas
- Cada iteração se baseia na anterior
- Iteração =/= release
- Quanto dura uma iteração?
- XP: 1-3 semanas
- SCRUM: 4 semanas
- DSDM, Crystal: até 6 semanas
|
|
43
|
|
|
44
|
|
|
45
|
|
|
46
|
- Fábrica taylorista
- Quem faz o trabalho não decide como vai fazê-lo.
- Estimativas são feitas pelo pessoal de planejamento
- Operário não participa de projeto ou planejamento
- Produção é a atividade-fim.
- Desenvolvimento de Software
- Só quem faz o trabalho tem capacidade técnica para saber como fazê-lo.
- Estimativas mais confiáveis são feitas pelo desenvolvedor.
- Desenvolvimento é projeto,
planejamento
- “Produção” é automatizável (compilação, empacotamento)
|
|
47
|
- Aceitação X Imposição.
- Comprometimento.
- Desenvolvedores tomam todas as decisões técnicas.
- Gerência atua facilitando a comunicação com o cliente.
- Transparência entre os participantes (incluindo o cliente)
|
|
48
|
- Aprendizado para melhoria do processo a cada iteração.
- O quê fizemos melhor/pior?
- O quê aprendemos ?
- O quê nos intriga, ou incomoda, ou “cheira” ?
- Métodos voltados a adaptação:
- ASD, Crystal
- XP, não no início: faça “pelo manual” durante as iterações iniciais.
Sinergia entre as práticas precisa ser compreendida pela equipe.
|
|
49
|
|
|
50
|
- Objetivo:
- Compromisso entre “nada de processo” e processos rigorosos à foco na eficiência.
- Meios:
- Adaptabilidade,
- Cada item de processo deve agregar valor,
- Orientação a pessoas,
- Comunicação
- Aprendizado.
- Problemas:
- Escalabilidade a equipes grandes/dispersas,
- Cultura: mudança de paradigma
|
|
51
|
- Software é seu objetivo primário
- Habilitar o próximo esforço é seu objetivo secundário
- Travel Light
- Mudanças incrementais
- Modele com um propósito, Modelos múltiplos
- Conteúdo é mais importante que representação
|
|
52
|
|
|
53
|
- Modelo = Documentação
- Você pode conhecer tudo desde o início
- Modelagem implica um processo de software pesado (heavy-weight)
- Você deve congelar os requisitos
- Seu design está “cravado na pedra”
- Você deve usar uma ferramenta CASE
- Modelagem é perda de tempo
- O mundo gira em torno da modelagem de dados
- Todos os desenvolvedores sabem como modelar
|
|
54
|
|
|
55
|
|
|
56
|
|
|
57
|
|
|
58
|
- O Feature-Driven Development (FDD) foi criado pelo pessoal da
TogetherSoft (Peter Coad e Jeff De Luca)
- http://thecoadletter.com/download/fddguide/
- FDD surgiu como solução para o seguinte problema:
- acomodar ciclos de negócio cada vez mais curtos;
- FDD apresenta um mecanismo simples e eficiente para indicar o progresso
dos projetos, constituindo uma ferramenta valiosa para gerenciamento de
projetos;
- FDD é também um processo ágil, iterativo e incremental com iterações
curtas como o XP. Mas, por outro lado, FDD é um processo orientado a
modelagem
|
|
59
|
- FDD começa estabelecendo a forma de um modelo geral e, então, continua
com uma série de iterações de 2 semanas no estilo “design by feature,
build by feature”.
|
|
60
|
- 5 processos:
- 1- Modelo geral (arquitetura)
- 2 -Lista de features:
- Levanta requisitos para todo o projeto
- 3 - Plan by feature:
- Define escopo de cada iteração (quais features)
- Forma times para desenvolver cada feature.
- (A cada iteração):
- 4 - Design by feature
- 5 - Build by feature
|
|
61
|
- Baseado em modelos e guiado por características e implementado em ciclos
curtos de iterações
- Os ciclos de implementação de uma característica são de no máximo 2
(duas) semanas. O desenvolvedores gostam porque estão permanentemente
recebendo novas tarefas. Os clientes gostam por que vêem os resultados
rapidamente, gerando uma sensação de fechamento das atitividades...
- Busca-se focar os esforços nas funcionalidades que sejam úteis aos olhos
dos clientes. Procura-se restringir a lista de funcionalidades
(características) àquelas que os usuários podem entender (as features)
|
|
62
|
- Uma feature ou característica é uma função com valor para o cliente e
que pode ser implementada em duas semanas ou me-nos e é descrita da
seguinte forma:
- <ação><artigo><resultado><preposição><artigo><objeto>
- Exemplos:
- calcular o total de uma venda
- calcular o total de compras de um cliente
- As features podem ser agrupadas em um feature set. Neste caso são assim
descritas:
- <ação - verbo no particípio><artigo><objeto>
- Exemplos:
- Comprando um produto
- Efetivando um pagamento
- Uma major feature set representa um conjunto completo de
funcionalidades:
- Gerenciamento de venda de produtos
|
|
63
|
|
|
64
|
- Sobre os papéis:
- Papéis chaves
- Gerente de projeto, arquiteto-chefe, gerente de desenvolvimento,
programador-chefe, dono-de-classe, especialista no negócio
- Papéis de suporte
- Gerente de liberações, gerente de configuração, administrador de rede,
especialista na ferramenta, testador, documentador, etc...
- Papéis adicionais
|
|
65
|
|
|
66
|
- Sobre as práticas:
- Modelagem dos objetos de negócio
- Desenvolver por características
- Posse de classes de código fonte
- Cada classe tem um responsável e ele é responsável por sua construção
e manutenção
- Time de características
- Cada feature tem um responsável
- Builds regulares
- Visible Progress Report
- Inspeções
|
|
67
|
|
|
68
|
|
|
69
|
|
|
70
|
|
|
71
|
- Prevê a Participação intensa do usuário como membro efetivo da equipe;
- Ciclos muito curtos – uma, duas semanas para dar retorno concreto;
- Testes, Testes, Refactoring e Testes
- Faça o essencial para resolver o seu problema
- Documente Sim! O que realmente for feito
- Muito Interessante para Projetos Pequenos e Médios
|
|
72
|
- Simplicidade, Comunicação, Feedback e Coragem
- “Estamos evidenciando maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:
- Indivíduos e interação 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.
- Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens
à esquerda.”
|
|
73
|
- Existem aspectos positivos e negativos em cada uma das abordagens;
- Nem todos os contratos podem ser feitos na base da “camaradagem”
- Não pense duas vezes: Teste Duas Vezes!!!
- Será que você realmente tem que pagar uma fortuna por uma ferramenta?
- A Documentação deve ser feita e
faz parte do Produto final! Não vamos retroceder...
- Procure usar documentos padronizados
- Cuidado com aspectos Religiosos
|
|
74
|
- Projeto C3 (Chrysler) - Kent Beck (1996)
- http://www.xprogramming.org
- Valores:
- Comunicação
- Simplicidade
- Feedback
- Coragem
- Práticas:
- Pair Programming, Refactoring, Simple Design, Test-driven development
- Collective Ownership, Coding Standard, Continuous Integration,
Sustainable Pace
- Customer tests, Whole Team, Planning Game, Small Releases, Metaphor
|
|
75
|
- Proprietária do con$órcio DSDM (Reino Unido, 1994)
- Ciclo:
- Estudo de viabilidade
- Estudo do negócio (workshops)
- 3 ciclos em paralelo, entrelaçados
- Ciclo do modelo funcional -> análise e protótipos
- Ciclo de design e build -> engenharia do produto
- Ciclo de implementação -> implantação operacional
- Princípios:
- Iterações fixas (2-6 semanas)
- Releases frequentes
- Qualidade total
- Adaptabilidade a mudanças de requisitos
|
|
76
|
- Alistair Cockburn (IBM – anos 90)
- http://alistair.cockburn.us/
- Cada projeto uma metodologia.
- 4 parâmetros determinam o método de desenvolvimento:
- Tamanho da equipe
- Localização geográfica
- Criticalidade/Segurança
- Recursos
- A recomendação de quais os artefatos, papéis e ciclo de desenvolvimento
de um projeto é parametrizada.
- O processo é revisado no fim de cada iteração.
|
|
77
|
- Richard Stallman (anos 80), Linus Torvalds (anos 90)
- http://www.opensource.org/
- Inicialmente, para software básico
- Maintainer:
- Orienta o desenvolvimento
- Decide o quê vai entrar no software “oficial”
- Catedral X Bazar
- Catedral: releases pouco freqüentes, desenvolvimento centralizado (GNU,
BSD)
- Bazar: releases freqüentes, desenvolvimento mais espalhado (Linux
kernel, apache.org)
|
|
78
|
- Jim Highsmith (1997)
- http://www.adaptivesd.com/
- Sistemas complexos => Resultados imprevisíveis
- Ciclo:
- à Colaboração à EspeculaçãoàAprendizado
- Abordagem:
- Do it wrong the first time: erre cedo, corrija cedo, não potencialize
mal-entendidos.
- Good enough quality: melhor compromisso entre dimensões de qualidade (extrínseca
e intrínseca) para os recursos disponíveis.
- Mecânica: RAD (rapid application development), sessões JAD (joint
application development) com o cliente.
|
|
79
|
|
|
80
|
|
|
81
|
- Jeff Sutherland, Ken Schwaber (1993)
- http://www.controlchaos.com/
- Sprints de 30 dias
- Estabilizar requisitos em cada iteração
- Scrum (reunião de status) diária (15 min)
- Guia o desenvolvimento daquele dia
- Foco em gerência e tracking
- Pode ser combinado com métodos mais prescritivos (ex: XP@scrum)
|
|
82
|
- O termo Scrum é uma metáfora para uma situação em um jogo de Rugby. Esta
situação envolve um grupo denso de pessoas, lutando pela posse da bola.
- um pouco de história...
- O Scrum não é um método completo... Não requer que seja utilizada
nenhuma prática ou técnica para o desenvolvimen-to de software
- Utiliza pequenos times...
- É um método para gerenciamento de um projeto de software
|
|
83
|
- Processos definidos X processos empíricos :
- Um processo definido usa uma base de conhecimento sobre o processo: são
descritos como reproduzíveis
- Um processo empírico envolve atividades complicadas, não reproduzíveis
e com resultados imprevisíveis
- Segundo Ken Schwaber, autor do Agile Development Methods with Scrum, as
atividades envolvidas no desenvolvimento de software são complexas e
poucas geram resultados repetidos
- O Scrum baseia-se nos métodos utilizados nas fábricas químicas, que
utilizam muito inspeções e ajustes.
|
|
84
|
- Principais conceitos da metodologia Scrum:
- Time: máximo 7 pessoas, multifuncionais, desenvolvedores e usuários
- Backlog do Produto
- Sprint: ciclo de desenvolvimento mensal
- Sprint Backlog
- Reunião de Planejamento do Sprint
- Reunião do Scrum diário
- Comunicação e retroalimentação
- ScrumMaster: lider responsável
- Incremento de produto potencialmente entregável: funcionalidades
implementadas, testadas e com performance adequada...
|
|
85
|
|
|
86
|
|
|
87
|
|
|
88
|
- Mary Poppendieck (2000)
- http://www.poppendieck.com/
- Focado na identificação de gargalos no processo de desenvolvimento de
software
- Metáfora (boa) de fábrica
- Empresta idéias de
- Qualidade Total, (Deming, anos
50)
- Lean Production (Japão, anos 50)
- Teoria de Sistemas Dinâmicos (MIT, anos 60)
- Lean Construction (adaptabilidade na construção civil, anos 90)
|
|
89
|
|
|
90
|
|
|
91
|
- 200 organizações. Por faturamento:
- >= US$ 1bi: 13%
- >= US$ 100, < US$ 1 bi: 17%
- >= US$ 5m, < US$ 100m : 33%
- < US$ 5m: 37%
- Exposição a metodologias/normas tradicionais:
- Rational Unified Process: 51%
- CMM: 27%
- ISO 9000: 26%
|
|
92
|
- % de empresas com mais da metade dos projetos definidos como ágeis
- 2001: 21%
- 2002: 34%
- 2003 (previsão): 50%
- Metodologias ágeis mais usadas (não caseiras)
- XP: 38%
- Feature-Driven Development: 23%
- Adaptive Software Development: 22%
- DSDM: 19%
- Complexidade dos projetos é similar (rigorosas X ágeis), ágeis
trabalham com prazos similares, mas equipes muito menores.
- http://www.cutter.com/freestuff/apmupdate.pdf
|
|
93
|
- Questões em aberto:
- Times grandes
- Times dispersos geograficamente
- Contratos com preço e escopo fixos
- Resistências culturais
- Cliente
- Gerência
- Desenvolvedores
- Departamento Jurídico
- Departamento de Qualidade
|
|
94
|
- O manifesto ágil:
- Satisfação do cliente através de entregas mais cedo e contínuas,
utilizando ciclos de iteração menores
- Aceitação e acomodação de requistos em qualquer tempo do
desenvolvimento
- Desenvolvedores e usuários trabalhando juntos
- Times motivados e em ambientes apropriados
- Minimização de documentação e maximização de troca de informação face2face
- Encorajamento de atitudes reflexivas e contínuo aprendizado
- O problema da avaliação métodos...
|
|
95
|
|
|
96
|
- Outros Agile Methods...
- ASD (Adaptive Software Development)
- Mission-driven, component-driven (results), time-limited, timeboxed;
risk driven; change tolerant
- Crystal Clear
- Strong communications; frequent deliveries; reduce overhead;
management by milestones and risk lists
- DSDM (Dynamic Systems Development Model)
- User involvement, stakeholder collaboration; empowered team; frequent
delivery; backtracking to reverse changes; high-level requirements
baselining; iterative and incremental development; integrated
lifecycle testing;
|
|
97
|
|
Anotações
