SlideShare uma empresa Scribd logo
METODOLOGIA ÁGIL: Família
Crystal de Cockburn
Vanessa Finoto
Faculdade de Tecnologia de Jales
Centro Estadual de Educação
Tecnológica Paula Souza
Jales - SP, Brasil
vanessa.finoto@fatec.sp.gov.br
Luiz Roberto Reinoso
Faculdade de Tecnologia de Jales
Centro Estadual de Educação
Tecnológica Paula Souza
Jales - SP, Brasil
luiz.reinoso@fatec.sp.gov.br
RESUMO
Metodologias Ágeis são conjuntos de ferramentas de gestão que vem sendo cada
vez mais utilizadas no desenvolvimento de sistemas. Uma dessas metodologias é a
família Crystal, desenvolvida no final da década de 90 por Alistair Cockburn. Ele
percebeu através de suas pesquisas a necessidade de uma metodologia para o
desenvolvimento de softwares de forma otimizada explorando de forma frequente as
características especificas de cada membro que estão inseridos na equipe. O
objetivo principal desse artigo é conhecer um pouco sobre como funciona a família
Crystal. Ao decorrer do trabalho conheceremos a história, as características
marcantes e a importância das cores, da criticidade e o valor das pessoas nessa
metodologia.
Palavras chaves: Crystal. Família. Metodologia
1. INTRODUÇÃO
A computação surgiu nos anos 40, e os maiores investimentos naquela
época eram voltados a hardware (MARQUES, 2012). No início dos anos 50, passou-
se a ter o domínio da tecnologia de hardware e então os investimentos se voltaram
ao desenvolvimento dos sistemas operacionais possibilitando o surgimento das
primeiras linguagens de programação (LEITÂO, 2010).
Com o desenvolvimento dessas duas importantes tecnologias foi necessário
criar sistemas mais complexos e maiores, então se iniciou a “crise do software”
(MARQUES, 2012). Em 1968 foi realizada uma conferência pelo Comitê de Ciência
da NATO (North Atlantic Treaty Organization) com o nome “Engenharia de Software”
(EING, 2003). Nessa conferência foi discutido sobre a existência de uma real crise,
onde constatou-se problemas em relação aos projetos e aos programas (COSTA,
2012).
E foi a partir deste cenário que passou a se desenvolver os processos e
metodologias de desenvolvimento de software (DIAS, 2005). Um dos primeiros
processos surgiu em 1970 que ficou conhecido como processo em cascata que
possuía sete fases e uma só poderia ser iniciada após o término da anterior, porém
esse modelo trazia alguns transtornos em relação à mudança nas etapas anteriores
(EING, 2003). Dez anos depois esse modelo foi substituído pelo espiral (COSTA,
2012).
Os conceitos relacionados a metodologias ágeis de software surgiram na
década de 90, antes os métodos eram considerados pesados com documentação e
regulamentações burocráticas, portanto apenas grandes empresas utilizavam
(SBROCO; MACEDO, 2012).
Considerando os avanços da tecnologia pequenas e medias empresas
automatizaram os seus processos. Novos sistemas surgiram com alto grau de
complexidade causando problemas relacionados ao uso das metodologias
tradicionais principalmente em relação ao tamanho do projeto e a quantidade de
pessoas envolvidas (SBROCO; MACEDO, 2012).
Então Alistair Cockburn criou uma família de metodologias ágeis conhecida
como Crystal em 1998 (NASCIMENTO, 2008). Advinda de uma necessidade
observada por ele quando trabalhava na IBM. Durante sua passagem dedicou-se a
pesquisar várias equipes que compunham a empresa e observou que as
metodologias usadas eram robustas e sempre fracassavam ao termino do projeto
(SOUZA; RIBEIRO; SOUZA, 2013).
A família Crystal se baseia na gestão de pessoas com o foco na interação,
habilidades, talentos e comunicação (FILHO, 2011). De acordo com Cockburn
(2004) as pessoas que fazem parte de uma equipe possuem diferentes talentos e
habilidades, sendo um diferencial durante o desenvolvimento de um projeto,
principalmente se considerarmos que uma empresa de software pode trabalhar com
projetos nas mais diferentes áreas de atuação (SBROCO; MACEDO, 2012).
Para uma melhor compreensão a família foi dividida em cores. A Crystal
sugere que seja escolhida uma cor apropriada para cada projeto, de acordo com o
nível de criticidade e o tamanho da equipe (JUNIOR, 2008). De acordo com Santos
(2007), a criticidade é dividida em quatro níveis: Conforto (C), Baixo Custo (D), Alto
Custo (E) e Risco de Vida (L).
De acordo com Sbroco e Macedo (2012), quanto mais escura a cor mais
crítico é o sistema. Projetos menores com cores claras como Clear e Yellow
envolvem poucos desenvolvedores e, no caso de problemas, o prejuízo tende a ser
menor. Já os projetos maiores ou de segurança crítica como Orange e Red
normalmente possuem mais profissionais, contudo a perda é maior, podendo colocar
a vida de pessoas em risco (JUNIOR, 2008) como podemos observar na Figura 1.
Figura 1 – Métodos Crystal e suas dimensões.
Fonte: ABRAHAMSSON et al., 2002.
Apesar de existir diversas metodologias diferentes na mesma família, todas
possuem algumas características em comum, como, por exemplo, a abordagem
iterativa, a ênfase na comunicação e na cooperação entre a equipe (COCKBURN,
2004). As metodologias desenvolvidas e utilizadas até hoje são a Crystal Clear e a
Crystal Orange (SANTOS, 2007) que serão discutidas no processo tópico. O
presente trabalho possui como objetivo estudar detalhadamente os conceitos e as
características básicas da família de metodologias Crystal.
2. CARACTERÍSTICAS
A família Crystal é considerada uma metodologia leve com um código
genético comum, que foi criada para atender vários tipos de projetos e equipes que
necessitam de táticas para resolver diversos problemas (MARQUES, 2012). È
importante ressaltar que não há “uma“ metodologia Crystal. Existem diferentes tipos
de metodologias Crystal para diferentes tipos de projeto (SINÉSIO; CORREIA;
SILVA, 2012).
Para Cockburn (2004) a metodologia não é tão importante, pois a ideia
central é que cada empresa consiga definir as tarefas que lhes forem mais
suscetíveis ao projeto em desenvolvimento. Para isso Cockburn (2004) desenvolveu
alguns princípios característicos que pode ser compartilhado entres os membros da
família que são:
 Trabalho face a face: É o envolvimento do cliente em todas as
decisões do desenvolvimento do projeto, tornando mais produtivo e passando
confiabilidade para o consumidor. É também a comunicação que surge naturalmente
entre os desenvolvedores, que conseguem captar as partes relevantes de todo o
processo, como se estivessem pegando a informação por osmose.
 Peso significa custo: O projeto deve evitar coisas complexas que
provavelmente o usuário final não vai utilizar, pois quanto mais complicado o
software maior será o custo e o tempo de entrega.
 Metodologia Diferenciada: Nem todos os projetos são iguais, cada
um tem o seu diferencial, seja pela sua complexidade, pela quantidade de pessoas
envolvidas ou área de atuação, por isso é necessária uma metodologia correta de
acordo com o projeto que será desenvolvido.
 Mais cerimônia mais criticidade: Pode não ser possível eliminar
todos os produtos intermediários relacionados ao trabalho, porém, eles podem ser
reduzidos na medida em que a equipe possui vias de comunicação próximas e
informais, sendo que, quanto maior a troca de experiências entre a equipe, menor
será a necessidade de documentação.
 Comunicação eficiente: Melhor existir uma comunicação eficiente
entre cliente e o desenvolvedor do que entregar um produto que não funciona.
 Habilidade: Capacidade de trabalhar e lidar com pessoas de diferentes
personalidades no mesmo projeto.
 Entrega frequente: A propriedade mais importante de qualquer projeto
é o de garantir entrega funcional e código testado a cada poucos meses.
 Segurança Pessoal: A Segurança Pessoal se refere a possibilidade
de dizer quando algo está incomodando, sem medo de represálias. Exemplos disso
seria dizer ao gerente que o cronograma não está bem feito.
 Foco: Essa propriedade destaca que a equipe precisa de tranquilidade
para trabalhar na tarefa que lhes foi passada. E essa tranquilidade vem de um
ambiente onde as pessoas não são tiradas de sua tarefa para atuar em outras
coisas incompatíveis.
 Eficiência: A metodologia destaca que os gargalos devem ser
encontrados e que não adianta a equipe tentar otimizar o que não é um gargalo,
pois, isso não vai melhorar o projeto como um todo.
A Crystal possui como característica diferencial o ciclo de vida, que é
baseado em integrações, onde tudo deve funcionar como um relógio (SBROCO;
MACEDO, 2012). Sendo que cada projeto deve liberar as versões do software de
um a quatro meses. Após cada iteração são feitas reflexões sobre possíveis
melhorias.
Uma equipe que segue fielmente a filosofia e os princípios pode obter
resultados incríveis. Na Figura 2 podemos observar um modelo do ciclo de vida que
considera o desenvolvimento de um software de alta qualidade.
Figura 2 – Ciclo de vida da família de metodologias Crystal.
Fonte: (ABRAHAMSSON et al., 2002).
De acordo com Cockburn (2004) o ciclo de vida desta família de metodologias é
baseado nas seguintes práticas:
 Encenação: Plano do próximo incremento do sistema. Os desenvolvedores
selecionam os requisitos que serão criados e o prazo para sua entrega;
 Edição e revisão: Construção, demonstração e revisão dos objetivos do
incremento;
 Monitoramento do Processo: O método é monitorado com relação ao
avanço e estabilidade da equipe. É medido em marcos e em estágios de
permanência;
 Paralelismo e fluxo: No Crystal laranja, as diferentes equipes podem operar
com máximo paralelismo. Isso é 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
iteração com objetivo de analisar o progresso do projeto.
 Produtos de Trabalho: sequência de lançamento, modelos de objetos
comuns, manual do usuário, casos de teste e migração de código.
 Padrões: padrões de notação, convenções de produto, formatação e
qualidade usadas no projeto.
 Ferramentas: ferramentas mínimas utilizadas.
Além do ciclo vida Cockburn (2004) descreve no seu livro Crystal Clear
sobre a importância do modelo de jogo econômico-cooperativo, que é o
desenvolvimento de software em uma série de "jogos" cujos movimentos consistem
basicamente em invenção e comunicação.
Cada jogo tem dois objetivos conflitantes: entrega de software funcional e
preparação para a próxima etapa do jogo (MARQUES, 2012). O jogo nunca se
repete, de modo que cada projeto exige estratégias ligeiramente diferentes de todos
os jogos anteriores (SINÉSIO; CORREIA; SILVA, 2012).
O modelo de jogo econômico-cooperativo leva as pessoas a pensarem
sobre seu trabalho em um projeto de uma forma muito específica, focada e eficaz
(COCKBURN, 2004).
2.1 OS PAPÉIS E RESPONSABILIDADE DA CRYSTAL CLEAR E ORANGE
Como foi descrito na introdução a família Crystal é dividida em cores. Sendo
que cada cor representa uma metodologia. Atualmente somente dois membros da
família são utilizados a Crystal Clear, Crystal Orange (SINÉSIO; CORREIA; SILVA,
2012).
O método Crystal Clear é destinado a projetos pequenos incluindo até seis
desenvolvedores, porém, com extensão que pode chegar á doze pessoa
trabalhando no mesmo grupo (SANTOS, 2007). Uma equipe usando essa
metodologia pode ser localizada em um ambiente de trabalho compartilhado, devido
às limitações em sua estrutura de comunicação (COCKBURN, 2004). O seu risco de
criticidade é classificado com D (baixo custo). As especificações e o projeto são
feitos informalmente, através de esboços e anotações (MARQUES, 2012). O Crystal
Clear possui quatro papeis principais que estão descritos no Quadro 1.
Quadro 1 — Papéis e Responsabilidade do método Crystal Clear
Fonte: (ABRAHAMSSON et al., 2002).
O método Crystal Orange abrange projetos de médio porte, com até 40
colaboradores. Os trabalhos são divididos em times multifuncionais diversos que são
organizadas de acordo com as responsabilidades adotadas (LEITÂO, 2010).
Uma das características presentes na metodologia é considerar o tempo de
mercado, ou seja, estar sempre pronta para adaptações, de forma a dar suporte às
equipes em uma mudança de mercado, sem perder a funcionalidade do projeto.
Cada incremento gerado tem duração de dois a quatro meses e o ciclo de total do
projeto dura de um a dois anos (MARQUES, 2012).
Em uma metodologia baseada em pessoas, invés de processos, os papéis,
e suas respectivas responsabilidades são aspectos muito importantes no Orange
(SINÉSIO; CORREIA; SILVA, 2012). Tanto a Crystal Clear quanto a Crystal Orange
possuem diversos papéis em comum (COCKBURN, 2004). É claro que, sendo uma
metodologia mais pesada, é natural que a Crystal Orange possua mais papéis como
observado no Quadro 2.
Quadro 2 — Papéis e Responsabilidade do método Crystal Clear
Fonte: (ABRAHAMSSON et al., 2002).
3. EXEMPLOS PRÁTICOS
Projeto Fictício para a empresa WebCell – Comercialização de
Celulares
A empresa deseja criar um sistema para Internet para comercializar seus
celulares, assim como proporcionar aos usuários satisfação em seus propósitos de
negócios com site. Para captar os requisitos, a metodologia sugere uma entrevista e
um questionário em forma de briefing com perguntas-chave sobre o projeto a ser
desenvolvido. O quadro a seguir apresenta um modelo de como isso pode ser
registrado:
Briefing entrevista/questionário
Quadro 3 – Questionário realizado na empresa WebCell
Briefing para projeto web
Projeto: Comérciode celularesnaWeb – WebCell.
Analista/gerente
responsável:
Maria Luísa e FlávioMacedo.
Data - Fevereiro 2016
O que o site pretende vender? Relacionar os serviços oferecidos.
A princípiocomercializarcelulares,permitirque osinternautascadastremsuacontapara comprar
no site. Alémde fazera divulgaçãodosprodutosatravésde imagense vídeosparatornar o processo
de vendamaisintuitivo.
Vantagens/Desvantagens sobre os concorrentes.
A principal vantagemé apossibilidadede adquirircelularescompreçosde fábrica,poiscomprando
pelosite,podemosoferecerumaentregamaisdireta.Umaoutra vantagemé filmar oscelularesem
funcionamentodandodetalhesparaquemestáinteressado.
Parceiros ou referências de sites (outras empresas do grupo).
O site deveráconterumalistade todosos fabricantesde celularesNacionaise importadoscomque
trabalhame seus linksde acesso.
Objetivos a serem alcançados.
Apresentarumwebsite completoe comele ampliarasvendasque hoje se restringemaoestadode
São Paulo.
Público-alvo.
Todosos públicos,principalmente osinteressadosemcomprarcelulares.
Conteúdo do site (relação inicial das páginas).
Home,contato,Área do Usuário,ofertas,Suporte,celulares, acessórios,maisprodutose
comunidade.
Ferramentas de marketing utilizadas atualmente (relacionar outdoor, comerciais etc.).
Outdooremcidades,panfletagem,anúnciosnosjornaise revistasdacapital.
Tempo para desenvolvimento sugerido pela empresa (urgência).
Um ano (negociável).
Fonte: Elaborado pelos autores.
Documento de Requisitos
Depois de receber o briefing devidamente respondido, é possível dar início a
documentação que relaciona os requisitos do sistema e suas funcionalidades
(MARQUES, 2012). Para garantir o correto regimento do documento serão
necessárias outras reuniões. A metodologia Crystal possibilita isso para definir
claramente o que se pretende (SBROCO; MACEDO, 2012).
Visões do usuário
A cada fase e cada documento, o usuário principal está envolvido e deve
valida-los, dando um feedback sobre o assunto. O usuário deve solicitar
modificações e alterações de possíveis equívocos se for necessário (MARQUES,
2012). O gerente de projeto pode solicitar, por meio de documento assinaturas do
usuário e do patrocinador do projeto, concordando com os requisitos solicitados.
Modelagem
Com o documento de requisitos em mãos, é então realizada a sua
modelagem, utilizando, no mínimo, os seguintes diagramas da UML: diagrama de
casos de uso, diagrama de atividades ou sequência e diagrama de classes. Esses
diagramas devem ser explicados ao usuário e validados por ele (SBROCO;
MACEDO, 2012).
Design de projeto
Um conjunto de interfaces deve ser criado com base nos questionamentos
do briefing, bem como a solicitação de cores, fontes e estilos feitas pelos
stakeholders.
Sequências de Releases
Após a modelagem dos requisitos e a escolha de telas, o coordenador de
projeto cria um modelo de prioridades junto com usuário e decide as
funcionalidades, recursos e data previstas para a entrega entre os desenvolvedores
(NASCIMENTO, 2008). Os programadores então passam a saber as datas previstas
para a entrega das funcionalidades e começam a codificação. Em cada iteração os
resultados são coletados e analisados para fases subsequentes, sempre levando em
conta que a Crystal Clear exige o mínimo de duas entregas de funcionalidades ao
cliente por mês (SBROCO; MACEDO, 2012). Isso pode ser observado no exemplo
do quadro a seguir.
Quadro 4 – Sequência de Desenvolvimento empresa WebCell
Sequência de desenvolvimento
Projeto: Comércio de Celulares Web - WebCell
ID Descrição Data Início Data Fim
RF001 Cadastro de celulares novos 01/fev/16 15/fev/16
RF002 Cadastro de usuários para login administrativo 01/fev/16 15/fev/16
... ...
... ... (listar os requisitos por ordem de prioridade)
Fonte: Elaborado pelos autores.
Casos de testes
Os testes de acordo com a Crystal Clear são realizados com o sistema
finalizado, ou seja, tem o objetivo de testar suas funcionalidades no ambiente de
trabalho (SBROCO; MACEDO, 2012).
Manual do usuário
O redator técnico vai incluindo no manual do usuário as funcionalidades que
já foram devidamente testadas. Além da descrição, é recomendável que inclua
outras formas de ajudar o usuário.
4. EMPRESAS QUE UTILIZAM
A metodologia Crystal foi desenvolvida e utilizada na IBM no início da
década de 2000, porém com o tempo foi substituída pela RUP (SOUZA; RIBEIRO;
SOUZA, 2013).
Apesar de não existir mais laços entre a Crystal e a IBM, o escritor Cockburn
continua investindo em sua metodologia (COCKBURN, 2004).
Através de pesquisas realizadas nesse artigo nos deparamos com a falta de
documentos e informações sobre empresas que utilizam a família Crystal. Mas de
acordo com Sbrocco e Macedo (2012), a metodologia pode ser utilizada em vários
tipos de empresas não importando o seu tamanho e nem sua área.
5. CONCLUSÃO
O escritor Alistair Cockburn vem destacando na área acadêmica de
metodologias os processos de desenvolvimento, e aplicou todo o seu conhecimento
para criar a família Crystal, que surgiu para melhorar as metodologias tradicionais.
Cockburn propôs o uso de determinada metodologia para cada tipo de
projeto sendo que essa estratégia pode ser aplicada ao projeto através de reuniões
e revisões. Essa utilização da um enorme dinamismo, e um retorno a mudanças.
Porém, exige dos desenvolvedores certa experiência no uso de processos e
técnicas para entender com clareza o funcionamento da metodologia nos projetos.
Além da família Crystal estar em recente desenvolvimento, o que provoca falta de
documentos e pesquisas, se comparada com outras metodologias como XP e
Scrum.
6. REFERÊNCIAS
ABRAHAMSSON, P.; SALO, O ;RONKAINEN, J; WARSTA, J. Agile software
development methods: review and analysis, VTT Technical report, 2002.
COCKBURN, Alistair. Crystal Clear: A Human-Powered Method Small Teams. New
Jersey: Addison Wesley, 2004.
COSTA, P. L. P. GESTproSOFT: Analise Comparativa sobre os métodos de Gestão
de Projetos de Software de Mercado. 2012. 138f. Dissertação (Mestrado em
Sistemas e Tecnologias de Informação para Organização) – Instituto Politécnica de
Viseu, Portugal, 2012.
DIAS, M. V. B. Um Novo Enfoque para o Gerenciamento de Projetos de
Desenvolvimento de Software. 2005. 211f. Dissertação (Mestrado em
Administração) – Universidade de São Paulo, São Paulo, 2005.
EING, O. P. Adaptações na Metodologia Ágil de Desenvolvimento de Software
XP. 2003. 105f. Dissertação (Mestrado em Ciência da Computação) – Universidade
Federal de Santa Catarina, Florianópolis, 2003.
FILHO, H. F. B. P. Um estudo analítico entre as abordagens de Engenharia de
Requisitos nas Metodologias Ágeis XP, SCRUM e Crystal. 2011. 36f. Monografia
(Pós-Graduação Em Ciência Da Computação) - Universidade Federal De
Pernambuco, Pernambuco, 2011.
JUNIOR, L. C. AQUA – Atividades De Qualidade No Contexto Àgil. 2008. 178f.
Dissertação (Mestrado Ciência da Computação) – Universidade Federal de São
Carlos, São Paulo, 2008.
LEITÃO, M. V. Aplicação de Scrum em Ambiente de Desenvolvimento de
Software Educativo. 2010. 71f. Monografia (Bacharel em Engenharia da
Computação) - Escola Politécnica de Pernambuco, Pernambuco, 2010.
MARQUES, A. N. Metodologias ágeis de desenvolvimento: Processos e
Comparações. 2012. 65f. Monografia (Tecnólogo em Processamento de Dados) -
Faculdade De Tecnologia De São Paulo, São Paulo, 2012.
NASCIMENTO, G.V. Um modelo de referencia para o desenvolvimento ágil de
software. 2008. 125f. Dissertação (Mestrado em Ciências de Computação e
Matemática Computacional) – Instituto de Ciências Matemática e de Computação,
São Paulo, 2008.
SANTOS, M. A. AGILE UBPM FOR SCRUM: Modelo de Aprimoramento do
Gerenciamento e Desenvolvimento Ágil Baseado na Percepção de Valor do Usuário.
2011. 158f. Monografia (Graduação de Ciência da Computação) - Universidade
Federal de Lavras, Minas Gerais, 2011.
SBOCCO, J. H. T. C; MACEDO, P.C. Metodologias Ágeis: engenharia de software
sob medida. 1. Ed. São Paulo: Érica, 2012.
SINÉSIO, T; CORREIA, C. A; SILVA, D. A. Crystal Clear Methodologies. 2012.
Disponível em:< https://pt.scribd.com/doc/240552399/Metodologia-Agil-de-
Desenvolvimento-Crystal-pdf>. Acesso em: 06 abr. 2016.
SOUSA, D. F; RIBEIRO, J; SOUSA, N. P. Metodologia Ágil de Desenvolvimento
de Softwares Crystal. 2013. Disponível em:<
https://pt.scribd.com/doc/240552399/Metodologia-Agil-de-Desenvolvimento-Crystal-
pdf>. Acesso em: 30 mar. 2016.

Mais conteúdo relacionado

Mais procurados

Comparativo entre Processos Ágeis
Comparativo entre Processos ÁgeisComparativo entre Processos Ágeis
Comparativo entre Processos Ágeis
Daniel Ferreira
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
João Carlos Ottobboni
 
SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...
SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...
SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...
New Relic
 
07 diagrama de classes de análise
07  diagrama de classes de análise07  diagrama de classes de análise
07 diagrama de classes de análise
Filipe Soares
 
Aula 8 teoria das cores ihc
Aula 8   teoria das cores ihcAula 8   teoria das cores ihc
Aula 8 teoria das cores ihc
Danilo Monteiro
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
Simoneinfo
 
Solução técnica - CMMI nível 3
Solução técnica - CMMI nível 3Solução técnica - CMMI nível 3
Solução técnica - CMMI nível 3
Emmanuel Neri
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Cloves da Rocha
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
Mauricio Volkweis Astiazara
 
OKR - Objective and Key Results
OKR - Objective and Key ResultsOKR - Objective and Key Results
OKR - Objective and Key Results
Rafaella Cavalca
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Cris Fidelix
 
1 requisitos funcionais e não funcionais ok
1  requisitos funcionais e não funcionais ok1  requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais okMarcos Morais de Sousa
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
Rildo (@rildosan) Santos
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
Daniel Brandão
 
Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!
Annelise Gripp
 
Fabrica software
Fabrica softwareFabrica software
Fabrica software
kokyfe
 
Programação Orientação a Objetos - Herança
Programação Orientação a Objetos - HerançaProgramação Orientação a Objetos - Herança
Programação Orientação a Objetos - Herança
Daniel Brandão
 
Cloud Native Engineering with SRE and GitOps
Cloud Native Engineering with SRE and GitOpsCloud Native Engineering with SRE and GitOps
Cloud Native Engineering with SRE and GitOps
Weaveworks
 

Mais procurados (20)

Comparativo entre Processos Ágeis
Comparativo entre Processos ÁgeisComparativo entre Processos Ágeis
Comparativo entre Processos Ágeis
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...
SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...
SRE-iously: Defining the Principles, Habits, and Practices of Site Reliabilit...
 
07 diagrama de classes de análise
07  diagrama de classes de análise07  diagrama de classes de análise
07 diagrama de classes de análise
 
Aula 8 teoria das cores ihc
Aula 8   teoria das cores ihcAula 8   teoria das cores ihc
Aula 8 teoria das cores ihc
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
 
Solução técnica - CMMI nível 3
Solução técnica - CMMI nível 3Solução técnica - CMMI nível 3
Solução técnica - CMMI nível 3
 
SCRUM.pptx
SCRUM.pptxSCRUM.pptx
SCRUM.pptx
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
 
OKR - Objective and Key Results
OKR - Objective and Key ResultsOKR - Objective and Key Results
OKR - Objective and Key Results
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
 
1 requisitos funcionais e não funcionais ok
1  requisitos funcionais e não funcionais ok1  requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais ok
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!
 
Fabrica software
Fabrica softwareFabrica software
Fabrica software
 
Programação Orientação a Objetos - Herança
Programação Orientação a Objetos - HerançaProgramação Orientação a Objetos - Herança
Programação Orientação a Objetos - Herança
 
Cloud Native Engineering with SRE and GitOps
Cloud Native Engineering with SRE and GitOpsCloud Native Engineering with SRE and GitOps
Cloud Native Engineering with SRE and GitOps
 

Semelhante a METODOLOGIA ÁGIL: Família Crystal de Cockbum

Crystal
CrystalCrystal
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Cris Fidelix
 
Métodos ágeis
Métodos ágeisMétodos ágeis
Métodos ágeis
Fernando Palma
 
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
Kéllyson Gonçalves da Silva
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
Daniel Wildt
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
Kéllyson Gonçalves da Silva
 
DevOps pela visão de um QA
DevOps pela visão de um QADevOps pela visão de um QA
DevOps pela visão de um QA
Kamilla Queiroz Xavier
 
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo RochaMetodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Fernando Palma
 
Agile2011 140902173318-phpapp02
Agile2011 140902173318-phpapp02Agile2011 140902173318-phpapp02
Agile2011 140902173318-phpapp02
Ricardo Moreira de Araújo
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Maicon Zerbielli
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
Daniel Cukier
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
André Luis Celestino
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
Ruan Pozzebon
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Fernando Palma
 
Ensiso day talks
Ensiso day   talksEnsiso day   talks
Ensiso day talks
César França
 
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
André Luis Celestino
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven development
Izabel Rodrigues
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e Projeto
Sergio Silva
 
Aula 1 analise e projeto
Aula 1   analise e projetoAula 1   analise e projeto
Aula 1 analise e projeto
Sergio Luiz da Silveira
 

Semelhante a METODOLOGIA ÁGIL: Família Crystal de Cockbum (20)

Crystal
CrystalCrystal
Crystal
 
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
 
Métodos ágeis
Métodos ágeisMétodos ágeis
Métodos ágeis
 
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
 
DevOps pela visão de um QA
DevOps pela visão de um QADevOps pela visão de um QA
DevOps pela visão de um QA
 
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo RochaMetodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
 
Agile2011 140902173318-phpapp02
Agile2011 140902173318-phpapp02Agile2011 140902173318-phpapp02
Agile2011 140902173318-phpapp02
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Metodologias de desenvolvimento
Metodologias de desenvolvimentoMetodologias de desenvolvimento
Metodologias de desenvolvimento
 
Ensiso day talks
Ensiso day   talksEnsiso day   talks
Ensiso day talks
 
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven development
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e Projeto
 
Aula 1 analise e projeto
Aula 1   analise e projetoAula 1   analise e projeto
Aula 1 analise e projeto
 

METODOLOGIA ÁGIL: Família Crystal de Cockbum

  • 1. METODOLOGIA ÁGIL: Família Crystal de Cockburn Vanessa Finoto Faculdade de Tecnologia de Jales Centro Estadual de Educação Tecnológica Paula Souza Jales - SP, Brasil vanessa.finoto@fatec.sp.gov.br Luiz Roberto Reinoso Faculdade de Tecnologia de Jales Centro Estadual de Educação Tecnológica Paula Souza Jales - SP, Brasil luiz.reinoso@fatec.sp.gov.br RESUMO Metodologias Ágeis são conjuntos de ferramentas de gestão que vem sendo cada vez mais utilizadas no desenvolvimento de sistemas. Uma dessas metodologias é a família Crystal, desenvolvida no final da década de 90 por Alistair Cockburn. Ele percebeu através de suas pesquisas a necessidade de uma metodologia para o desenvolvimento de softwares de forma otimizada explorando de forma frequente as características especificas de cada membro que estão inseridos na equipe. O objetivo principal desse artigo é conhecer um pouco sobre como funciona a família Crystal. Ao decorrer do trabalho conheceremos a história, as características marcantes e a importância das cores, da criticidade e o valor das pessoas nessa metodologia. Palavras chaves: Crystal. Família. Metodologia 1. INTRODUÇÃO A computação surgiu nos anos 40, e os maiores investimentos naquela época eram voltados a hardware (MARQUES, 2012). No início dos anos 50, passou- se a ter o domínio da tecnologia de hardware e então os investimentos se voltaram ao desenvolvimento dos sistemas operacionais possibilitando o surgimento das primeiras linguagens de programação (LEITÂO, 2010). Com o desenvolvimento dessas duas importantes tecnologias foi necessário criar sistemas mais complexos e maiores, então se iniciou a “crise do software” (MARQUES, 2012). Em 1968 foi realizada uma conferência pelo Comitê de Ciência da NATO (North Atlantic Treaty Organization) com o nome “Engenharia de Software” (EING, 2003). Nessa conferência foi discutido sobre a existência de uma real crise,
  • 2. onde constatou-se problemas em relação aos projetos e aos programas (COSTA, 2012). E foi a partir deste cenário que passou a se desenvolver os processos e metodologias de desenvolvimento de software (DIAS, 2005). Um dos primeiros processos surgiu em 1970 que ficou conhecido como processo em cascata que possuía sete fases e uma só poderia ser iniciada após o término da anterior, porém esse modelo trazia alguns transtornos em relação à mudança nas etapas anteriores (EING, 2003). Dez anos depois esse modelo foi substituído pelo espiral (COSTA, 2012). Os conceitos relacionados a metodologias ágeis de software surgiram na década de 90, antes os métodos eram considerados pesados com documentação e regulamentações burocráticas, portanto apenas grandes empresas utilizavam (SBROCO; MACEDO, 2012). Considerando os avanços da tecnologia pequenas e medias empresas automatizaram os seus processos. Novos sistemas surgiram com alto grau de complexidade causando problemas relacionados ao uso das metodologias tradicionais principalmente em relação ao tamanho do projeto e a quantidade de pessoas envolvidas (SBROCO; MACEDO, 2012). Então Alistair Cockburn criou uma família de metodologias ágeis conhecida como Crystal em 1998 (NASCIMENTO, 2008). Advinda de uma necessidade observada por ele quando trabalhava na IBM. Durante sua passagem dedicou-se a pesquisar várias equipes que compunham a empresa e observou que as metodologias usadas eram robustas e sempre fracassavam ao termino do projeto (SOUZA; RIBEIRO; SOUZA, 2013). A família Crystal se baseia na gestão de pessoas com o foco na interação, habilidades, talentos e comunicação (FILHO, 2011). De acordo com Cockburn (2004) as pessoas que fazem parte de uma equipe possuem diferentes talentos e habilidades, sendo um diferencial durante o desenvolvimento de um projeto, principalmente se considerarmos que uma empresa de software pode trabalhar com projetos nas mais diferentes áreas de atuação (SBROCO; MACEDO, 2012). Para uma melhor compreensão a família foi dividida em cores. A Crystal sugere que seja escolhida uma cor apropriada para cada projeto, de acordo com o nível de criticidade e o tamanho da equipe (JUNIOR, 2008). De acordo com Santos
  • 3. (2007), a criticidade é dividida em quatro níveis: Conforto (C), Baixo Custo (D), Alto Custo (E) e Risco de Vida (L). De acordo com Sbroco e Macedo (2012), quanto mais escura a cor mais crítico é o sistema. Projetos menores com cores claras como Clear e Yellow envolvem poucos desenvolvedores e, no caso de problemas, o prejuízo tende a ser menor. Já os projetos maiores ou de segurança crítica como Orange e Red normalmente possuem mais profissionais, contudo a perda é maior, podendo colocar a vida de pessoas em risco (JUNIOR, 2008) como podemos observar na Figura 1. Figura 1 – Métodos Crystal e suas dimensões. Fonte: ABRAHAMSSON et al., 2002. Apesar de existir diversas metodologias diferentes na mesma família, todas possuem algumas características em comum, como, por exemplo, a abordagem iterativa, a ênfase na comunicação e na cooperação entre a equipe (COCKBURN, 2004). As metodologias desenvolvidas e utilizadas até hoje são a Crystal Clear e a Crystal Orange (SANTOS, 2007) que serão discutidas no processo tópico. O presente trabalho possui como objetivo estudar detalhadamente os conceitos e as características básicas da família de metodologias Crystal. 2. CARACTERÍSTICAS A família Crystal é considerada uma metodologia leve com um código genético comum, que foi criada para atender vários tipos de projetos e equipes que
  • 4. necessitam de táticas para resolver diversos problemas (MARQUES, 2012). È importante ressaltar que não há “uma“ metodologia Crystal. Existem diferentes tipos de metodologias Crystal para diferentes tipos de projeto (SINÉSIO; CORREIA; SILVA, 2012). Para Cockburn (2004) a metodologia não é tão importante, pois a ideia central é que cada empresa consiga definir as tarefas que lhes forem mais suscetíveis ao projeto em desenvolvimento. Para isso Cockburn (2004) desenvolveu alguns princípios característicos que pode ser compartilhado entres os membros da família que são:  Trabalho face a face: É o envolvimento do cliente em todas as decisões do desenvolvimento do projeto, tornando mais produtivo e passando confiabilidade para o consumidor. É também a comunicação que surge naturalmente entre os desenvolvedores, que conseguem captar as partes relevantes de todo o processo, como se estivessem pegando a informação por osmose.  Peso significa custo: O projeto deve evitar coisas complexas que provavelmente o usuário final não vai utilizar, pois quanto mais complicado o software maior será o custo e o tempo de entrega.  Metodologia Diferenciada: Nem todos os projetos são iguais, cada um tem o seu diferencial, seja pela sua complexidade, pela quantidade de pessoas envolvidas ou área de atuação, por isso é necessária uma metodologia correta de acordo com o projeto que será desenvolvido.  Mais cerimônia mais criticidade: Pode não ser possível eliminar todos os produtos intermediários relacionados ao trabalho, porém, eles podem ser reduzidos na medida em que a equipe possui vias de comunicação próximas e informais, sendo que, quanto maior a troca de experiências entre a equipe, menor será a necessidade de documentação.  Comunicação eficiente: Melhor existir uma comunicação eficiente entre cliente e o desenvolvedor do que entregar um produto que não funciona.  Habilidade: Capacidade de trabalhar e lidar com pessoas de diferentes personalidades no mesmo projeto.  Entrega frequente: A propriedade mais importante de qualquer projeto é o de garantir entrega funcional e código testado a cada poucos meses.
  • 5.  Segurança Pessoal: A Segurança Pessoal se refere a possibilidade de dizer quando algo está incomodando, sem medo de represálias. Exemplos disso seria dizer ao gerente que o cronograma não está bem feito.  Foco: Essa propriedade destaca que a equipe precisa de tranquilidade para trabalhar na tarefa que lhes foi passada. E essa tranquilidade vem de um ambiente onde as pessoas não são tiradas de sua tarefa para atuar em outras coisas incompatíveis.  Eficiência: A metodologia destaca que os gargalos devem ser encontrados e que não adianta a equipe tentar otimizar o que não é um gargalo, pois, isso não vai melhorar o projeto como um todo. A Crystal possui como característica diferencial o ciclo de vida, que é baseado em integrações, onde tudo deve funcionar como um relógio (SBROCO; MACEDO, 2012). Sendo que cada projeto deve liberar as versões do software de um a quatro meses. Após cada iteração são feitas reflexões sobre possíveis melhorias. Uma equipe que segue fielmente a filosofia e os princípios pode obter resultados incríveis. Na Figura 2 podemos observar um modelo do ciclo de vida que considera o desenvolvimento de um software de alta qualidade. Figura 2 – Ciclo de vida da família de metodologias Crystal. Fonte: (ABRAHAMSSON et al., 2002).
  • 6. De acordo com Cockburn (2004) o ciclo de vida desta família de metodologias é baseado nas seguintes práticas:  Encenação: Plano do próximo incremento do sistema. Os desenvolvedores selecionam os requisitos que serão criados e o prazo para sua entrega;  Edição e revisão: Construção, demonstração e revisão dos objetivos do incremento;  Monitoramento do Processo: O método é monitorado com relação ao avanço e estabilidade da equipe. É medido em marcos e em estágios de permanência;  Paralelismo e fluxo: No Crystal laranja, as diferentes equipes podem operar com máximo paralelismo. Isso é 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 iteração com objetivo de analisar o progresso do projeto.  Produtos de Trabalho: sequência de lançamento, modelos de objetos comuns, manual do usuário, casos de teste e migração de código.  Padrões: padrões de notação, convenções de produto, formatação e qualidade usadas no projeto.  Ferramentas: ferramentas mínimas utilizadas. Além do ciclo vida Cockburn (2004) descreve no seu livro Crystal Clear sobre a importância do modelo de jogo econômico-cooperativo, que é o desenvolvimento de software em uma série de "jogos" cujos movimentos consistem basicamente em invenção e comunicação. Cada jogo tem dois objetivos conflitantes: entrega de software funcional e preparação para a próxima etapa do jogo (MARQUES, 2012). O jogo nunca se repete, de modo que cada projeto exige estratégias ligeiramente diferentes de todos os jogos anteriores (SINÉSIO; CORREIA; SILVA, 2012).
  • 7. O modelo de jogo econômico-cooperativo leva as pessoas a pensarem sobre seu trabalho em um projeto de uma forma muito específica, focada e eficaz (COCKBURN, 2004). 2.1 OS PAPÉIS E RESPONSABILIDADE DA CRYSTAL CLEAR E ORANGE Como foi descrito na introdução a família Crystal é dividida em cores. Sendo que cada cor representa uma metodologia. Atualmente somente dois membros da família são utilizados a Crystal Clear, Crystal Orange (SINÉSIO; CORREIA; SILVA, 2012). O método Crystal Clear é destinado a projetos pequenos incluindo até seis desenvolvedores, porém, com extensão que pode chegar á doze pessoa trabalhando no mesmo grupo (SANTOS, 2007). Uma equipe usando essa metodologia pode ser localizada em um ambiente de trabalho compartilhado, devido às limitações em sua estrutura de comunicação (COCKBURN, 2004). O seu risco de criticidade é classificado com D (baixo custo). As especificações e o projeto são feitos informalmente, através de esboços e anotações (MARQUES, 2012). O Crystal Clear possui quatro papeis principais que estão descritos no Quadro 1. Quadro 1 — Papéis e Responsabilidade do método Crystal Clear Fonte: (ABRAHAMSSON et al., 2002). O método Crystal Orange abrange projetos de médio porte, com até 40 colaboradores. Os trabalhos são divididos em times multifuncionais diversos que são organizadas de acordo com as responsabilidades adotadas (LEITÂO, 2010). Uma das características presentes na metodologia é considerar o tempo de mercado, ou seja, estar sempre pronta para adaptações, de forma a dar suporte às equipes em uma mudança de mercado, sem perder a funcionalidade do projeto.
  • 8. Cada incremento gerado tem duração de dois a quatro meses e o ciclo de total do projeto dura de um a dois anos (MARQUES, 2012). Em uma metodologia baseada em pessoas, invés de processos, os papéis, e suas respectivas responsabilidades são aspectos muito importantes no Orange (SINÉSIO; CORREIA; SILVA, 2012). Tanto a Crystal Clear quanto a Crystal Orange possuem diversos papéis em comum (COCKBURN, 2004). É claro que, sendo uma metodologia mais pesada, é natural que a Crystal Orange possua mais papéis como observado no Quadro 2. Quadro 2 — Papéis e Responsabilidade do método Crystal Clear Fonte: (ABRAHAMSSON et al., 2002). 3. EXEMPLOS PRÁTICOS Projeto Fictício para a empresa WebCell – Comercialização de Celulares A empresa deseja criar um sistema para Internet para comercializar seus celulares, assim como proporcionar aos usuários satisfação em seus propósitos de negócios com site. Para captar os requisitos, a metodologia sugere uma entrevista e um questionário em forma de briefing com perguntas-chave sobre o projeto a ser
  • 9. desenvolvido. O quadro a seguir apresenta um modelo de como isso pode ser registrado: Briefing entrevista/questionário Quadro 3 – Questionário realizado na empresa WebCell Briefing para projeto web Projeto: Comérciode celularesnaWeb – WebCell. Analista/gerente responsável: Maria Luísa e FlávioMacedo. Data - Fevereiro 2016 O que o site pretende vender? Relacionar os serviços oferecidos. A princípiocomercializarcelulares,permitirque osinternautascadastremsuacontapara comprar no site. Alémde fazera divulgaçãodosprodutosatravésde imagense vídeosparatornar o processo de vendamaisintuitivo. Vantagens/Desvantagens sobre os concorrentes. A principal vantagemé apossibilidadede adquirircelularescompreçosde fábrica,poiscomprando pelosite,podemosoferecerumaentregamaisdireta.Umaoutra vantagemé filmar oscelularesem funcionamentodandodetalhesparaquemestáinteressado. Parceiros ou referências de sites (outras empresas do grupo). O site deveráconterumalistade todosos fabricantesde celularesNacionaise importadoscomque trabalhame seus linksde acesso. Objetivos a serem alcançados. Apresentarumwebsite completoe comele ampliarasvendasque hoje se restringemaoestadode São Paulo. Público-alvo. Todosos públicos,principalmente osinteressadosemcomprarcelulares. Conteúdo do site (relação inicial das páginas). Home,contato,Área do Usuário,ofertas,Suporte,celulares, acessórios,maisprodutose comunidade. Ferramentas de marketing utilizadas atualmente (relacionar outdoor, comerciais etc.). Outdooremcidades,panfletagem,anúnciosnosjornaise revistasdacapital. Tempo para desenvolvimento sugerido pela empresa (urgência). Um ano (negociável). Fonte: Elaborado pelos autores.
  • 10. Documento de Requisitos Depois de receber o briefing devidamente respondido, é possível dar início a documentação que relaciona os requisitos do sistema e suas funcionalidades (MARQUES, 2012). Para garantir o correto regimento do documento serão necessárias outras reuniões. A metodologia Crystal possibilita isso para definir claramente o que se pretende (SBROCO; MACEDO, 2012). Visões do usuário A cada fase e cada documento, o usuário principal está envolvido e deve valida-los, dando um feedback sobre o assunto. O usuário deve solicitar modificações e alterações de possíveis equívocos se for necessário (MARQUES, 2012). O gerente de projeto pode solicitar, por meio de documento assinaturas do usuário e do patrocinador do projeto, concordando com os requisitos solicitados. Modelagem Com o documento de requisitos em mãos, é então realizada a sua modelagem, utilizando, no mínimo, os seguintes diagramas da UML: diagrama de casos de uso, diagrama de atividades ou sequência e diagrama de classes. Esses diagramas devem ser explicados ao usuário e validados por ele (SBROCO; MACEDO, 2012). Design de projeto Um conjunto de interfaces deve ser criado com base nos questionamentos do briefing, bem como a solicitação de cores, fontes e estilos feitas pelos stakeholders. Sequências de Releases Após a modelagem dos requisitos e a escolha de telas, o coordenador de projeto cria um modelo de prioridades junto com usuário e decide as
  • 11. funcionalidades, recursos e data previstas para a entrega entre os desenvolvedores (NASCIMENTO, 2008). Os programadores então passam a saber as datas previstas para a entrega das funcionalidades e começam a codificação. Em cada iteração os resultados são coletados e analisados para fases subsequentes, sempre levando em conta que a Crystal Clear exige o mínimo de duas entregas de funcionalidades ao cliente por mês (SBROCO; MACEDO, 2012). Isso pode ser observado no exemplo do quadro a seguir. Quadro 4 – Sequência de Desenvolvimento empresa WebCell Sequência de desenvolvimento Projeto: Comércio de Celulares Web - WebCell ID Descrição Data Início Data Fim RF001 Cadastro de celulares novos 01/fev/16 15/fev/16 RF002 Cadastro de usuários para login administrativo 01/fev/16 15/fev/16 ... ... ... ... (listar os requisitos por ordem de prioridade) Fonte: Elaborado pelos autores. Casos de testes Os testes de acordo com a Crystal Clear são realizados com o sistema finalizado, ou seja, tem o objetivo de testar suas funcionalidades no ambiente de trabalho (SBROCO; MACEDO, 2012). Manual do usuário O redator técnico vai incluindo no manual do usuário as funcionalidades que já foram devidamente testadas. Além da descrição, é recomendável que inclua outras formas de ajudar o usuário.
  • 12. 4. EMPRESAS QUE UTILIZAM A metodologia Crystal foi desenvolvida e utilizada na IBM no início da década de 2000, porém com o tempo foi substituída pela RUP (SOUZA; RIBEIRO; SOUZA, 2013). Apesar de não existir mais laços entre a Crystal e a IBM, o escritor Cockburn continua investindo em sua metodologia (COCKBURN, 2004). Através de pesquisas realizadas nesse artigo nos deparamos com a falta de documentos e informações sobre empresas que utilizam a família Crystal. Mas de acordo com Sbrocco e Macedo (2012), a metodologia pode ser utilizada em vários tipos de empresas não importando o seu tamanho e nem sua área. 5. CONCLUSÃO O escritor Alistair Cockburn vem destacando na área acadêmica de metodologias os processos de desenvolvimento, e aplicou todo o seu conhecimento para criar a família Crystal, que surgiu para melhorar as metodologias tradicionais. Cockburn propôs o uso de determinada metodologia para cada tipo de projeto sendo que essa estratégia pode ser aplicada ao projeto através de reuniões e revisões. Essa utilização da um enorme dinamismo, e um retorno a mudanças. Porém, exige dos desenvolvedores certa experiência no uso de processos e técnicas para entender com clareza o funcionamento da metodologia nos projetos. Além da família Crystal estar em recente desenvolvimento, o que provoca falta de documentos e pesquisas, se comparada com outras metodologias como XP e Scrum. 6. REFERÊNCIAS ABRAHAMSSON, P.; SALO, O ;RONKAINEN, J; WARSTA, J. Agile software development methods: review and analysis, VTT Technical report, 2002. COCKBURN, Alistair. Crystal Clear: A Human-Powered Method Small Teams. New Jersey: Addison Wesley, 2004.
  • 13. COSTA, P. L. P. GESTproSOFT: Analise Comparativa sobre os métodos de Gestão de Projetos de Software de Mercado. 2012. 138f. Dissertação (Mestrado em Sistemas e Tecnologias de Informação para Organização) – Instituto Politécnica de Viseu, Portugal, 2012. DIAS, M. V. B. Um Novo Enfoque para o Gerenciamento de Projetos de Desenvolvimento de Software. 2005. 211f. Dissertação (Mestrado em Administração) – Universidade de São Paulo, São Paulo, 2005. EING, O. P. Adaptações na Metodologia Ágil de Desenvolvimento de Software XP. 2003. 105f. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Santa Catarina, Florianópolis, 2003. FILHO, H. F. B. P. Um estudo analítico entre as abordagens de Engenharia de Requisitos nas Metodologias Ágeis XP, SCRUM e Crystal. 2011. 36f. Monografia (Pós-Graduação Em Ciência Da Computação) - Universidade Federal De Pernambuco, Pernambuco, 2011. JUNIOR, L. C. AQUA – Atividades De Qualidade No Contexto Àgil. 2008. 178f. Dissertação (Mestrado Ciência da Computação) – Universidade Federal de São Carlos, São Paulo, 2008. LEITÃO, M. V. Aplicação de Scrum em Ambiente de Desenvolvimento de Software Educativo. 2010. 71f. Monografia (Bacharel em Engenharia da Computação) - Escola Politécnica de Pernambuco, Pernambuco, 2010. MARQUES, A. N. Metodologias ágeis de desenvolvimento: Processos e Comparações. 2012. 65f. Monografia (Tecnólogo em Processamento de Dados) - Faculdade De Tecnologia De São Paulo, São Paulo, 2012. NASCIMENTO, G.V. Um modelo de referencia para o desenvolvimento ágil de software. 2008. 125f. Dissertação (Mestrado em Ciências de Computação e Matemática Computacional) – Instituto de Ciências Matemática e de Computação, São Paulo, 2008.
  • 14. SANTOS, M. A. AGILE UBPM FOR SCRUM: Modelo de Aprimoramento do Gerenciamento e Desenvolvimento Ágil Baseado na Percepção de Valor do Usuário. 2011. 158f. Monografia (Graduação de Ciência da Computação) - Universidade Federal de Lavras, Minas Gerais, 2011. SBOCCO, J. H. T. C; MACEDO, P.C. Metodologias Ágeis: engenharia de software sob medida. 1. Ed. São Paulo: Érica, 2012. SINÉSIO, T; CORREIA, C. A; SILVA, D. A. Crystal Clear Methodologies. 2012. Disponível em:< https://pt.scribd.com/doc/240552399/Metodologia-Agil-de- Desenvolvimento-Crystal-pdf>. Acesso em: 06 abr. 2016. SOUSA, D. F; RIBEIRO, J; SOUSA, N. P. Metodologia Ágil de Desenvolvimento de Softwares Crystal. 2013. Disponível em:< https://pt.scribd.com/doc/240552399/Metodologia-Agil-de-Desenvolvimento-Crystal- pdf>. Acesso em: 30 mar. 2016.