Agile Methods: Crystal

Já ouviu muito falar de Crystal mas nunca nem viu? Bom espero que esse pequeno overview te ajude ok?

Vou iniciar este ano com uma nova página chamada Agile Methods, com o intuito de mostrar que a selva agile tem muito mais a oferecer do que madeira!

Se você está cansado daquela imagem de um “Guarda-chuva AGILE com vários nomes”, que você sempre vê mas nunca soube o motivo nem como funciona, vem comigo!

Primordialmente, cuidado!!! Se você acredita que esse vais ser só um pequeno artigo, você está bem enganado, aqui vão pelo menos de 30 minutos à uma hora de leitura, então se você realmente quer entender sobre Crystal, mesmo que o básico, inicie aqui, se quiser saber mais, entre em contato.

Eu particularmente adoro a família de métodos do Crystal e por isso resolvi começar por ele, então vamos lá!

Em primeiro lugar o método Crystal é uma família de métodos, desenvolvida por Alistair Cockburn.

Esses métodos se concentraram principalmente nas pessoas e em sua interação e foram estabelecidos em 1990, quando a IBM pediu à Alistair1 para criar uma maneira de gerenciar um projeto orientado a objetos.

O que vamos ver neste artigo?

Família Crystal

O que é o Crystal? Discutiremos o que torna o método Crystal diferente de outros métodos Agile.

Além disso, falaremos sobre como ele foi projetado, as razões por trás disso, em detalhes.

A família Crystal: Alistair acreditava que um tamanho único não serve para todos.

Em outras palavras, significa que um mesmo método não pode ser aplicado a todo tipo de projeto.

Sobretudo ele projetou o Crystal de uma maneira que ele possua vários métodos.

A família Crystal nos apresenta vários métodos projetados sob a metodologia Crystal.

Além do exposto, ele também explica o motivo pelo qual inclui várias maneiras e como elas são diferentes umas das outras.

Funções e responsabilidades: descreve as múltiplas funções e suas responsabilidades com base em seu método.

Características e propriedades: Vamos tentar entender os recursos e as propriedades com a ajuda de exemplos.

Fluxo do processo Crystal: o fluxo de trabalho completo do método Crystal será definido nesta seção. Além disso, o processo envolvido será descrito.

Vantagens e desvantagens: Além do exposto, as vantagens e desvantagens do método Crystal e como elas afetam o projeto serão explicadas nesta seção.

Comparativo entre o Scrum e  o Crystal: Finalmente, a comparação de como o Crystal é diferente do Scrum (será? #NoSpoilers).

O que é o método Crystal? Qual é a diferença e qual é o seu foco?

Primeiramente em 1991, a IBM pediu a Alistair Cockburn para desenvolver uma metodologia do projeto orientado a objetos; e claro, ele sabia que seria um desafio.

Então após uma extensa pesquisa, ele concluiu que todas as equipes de sucesso compartilhavam o mesmo padrão e técnicas sem usar nenhuma metodologia específica do Projeto.

Consequentemente, ele usou suas descobertas e construiu uma família de metodologias e a chamou de Crystal.

A metodologia Crystal é uma das abordagens mais leves e flexíveis para desenvolver software.

Sob o mesmo ponto de vista, é composto por vários processos ágeis, incluindo Crystal Clear, Crystal Yellow, Crystal Orange e outros métodos caracterizados de forma única.

Para concluir, a família Crystal foca na percepção de que cada projeto tem características únicas. Portanto, as políticas e práticas devem ser personalizadas para acomodar esses recursos.

Propriedades Crystal

Crystal Propriedades

 

Trabalho em equipe

A primeira propriedade é o trabalho em equipe, que se concentra em dar tarefas aos membros da equipe e, além disso, incentiva-os a realizar tarefas em equipe e não como indivíduos.

Comunicação

A segunda é a comunicação. É o aspecto mais crítico de qualquer projeto. É necessária uma comunicação adequada por e-mail ou pessoalmente entre o Cliente e os Desenvolvedores.

Além disso, é vital também dentro das equipes.

Simplicidade

A terceira propriedade concentra-se no fato de que o Design do Produto, o Documento de Requisitos e outras documentações precisam ser compreensíveis e diretos.

Isso permitirá que todos compreendam e trabalhem com mais eficiência.

Reflexão

A propriedade Próximo tem como objetivo alcançar três aspectos principais da Reflexão, ou seja:

  • Respondendo e relatando corretamente : Primeiro, todos os envolvidos no projeto devem responder conforme e quando necessário. Além disso, eles devem fornecer todas as atualizações a tempo para facilitar o entendimento do progresso por outras pessoas.

  • Raciocínio : em segundo lugar, isso significa fornecer um motivo válido para cada ação. Desenvolvedores e testadores devem ter a lógica certa para cada um de seus esforços para não deixar sua atividade considerar um desperdício.

  • Reconstrução como e quando necessário : Finalmente, o Testador e os Desenvolvedores devem estar cientes de todos os estágios que executaram, para que seja fácil reverter e reconstruir a codificação.

Ajustes frequentes

A equipe deve poder fazer os ajustes de acordo com a situação e as alterações necessárias.

Melhorar processos

A melhoria é um processo contínuo. Eles podem ser aprimorados com base no feedback do cliente, feedback interno, da saída da reunião, após a análise da causa raiz de qualquer bug.

Na mesma linha que outros métodos ágeis, a Metodologia Crystal também promove entrega contínua e em tempo de entregas funcionais de pacotes de software.

Ainda inspira alta participação do usuário, adaptabilidade e exclusões de distrações e qualquer desperdício.

As bases do Método Crystal

Da mesma forma, estas duas bases são assumidas de acordo com duas suposições críticas:

  • Primeiro, a equipe pode se tornar mais eficiente, simplificando seu trabalho e o projeto.

  • Segundo, todo projeto é diferente dos outros e requer alguns métodos e estratégias específicos.

De acordo com Alistair, todo projeto é um jogo, e precisamos criar uma estratégia para vencer o jogo.

Ele disse que devemos incluir todos, permitir que eles interajam e recebam as ideias de todos enquanto planejam um projeto.

Da mesma forma, ele preconiza que não devemos nos concentrar no que fizemos; mas devemos nos concentrar “no que o cliente quer que façamos?

O  Método Crystal se concentra em

  1. Pessoas envolvidas

  2. Interação entre as equipes

  3. Comunidade

  4. Habilidades das pessoas envolvidas

  5. Seus talentos

  6. Comunicação entre todas as equipes

A família Crystal

Após algum tempo realizando observação, dependendo da Criticidade, os projetos mudam o número de pessoas envolvidas em cada um deles.

Eventualmente Alistair observou que pequenas equipes foram capazes de construir e entregar projetos sem muita documentação e relatórios de status.

Tal qual enquanto as equipes maiores, trabalhando em projetos de grande escala, precisavam de muita papelada, atualizações contínuas e muita comunicação.

Ele descobriu que depende do tamanho do projeto e da complexidade do projeto.

Portanto, ele projetou o método Crystal , que possuía técnicas diferentes para diferentes tamanhos de projeto.

Por isso concluiu que a adequação do método Crystal depende de três dimensões:

  • Primeiro, tamanho da equipe

  • Segundo, Criticidade

  • Terceiro, a prioridade do projeto

Por exemplo, uma escola divide sua sexta série em diversas seções, tais como 6ª A, 6ª B, 6ª C com base nas seguintes métricas

  • As pontuações das turmas anteriores

  • Capacidade de entender

  • A força geral da sala comparada às outras

Portanto, dividir uma turma em seções ajuda muito os professores. Como o nível de compreensão é quase semelhante para todos os alunos, permite que os professores definam suas estratégias de ensino de acordo.

UAU! Esse foi o primeiro exemplo do mundo ágil que você leu que não era sobre software ou algo holístico como lego? Será que esse autor pode me falar mais? 

Claro que posso, mas pega um cafezinho vai….

Alistair usou cores diferentes para diferenciar entre métodos diferentes. O que, por sua vez, facilita a identificação de que maneira é usada quando.

 Crystal Tamanho

Métodos da família Crystal

Crystal Clear

  • Equipe pequena de 1-6 pessoas;
  • Suporta preço fixo, sem contrato de negociação;
  • Orientado para as pessoas não se concentra muito em processos e artefatos;
  • Requer documentação;
  • O foco da segurança do projeto.

Crystal Yellow

  • Equipe ainda de tamanho pequeno para médio de 7-20 pessoas;
  • Propriedade clara das áreas de código. A propriedade da área de código é definida para que, se houver alguma alteração necessária, apenas a pessoa que possui esse código cuidará dele;
  • O feedback é retirado dos “Usuários Reais“. Além disso, elimina outras confusões que podem ocorrer devido à comunicação indireta;
  • Prefira comunicação acessível e direta. Reduz a necessidade de muita documentação. Portanto, fica fácil para o desenvolvedor entender seu trabalho;
  • As declarações de missão são os objetivos definidos e verificados com o cliente;
  • O teste automatizado é usado para resolver os erros mais rapidamente;
  • Planos mensais de melhoria são definidos. O que inclui fazer uma lista de tarefas e alcançá-la dentro do prazo.

Crystal Orange

  • Equipe de tamanho médio 21-40 pessoas;
  • O projeto com duração média de 1-2 anos;
  • Divida as equipes de acordo com suas habilidades funcionais;
  • Assim como o método ágil, siga o desenvolvimento incremental;
  • É necessária uma liberação a cada 3-4 meses;
  • Todo lançamento é chamado de “Incremento”;
  • Projetado para projetos de tamanho médio.

Crystal Orange Web

  • Equipe de tamanho médio 21-40 pessoas;
  • Usado nos projetos que têm uma base de código em constante evolução que está sendo usada pelo público;
  • Ele se concentra em elevar o defeito mínimo.

Embora o Crystal Orange Web e o Crystal Orange sejam semelhantes, o Crystal Orange Web não lida com um único projeto, mas com uma série de iniciativas que requerem programação.

Contudo o resultado dessas iniciativas é mesclado com a base de código e é usado pelos desenvolvedores. No entanto, o método permanece o mesmo.

Logo essa é a razão pela qual não é mostrado no diagrama separadamente.

Crystal Red

  • Equipe de tamanho médio/grande 40-80 pessoas;

O método tradicional de desenvolvimento de software.

Além disso, as equipes são formadas e divididas conforme o trabalho necessário.

Crystal Maroon

  • Equipe de tamanho grande 80-200 pessoas;
  • Relacionado para equipes de projetos de grande porte;
  • Tempo médio de mais de 2 anos de projeto;

Além disso, os métodos definidos são diferentes e de acordo com a necessidade do software.

Embora acima estejam citados os principais membros da família Crystal. No entanto, para projetos de tamanho extremamente maiores, existem ainda mais dois métodos.

Crystal Diamond e Sapphire

Sem dúvida ambos são os métodos usados ​​para projetos muito críticos e de larga escala. Sua equipe e estratégias são decididas de acordo com a criticidade do projeto.

Além disso estes projetos devem ser incrivelmente significativos e envolvem o risco potencial da vida humana .

 Crystal Framework

Conforme mostrado na imagem acima, Conforto (C), Dinheiro (D), Dinheiro essencial (E) e Vida útil do projeto (L) são os fatores verticais.

Enquanto o fator horizontal é o tamanho da equipe .

Como escolher a metodologia Crystal correta?

Portanto, de acordo com Alistair, todos esses fatores devem ser considerados para decidir qual método seguir.

Por exemplo, para um projeto de tamanho 40, antes de confirmar a data de lançamento, os desenvolvedores considerarão o seguinte:

  • Quantas horas cada recurso fica confortável em trabalhar (C)
  • A quantia disponível de dinheiro (D) a ser usada para esse projeto
  • Quanto dinheiro é necessário para concluir o projeto (E)
  • Se algum desses requisitos não atender, o tamanho da equipe e a vida útil do projeto (L) poderão ser aumentadas ou diminuídos. E, finalmente, a metodologia mais viável é escolhida.

Como alternativa, considerando o tamanho da equipe, os desenvolvedores podem estimar a conclusão do projeto (L) com base no dinheiro fornecido (E), dinheiro disponível (D) e conforto dos recursos (C).

Papéis e responsabilidades

A diferença fundamental entre o Crystal Clear e outros métodos do Crystal é que, no Crystal Clear, há apenas uma equipe em um projeto.

Enquanto no restante dos métodos Crystal, existem várias equipes a seguir no projeto.

No entanto, em todas as metodologias do Crystal, uma tarefa pode incluir várias funções.

Os métodos Crystal têm muitas posições como Patrocinador Executivo, Executivo, Designer Líder, Programador, Usuário Embaixador e Testador.

Estes são os papéis principais.

Existem algumas outras sub-funções como Coordenador do Projeto, Business Expert, redator técnico, e testador de negócios.

Os papéis acima são divididos em duas categorias:

Funções reais

O patrocinador executivo é quem:

  • Aloca ou decide a alocação do dinheiro para o projeto;
  • Cria visibilidade para o projeto;
  • Ajude a equipe a tomar decisões cruciais em nível de negócios;

O usuário embaixador é o único:

  • Quem testaria o produto final;
  • Alguém que conhece o procedimento operacional completo;
  • Quem tem o conhecimento de todo o sistema em uso;

O Designer Principal(ou líder) é responsável por todo o trabalho técnico:

  • Deve ter uma experiência massiva com desenvolvimento de software
  • Deve ser capaz de descobrir quando a equipe do projeto está no caminho certo

O programador é outra pessoa significativa.

  • Um programador trabalha junto com o designer para criar o sistema de software.
  • Além disso, uma pessoa que pode codificar ou programar pode criar design e vice-versa.

Papel

Produto de trabalho

Patrocinador Declaração de missão e as prioridades de troca
Time como Grupo Estrutura do time e suas convenções
Resultados do workshop de reflexão
Coordenador O mapa do projeto
O plano de liberação
O status do projeto
A lista de riscos
O plano e o status da iteração
O cronograma de visualização
O especialista em negócios e o usuário Embaixador A lista ator-objetivo
O arquivo de casos de uso e requisitos
O modelo de função do usuário

Os papéis virtuais

O coordenador é o gerente de projetos, responsável por

  • Fazer as anotações nas reuniões de planejamento e revisão do projeto
  • Combinar as informações e as apresente aos patrocinadores
  • Manter o patrocinador do projeto informado sobre o status do projeto e manter as coisas visíveis.

O Especialista em negócios é a pessoa que:

  • Sabe como os negócios funcionam
  • Identifica as prioridades e pode diferenciar entre tarefas menos anteriores
  • Entende as políticas e garante que todos as sigam
  • Desenvolva todas as consultas que um programador possa ter sobre políticas e sistemas

O Redator técnico e o testador não são papéis permanentes e sim rotativos ou temporários. Um testador é responsável por:

  • Testar o software
  • Relatar um bug (se houver)
  • Tente corrigir o erro no final dele primeiro (se possível)

Enquanto o Redator técnico é responsável por escrever manual de ajuda do usuário.

Papel

Produto de trabalho

Designer principal (líder) Descrição da arquitetura
Designer-Programador Os rascunhos da tela
O modelo de domínio comum
Os rascunhos e notas de design
O código fonte
Testador O relatório de erro naquele momento
Redator técnico O manual de ajuda do usuário

As principais características da metodologia Crystal

  • Movido pelo homem: significa que o design do processo ocorre de maneira a dar importância às pessoas envolvidas no processo. Além disso, garante que o processo seja fácil de se adaptar e permite que as pessoas cresçam e se tornem mais organizadas.

  • Adaptável: O Crystal é uma metodologia que acredita na busca e adaptação, conforme os requisitos. Em outras palavras, significa que a fixação de processos, padrões e ferramentas não ocorre nesse método. Além disso, eles são ajustados para atender à necessidade da equipe e do projeto atual. Em outras palavras, eles são flexíveis.

  • Ultra-leve: Ultra-leve significa, sem documentação extensa, sem regras ou gerenciamento rígidos e rápidos e sem relatórios específicos. Em outras palavras, o método Crystal mantém as coisas leves, mantendo o fluxo de trabalho e a comunicação transparentes entre os membros da equipe envolvidos e o cliente.

Propriedades

As sete propriedades do Crystal Clear necessárias para executar um projeto com êxito são:

1. Entrega frequente

A prioridade de qualquer projeto é fornecer software de funcionando no final de cada versão, independentemente do tipo de projeto, tamanho da equipe, orçamento ou lucro.

Portanto, essa entrega deve ser frequente.

Para entender melhor, vamos considerar que ir à escola é uma tarefa. Dividimos essa tarefa em pequenas iterações como

  • Acordar a tempo;
  • Tomar banho;
  • Levar um lanche;
  • Pegar o ônibus;
  • Chegar à escola.

Com o propósito de chegar à escola a tempo, precisamos garantir que cada uma das iterações seja entregue a tempo. A entrega de cada iteração a tempo garantirá a liberação a tempo.

Certamente a entrega frequente de software tem muitos benefícios, que incluem:

  • Liberação de iteração regular. O que, por sua vez, significa as funcionalidades de trabalho fornecidas regularmente.
  • É possível encontrar os problemas e resolvê-los em tempo real, pois garantem que o ciclo de iteração seja curto semanalmente, não mais que quatro meses).
  • O Cliente pode ver em tempo real se o projeto está se movendo conforme suas expectativas ou não.

2. Melhoria reflexiva

Crystal Clear é um método e não um padrão. Deixa muitas coisas para a equipe reproduzir e confirmar após a discussão.

Uma decisão incorreta pode produzir um resultado adverso. Portanto, é crucial discutir em cada situação, o que pode funcionar e o que pode não funcionar.

Durante os dias de faculdade, para a prática de física, fizemos várias leituras do mesmo aparelho, para o exame prático correspondente. No entanto, cada leitura acabou sendo diferente. Você se lembra do que costumava fazer nessa situação? Discutíamos entre nós e encontramos a leitura mais próxima.

Da mesma forma, neste método, para qualquer problema, podemos discutir e chegar à solução mais próxima. É chamado de reflexão e melhoria.

Melhora o processo de várias maneiras

  • Pode-se encontrar a resposta para o problema através de discussão.
  • Os desenvolvedores também dedicam seu tempo a melhorar o processo.
  • Uma reunião semanal ou um workshop ajuda a encontrar quais processos estão funcionando e o que precisa ser modificado.

3. Comunicação Osmótica

Inegavelmente a comunicação osmótica funciona bem para equipes de pequeno porte. Essa comunicação ocorre quando todos os membros da equipe estão em uma mesma sala.

Uma discussão ocorre entre todos os membros. Eles podem ou não participar, mas todos percebem a ideia da discussão.

Além disso, só o fato de uma discussão qualquer acontecer entre os membros de um time, a conversa acaba ficando na cabeça de todos, seja uma resolução simples de um problema, seja um erro grave.

Em suma para que a comunicação osmótica funcione, é necessário o requisito de proximidade física entre os membros da equipe.

Bem como uma discussão em sala de aula. Os professores serão o especialista da disciplina (desenvolvedor especialista no nosso caso). Eles responderão a todas as perguntas dos alunos.

Benefícios de um time co-localizado

  • A informação flui rapidamente;
  • Redução de despesas gerais de comunicação;
  • Todos conhecem quais problemas podem ocorrer e já conhecem as soluções.

4. Segurança pessoal

Segurança pessoal é o primeiro passo em direção à confiança. Os membros da equipe devem se manifestar quando algo os estiver incomodando, sem medo de serem interrogados ou retaliados.

Esta informação pode ser qualquer coisa como

  • O design de outra pessoa precisa de melhorias;
  • As estimativas de tempo não são realistas;
  • O companheiro de equipe não chegou a tempo ou qualquer outra coisa.

Quando alguém na equipe for capaz de falar sem obstruções, uma equipe poderá determinar e corrigir suas falhas.

Além disso, quando a confiança não é quebrada, a equipe tende a falar livremente. O que, por sua vez, ajudará na redução de defeitos e ajudará a concluir o projeto a tempo.

Certamente gera uma sensação de segurança pessoal; essa é uma propriedade muito desafiadora para se obter em uma equipe. Logo durante o projeto, as pessoas conhecem quem é útil e as ouvem atentamente e quem não é.

Eventualmente, eles encontram com quem se sentem confortáveis ​​e se sentem seguros para conversar. Com a Segurança Pessoal, eles falam de coração durante as sessões de Melhoria Reflexiva .

Entretanto para qualquer projeto, há três coisas que os desenvolvedores de software devem estar abertos:

  • Ser capaz de revelar sua ignorância;
  • Ser capaz de dizer os erros cometidos;
  • Aceitar a incapacidade que eles têm para atender aos requisitos de uma tarefa.

Essas três coisas estão diretamente relacionadas ao projeto e impactarão a entrega:

  • É como dizer ao seu chefe que você subestimou o custo ou despesa em mais de 50%, ou;
  • Discordar do seu chefe sobre o cronograma em uma reunião de equipe;
  • Ter um longo debate “acalorado” com seu companheiro de equipe e ainda assim terminar amigável.

Deste modo a segurança pessoal permite que:

  • Membros da equipe falem livremente;
  • Compartilhem suas opiniões e dúvidas sem se preocupar com o que os outros vão pensar;
  • Comunicação adequada e eficaz;
  • Indivíduos para corrigir seus erros.

5. Foco

Ademais líderes e executivos devem definir as prioridades corretamente. Eles devem decidir em que os desenvolvedores devem trabalhar e permitir que eles trabalhem nessas atividades sem nenhuma interrupção.

Eles devem dar à equipe algum tempo dedicado (pelo menos 2 a 3 horas) todos os dias. Durante esse período, os desenvolvedores devem trabalhar apenas nessa atividade sem interrupções, demonstrações, ligações ou reuniões.

Enquanto isso os desenvolvedores devem poder se concentrar em seu trabalho para esse período específico.

Por exemplo, durante os exames escolares (ou simulados), três horas dedicadas são atribuídas para escrever as respostas para um conjunto específico de perguntas. Durante essas três horas, o aluno se concentra em escrever as respostas para essas perguntas e não será interrompido até que o tempo termine.

As vantagens de se concentrar são:

  • Os desenvolvedores entendem melhor a tarefa;
  • Melhorando o foco, mais cedo o trabalho será realizado;
  • Objetivo e definições do projeto ficam mais claras;
  • Não existe perda de tempo e recursos em itens desnecessários.

6. Fácil acesso a um usuário especialista

De acordo com Keil e Carmel2 que realizaram uma pesquisa:

“Os projetos bem-sucedidos tinham links melhores e diretos para os usuários reais, em comparação com os que não obtiveram êxito”.

Os desenvolvedores precisam ter um link direto para o “usuário real” Usuário real significa o mesmo conjunto de pessoas que usarão o produto do projeto.

Assim eles são as pessoas que usarão o produto e, portanto, poderão dizer melhor aos desenvolvedores como querem que o produto seja.

Uma criança só pode dizer se o livro que o professor afirma ser fácil de entender é realmente fácil de entender ou não. Aqui, o garoto será o usuário real e o livro é o produto.

No entanto, na prática, é difícil ter acesso direto a usuários reais. Em caso de lançamento frequente, os desenvolvedores precisam testar um novo recurso toda semana.

O que, por sua vez, torna-se muito difícil de encontrar o usuário real para verificá-lo toda semana. Uma solução para isso é encontrar um único usuário disposto a experimentar seu novo software.

Esse problema ocorre com todos os métodos com entrega frequente.

Além disso, existem muitos pontos positivos que os desenvolvedores ganham quando têm acesso a usuários reais

  • Eles podem receber feedback em tempo real;
  • Pode-se incluir melhorias conforme o especialista (usuário real);
  • Os desenvolvedores trabalham diretamente com os especialistas, facilitando a comunicação;
  • O processo de aprovação se torna fácil e, portanto, o tempo e documentação também são reduzidos.

7. Ambiente técnico e Integração frequente

O objetivo principal do ambiente técnico é fazer integração e teste contínuos para identificar erros, quebras de código, bugs etc.

Em virtude de a integração contínua ocorrer regularmente usando testes automatizados, o gerenciamento de configuração e integração frequentes. Portanto, é menos provável que os problemas ocorram.

Concomitantemente os testadores podem verificar rapidamente se o código está funcionando bem ou não usando testes automatizados.

Assim se houver algum problema, o código pode ser revisado para fazê-lo funcionar.

Nesse sentido o teste automatizado é mais rápido que o manual e dá liberdade ao testador para concluir rapidamente o trabalho e voltar para casa a tempo.

Usando o gerenciamento de configuração, é possível fazer o seguinte:

  • Em primeiro lugar, as pessoas podem verificar seu trabalho;
  • Em segundo lugar, eles podem fazer alterações, se necessário;
  • Além disso, eles podem finalizar a configuração para liberação;
  • Finalmente, eles podem reverter para o estágio anterior se encontrarem algum problema.

Naturalmente as equipes integram mais frequentemente o sistema além disso é mais rápido para eles detectarem problemas. A maior parte da equipe técnica faz isso várias vezes ao dia e, ou então diariamente.

Vantagens de ter um ambiente técnico

  • Permite que desenvolvedores e testadores identifiquem os problemas que surgem da mudança;
  • É fácil detectar problemas se todas as atividades acima acontecerem diariamente.
  • Os problemas não crescem para o nível do projeto e são resolvidos apenas na iteração.

No entanto, para o Crystal Clear, essa não é uma propriedade obrigatória, pois é um projeto de tamanho pequeno. Abaixo está a imagem dos recursos necessários para o Crystal Clear.

 crystal-propriedades5

Padrões de política

As práticas que são seguidas e aplicadas durante o processo de desenvolvimento de software são o padrão de políticas.

Tanto o Crystal Clear como o Crystal Orange sugerem os padrões de política abaixo mencionados.

  • Entrega incremental regular;
  • Rastreamento de progresso por etapas com base em entregas de software e decisões significativas, em vez de documentos escritos;
  • Envolvimento direto do usuário;
  • Teste de regressão automatizado da funcionalidade;
  • Duas visualizações do usuário por versão. O que, por sua vez, significa que pelo menos dois usuários verificarão a função liberada para evitar erros;
  • Workshops de ajuste de produto e metodologia no início e no meio de cada incremento.

Então a maioria dos padrões de política é a mesma para todos os métodos do Crystal. No entanto, o tempo de entrega incremental pode variar de acordo com a força e o número de funcionários do projeto.

Por exemplo, o padrão de política do Crystal Clear sugere entrega incremental dentro de dois a três meses. Enquanto que para a Crystal Orange, a entrega incremental pode durar até quatro meses.

Em outras palavras os padrões de política são obrigatórios à seguir para qualquer processo. No entanto, eles são substituíveis por uma prática semelhante.

Fluxo de processo

Inicialmente o processo padrão do ciclo de vida do Crystal é semelhante ao Scrum, como mostra a figura abaixo:

 crystal-fluxo[5]

Tal qual esta figura mostra qualquer entrega do projeto iniciada com pequenos episódios. Os episódios (iterações) são projetados.

Naturalmente o planejamento e a codificação da funcionalidade ocorrem para que sua entrega possa seguir na próxima iteração.

  • A mesma base de código também pode ser usada para a próxima codificação de iteração. Isso é chamado de integração desse episódio;
  • Depois disso, cada iteração é entregue diariamente ou semanalmente;
  • Quando todas as iterações terminam, a integração do projeto como um todo é executada;
  • Finalmente, após a integração e o teste, a entrega do projeto ocorre.

 crystal-episodios

O método dos 7 ciclos do Crystal é o seguinte:

1. O ciclo do projeto :

Um ciclo de projeto possui as três partes a seguir:

Parte 1: A atividade de fretamento

Em primeiro lugar, a fase de fretamento envolve várias atividades. Desenvolvendo um plano inicial, criando e designando equipes de Desenvolvimento, realizando análises de viabilidade.

Ou seja, algumas das atividades mais importantes realizadas são:

  • Criar a equipe principal: a definição e a criação da equipe completa ocorrem na fase de criação dos gráficos hierárquicos. A decisão de um patrocinador executivo, um designer, um desenvolvedor e um usuário importante ocorre. Após a seleção dos papéis principais, mais duas ou três pessoas serão adicionadas às equipes.

  • Fazer exploração: Nesta fase, o desenvolvedor e a equipe de design explorarão todas as soluções e escolherão a solução mais adequada para o desenvolvimento.

  • Metodologia de modelagem: Após a discussão de todas as soluções possíveis, os Desenvolvedores finalizarão a metodologia que seguirão para o desenvolvimento.

  • Planejamento inicial do projeto : Após a finalização do método, os desenvolvedores se sentarão com o restante das equipes e farão o planejamento da fase inicial. Além disso, eles começarão a projetar o projeto adequadamente.

Parte 2: Entrega cíclica

Em segundo lugar, a entrega cíclica tem duas fases, durante as quais:

  • A equipe atualiza e aprimora o plano de liberação;
  • A equipe de desenvolvimento implementa uma subseção dos requisitos por meio de uma ou mais iterações;
  • A entrega integrada de produtos acontece com usuários reais;
  • O desenvolvedor líder analisa o plano do projeto e a metodologia de desenvolvimento adotada;

Parte 3: Conclusão

Por fim, esta fase tem as atividades finais. A implantação do produto ocorre no ambiente de um usuário real.

Logo após a implementação, as revisões e reflexões pós-implantação ocorrem nesta fase.

2. O ciclo de entrega

O ciclo de entrega é a unidade de entrega e mostra o progresso até a entrega. Mostra a entrega do produto final. Pode levar de uma semana a três meses ou mais, dependendo do tamanho do projeto. Além do acima, esse ciclo oferece duas ou mais iterações.

3. O ciclo de iteração

A unidade de estimativa, desenvolvimento e teste. Além disso, também pode variar de uma semana a três meses.

4. A semana / dia de trabalho:

É uma unidade que mostra todo o trabalho realizado por uma semana.

5. Período de integração:

É uma unidade de design, desenvolvimento, integração e teste de sistema. Esse período começa em algumas horas e pode durar até três dias.

6. O dia de trabalho:

Uma unidade que mostra todo o trabalho realizado diariamente.

7. O episódio:

Projetando, desenvolvendo e verificando uma pequena seção (iteração) de código. Pode levar de alguns minutos a algumas horas.

 crystal-atividades

A figura acima mostra o desempenho de diferentes atividades em vários ciclos.

Por exemplo, o Ciclo do Projeto tem o Gráfico como uma das atividades. Primeiro, para planejar todas as Iterações, teremos uma reunião Standup Diária.

Segundo, o planejamento para testes e codificação ocorre. Por fim, teste o planejamento antes do lançamento. Da mesma forma, o mesmo processo segue para cada iteração.

Fluxo incremental do processo de desenvolvimento:

Todas as metodologias do Crystal envolvem muitas práticas, como desenvolvimento incremental. Contudo na descrição de Crystal Orange e Crystal Clear (Cockburn 1998), esse desenvolvimento incremental tinha muitas atividades. Essas atividades são:

  • Staging
  • Monitoramento
  • Revisão
  • Paralelismo e fluxo

E muitas mais. Vamos conhecer mais sobre essas atividades.

Staging

O planejamento do próximo incremento acontece nesta etapa. Nesta fase, os desenvolvedores também planejam o próximo lançamento.

Consiste em um cronograma de atividades concluídas do primeiro mês ao final é apresentado.

Além disso, a equipe de desenvolvimento, que estaria trabalhando nele, selecionará os requisitos que precisam ser implementados nesse incremento específico e serão agendados conforme sua capacidade de entrega.

Monitoramento

O monitoramento visa garantir que o progresso seja conforme o plano.

Em outras palavras, refere-se às entregas da equipe durante o processo completo de desenvolvimento de software, relacionadas ao seu crescimento e estabilidade.

Em suma o progresso contínuo em diferentes estágios é mensurável sob vários marcos, como:

  • Início: quando o trabalho do projeto começa e a equipe de desenvolvimento começa a trabalhar no planejamento.
  • Revisão 1: Monitora a revisão do planejamento do projeto e garante a cobertura de todos os pontos.
  • Revisão 2: Monitorando se a análise de codificação e design ocorre.
  • Teste: Depois que a codificação termina, surge a necessidade de teste. O que, por sua vez, requer monitoramento para que o teste seja executado adequadamente.
  • Entrega: Após o teste bem-sucedido da funcionalidade, o cliente recebe a entrega. No entanto, antes disso, o líder deve monitorar se a funcionalidade fornecida é conforme as expectativas do cliente.
  • Estágios de estabilidade: refere-se à necessidade de observar que o projeto é estável o suficiente para revisar. Se houver alguma flutuação, os desenvolvedores precisam cuidar disso.
  • Monitoramento: É um processo contínuo até a entrega do projeto, e todos os métodos de cristal exigem.

Revisão

Cada incremento e release possui muitas iterações associadas. E a iteração inclui as seguintes atividades:

  • Construção: Os desenvolvedores fazem o design e a codificação aqui.
  • Demonstração e teste: Os testadores executam esta fase.
  • Revisão dos objetivos do incremento: O desenvolvedor faz a revisão e verificará se está trabalhando no sentido do compromisso ou não.

Paralelismo e Fluxo

Paralelismo e fluxo significam a execução simultânea de duas obras.

Em outras palavras, significa que, quando a equipe de monitoramento confirmar que todas as entregas estão estáveis ​​o suficiente, a próxima tarefa será iniciada.

Agora, nesta fase, a maioria das equipes pode trabalhar paralelamente nas obras atribuídas a elas.

Estratégia de diversidade holística

Como o Crystal Clear é o método muito pequeno no tamanho da equipe, ele não precisa de uma estratégia de diversidade. As outras formas além da Crystal Clear seguem a Estratégia de diversidade holística.

Significa dividir grandes equipes em pequenos grupos, de acordo com suas funcionalidades e conhecimentos.

A ideia por trás disso é incluir várias especialidades em uma única equipe.

Técnica de ajuste de metodologia

Essa é uma técnica básica de racionalização dos métodos para vários métodos do Crystal. Essa técnica usa os dados de entrevistas, workshops e feedbacks do projeto para descobrir ou definir uma nova técnica ou ajustar qualquer método existente do método Crystal.

A ideia por trás disso é corrigir ou melhorar o processo de desenvolvimento atual.

Sem dúvida o método Crystal acredita que, a cada incremento, o projeto pode ter obtido algum conhecimento novo (lições aprendidas). Que, por sua vez, são usados ​​nos próximos projetos e nos próximos incrementos.

Além disso, também nos ajuda a descobrir qual ferramenta ou técnica é mais adequada para qual método de cristal.

Visualizações do usuário

Os métodos Crystal sugerem que, para cada versão, o produto final deve ser visualizado pelos usuários pelo menos duas vezes. Isso, por sua vez, diminui as chances de a equipe ter verificado ou testado errado.

Para um projeto em larga escala, esse número de visualizações do usuário pode aumentar para três por incremento.

Oficinas de reflexão

Geralmente a maioria das metodologias de projetos menores do Crystal, como Crystal Clear e Crystal Orange, não define nenhuma técnica específica a ser usada em seus projetos.

Certamente eles podem adotar técnicas de outros métodos populares como XP, Scrum e outros.

Com o propósito de sempre se adequar ao projeto, eles podem até substituir as técnicas de outras metodologias no lugar da adotada por eles.

Os métodos do Crystal adotaram a técnica conhecida como reflexão.

De acordo com seus pilares os métodos de cristal realizam oficinas de reflexão antes e depois de cada incremento. Além disso, o objetivo de ter essas oficinas é promover o aprendizado constante dos resultados dos testes, feedbacks e experiências.

Conclusão sobre o CrystalSe você chegou até aqui está de parabéns Padawan!!!

Ao contrário de outros métodos, a Crystal Clear se concentra no ajuste de projetos e métodos de acordo com as pessoas e o orçamento. O que, por sua vez, torna esse método diferente.

Em suma métodos diferentes para diferentes tamanhos de equipe, o Crystal fornece uma ideia clara sobre qual método usar e quando. Portanto, economiza tempo e esforço.

Vantagens e desvantagens do método Crystal

Vantagens

  • Primeiro, o método Crystal é flexível e pode se ajustar ao tipo de projeto, tamanho da equipe e requisitos do projeto.
  • Em segundo lugar, ocorre a entrega prioritária dos componentes críticos e altamente essenciais do projeto.
  • Além do exposto, esse projeto pode ter até dez membros da equipe.
  • Além disso, esse método promove a comunicação eficaz da equipe e ajuda os membros da equipe a aprender uns com os outros.
  • Geralmente, possui um contrato de preço fixo, o que ajuda na finalização do tamanho e no planejamento da equipe, de acordo com o orçamento.

Desvantagens

  • Em primeiro lugar, os princípios seguidos podem variar de acordo com o tamanho da equipe e do projeto, o que dificulta a compreensão.
  • Em segundo lugar, ele precisa de comunicação constante, e é por isso que pode não funcionar bem para os projetos que têm várias áreas de trabalho.
  • Além disso, como o planejamento e o desenvolvimento não dependem do requisito, torna-se difícil mudar de uma abordagem para outra no meio do projeto.

Diferenças entre Crystal e Scrum

Crystal

Scrum

O cristal é mais permissivo. Portanto, ele aceita alterações de acordo com o requisito de projeto e tamanho da equipe. Scrum é mais disciplinado. Portanto, uma vez iniciado o Sprint, ele não permite que outras alterações sejam realizadas no escopo do sprint.
O Crystal oferece conforme a criticidade O Scrum entrega conforme a prioridade dos itens da lista de pendências.
Devido à flexibilidade, o requisito de documentação adequada se torna vital. Muitas vezes criticado devido a documentação insuficiente
Depois de finalizar o processo e o orçamento, nada pode mudar. Devido à aceitação de solicitações ad hoc, os clientes exigem mais.
O Crystal possui métodos diferentes para cada tipo de projeto, com base no número de pessoas que trabalham na equipe. O Scrum acredita em “um método serve para todos”. Independentemente do tamanho da equipe, uma única metodologia se aplica aqui. A equipe geral divide as equipes de scrum. Portanto, o número de equipes de Scrum pode aumentar, mas o tamanho da equipe de Scrum individual permanece o mesmo.

Nota do autor

Se até o momento você não entendia nada de Crystal, você acabou entendo agora o motivo de eu gostar do Método? Contrato à preço fixo, flexibilidade de uso de ferramentas e métodos, comunicação clara, cliente cara-a-cara, testes, ou seja, tudo o que temos no Brasil! o Alistair é realmente Fantástico!!!!!!!

Tem opinião diferente da minha? Parecida? Alguma crítica ou elogio? Comente ai à baixo!

Referências

  1. Alistair Cockburn – Wikipédia
  2. Keil, Mark & Carmel, Erran, Customer-Development Links in Software Development.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *