Crystal é uma família de metodologias de desenvolvimento de software e, como os cristais, possui diferentes cores e rigidez, referindo-se ao tamanho e ao nível crítico do projeto.

Criada por Alistair Cockburn e Jim Highsmith a fim de conseguir uma abordagem de desenvolvimento de software que premia a “manobrabilidade” durante o que Cockburn caracteriza como “um jogo cooperativo de invenções e comunicação de recursos limitados, com o principal objetivo de entregar softwares úteis funcionando e com o objeto secundário de preparar-se para o jogo seguinte”.

Os métodos Crystal são focados nos talentos e nas habilidades das pessoas, permitindo que o processo de desenvolvimento seja moldado conforme as características específicas da equipe, mesclando a sua cultura de trabalho com a proposta de desenvolvimento ágil.

A metodologia Crystal utiliza dois parâmetros para adequar-se a ao projeto de software, sendo a primeira métrica o número de pessoas envolvidas e a segunda métrica o nível crítico.

Parâmetros conforme o tamanho

Cada método Crystal é caracterizado por uma cor, de acordo com o número de envolvidos.

  • Crystal Clear é uma metodologia leve, para equipes de uma a oito pessoas, podendo chegar até doze em casos especiais;
  • Yellow, para equipes por volta de dez a vinte membros;
  • Orange e a variante Orange Web são apropriados para equipes de vinte a cinquenta participantes;
  • Red para equipes de cinquenta a cem membros. Cada um dos métodos com graus de gerenciamento e de comunicação ajustados de acordo com o tamanho da equipe.

Parâmetros conforme nível crítico do projeto

Além das cores, o Crystal utiliza-se de algumas letras para representar potenciais perdas causados por uma falha no sistema de desenvolvimento de software.

img-metodologia-crystal

 

  • C de Confort (Conforto), casos em que a falha do sistema ocasiona a perda de credibilidade do usuário devido ele não atender este conforto, como exemplo temos o serviço de um aparelho celular. Caso este falhe o usuário devera utilizar-se de um outro ou ate mesmo utilizar-se de outros meios para realizar a comunicação desejada.
  • D de Discretionary money (Dinheiro disponível para uso conforme necessário, cujo uso depende de decisão de alguém com poder de decisão). Casos em que a falha do sistema ocasiona na perda de dinheiro, mas de valor inexpressivo, tendo como exemplo o sistema de um caixa de um supermercado, tal falha pode impactar em não cobrar determinados produtos ou cobrar produtos com um valor superior que logo seria descoberto por clientes gerando a perda de valores, mas que não levará o mercado à falência.
  • E de Essencial money (Dinheiro essencial – dinheiro indispensável, absolutamente necessário) casos em que a falha do sistema ocasiona a perda de um quantia indispensável, grandes valores, como exemplo temos o sistema de reserva de uma companhia aérea, esta não funcionando ocasionará a perda de valores significativos devidos aos gastos que a mesma acarretaria e assim na qual pode culminar até mesmo na falência da empresa.
  • L de Life (vida) casos em que a falha do sistema ocasiona a perda de Vidas, tendo como referência um software de piloto automático onde sua falha poderia derrubar um avião e matar seus tripulantes.
    Grandes projetos geralmente requisitam mais coordenação e metodologias mais rígidas que projetos menores, ou quanto mais crítico for o software. Tanto que o Crystal Clear, não trata dos aspectos relacionados a projetos onde o dinheiro é essencial, mas a equipe poderá estender o Crystal Clear para isso.

Entre outras observações em relação aos níveis críticos do método Crystal é que também é omitido os sistemas de vida crítica (Life-critical) porque Alistair Cockburn diz não ter trabalhado nisso ou entrevistado pessoas sobre projetos de vida crítica, de maneiras que ele não possui informação suficiente para dizer exatamente como um projeto ágil de vida crítica se parece.

 

Características da metodologia Crystal

Independentemente de qual implementação Crystal você escolhe, você encontrará sete princípios-chave em cada um:

  • Entrega freqüente: os proprietários de projetos-cliente podem esperar resultados da equipe a cada dois meses. Em maior ou mais projetos críticos, as prestações não podem entrar em produção, mas os interessados irão ver as versões intermediárias e ser capaz de fornecer feedback.
  • Feedback contínuo: Toda equipe do projeto se reúne regularmente para discutir as atividades do projeto. A equipe também se reúne regularmente com as partes interessadas para garantir que o projeto está caminhando na direção esperada e comunicar quaisquer novas descobertas que podem afetar o projeto.
  • Comunicação Constante: Pequenos projetos esperam que toda a equipe tenha que estar na mesma sala, enquanto projetos maiores são esperados para ser co-localizados na mesma facilidade. Todos os projetos esperam ter acesso frequente as pessoas que definem os requisitos.
  • Segurança: Crystal é algo único em seu foco no aspecto da segurança de desenvolvimento de software. Isto vem em duas formas, sendo que uma delas é a zona segura para que os membros da equipe devam ter para serem eficazes e para comunicar a verdade durante o projeto, sem medo de represálias, o que é verdadeiro na maioria das metodologias ágeis. A outra forma de segurança, que só o Crystal reconhece, é que a finalidade de cada projeto de software não é o mesmo e que alguns projetos de software afetam a segurança de seus usuários finais. Por exemplo, um sistema de ônibus espacial é muito mais crítica do que uma batedeira.
  • Foco: Os membros da equipe devem conhecer dois ou três itens prioritários e cada membro deve trabalhar com tempo para concluí-las sem interrupção.
  • Acesso para Usuários: Como a maioria dos métodos ágeis, Crystal espera que a equipe do projeto tenha acesso a um ou mais usuários do sistema a ser construído.
  • Testes automatizados e Integração: Crystal tem várias capacidades para a verificação da funcionalidade do projeto. Controles devem ser postos em prática para apoiar a versão, testes automatizados, e frequente integração dos componentes do sistema.

Ciclo da metodologia Crystal

O ciclo de vida desta família de metodologia é baseado nas seguintes práticas:

  • Staging: Planejamento do próximo incremento do sistema. A equipe seleciona os requisitos que serão implementados na iteração e o prazo para sua entrega;
  • Edição e revisão: Construção, demonstração e revisão dos objetivos do incremento;
  • Monitoramento: O processo é monitorado com relação ao progresso e estabilidade da equipe. É medido em marcos e em estágios de estabilidade;
  • Paralelismo e fluxo: Em Crystal Orange as diferentes equipes podem operar com máximo paralelismo. Isto é permitido através do monitoramento da estabilidade e da sincronização entre as equipes;
  • Inspeções de usuários: são sugeridas duas a três inspeções feitas por usuários a cada incremento;
  • Workshops refletivos: são reuniões que ocorrem antes e depois de cada interação, com objetivo de analisar o progresso do projeto;
  • Local matters: são os procedimentos a serem aplicados, que variam de acordo com o tipo de projeto;
  • Work Products (Produtos de Trabalho): seqüência de lançamento, modelos de objetos comuns, manual do usuário, casos de teste e migração de código. Especificamente para o Clear, são casos de uso e descrição de funcionalidade e, especificamente para o Orange, são documentos de requisitos;
  • Standards (padrões): padrões de notação, convenções de produto, formatação e qualidade usadas no projeto;
  • Tools: Ferramentas mínimas utilizadas. Para Crystal Clear, são compiladores, gerenciadores de versão e configuração, ferramentas de versão, programação, teste, comunicação, monitoramento de projeto, desenho e medição de desempenho.

img-ciclo-crystal

Categorized in:

Tagged in: