• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Crystalfinal 100906101303-phpapp02
 

Crystalfinal 100906101303-phpapp02

on

  • 374 views

 

Statistics

Views

Total Views
374
Views on SlideShare
374
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Pronuncia-se Coh-burn e não Cockburn. Filósofo, poeta. Alistair foi contratado pela IBM em 1991 para estudar metodologias e criar uma metodologia para projetos que usavam OO. Evitou falar apenas sobre sua experiência, como a maioria dos metodologistas fazem Entrevistou vários metodologistas, inclusive Kent Beck durante o C3, quando foi criado o XP.
  • Por que uma família ? Porque cada projeto tem suas particularidades. Cada projeto precisaria de sua própria metodologia. Não é um kit como o RUP, do qual você pode pegar pedaços e montar uma metodologia J ogo de Celular x Controlador de vôo: v ocês acham que pode ser a mesma metodologia? Crystal porque o nome remete a cristais, que existem com várias durezas na natureza, do quartzo ao diamante.
  • Pessoas são Espontâneas / Não lineares. Boas em Comunicação, Olhar ao redor/olhar o todo, Copiar e modificar. Ruins emdisciplina, consistência, mudar hábitos (resistem muito) ‏, seguir instruções. Não são componentes que podem ser plugados ou desplugados facilmente. Não são recursos, são pessoas. Por isso, Crystal é focado em comunicação e comunidade.
  • Toda família tem um código genético em comum: com Crystal não é diferente
  • Mentalidade de Jogo Cooperativo
  • Uma série de jogos cooperativos de invenção e comunicação com dois objetivos conflitantes: e ntregar software funcionando agora; Preparar-se para a próxima etapa do jogo.
  • Prioridades das metodologias
  • A principal prioridade do projeto é a Sobrevivência (e entrega do software) ‏. As outras duas são conflitantes: um processo eficiente pode ser intolerável pelas pessoas (o time precisa aceitar o processo) ‏.
  • Princípios de Design de Metodologias
  • Princípios
  • Comunicaçao cara a cara é a maneira mais barata e rápida de trocar informações.
  • Comunicação: quanto mais pessoas, menos eficiente a comunicação.
  • Comunicação:  troca de experiências; com mais experiência compartilhada , você pode escrever menos; com menos experiência compartilhada , você tem que escrever mais.
  • Custo da distância: a s pessoas não vão descer escadas para se comunicar; surgirá o Cone do Silêncio.
  • Evitar burocracia desnecessária, Usar a metodologia mais leve o possível. Custo de tempo; Custo de pessoas (motivação); Custo de ferramentas; Custo de time-to-market.
  • Quanto maior o time, há mais problemas de comunicação: há necessidade de processos mais definidos.
  • Maior cerimônia: maior cuidado nas decisões. Passos tem que ser mais planejados e planos mais detalhados, para evitar "putz, eu esqueci daquilo". O esquecimento aqui pode acabar com vidas, com quantias consideráveis de dinheiro, etc...
  • Entregas intermediárias aqui se referem a: documentos de análise; documentos de requisitos; planos de testes; lista de riscos. Isso tudo são promessas: entregue software funcionando. Software funcionando é o que gera feedback.
  • Prática vs. Teoria. Processo não é disciplina: Disciplina é trabalhar de forma consistente; Processo é seguir passos já definidos; XP requer disciplina; Crystal incentiva o copiar/colar (ajustar). Formalidade não é habilidade: só porque há um processo formal o indivíduo não vai ser bom automaticamente; a habilidade (talento individual) é importante. Documentação não necessarimente é entendimento: documentação não garante que o cara entendeu o que precisa; o que importa é o entendimento; documentação é importante como meio de comunicação do presente com o futuro . Ágil foca mais em habilidade, disciplina e entendimento (Manifesto ágil). Processos tradicionais focam mais em Processo, Formalidade e Documentação.
  • Gargalo: ache os gargalos; não adianta tanto otimizar o que não é gargalo; não vai melhorar o projeto como um todo.
  • As Sete Características de Projetos de Sucesso
  • Você entregou software: Testado; de acordo com a definição de pronto ( scrum )‏; funcionando e utilizável; pelos menos duas vezes nos últimos seis meses?
  • Seu time se juntou nos últimos 3 meses para: discutir e melhorar seus hábitos de trabalho. Melhoria contínua - Kaizen do Lean.
  • Você leva mais do que 30 segundos para perguntar algo para alguém que provavelmente tem a resposta? Você se vira mais de 90 graus? Você ouve algo relevante de alguma conversa entre outros membros da equipe?
  • Transparência poder expor erros seus. Você se sente seguro para dar más notícias para o seu chefe ? A equipe se sente parte do projeto? As pessoas tem longos debates sobre suas idéias mas ainda se mantém amigáveis ? Ser amigável melhora o fluxo de informação: ser amigável é ter boa-vontade em ouvir opiniões alheias.
  • As pessoas da equipe sabem as prioridades (e m que devem focar)? Elas tem pelo menos duas horas a cada dois dias para trabalhar sem interrupções ? Encorajados a desligar o telefone. No Scrum, blindar a equipe é papel do Scrum Master.
  • Você recebe a resposta de um especialista em menos 3 dias? Ou em menos de poucas horas?
  • Refatoração. Controle de versão. Gerência de configuração. Builds automatizados. Testes automatizados: unitários, de integração, funcionais. Integração frequente: executar o build; executar os testes.
  • Projetos de Sucesso: as 7 características. Alistair pesquisou e identificou uma oitava característica que só aparece nos melhores projetos: colaboração além das barreiras do seu time. Por toda a organização.
  • Crystal é baseada nos 3 primeiros fatores
  • Técnicas
  • 360 exploratório: checando a viabilidade; valor de negócio; tecnologia. Vença cedo: u se técnicas como o Esqueleto ambulante para entregar valor logo no começo do projeto; você ganha auto-confiança e seu cliente confia mais em você. Esqueleto ambulante: i mplemente uma funcionalidade pequena de cima a baixo no seu sistema. Você valida a arquitetura; obtém feedback do cliente mais rápido  ; descobre problemas cedo. Programação lado-a-lado: time próximo; comunicação osmótica; XP não sugere isso; Crystal aceita é difícil parear e sugere lado-a-lado. Planejamento relâmpago: mesmo que o sprint planning ou XP Planning Game, mas sugere que se faça uma lista de dependências entre tarefas. Design Ágil de Interfaces: GUI no papel de pão; Foto no quadro branco; Modelagem por rascunho.
  • Metodologias base para serem adaptadas
  • Toda metodologia é um conjunto de convenções aceitas por um grupo. Tuning – Ajuste: A metodologia tem que evoluir; a organização tem que aprender, tem que criar a própria metodologia. Dois passos: estude sua metodologia básica; use workshops de reflexão sobre a metodologia. Não use a mesma metodologia para sempre: reveja constantemente os seus problemas e atue neles. Uma das palestras do Alistair, de 2007, chama "Crystal - como fazer metodologias se encaixarem no seu projeto".
  • Eixo horizontal: tamanho do time. Eixo Vertical: quão críticos são os erros. Comfort  - se eu errar eu só vai ser mais chato fazer algo; Discretionary money  - dinheirinho, que dá pra gastar em bobagens. Essential money  - dinheiro considerável. Life -  quando a vida de pessoas está em jogo. Na prática, só aconteceram projetos Clear, Yellow e Orange.
  • Da matriz de criticalidade por tamanho de equipe: Nenhum Crystal Red ainda; nenhum projeto com equipe pequena que perder dinheiro é um problema sério (não recomendável); nenhum projeto em que erros possam fazer com que vidas sejam perdidas.
  • Alistair cita paper de Boehm-Turner, que estenderam a escala de Criticidade/Tamanho para considerar: Pessoal - Porcentagem de sêniors na equipe. Dinamismo - Mudança de requisitos por mês. Cultura - algumas empresas toleram mais incerteza que outras. Métodos ágeis estão mais próximos do centro dessa escala.
  • Crystal Yellow: m encionado na 2a. Ed. do livro Agile Software Development. No livro ele fala de um case da construção de um Correio na França, do prédio aos sistemas de informação. As interações a cada 6 semanas ajudaram bastante. O cliente estava disposto a colaborar.
  • Crystal Orange e Crystal Orange Web. Esse último foi c riado para eBucks.com: empresa nova, mas já estabelecida; não havia uma cultura organizacional.
  • Shu - Ha – Ri. Aprender - Desatachar – Transcender. Conceito que vem das artes marciais japonesas. Shu: proteger, obedecer em japonês. Iniciante: faz as coisas "by the book", segue o que o mestre manda. Ha: desatachar, digredir em japonês. Competente: quebra da tradicao; critica as visões do mestre. Ri: sair, separar em japonês.Mestre:   transcende tudo e faz as coisas por instinto, às vezes quebrando as próprias regras.
  • Alistair diz que se você falhar no XP você pode tentar o Crystal Clear. Crystal permite que você seja menos disciplinado. Por outro lado, requer mais documentação. O 1o. livro de Kent Beck sobre XP é Shu, mais prescritivo. O 2o. livro é Ha-Ri, fala mais sobre as idéias.
  • Encare cada projeto como um novo projeto com um novo processo. Não importa o processo, importa o sucesso. A mente ágil é a mente do iniciante. Ver o todo. Crystal é maleável e tolerante.
  • Surviving Object Oriented Projects, de Jan/1998. Crystal Clear, de Out/2004. Descreve Crystal Clear. Agile Software Development, the Cooperative Game: Duas versões: 1a. - Out/2001; 2a. - Out/2006. Discutem Agilidade em geral. A 2a. versão tem o texto dos capítulos da 1a. mais um capítulo de Evolução para cada capítulo. A 2a. versão foi a primeira a ter Yellow. Outros Livros: Writing Effective Use Cases de Out/2000.
  • Retrospectiva do nosso trabalho
  • Ter as características de um projeto de sucessso não garante que ele será um. Precisamos da opinião dos nosso clientes: feedback!

Crystalfinal 100906101303-phpapp02 Crystalfinal 100906101303-phpapp02 Presentation Transcript

  • http://www.imotion.com.br/imagens/data/media/83/10628cristais.jpg
  • Criada por Alistair Cockburnhttp://www.flickr.com/photos/guilhermechapiewski/4097110689/
  • Uma família de metodologiashttp://www.flickr.com/photos/chris_gin/2313273990/
  • Pessoashttp://www.flickr.com/photos/suvcougar/1273657633/
  • Jogo Cooperativo
  • Prioridades
  • Comunicação Eficiênciahttp://refcardz.dzone.com/refcardz/scrum
  • Comunicação Eficiência
  • Comunicação Custo da distância
  • Técnicas
  • Ajustehttp://www.flickr.com/photos/worldofarun/4271756652
  • http://assets.devx.com/articlefigs/17424.jpg
  • A família Crystal Coletaram exemplos de projetos de sucesso que utilizaram metodologias ágeisbaseadas em comunicação e comunidade para criar uma família de metodologias quepossa ser utilizada como ponto de partida em um processo de desenvolvimento desoftware. Os membros da família dividem entre si:  Valores e princípios  Mudanças "on-the-fly“ Alistair considera pouco traumática a mudança de uma metodologia para outra: 4pessoas trabalhando em um projeto pequeno que cresce ao ponto de necessitar de 20pessoas não devem perguntar "como preservamos nossas convenções primárias?", e sim"qual é um bom caminho para 20 pessoas trabalharem juntas neste projeto?"Entre os valores, destacam-se:  Foco em comunicação e pessoas: ferramentas, produtos e processos estão lá apenas para auxiliar as pessoas  Tolerância: reconhece a variedade da natureza humana.
  • A família CrystalAs duas principais regras em comum:  deve-se usar entregas incrementais, de no máximo 4 meses (mas preferencialmente d de um a três meses)  deve-se realizar "workshops de reflexão" antes e depois de cada iteração (se p possível também fazendo um "workshop" no meio do processo)As duas técnicas base:  técnicas de ajuste: utilizar workshops e entrevistas com os envolvidos para converter uma metodologia base em algo que possa servir de ponto de partida para o projeto  a técnica utilizada para administrar o "workshop de reflexão"Você deve ficar à vontade para trocar estas técnicas por outras se você enxerga umamaneira mais fácil de alcançar o mesmo objetivo, podendo “pegar emprestado” práticasde outras metodologias/processos como XP ou Scrum.As diferenças báscias entre os membros da família Crystal são essencialmenteestruturais.
  • http://www.flickr.com/photos/tropical-blizzard/4930032656 Crystal Clear
  • Para Projetos D6: 3-10 pessoas Disposição Papéis Necessários Em um único ambiente - padrinho E6 E10 (ou em salas - programador-arquiteto a adjacentes) sênior D6 D10 - programador-arquiteto Times - usuário (parcial) C6 C10 Um único time de Papéis Acumulados programadores- arquitetos - coordenador - especialista de domínio - analista de requisitos
  • Padrões-Entrega de incrementos de software regularmente (a cada2 ou 3 meses)-Controle de progresso é feito através de “milestones”baseadas na entrega de software-Uso de testes automatizados em funcionalidades maiscríticas-Envolvimento direto do usuário-Workshops de reflexão devem ser feitos no começo e nomeio de cada incremento
  • Produtos-Sequência de release-Agendamento de entregas-Casos de uso ou descrição de funcionalidades-Rascunhos de design e notas, caso seja necessário-Modelo de objetos-Código “pronto”-Casos de teste-Manual do usuário
  • Definidos pelo time- Templates para os produtos- Padrões de design e codificação- Padrões para testes- Como será feita a documentaçãoFerramentas mais importantes- Um sistema de versionamento e gerenciamento deconfiguração- Um quadro branco
  • Crystal Yellow
  • Para Projetos D20: 15-30 pessoas Disposição Papéis Necessários Em um único ambiente - Padrinho ( (ou em escritórios adjacentes) - Líder de projeto - Sub-líder de times E20 E30 - Especialista de domínio Times - Programador-arquiteto sênior D20 D30 Um único time separados - Programador-arquiteto pelas atividades - Tester C20 C30 desempenhadas
  • Crystal Orangehttp://www.flickr.com/photos/wgyuri/501884430
  • Para Projetos D40: 30-50 pessoas Disposição Papéis Necessários Fisicamente o mais próximo - Padrinho possível (mesmo prédio) - Especialista de domínio - Usuário especialista E40 E50 - Facilitador técnico Times - Analista de negócio D40 D50 Um único time separado pelas - Gerente de projeto atividades desempenhadas - Arquiteto - Líder de design C40 C50 - Programador-arquiteto senior - Planejamento de Sistema - Monitoramento de Sistema - Programador-arquiteto - Arquitetura - Designer de interface - Tecnologia - Documentador (escritor - Funcionalidades t técnico) - Infra-estrutura - Tester - Teste
  • Notas do criador sobre a família Crystal“Projetos diferentes têm necessidades diferentes.Terrivelmente óbvio, exceto (talvez) para os metodologistas...”“... não é a minha intenção que você pegue estas descriçõese as use sem alterá-las, mas sim que você as pegue, critique-as, adicione e subtraia detalhes até que ela atenda às suasnecessidades. Modificação de metodologia é a essência doCrystal...”“... e no fim das contas, é melhor entregar um softwarefuncionando aceitavelmente (agregando valor) do que nãoentregar um software perfeito.”
  • http://assets.devx.com/articlefigs/17426.jpg
  • Shu Ha Ri
  • Scrum: auto-organização
  • Scrum: auto-organização XP: auto-disciplina
  • Scrum: auto-organização XP: auto-disciplinaCrystal: auto-consciência
  • Para saber mais
  • • Alexandre Aquiles • Bruno Perillo • Martha Luiza Xisto • Rodrigo Normandia Souza • Túlio César Gaio • Willian Gaiohttp://www.jornallivre.com.br/images_enviadas/historia-de-jacarei6-jpg.jpg
  • Perguntas?
  • Referências• COCKBURN, Alistair. Agile Software Development: The Cooperative Game. 2nd ed. Addison-Wesley Professional, 2006.• COCKBURN, Alistair. Crystal is about self-awareness. Recuperado de: http://alistair.cockburn.us/Crystal+is+about+self-awareness em 30 ago. de 2010.• COCKBURN, Alistair. Crystal (How to make a methodology fit). Recuperado de: http://alistair.cockburn.us/Crystalmethods180.ppt em 31 ago. de 2010.• COFFIN, Rod; LANE, Derek. A Practical Guide to Seven Agile Methodologies (Part 2). Recuperado de: http://www.devx.com/architect/Article/32836/1954 em 30 ago. de 2010.