Construindo uma Metodologia Just-in-Time centrada em pessoas

1
Construindo uma Metodologia Just-in-Time centrada
em pessoas
Universidade Federal de Campina
Grande Pós-Graduação em Informática

• Jailton Cardoso
• Nelson Júnior
• Verlaynne Rocha
• Disciplina Gerência de Processos
• Professora Francilene Garcia

2
Roteiro

• Introdução
• Motivação
• Descrevendo a técnica
• Caracterizando pessoas no desenvolvimento de
  software
• Descrevendo a família de metodologias Crystal
• Considerações Finais

3
Introdução

• Processo de desenvolvimento de software
• Não há única metodologia que se encaixe
  perfeitamente
• Alternativas
• Combinação de metodologias
• Uso de uma metodologia dinâmica (adaptável)

4
Introdução

• Metodologias classificação
• Metodologias Pesadas
• Ênfase em documentação e no processo
• Metodologias Ágeis
• Ênfase no código e centrada nas pessoas
  envolvidas
• Foco do trabalho
• Família de metodologias Crystal

5
Motivação

• Project Winifred
• IBM Consulting Group na Inglaterra
• Siemens in Munique
• Apenas em Winifred existiu uma metodologia sendo
  utilizada, que serviu como base para a técnica
  que será apresentada.

6
Descrevendo a técnica

• Processo iterativo incremental.
• Cada incremento pode ter de uma semana a quatro
  meses de duração.
• A metodologia é costurada.
• A sugestão dada é composta por cinco fases.

7
Descrevendo a técnica Antes do projeto

• Entrevistas com pessoas que participaram de
  projetos anteriores, com o intuito de descobrir
  as que são adequadas ao projeto em questão, e
  dentre essas, as que gostariam ou não de
  trabalhar nesse projeto.
• Chegar a conclusões sobre os pontos fortes e
  fracos da organização, ou seja, o que pode trazer
  vantagens e o que pode atrapalhar o bom
  desenvolvimento do projeto.

8
Descrevendo a técnica No início do projeto

• Construção da metodologia inicial
• Para isso é utilizado o resultado das
  entrevistas, as características do projeto e as
  pessoas que irão compor o time.
• Essa fase pode levar de dois a cinco dias.

9
Descrevendo a técnica Durante o primeiro
incremento

• Parar no meio para decidir
• Devemos continuar fazendo o que estamos fazendo?
  Devemos continuar fazendo da forma como estamos
  fazendo?
• Nessa hora é possível
• Recomeçar o projeto
• Modificar a forma de trabalho
• Cortar uma parte do escopo
• Grandes mudanças acontecerão, caso a equipe
  esteja mudando muito os hábitos de trabalho para
  poder se adequar a metodologia empregada.
• Esta fase tem como objetivo principal, detectar
  possíveis catástrofes e acompanhar o que o time
  está falando sobre a forma de trabalho.
• Essa reunião pode durar de 1 a 3 horas.

10
Descrevendo a técnica Depois de cada incremento

• Reflexão sobre o que aconteceu de bom e de ruim
  no incremento que passou.
• O que deve ser modificado na metodologia.
• Quais são as prioridades para o próximo
  incremento.
• Essa etapa pode durar de 4 a 12 horas

11
Descrevendo a técnica Durante os incrementos
seguintes

• No meio de cada incremento acontece uma reunião,
  de poucas horas, com o intuito de
• Checar a forma de trabalho das pessoas
• Decidir se será feita alguma pequena modificação
  na metodologia.
• Após a entrega de alguma versão do sistema
  (depois de duas ou três iterações) é a hora ideal
  para introduzir novas técnicas e padrões à
  metodologia.
• O objetivo principal deste encontro é descobrir
  itens que tenham sido esquecidos de serem
  discutidos ao final do incremento anterior e dar
  ao time a chance de voltar a traz em experiências
  que não tenham dado certo.
• Essa faze pode durar de 2 a 6 horas dependendo
  das mudanças ocorridas

12
Descrevendo a técnica Durante os incrementos
seguintes.

• Fazer encontros para revisões duas vezes por
  incremento, permite que o time leve em conta as
  experiências mais recentes quando vão introduzir
  mudanças na metodologia.
• Dessa forma a metodologia vai sendo costurada
  ao longo dos incrementos.

13
Caracterizando pessoas no desenvolvimento de
software

• Influência das pessoas no processo
• Componentes ativos, não-lineares e variáveis
• Devem ser considerados em primeira ordem
• Estudos anteriores não funcionavam por não levar
  em conta as pessoas em primeira ordem
• Como o comportamento das pessoas influenciam no
  desenvolvimento?
• Qual a implicação sobre a metodologia aplicada?

14
Caracterizando pessoas no desenvolvimento de
software

• Conclusões após estudo sobre 23 projetos
• Quase toda metodologia pode ser moldada para
  atender algum projeto
• Qualquer metodologia pode levar um projeto a
  falhar
• Processos pesados podem ter sucesso
• Processos leves chegam mais freqüentemente ao
  sucesso. As pessoas envolvidas creditam isso a
  leveza do processo

15
Caracterizando pessoas no desenvolvimento de
software

• Características principais identificadas
• Pessoas são seres comunicantes
• Face a face é mais eficiente
• Pessoas tendem a ser inconsistentes
• Dificuldade em agir disciplinadamente sempre
• Pessoas variam muito
• Hábitos variam, trabalhar a noite ou durante o
  dia
• Pessoas querem ser bons cidadãos

16
Caracterizando pessoas no desenvolvimento de
software

• Comunicação
• Forma mais eficiente uso de whiteboard
• Características de uma comunicação eficiente
• Proximidade física
• Contato físico melhor do que via videoconferência
• Múltiplas modalidades
• Gestos e palavras
• Inflexão e tonalidade da voz
• Perguntas e respostas em tempo real

17
Caracterizando pessoas no desenvolvimento de
software
Perde-se as características gradativamente
18
Caracterizando pessoas no desenvolvimento de
software
Comunicação eficiente Coloque todas as pessoas
dentro de uma sala Certifique-se de que os
whiteboards e e cantinhos de café estejam bem
espalhados pelo prédio da empresa
19
Caracterizando pessoas no desenvolvimento de
software

• Tendência à inconsistência
• Relaxamento quanto ao comportamento
• Dificuldade em manter a disciplina continuamente
• Processos pesados falham com freqüência
• Pessoas possuem qualidades e defeitos
• Forma de gerenciar um grupo de pessoas pode
  modificar a consistência de suas ações

20
Caracterizando pessoas no desenvolvimento de
software

• Variação de pessoa pra pessoa
• Pessoas tem aptidões variadas
• Pessoas possuem costumes e formas de trabalhar
  diferentes
• Metodologia aplicada a um grupo
• Alguns se adaptam melhor
• Outros podem até rejeitar
• Difícil buscar um consenso sobre alguma norma ou
  metodologia
• Metodologias que requisitam muita disciplina
  tendem ao insucesso

21
Caracterizando pessoas no desenvolvimento de
software

• Tendência a ser bons cidadãos
• Tendem a olhar ao redor delas
• Boa percepção da situação, boas idéias
• Tomam iniciativas
• Pessoas chaves nos momentos chaves
• Motivo para sucesso do projeto
• Importante incentivar o senso de cidadania no
  grupo

22
Caracterizando pessoas no desenvolvimento de
software

• Outras características
• Aprendizagem observando
• Olhando e fazendo
• Trabalhar com exemplos
• Mudança nos hábitos
• Difícil de efetivar tais mudanças nas pessoas
• Cabeças pequenas
• Capacidade limitada de absorver informações

23
Descrevendo a família de metodologias Crystal

• Pontos chaves para escolha de uma metodologia
  são
• Tamanho da equipe/distribuição
• Criticalidade do projeto
• Prioridades

24
Descrevendo a família de metodologias Crystal -
Princípios

• 1. Uma grande metodologia é necessário quanto
  mais pessoas são envolvidas
• Grande significa que mais elementos de controle
  são necessários

25
Descrevendo a família de metodologias Crystal -
Princípios

• 2.Um sistema mais crítico no qual um defeito
  não detectado irá produzir maiores danos
  necessitam maior visibilidade publica da sua
  corretude (grande densidade) na sua construção. A
  criticalidade é separada em loss zones (zonas de
  perda)
• Loss confort
• Loss of discretionary money
• Loss irreplaceable money
• Loss of life

26
Descrevendo a família de metodologias Crystal -
Princípios

• Loss confort significa que com uma falha do
  sistema, pessoas irão ter maior trabalho manual
• Loss of discretionary money se uma perda de
  dinheiro é meramente desconfortavel, podendo ser
  reparado em um momento posterior
• Loss irreplaceable money se a perda de dinheiro
  pode gerar uma falência
• Loss of life se pessoas podem perder a vida
  numa falha do sistema

27
Descrevendo a família de metodologias Crystal -
Princípios

• 3.Um incremento relativamente pequeno incremento
  no tamanho ou densidade de uma metodologia
  adiciona uma quantidade relativamente grande ao
  custo do projeto
• Este é um dos mais importantes princípios no
  projeto de uma metodologia

28
Descrevendo a família de metodologias Crystal -
Princípios

• 4.A forma mais efetiva de comunicação (para o
  propósito de transmitir ideias), é interativa,
  face-to-face.

A eficiência da comunicação decresce quando o
contato pessoal decresce
29
Descrevendo a família de metodologias Crystal -
Framework

• Metodologia por Projeto
• Toda metodologia é baseada no medo
• Cada elemento no processo ou metodologia pode ser
• considerado um prevenção de alguma experiência
  errada
• Receio que programadores façam códigos errados?
  Fazer revisão de código
• Receio que usuários não saibam o que eles
  realmente querem? Criar protótipos

30
Descrevendo a família de metodologias Crystal -
Framework

• Neste framework a metodologia adotada difere de
  acordo com o número de pessoas envolvidas, a
  criticalidade do projeto e as prioridades
• 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

31
Descrevendo a família de metodologias Crystal -
Framework

• A figura divide o espaço em sete tamanhos de
  projetos e quatro zonas de criticalidade. A
  metodologia será maior (mais elementos de
  comunicação) para a direita e mais densa (mais
  controles) para cima.
• Com este grid nos podemos contar o número de
  pessoas no projeto, discutir sua criticalidade e
  prioridade
• 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

32
Descrevendo a família de metodologias Crystal -
Framework

• Cristal é segmentado em cores com características
  comuns. Clear para o menor e mais leve , e
  Yellow, Orange, Red, Maroon, Blue e
  Violet e assim por diante para grandes grupos
  usando grandes metodologias

33
Descrevendo a família de metodologias Crystal -
Framework

• Crystal Orange (características)
• 10-40 pessoas
• 1-2 ano de duração
• Não é um sistema life-critical
• Há uma necessidade de comunicação entre o atual e
  o futuro staff e manter um baixo custo e tempo
• Crystal Clear
• Até 6 pessoas
• Há apenas uma equipe
• As mesmas politicas aplicadas ao Orange, exceto
  que os incrementos são de 2 meses ou menos

34
Considerações finais

• Pessoas devem ser consideradas em primeira ordem
  no processo de software
• Nenhuma metodologia satisfaz por completo um
  projeto
• Metodologias devem ser adaptáveis ao longo de um
  projeto
• Processos leves e metodologias ágeis tendem a ter
  mais sucesso

35
Referências

• Crystal Methodologies, http//alistair.cockburn.us
  /crystal/
• Cockburn, A., "Just-in-Time Methodology
  Construction" presented at the Extreme
  Programming and Flexible Processes conference,
  Sardinia, June 2000
• Cockburn, A., "Characterizing People as
  Non-Linear, First-Order Components in Software
  Development, presented at the 4th International
  Multi-Conference on Systems, Cybernetics, and
  Informatics,Orlando, FL, June 2000.
• Cockburn, A., "Selecting a project's
  methodology," IEEE Software, July/August 2000,
  pp. 64-71
• Cockburn, A., "A methodology per project,"
  submitted to IEEE Software.