Fam

1
Família Crystal
Uma Metodologia Just-in-Time Centrada em Pessoas

• Fabiana Ferreira do Nascimento
• fabiana_at_dsc.ufcg.edu.br
• Leidjane Matos de Souto
• leidjane_at_dsc.ufcg.edu.br
• Kylly Araújo de Oliveira
• kylly_at_dsc.ufcg.edu.br

2
Roteiro

• Introdução
• Metodologias Ágeis
• Metodologias Just-in-Time
• Metodologia Crystal
• Metodologia Proposta
• Conclusões
• Referências

3
Introdução

• Desenvolvimento de Software no passado
• Engenharia de Software Tradicional
• Analisar, projetar, e só depois começar a
  construir
• Era preciso prever o futuro
• Como ter certeza que se sabe hoje exatamente o
  que se quer amanhã?
• Temores
• Mudanças nos requisitos depois que a fase de
  análise e design foi concluída

4
Introdução
5
Introdução

• Desenvolvimento hoje
• Metodologias modernas incentivam iterações curtas
• Mudanças em etapas avançadas do desenvolvimento
  seriam mais baratas
• Mudança não é mais um bicho tão feio
• Podemos conviver com a mudança

6
Introdução

• Desenvolvimento hoje (cont.)
• Se mudar já não custa tanto, por que não
  abraçá-la de uma vez?
• Deixar coisas que não são necessárias agora para
  depois
• Deixar de investir tanto tempo no design prévio
• Tomar a liberdade de mudar deliberadamente o
  design em qualquer etapa do desenvolvimento

7
Introdução
8
Introdução

• Hoje devemos procurar uma maneira para melhor
  adaptar no projeto as mudanças que irão surgir.
• Opções
• Metodologias densas
• Metodologias ágeis

9
Introdução

• Métodos ágeis podem conter a solução.
• A estratégia é reduzir o custo das mudanças.
  Como ?
• Diminuir o tempo de entrega das realeses
• Procurar soluções mais simples
• Fornecer projeto de qualidade continuamente
• Testar constantemente

10
Introdução

• Movimento iniciado por programadores experientes
  e consultores em desenvolvimento de software.
• Questionam e se opõe a uma série de
  mitos/práticas adotadas em abordagens
  tradicionais de Engenharia de Software e Gerência
  de Projetos.
• Manifesto Ágil
• Assinado por 17 desenvolvedores em Utah em
  fevereiro/2001.

11
Manifesto Ágil

• Estamos descobrindo 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çõ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.
• Ou seja, mesmo dando valor aos itens à direita,
  valorizamos
• mais os itens à esquerda."
• Kent Beck, Mike Beedle, Arie van Bennekum,
  Alistair Cockburn, ard 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

12
Metodologias ágeis

• Uma metáfora para Desenvolvimento de Software
• Um jogo Cooperativo de Invenção e Comunicação.
  Alistair Cockburn.
• Como um grupo de pessoas escalando uma montanha
  em conjunto.
• Jogo cooperativo, finito, onde se busca alcançar
  um objetivo.

• Como representantes de metodologias ágeis podemos
  citar XP, Scrum, Crystal etc.

13
Metodologias Ágeis

• Um time pode ser mais efetivo em realizar
  mudanças se
• Reduzir o custo de trocar informações
• Reduzir o tempo entre fazer uma decisão e ver as
  conseqüências dessa decisão

14
Metodologias Ágeis

• Pessoas ágeis não trabalham bem em ambientes de
  desenvolvimento densos e vice-versa.
• Processos rigorosos são projetados para adaptar
  as pessoas para uma organização, enquanto que
  processos ágeis são projetados para desenvolver o
  potencial em cada time ou indivíduo.
• O projeto é um ecossistema ?

15
Metodologias Ágeis

• Processos ágeis possuem as seguintes
  características
• Usa subprojetos curtos
• Refletindo sobre suas práticas
• Times pequenos e reunidos na mesma sala
• Atendendo a comunidade

16
Metodologias Ágeis

• Propostas para o gasto com recursos no projeto
• MFI o time pode escolher gastar recursos agora
  para ganhar informações o mais cedo quanto
  possível
• MFF o time pode optar a gastar recursos para
  preservar a flexibilidade posteriormente.
• Diferentes estratégias de projeto são feitas pela
  decisão de que acontecimentos são previsíveis,
  imprevisíveis mas resolvíveis, ou
  não-resolvíveis, decidindo quais são MFI ou MFF.

17
Metodologias Ágeis

• Dez princípios para metodologias ágeis
• Projetos diferentes necessitam de diferentes
  metodologias
• Quando existe risco se o projeto anda devagar ou
  com gasto de tempo em planejamento, então
  técnicas ágeis são mais apropriadas. Quando
  existe risco em saltar o planejamento então
  técnicas plan-driven são mais apropriadas.
• Metodologias pequenas trazem benefícios quando o
  custo aumenta
• Como metodologias pequenas exigem poucos
  elementos de controle, isso permite trabalhar com
  uma maior eficiência e atacar problemas maiores.

18
Metodologias Ágeis

• Grandes times necessitam de mais elementos de
  comunicação
• Projetos mais críticos precisam de mais elementos
  de validação
• Sistemas de armamentos automáticos necessita de
  um gasto maior de tempo na localização e
  eliminação de defeitos do que um sistema de
  emissão de ordens para almoçar num restaurante.
• Formalidade, Processo e Documentação não
  substituem a Disciplina, Habilidade e Compreensão
• Um gerente de projeto ágil confia em habilidades,
  qualidade e compreensão, e exibe menos da
  formalidade, processo e documentação

19
Metodologias Ágeis

• Interatividade, comunicação face-a-face é o canal
  mais barato e mais rápido para intercâmbio de
  informação
• Suponha que um desenvolvedor ganhe 2 por minuto.
  Considerando que ele faz 100 trocas de
  informações por semana, e que cada troca leva em
  média 1 minuto, então, por semana ele custa 200.
  Considerando que 1 ano possui 50 semanas, então
  ele custa por ano 10,000. Considere 10 pessoas
  no projeto, o custo aumenta para 100,000 por
  ano. Agora se considerarmos a troca de
  informações com pessoas de outra sala, e que no
  total, com o deslocamento entre as salas se gaste
  5 minutos, por conta de atraso das escadas ou do
  elevador, temos o custo elevado para 500,000.

20
Metodologias Ágeis

• Aumento de comunicação e feedback reduz a
  necessidade para produtos intermediários
• O aumento do uso de comunicação interativa nunca
  eliminará a necessidade de documentação de
  projeto, mas pode reduzir durante os estágios de
  projeto e desenvolvimento.
• Desenvolvimento concorrente para determinar o
  projeto em tempo menor versus Desenvolvimento
  serial para obter um custo menor no
  desenvolvimento do projeto.

21
Metodologias Ágeis
22
Metodologias Ágeis

• Eficiência é direcionada também de forma a não
  engargalar atividades
• A prudência nos diz que os modeladores devem
  completar e estabilizar a sua tarefa antes de
  passá-la para o DBA.

23
Metodologias Ágeis

• Desenvolvimento sobre pontos estratégicos
• Desenvolvedores dedicados
• Desenvolvedores experientes
• Pequenos times
• Testes automatizados
• Fácil acesso aos usuários

24
Metodologias Just-in-Time (ou dinâmica)

• Levando em consideração as peculiaridades dos
  métodos ágeis outra questão a se levantar é
  quanto a adaptabilidade do projeto no tempo
• Algumas idéias ajudam na construção de uma
  metodologia just-in-time (ou dinâmica)

25
Metodologias Just-in-Time (ou dinâmica)

• Antes do projeto
• Entrevista com o pessoal de projetos anteriores
  na organização
• No início do projeto
• Construir esboço da metodologia para o projeto
• Durante o primeiro incremento
• Entrevista com membros da equipe
• Depois do primeiro incremento
• Realizar um workshop da equipe após cada
  incremento
• Durante incrementos subseqüentes
• Aplicar as melhorias. Caso elas não funcionem
  voltar para o modelo original e propor outras e
  assim em diante.

26
Metodologias Just-in-Time (ou dinâmica)

• Metodologias ágeis para ambientes voltados para o
  mercado (time-to-market)
• Pontos fortes dos indivíduos
• Comunicação pessoal (face-to-face)
• Iniciativa
• Gerenciamento de dependências intra-projeto
• Variabilidade e inconsistência das pessoas

27
Família Crystal

• Criada por Alistair Cockburn
• http//alistair.cockburn.us/crystal
• Editor da série Agile Software Development da
  Addison-Wesley.

28
Família Crystal

• Filosofia básica
• ênfase em comunicação
• leve nos produtos gerados
• Princípios
• Precisamos de menos produtos intermediários se
  possuímos
• canais de comunicação informal ricos e rápidos
• entrega freqüente de código funcionando
• uso dos pontos fortes das pessoas (conversas.
  olhar a sua volta, interagir com outros)
• estar ciente dos pontos fracos das pessoas (baixa
  disciplina, falta de cuidado)

29
Família Crystal

• Termos
• Tamanho da metodologia número de elementos de
  controle (artefatos, modelos, atividades,
  milestones, medidas de qualidade etc).
• Densidade é o nível de detalhamento e
  consistência exigida nos elementos de controle.
• Tamanho do projeto número de pessoas envolvidas.

30
Família Crystal

• Além das idéias sugeridas já mencionadas de como
  construir uma metodologia, podemos acrescentar
• Considerar o tamanho e a criticalidade. Os
  desenvolvedores definem um escopo de preocupação,
  priorizando alguma qualidade para o projeto.
  Baseado nestas escolhas, o time seleciona quão
  leve ou pesada será a metodologia que eles querem
  para o projeto.

31
Família Crystal

• Separamos a criticalidade em quatro zonas
• Perda de conforto quando o sistema falha, a sua
  conseqüência é a perda de conforto das pessoas
• Perda de dinheiro quando existe problemas no
  sistema, suas conseqüências são a perda de
  dinheiro em escalas recuperáveis
• Perda de muito dinheiro quando o sistema falha,
  grandes perdas são calculadas
• Perda de vida falha no sistema implica na
  possibilidade de vidas serem perdidas

32
Família Crystal
?
33
Família Crystal

• Escopo

34
Família Crystal

• Crystal Orange escopo
• Para projetos D40
• Até 40 pessoas
• Perda de dinheiro como fator crítico
• Não indicados para projetos muito grandes
• (insuficiência em subequipes)
• Não indicados para projetos críticos
• (verificação insuficiente)
• (Described in Surviving OO Projects, Cockburn,
  1998, pp. 77-93)

35
Família Crystal

• Crystal Orange papéis e equipe
• Papéis Sponsor, Business expert, Usage expert,
  Technical facilitator, Business analyst/designer,
  Project Manager, Architect, Lead
  designer/programmer, Designer/programmer, Design
  Mentor, Reuse Point, Writer, Tester, UI designer.
• Equipes System planning, Project monitoring,
  Architecture, Technology, Functions,
  Infrastructure, External test.

36
Família Crystal

• Crystal Orange padrões
• Software é entregue incrementalmente e
  regularmente, a cada 2-4 meses,
• Progresso é acompanhado por milestones,
  consistindo de entrega de software ou decisões
  principais, em oposição a documentos escritos,
• Exista teste de regressão automatizado para
  funções da aplicação,
• Exista o envolvimento direto do usuário,
• Existam dois usuários revisores por release,
• Workshops para refinar a metodologia são feitos
  no início e na metade de cada incremento.

37
Família Crystal

• Crystal Orange produtos
• Artefatos incluem um documento de requisito,
  seqüência de release, planejamento, relatórios de
  estados, documento de projeto da UI, um simples
  modelo de objeto, especificações das dependências
  entre as equipes, manual do usuário, código
  fonte, casos de teste, migração de código, cada
  artefato é desenvolvido até que seja entendido
  pelos colegas para um nível de precisão e
  estabilidade que permita revisões.
• Templates dos artefatos, estilo de código,
  padrões de IU, detalhes de teste de regressão são
  deixados como padrões locais para serem ajustados
  e mantidos pela equipe.

38
Família Crystal

• Crystal Clear escopo
• Para projetos D6
• 3-6 pessoas, na mesma sala
• Perda de dinheiro como fator crítico
• Não indicado para projetos maiores
• (insuficiência de coordenação de grupo)
• Não indicado para projetos de vida-crítica
• (insuficiência verificação)
• (Described in Crystal Clear, Cockburn, 2002
• also in Agile Software Development, Cockburn
  2001)

39
Família Crystal

• Crystal Clear papéis e equipe
• Pápéis Sponsor, Senior Designer,
  Designer/Programmer, e User (pelo menos
  part-time). As pessoas do projeto compartilham
  outros papéis Project Coordinator, Business
  Expert, Requirements Gatherer.
• Equipe única equipe

40
Família Crystal

• Crystal Clear padrões
• Os mesmos padrões de política aplicados pelo
  Orange, exceto que os incrementos são dois meses
  ou menos.

41
Família Crystal

• Crystal Clear produtos e milestones
• Requer poucos artefatos seqüência de releases,
  planejamento de revisões e entregas, use cases,
  esboçar planos e anotações quando necessário,
  simples modelo de objetos, execução e migração do
  código, casos de teste e manual do usuário,
• Templates de produtos, estilo de código, padrões
  de interface do usuário e detalhes de teste de
  regressão são ainda deixados como padrões locais
  a serem mantidos pela equipe,

42
Metodologia Proposta

• Motivação
• Abordagem do projeto
• Preferências pessoais

43
Metodologia Proposta
Estimativa ? unidade de tempo Proposta (cliente)
? entrega
A avaliação da complexidade do problema definirá
os elemento necessários a serem trabalhados, e,
portanto, indicará a dimensão da metodologia.
Início do Projeto (Planejamento)
Antes do Projeto (Contextualização)
A identificação do produto, por exemplo, se o
mesmo é de encomenda ou de prateleira, definirá a
questão de possíveis prazos de manutenção, e,
portanto, a necessidade de documentação.
I n c r eme n t o
Estimativa de tempo de previsão do produto no
mercado. Haverá a necessidade de saber a
estabilidade da equipe, prevendo possíveis
manutenções e a partir de então detectar o grau
de necessidade de documentação.

• Realizar workshop da equipe para
• avaliar aprendizado e melhorias
• rever variáveis do projeto

Estimativa em unidade de tempo, a experiência da
equipe em projetos passados definirá a questão da
viabilidade do projeto no prazo proposto pelo
cliente e também a quantidade necessárias de
pessoas da equipe.
Tamanho da equipe
Aplica-se ao incremento
Depois

• Prazo
• Dimensão do problema
• Classificação segundo a natureza do produto
• Ciclo de vida do projeto
• Experiência da equipe envolvida em projetos
  similares
• Base de Informações (variações ocorridas nos
  projetos anteriores).

• Definir artefatos, papéis, padrões, produtos,
  milestones, etc, à partir do escopo da família
  Crystal.
• Construir esboço da metodologia

Servirá de consulta nas tomadas de decisões
futuras, e que armazenará possíveis modificações
nas metodologias já adotadas, de forma a
refiná-las adequadamente às necessidades dos
projetos.
Se houver mudanças, realimentar
Durante

• Entrevista com membros da equipe
• Mudar itens problemáticos fáceis de mudar ou
  catastróficos se não mudar

Base de informações compartilhada
44
Metodologia Proposta
Início do Projeto (Planejamento)
Antes do Projeto (Contextualização)
I n c r eme n t o

• Realizar workshop da equipe para
• avaliar aprendizado e melhorias
• rever variáveis do projeto

Tamanho da equipe
Aplica-se ao incremento
Depois

• Prazo
• Dimensão do problema
• Classificação segundo a natureza do produto
• Ciclo de vida do projeto
• Experiência da equipe envolvida em projetos
  similares
• Base de Informações (variações ocorridas nos
  projetos anteriores).

• Definir artefatos, papéis, padrões, produtos,
  milestones, etc, à partir do escopo da família
  Crystal.
• Construir esboço da metodologia

Se houver mudanças, realimentar
Durante

• Entrevista com membros da equipe
• Mudar itens problemáticos fáceis de mudar ou
  catastróficos se não mudar

Base de informações compartilhada
45
Conclusões

• A família crystal ensina que aspectos considerar
  quanto a escolha de uma metodologia a ser
  aplicada a um projeto
• Um dos aspectos mais importantes considerado
  nessas metodologias é a forma de comunicação
  entre as pessoas envolvidas, conseqüência direta
  para a produtividade e respostas a mudanças.

46
Conclusões

• Os projetos devem ser priorizados quanto a sua
  criticalidade para a escolha de uma metodologia
  adequada.
• Apesar dos princípios terem participação na
  escolha da metodologia, as preferências e
  prioridades do projeto são relevantes para esta
  decisão.

47
Referências

• 1 Cockburn, A., "Selecting a project's
  methodology," IEEE Software, July/August 2000,
  pp. 64-71, early version vailable on line at
  http//members.aol.com/humansandt/papers/methyperp
  roject/methyperproject.htm.
• 2 Cockburn, A., "Just-in-time methodology
  construction," in the proceedings of Extreme
  Programming and Flexible Processes, 2000 (to
  appear), early version available online at
  http//members.aol.com/humansandt/papers/jitmethy/
  jitmethy.htm.

48
Referências

• 3 Beck, K., Extreme Programming Explained,
  Addison-Wesley Longman, 1999.
• 4 Highsmith, J., Adaptive Software Development,
  Dorset House, 2000.
• 5 Cockburn, A., Crystal Clear A Human-Powered
  Methodology for Small Teams, Addison-Wesley
  Longman, in preparation, early drafts available
  online at http//members.aol.com/humansandt/crysta
  l/clear.
• 6 Stapleton, J., DSDM Dynamic Systems
  Development Method, Addison-Wesley, 1997, or
  online at .