A família Crystal: metodologias ágeis adaptáveis
•Transferir como PPT, PDF•
0 gostou•502 visualizações
O documento descreve a família Crystal de metodologias ágeis, criada por Alistair Cockburn para fornecer uma variedade de opções de acordo com o tamanho e complexidade de cada projeto. A família Crystal compartilha valores como foco em comunicação e pessoas e princípios como entregas incrementais curtas e workshops de reflexão. As metodologias variam em estrutura, papéis e ferramentas de acordo com o tamanho do time e projeto, mas permitem adaptações para atender às necessidades específicas de cada situação.
Recomendados
Mais conteúdo relacionado
Mais procurados
Destaque
Semelhante a A família Crystal: metodologias ágeis adaptáveis
Semelhante a A família Crystal: metodologias ágeis adaptáveis (20)
Último
Último (20)
A família Crystal: metodologias ágeis adaptáveis
- 2. Criada por Alistair Cockburn http://www.flickr.com/photos/guilhermechapiewski/4097110689/
- 3. Uma família de metodologias http://www.flickr.com/photos/chris_gin/2313273990/
- 9. Prioridades
- 13. Comunicação Eficiência http://refcardz.dzone.com/refcardz/scrum
- 14. Comunicação Eficiência
- 15. Comunicação Custo da distância
- 33. Técnicas
- 39. A família Crystal Coletaram exemplos de projetos de sucesso que utilizaram metodologias ágeis baseadas em comunicação e comunidade para criar uma família de metodologias que possa ser utilizada como ponto de partida em um processo de desenvolvimento de software. 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: 4 pessoas trabalhando em um projeto pequeno que cresce ao ponto de necessitar de 20 pessoas 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.
- 40. A família Crystal As 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 uma maneira mais fácil de alcançar o mesmo objetivo, podendo “pegar emprestado” práticas de outras metodologias/processos como XP ou Scrum. As diferenças báscias entre os membros da família Crystal são essencialmente estruturais.
- 41. http://www.flickr.com/photos/tropical-blizzard/4930032656 Crystal Clear
- 42. 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
- 43. Padrões -Entrega de incrementos de software regularmente (a cada 2 ou 3 meses) -Controle de progresso é feito através de “milestones” baseadas na entrega de software -Uso de testes automatizados em funcionalidades mais críticas -Envolvimento direto do usuário -Workshops de reflexão devem ser feitos no começo e no meio de cada incremento
- 44. 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
- 45. Definidos pelo time - Templates para os produtos - Padrões de design e codificação - Padrões para testes - Como será feita a documentação Ferramentas mais importantes - Um sistema de versionamento e gerenciamento de configuração - Um quadro branco
- 46. Crystal Yellow
- 47. 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
- 49. 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
- 50. 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ções e as use sem alterá-las, mas sim que você as pegue, critique- as, adicione e subtraia detalhes até que ela atenda às suas necessidades. Modificação de metodologia é a essência do Crystal...” “... e no fim das contas, é melhor entregar um software funcionando aceitavelmente (agregando valor) do que não entregar um software perfeito.”
- 52. Shu Ha Ri
- 54. Scrum: auto-organização XP: auto-disciplina
- 55. Scrum: auto-organização XP: auto-disciplina Crystal: auto-consciência
- 56. Para saber mais
- 59. • Alexandre Aquiles • Bruno Perillo • Martha Luiza Xisto • Rodrigo Normandia Souza • Túlio César Gaio • Willian Gaio http://www.jornallivre.com.br/images_enviadas/historia-de-jacarei6-jpg.jpg
- 60. Perguntas?
- 61. 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.
Notas do Editor
- 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!