Metodologias de Desenvolvimento gil: Crystal Clear

Helena Filipa da Cunha Fernandes, n65352

Mestrado Integrado em Engenharia Eletrnica Industrial e Computadores
Universidade do Minho
Campus de Azurm 4800-058 Guimares, Portugal
A65352@alunos.uminho.pt

Abstract. A famlia Crystal um conjunto de metodologias criada por Alistair

Cockburn que possui uma abordagem voltada para a gesto de pessoas. Como a
qualidade do projeto sensvel a fatores humanos, a famlia Crystal no , propositadamente, completamente definida, devendo adaptar-se a cada projeto. A
definio da melhor metodologia a adotar depender do nmero de pessoas envolvidas e da complexidade do projeto. Para tal, a famlia Crystal definida
graficamente por cores que indicam a densidade da metodologia a adotar.
Quanto mais escura a cor, mais complexo o projeto e mais densa a metodologia. A Crystal Clear uma metodologia voltada para equipas entre duas e
oito pessoas, a partilhar o mesmo espao, permitindo uma comunicao osmtica que no aspira a ser a melhor metodologia, mas suficiente para levar o projeto at zona de segurana.

Keywords: Metodologia gil, Crystal Clear, Cdigo Gentico

Introduo

Segundo o mais recente estudo realizado pelo CHAOS Report (CHAOS Report
2015), pesquisa realizada pela empresa Standish Group1 a 50000 projetos de variadas
dimenses e de todo o mundo, apenas 29% tiveram sucesso, isto , foram entregues a
tempo, sem exceder o oramento e com resultados satisfatrios. A percentagem de
projetos que falharam estes trs critrios foi de 19%, e os restantes 52% dizem respeito aos projetos que apenas contemplaram 1 ou 2 dos critrios. A anlise dos dados que
datam desde 2011 at 2015 mostram que quanto mais pequenos so os projetos, maior
ser a probabilidade de sucesso.[1]
O estudo apresenta tambm um ranking de fatores que trabalhados em conjunto
criaro um projeto bem-sucedido. Os trs mais importantes so: o suporte executivo, a
maturidade emocional e o envolvimento do utilizador. Tem-se suporte executivo
quando um executivo ou grupo de executivos assistem e apoiam em pano de fundo,
1

Empresa de consultoria que se dedica ao melhoramento da gesto de projetos de desenvolvimento de software. Publica todos os anos um relatrio (CHAOS Report) sobre o estado da
indstria de desenvolvimento de software.

quer financeiramente quer emocionalmente, encorajando a concluso bem-sucedida

do projeto. A maturidade emocional diz respeito ao comportamento bsico das pessoas que integram a equipa de trabalho, por exemplo, na rpida tomada de decises e
cooperao entre colegas que trabalham juntos em direo s mesmas metas e objetivos. O envolvimento do utilizador/cliente requer que este esteja presente no processo
de recolha de informao e tomada de certas decises.
Estes trs fatores so claramente voltados para a gesto de pessoas.
A famlia Crystal, conjunto de metodologias que vo ser descritas neste artigo,
possui uma abordagem voltada para essa gesto, onde os talentos e habilidades pessoais so fatores decisivos para a finalizao de um projeto bem-sucedido. [1]
Este artigo est dividido em 4 seces: na primeira seco encontra-se uma breve
introduo famlia Crystal, na segunda, uma descrio do seu cdigo gentico, na
terceira, a descrio da Crystal Clear, bem como o processo e constituio de uma
equipa e por fim, na quarta seco as concluses tiradas da reflexo sobre os conceitos aprendidos na redao deste artigo.
Este artigo foi baseado em artigos, pginas web sobre o tema e em publicaes bibliogrficas do prprio criador da metodologia.

Introduo famlia Crystal

Criada por Alistair Cockburn, Crystal uma abordagem ao desenvolvimento de software voltada para a gesto de pessoas e portanto muito sensvel a fatores humanos. O
sucesso de um projeto est dependente dos talentos e habilidades pessoais de cada
elemento da equipa, assim como a complexidade do projeto em si e nmero de pessoas a trabalhar nele. Sendo assim, esta uma abordagem propositadamente pouco definida que, alm de partilhar o mesmo cdigo gentico, adaptado s necessidades de
cada projeto.
Em todos os ramos da famlia, existem trs propriedades comuns a todas elas que
so a Entrega Frequente, a Comunicao Cara-a-Cara e a Melhoria por Reflexo.
Alistair caracterizou as diferentes metodologias Crystal por cores, de acordo com
dois critrios: o nmero de pessoas a coordenar e a criticidade do projeto.

Fig. 1. Relao entre as cores e o nmero de pessoas a coordenar

Na Fig.1 est ilustrada a relao entre o tamanho da equipa e a cor da metodologia

a adotar. Quanto maior a equipa, mais complexa a coordenao e comunicao e,
portanto, mais densa a cor da metodologia.[2]
Uma segunda dimenso importante a ter em conta para classificar estas metodologias a criticidade, o potencial estrago causado por certos defeitos que no foram
detetados: perda de conforto (C), perda de dinheiro discricionrio (D), perda de dinheiro essencial para o projeto (E), e perda de vida do sistema (L). Estes critrios
podem ser verificados no sistema axial da Fig.2.

Fig. 2. Representao da criticidade de cada metodologia num sistema axial[3]

Por exemplo, a caixa C20 significa que uma equipa de 20 elementos est a trabalhar num sistema de perda de conforto do sistema.
Por observao da figura podemos concluir que esta classificao implica a existncia de pelo menos 16 metodologias.
O nome Crystal deriva das duas dimenses consideradas acima, em analogia geologia dos cristais, que tambm so classificados conforme duas dimenses: a cor e a
dureza. O tamanho da equipa corresponde cor do cristal: transparente, amarelo,
laranja, vermelho, marron, azul e violeta; e a criticidade corresponde dureza do
mineral: dureza de quartzo quando apenas existe perda de conforto e de diamante para
perda de vida do sistema. [3]

Cdigo Gentico da Famlia Crystal

Crystal uma famlia de metodologias com um cdigo gentico comum. O cdigo

gentico ajuda a desenvolver um novo membro da famlia que, se todas as convenes funcionarem em sintonia, aumenta a probabilidade de sucesso do projeto.
Este cdigo gentico que criar a metodologia desenhado no incio de cada
projeto e, se necessrio, periodicamente durante o mesmo.[4]

O cdigo gentico do Crystal consiste em 6 elementos:

Modelo de Jogo econmico-cooperativo;

Prioridades selecionadas;
Propriedades selecionadas;
Princpios selecionados;
Tcnicas e estratgias selecionadas;
Metodologias-exemplo a copiar;

3.1

Modelo de Jogo econmico-cooperativo

Tratar o desenvolvimento de software como um jogo cooperativo de inveno e comunicao liberta a equipa para decidir que movimento faz sentido fazer num certo
ponto do projeto e qual a estratgia que criar uma boa posio para a prxima jogada. Com este elemento do cdigo gentico, liberta a equipa tambm da iluso de que
existe apenas uma frmula para usar em todos os projetos.[4]
Trabalhar o projeto como sendo uma parte de uma srie de jogos interconectados
faz com que se destaque a importncia no s de entregar o sistema no final mas tambm a importncia de ajustar o mtodo de trabalho medida que este vai evoluindo.
Mas o intuito de todos os jogos resume-se competio. Cada equipa ter de adaptar
o seu jogo para que a competio se torne uma oportunidade para a colaborao,
onde no apenas um elemento que sai vitorioso, mas sim toda a equipa.

3.2

Prioridades

Em qualquer metodologia, existe um conjunto de prioridades a ter em conta. Nas

metodologias Crystal, as prioridades so as seguintes:
Segurana no resultado do projeto (entrega do software);
Eficincia do Processo;
Habitabilidade das convenes.
A prioridade mais importante a primeira. Se o software no for entregue, o projeto falhou.
As outras duas prioridades so conflituosas. Poder haver um processo que seja o
mais eficiente, mas que a equipa no esteja to vontade para o usar. Para que a metodologia funcione, esta dever ser aceite pela equipa. Mais uma vez, no existe uma
frmula para todos os projetos mas sim um mtodo que se adequa a cada equipa.

3.3

Propriedades

Alistair chama a estas propriedades as Sete Propriedades dos Projetos BemSucedidos. Considera que as propriedades so mais importantes que os procedimentos pois esto mais voltadas para a maneira como a equipa funciona, e no para as
ferramentas com que trabalham. Uma equipa tem a completa noo da sua condio
pois avalia-se mais facilmente, e mais facilmente se adapta s suas condies. A maneira como a equipa se adapta para ir ao encontro destas propriedades no so definidas pela metodologia, mas sim pela equipa.
Ento, as sete propriedades que faro uma equipa de sucesso so:

Entregas Frequentes;
Melhorias Refletivas;
Comunicao Cara-a-Cara;
Segurana pessoal;
Foco;
Fcil acesso a utilizadores experientes;
Ambiente tcnico com testes automatizados, gesto de configurao e frequente
integrao.

A famlia Crystal foca-se nas trs primeiras propriedades pois devero estar presentes em todos os projetos. As outras quatro apenas aumentam a margem da safety
zone.
Nomear estas propriedades melhora tambm a comunicao da equipa, pois sabero expressar-se com mais clareza, e da avaliar melhor a sua situao e discutir maneiras de a corrigir, se necessrio.
Entregas Frequentes. A propriedade mais importante de qualquer projeto, pequeno
ou grande, gil ou no, so as entregas continuadas de cdigo testado a utilizadores
reais. [3]
As vantagens desta prtica so, entre outras:
o patrocinador obtm feedback do progresso da equipa;
o utilizador/cliente tem a oportunidade de saber se o que pediram inicialmente vai
de encontro s suas necessidades e informar a equipa do que acha do desenvolvimento j efetuado;
os programadores mantm o foco;
a equipa mantm-se motivada a cada feedback positivo.
H que ter em ateno a frequncia com que se fazem estas entregas, O cliente
poder no estar disponvel para fazer os testes, ento tero de se virar para uma comunidade de utilizadores que, caso as entregas sejam frequentes, esta poder sentir-se
irritada ou, se caso no forem entregues frequentemente, problemas de funcionamento
podero ser detetados numa fase mais avanada do projeto e por consequncia, a falha
do mesmo. A soluo seria encontrar um utilizador amigvel que estivesse disposto
a fazer estes testes com a frequncia adequada ao ritmo de iterao da equipa.

Melhorias Refletivas. Por outras palavras, refletir e melhorar. Periodicamente, a

equipa ter de se juntar e refletir no que pode melhorar para a prxima iterao. O
objetivo desta propriedade tornar o que seriam falhas catastrficas em elementos de
sucesso. Estas melhorias podero ser aplicadas aos elementos da equipa, tecnologia
e ferramentas usadas, e prpria metodologia, e esta no estiver a funcionar. Estas
reunies devero acontecer, pelo menos, a cada entrega efetuada.
Comunicao Cara-a-Cara. No s a forma mais econmica de comunicar, mas
tambm a maneira mais rpida para se trocar informao. Para isso, basta que a equipa esteja sentada na mesma sala. Se um elemento tiver uma questo acerca do projeto,
como toda a gente est na mesma sala, no s a resposta ir ser dada pela pessoa a
quem esta foi feita, mas tambm ir ser ouvida pelos outros membros da equipa, e
desta maneira toda a equipa fica informada, caso a dvida surgisse a outro membro,
Tambm pode ser uma oportunidade para iniciar uma discusso de ideias que poder
ser importante para o enriquecimento do projeto. Podemos ento dizer que esta uma
comunicao osmtica, onde a informao flui em segundo plano e pode ser retida
por qualquer membro da equipa. De sublinhar que existem certos entraves a esta propriedade: quanto maior a equipa, maior ser a dificuldade de comunicao; podero
haver membros da equipa que no conseguem trabalhar num ambiente deste tipo. Para
cada um dos casos, devero ser discutidas estratgias para lidar com estes entraves.
Segurana Pessoal. Essencialmente, falar quando algo est a incomodar, sem medo
de represlias. uma propriedade muito importante no que diz respeito a descobrir e
resolver fraquezas que podero estar a atrasar a equipa. tambm um passo importante para construir confiana. Quando os elementos sentem que no podem confiar
uns nos outros, atrasa o jogo cooperativo, dificulta a comunicao e a eficincia do
processo fica comprometida. De sublinhar que no se pode confundir Segurana Pessoal e falta de cortesia. Ter de estar sempre em mente que uma equipa trabalha em
prol dos mesmo objetivos, e para estes serem alcanados importante reduzir as fraquezas que possam estar a atrasar o processo.
Foco. O primeiro passo para o foco primeiramente saber o que se vai fazer, e depois
ter tempo e paz de esprito para trabalhar nisso. Saber no que trabalhar vem da comunicao acerca dos objetivos, e prioridades, tipicamente com o Patrocinador Executivo. Tempo e paz de esprito vem de um ambiente onde uma pessoa no distrada da
sua tarefa e chamada para fazer outra incompatvel.[3] , portanto tarefa do Patrocinador Executivo clarificar toda a equipa de quais so as suas funes e prioridades e
certificar-se de que toda a gente mantenha o foco no seu trabalho. Idealmente, uma
equipa trabalha apenas num projeto de cada vez.
Fcil acesso a utilizadores experientes. Acesso contnuo a estes utilizadores daro
equipa:

 um lugar para experimentar e testar as entregas frequentes;

rpido feedback da qualidade do seu produto final
facilidade na tomada de decises;
Quanto mais a equipa recorre a estes utilizadores reais, mais vantagens podem tirar
desses contatos continuados.
At equipas que praticam outras metodologias geis podero deparar-se catastrficos
maus resultados no fim do projeto por negligenciarem o feedback dado no decorrer do
projeto.

3.4

Princpios

Diferentes projetos necessitam de diferentes metodologias. No existe uma metodologia padro que possa ser utilizada em todos os projetos. Como j foi descrito na
seco Introduo famlia Crystal, para cada projeto ter de se ter em considerao,
primeiro de tudo, o nmero de elementos que equipa ter. Em segundo, o grau de
estrago que poderia advir de um defeito no sistema. S depois de fazer esta avaliao
que se poder ajustar a densidade de metodologia necessria a cada projeto. Obviamente que se um erro do sistema implicar a perda de vida, como, por exemplo, numa
central nuclear, a metodologia dever ser discutida ao pormenor e aplicada com rigor.
Equipas maiores precisam de mais elementos de comunicao. O tamanho das
equipas o ponto crtico que distingue os membros da famlia Crystal. Crystal Clear,
por exemplo, s dever ser aplicado a equipas que conseguem fazer Comunicao
Osmtica. Equipas de maior dimenso, que no se consigam juntar na mesma sala,
devero discutir outros canais de comunicao.
Projetos que lidam com maior potencial para danos necessitam de mais elementos de validao. Como j foi descrito no primeiro princpio, num projeto que lide
com perda de vida em caso de falha dever haver mais cuidado com a escolha da
metodologia a seguir. A diferena no estar nos canais de comunicao e na coordenao da equipa, mas sim na verificao e validao. Dever ser feita uma reviso
esmiuada aos requisitos, fase de desenvolvimento e aos testes, deixando bem claro
que o sistema funciona. Mas para um projeto mais leve, por exemplo, um sistema de
reconhecimento facial, no so necessrias tantas revises que implicam gasto de
dinheiro, energia e tempo. Se no decorrer do projeto surgir a necessidade de certas
verificaes, a flexibilidade da metodologia permite que essas verificaes sejam
adicionadas ao processo.
Excesso de metodologia fica caro. Nem sempre quanto mais metodologia, melhor
verdade. Em certos projetos, o excesso de passos no processo, documentao e relatrios de estado significam atraso na entrega do produto final. Quando se substitui

esse excesso de mtodo com boa comunicao, cortando na burocracia, geralmente

significam rpidas entregas do produto final e poupana de fundos.
Formalidade, processo e documentao no substituem disciplina, habilidade e
entendimento. Pessoas que criam software so pessoas que precisam de inventar e
comunicar as suas ideias, baseando-se nas suas habilidades e entendimento do assunto. [3] Disciplina, habilidade e entendimento so propriedades intrnsecas de cada
pessoa e no ser o preenchimento de relatrios, documentao detalhada do estado
cdigo e o facto de seguirem certos passos de desenvolvimento que substituir a capacidade de inveno.
Comunicao interativa e cara-a-cara o canal mais barato e rpido para troca
de informao. Aparte de certas vantagens que a comunicao por e-mail, telefone e,
eventualmente, papel possa ter (como por exemplo isolamento de reaes socioemocionais), a verdade que se perde bastante eficincia de comunicao, que se
traduz em perda de tempo e aumento de erros. Como quase todos os projetos so sensveis a tempo e custo, a comunicao cara-a-cara tira vantagem do facto de ter a
equipa toda na mesma sala, com feedback instantneo, a utilizar uma linguagem mais
informal, a criar laos (muito importante para a metodologia funcionar) e a tirar apontamentos num quadro comum a todos onde poder ser posteriormente ser consultado
por toda a gente. , portanto um canal rico em informao e emoes que no exige
grandes gastos de tempo e dinheiro.
Mais feedback e comunicao reduzem a necessidade de entregas intermdias.
Estas entregas intermdias referem-se a documentao que entregue aos utilizadores, patrocinadores e examinadores em conjunto com o sistema parcialmente funcional ao longo do processo onde est descrito o que ainda falta fazer, como vai ser feito,
por quem vai ser feito, o que prometem entregar no final Com a comunicao formatada para ser feita cara-a-cara, com o aumento de feedback e rapidez que advm
deste processo, menos documentao deste tipo necessria.
Desenvolvimento simultneo e em srie transforma custos em velocidade e flexibilidade. Este princpio diz que, se for bem feito, o desenvolvimento simultneo pode
acelerar o processo, apear do salrio ser mais alto, em comparao com o desenvolvimento em srie, onde cada tarefa trabalhada at ao fim e s depois passam para a
prxima. O problema do desenvolvimento em srie que se houver uma falha em
algum ponto do processo, este ter de ser comeado do incio, significando mais gastos de tempo e dinheiro. Para que funcione, os requisitos devero estar bem definidos
e claros, para a compreenso de todos. A famlia Crystal , portanto, construda sobre
o uso do desenvolvimento simultneo, onde os erros podem ser descobertos e resolvidos em tempo real e que requer boa comunicao, propriedade fundamental que faz
parte do cdigo gentico desta famlia.

3.5

Tcnicas e Estratgias

Crystal Clear no requer nenhuma tcnica ou estratgia mas so teis para quem est
a comear um projeto. Podero haver outras que serviro melhor o propsito mas
estas so as mais significativamente usadas pelas equipas de desenvolvimento gil.
As estratgias so as seguintes:
Exploratrio 360. Consiste em analisar, em poucos dias ou semanas, os requisitos,
planos de projeto, equipa, metodologia e valor do projeto
Early Victory. Pequenas vitrias ajudam o grupo a desenvolver confiana e solidez.
Quanto mais cedo, melhor.
Esqueleto Andante. Para que a equipa alcance pequenas vitrias, implementar uma
pequena funcionalidade do incio ao fim, de forma a receber feedback o mais rapidamente possvel e corrigir possveis erros.
Re-arquitetura Incremental. Dividir a arquitetura em fases, mantendo o sistema
funcional medida que se vai avanando.
Radiadores de Informao. Consistem em deixar a informao exibida num local
onde todos possam ter fcil acesso a ela. Dever estar sempre atualizada e exibida de
forma clara.

As Tcnicas so as seguintes:
Metodologias de formao. Reunir informao sobre experincias passadas e usar
essa informao para definir as convenes iniciais.
Workshop de Reflexo. Uma pausa no trabalho, de uma hora, depois de cada entrega
para refletir no produto, progresso e processo.
Planeamento Relmpago. Definir tarefas e as suas dependncias e dispor as mesmas
numa cronologia.
Estimativa Delphi. No incio do projeto, estimar a durao do mesmo.

Reunies Dirias. Reunio onde toda a gente, num mximo de 10 minutos, anuncia
no que cada um est a trabalhar e se for o caso, onde esto a ter dificuldades em avanar.
Design gil de Interfaces. Num dia ou dois, planear o design da interao do utilizador com o sistema.
Miniatura do Processo. De maneira simplificada e resumida, explicar o processo que
est a ser utilizado.
Programao lado-a-lado. Duas pessoas sentadas lado-a-lado a trabalhar em diferentes tarefas, permitindo que estes se ajudem mutuamente.
Burn Charts. Grfico que mostra quantas tarefas esto completas e quantas faltam.
De maneira simplificada informar sobre o andamento do projeto.

3.6

Metodologias-exemplo a copiar

Os humanos, melhor que inventar, so melhores a modificar. Por esta razo, Crystal
tem metodologias-exemplo que podem ser copiadas ou modificadas para cada situao. Estes exemplos no foram criados para serem seguidos e implementados fora,
mas para serem modificados, adicionando ou retirando detalhes at que o resultado
sirva o propsito. [4] A metodologia que vai ser descrita a seguir (Crystal Clear) um
exemplo.

Crystal Clear

Crystal Clear um membro de famlia Crystal que se pode descrever como sendo
uma metodologia que usada para projetos pequenos, apenas com o risco de perda de
conforto ou perda de dinheiro discricionrio em caso de falha, onde so formada
equipas de 6 a 8 elementos, sentados na mesma sala, permitindo comunicao osmtica entre a equipa, as entregas so frequentes, acompanhadas de feedback dado pelos
utilizadores especialistas e do prprio cliente, onde a metodologia flexvel e pode
ser modificada se for necessrio. A preciso, no incio do projeto baixa, mas alta
quando o produto o final ou aproximado. Baixa preciso pois a linguagem usada
pela equipa simples e clara, a informao exibida num quadro a que toda a gente
tem acesso, a comunicao com o patrocinador executivo e com o cliente feita caraa-cara, fazendo com que o tempo gasto em burocracia seja convertido em trabalho de
inveno e o foco seja mantido na tarefa que esto a realizar. Alta preciso refere-se a

demonstraes funcionais, cdigo final, casos de teste, manuais de utilizador ou textos de apoio.
Crystal no foi desenhado para empresas que querem metodologias padronizadas,
ou que trabalhem em projetos longos. Foi pensada para organizaes que sabem quais
so os seus pontos fortes e fracos, adaptando a Crystal Clear de forma a tomar partido
desses pontos fortes e cobrindo as fraquezas. A Crystal Clear destina-se, em primeiro
lugar a organizaes que querem construir a sua prpria metodologia, de maneira a
possibilitar a rpida entrega de software.[3]
4.1

A Equipa

A equipa que aqui vai ser descrita apenas um modelo funcional da Crystal Clear
que pode, obviamente, ser modificada, como em tudo nesta metodologia.
Existem 8 papis em Crystal Clear, onde 4 deles tero de ser pessoas diferentes e os
outros 4 podem ser adicionalmente designados s pessoas envolvidas no projeto.
Os primeiros quatro papis so:
Executive Sponsor. a pessoa que est a alocar ou a defender qual o destino do dinheiro do projeto. Dever manter em mente os objetivos a longo prazo, gerindo tambm as prioridades a curto prazo, as entregas, a evoluo do sistema e manuteno da
equipa. Cabe ao Executive Sponsor tomar decises a nvel dos negcios e criar visibilidade para o projeto. Para isso, dever estar sempre informado do decorrer dos trabalhos e tomar decises que sejam relevantes para o avano dos mesmos.
Ambassador User. a pessoa que deve estar familiarizado com os procedimentos
operacionais e o sistema em uso. Deve saber quais os modos de operao so mais
frequentemente utilizados, que atalhos so precisos e que informao dever estar
visvel para o sistema poder ser usado. Espera-se que o Ambassador User esteja intimamente familiarizado com as atividades dos utilizadores para que o sistema esteja
adequadamente adaptado.
Lead Designer. o lder do trabalho tcnico que ter de ter experincia em desenvolvimento de software, ter de estar apto a fazer a arquitetura do sistema, saber se a
equipa est no bom caminho e se no estiver, ter a soluo para a direcionar no bom
caminho. Dever ser a pessoa (ou uma das pessoas) mais competente/ fluente/experiente da equipa. Desempenhar tambm funes de programador, aparte de
liderar a equipa tcnica, se a constituio da equipa assim requerer.

Designer-Programmer. Ser a pessoa que ir proceder implementao do cdigo e

antes de o implementar, mais importante que a implementao em si, ter de escrever
o sistema em algoritmos pois fazer trabalho de programao exige no s escrever o
cdigo como tambm fazer o design do mesmo.

Os outros quatro papis que podero ser desempenhados pelo resto da equipa, ou
at adicionados s funes anteriores so:
Coordinator. Ser a pessoa responsvel por tirar apontamentos sobre o planeamento
do projeto e estado do processo, notas essas que sero tornadas pblicas no quadro
comum. um papel que poder idealmente ser desempenhado pelo Executive Sponsor ou Lead Designer, e pode ser rotativo.
Bussiness Expert. Esta pessoa ir responder s questes que a equipa tcnica ter
sobre o ncleo de funcionamento do sistema que esto a desenvolver. Quais a polticas envolvidas da rea onde o software vai ser usado. O mais usual ser o Ambassador User a arrecadar esta funo, ma poder ser tambm qualquer membro da equipa
ou um especialista externo. De notar que a diferena entre Ambassador User e o Bussiness Expert que o primeiro sabe como o utilizador lida com o sistema e o segundo
sabe como o negcio lida com o sistema.
Tester. tarefa do Tester detetar e reportar bugs. O sistema ter de passar primeiramente pelas mos desta pessoa antes de chegar aos utilizadores.
Writer. O trabalho do Writer tratar de escrever textos para ajudar a utilizar o sistema, escrever o manual de utilizador e o manual de treino. Mas ser a equipa a decidir
o que dever constar nestes documentos. Este trabalho pode ser feito por um membro
da equipa ou elemento externo.

4.2

O Processo

Crystal Clear usa ninhos de ciclos de processos de vrios tamanhos: Desenvolvimento, iterao, perodo de entrega e todo o projeto.[5]

Fig. 3. Ciclos de Processos que ocorrem durante um projeto[3]

Ciclo do Projeto. Um ciclo de projeto em Crystal Clear tem trs partes:

Mapeamento de atividades. Demora alguns dias ou semanas. Durante este tempo iro:
Construir o ncleo da equipa;
Fazer o Exploratrio 360;
Dar forma s convenes da metodologia;
Construir o plano inicial do projeto.
No final desta parte, a equipa dever ter decidido se o projeto vai para a frente e em
caso afirmativo, um grupo de pessoas com uma metodologia rascunhada e uma ideia
do que vo e esto a fazer.
Um ou dois ciclos de entregas. Que vai ser descrito frente.
Reflexo sobre o projeto. Refletir sobre o que est a funcionar bem, o que poderia
estar a funcionar melhor, refletir sobre todo o processo e sobre o projeto. No final,
para um projeto ser considerado bem-sucedido, o produto tem de ser entregue e a
equipa ter de querer trabalhar junta outra vez. Caso isso acontea, no s o projeto
foi bem-sucedido mas tambm a metodologia Crystal serviu o seu propsito.

Ciclo de Entrega. Um ciclo de entrega pode ter trs ou quatro partes:

Recalibrao do plano de Entregas. Na primeira entrega esta recalibrao no far
sentido, mas aps essa entrega e aps dado o feedback dos utilizadores, a equipa ter
informao relevante que poder significar uma reviso aos requisitos e consequente
mudana nos planos do projeto.
Sries de uma ou mais iteraes. Descritas mais frente
Entrega a Utilizadores reais. Para que a equipa possa obter informao relevante
continuao dos trabalhos.
Reflexo sobre a entrega. Com base no feedback recebido dos utilizadores, discutir
sobre que mudanas fazer ao projeto, o que acrescentar, o que manter. De notar que
nesta parte iro refletir sobre o produto, e no o processo.

Ciclo de Iterao. No perodo de iterao a equipa ir

Planear as iteraes. Serve para definir as prioridades d equipa para aquela semana.
Realizar as atividades do ciclo de integrao. Descritas mais frente.

Workshop de Reflexo. Onde dever ser feita uma reflexo sobre os hbitos de trabalho, sobre as relaes com os outros membros da equipa, o modelo de comunicao
em uso, novas tcnicas que queiram experimentar, etc.

Ciclo de Integrao. Corresponde integrao de pequenos desenvolvimentos do

projeto. Requer que toda a equipa saiba o que cada um est a desenvolver para poderem integrar a sua parte com a dos outros. feito tambm um teste automatizado no
fim de cada integrao
Desenvolvimento. Na figura representado por epis. de episdio. Durante um episdio, uma pessoa trabalha numa pequena tarefa de programao at estar completa e no
fim, idealmente, testa-se por processos automatizados. Dever demorar menos de um
dia, dependendo do programador e das convenes do projeto.

Concluses

Crystal Clear um conjunto de metodologias baseadas em metodologia gil, focada

na gesto das pessoas, onde uma equipa de dois a oito elementos se juntam na mesma
sala a trabalhar, fazendo uma comunicao osmtica, as entregas so frequentes, tal
como as reflexes sobre o produto, mtodo de trabalho e convenes do processo.
uma metodologia que para funcionar, pelo menos uma pessoa da equipa dever
estar familiarizada com a metodologia e toda a equipa dever trabalhar em direo s
mesmas metas, desenvolvendo pelo caminho confiana no resto da equipa e canais de
comunicao que os elementos se sintam totalmente seguros em usar sem medo de
represlia. Alm de depender das habilidades tcnicas dos seus elementos, o sucesso
depende tambm das emoes, personalidade e estado de espirito dos mesmos, sendo
portanto uma metodologia no muito definida e bastante folgada para lidar com esse
aspeto. medida que o projeto vai avanando, a metodologia pode ser redefinida,
bem como os requisitos e a prpria equipa. Para um projeto ser considerado bemsucedido, o produto ter de ser entregue funcional e a equipa ter de estar satisfeita
quer com o resultado final, quer com o processo que foi seguido durante a sua execuo.
Devido sua estrutura pouco padronizada e dependente de uma boa comunicao,
uma metodologia que no se destina a ser usada em grandes empreendimentos com
grandes equipas, onde possa existir perda de algo mais que no seja conforto em caso
de falha do sistema.
uma metodologia que est talhada para ser usada em projetos onde se queira
uma entrega rpida, com resultados o mais aproximado possvel ao pedido do cliente,
que se consegue construindo um bom canal de comunicao entre a equipa e o cliente
e cortando na burocracia e formalidade.

Por ser uma metodologia que no usa uma frmula universal para todos os projetos e equipas, e tem de ser dispensado tempo para a planear, as equipas de trabalho
nem a chegam a consideram e preferem usar outras metodologias geis ou tradicionais.
Tem como pontos positivos as entregas serem frequentes que permitem contacto
constante com o cliente; reduz a probabilidade de falha na entrega final; bastante
voltil, podendo adaptar-se a cada grupo de trabalho e projeto (desde que no muito
grande); utilizando uma linguagem clara, simples e continuada as tarefas esto bem
definidas e cada um sabe exatamente o que tem de fazer; uma mudana nos requisitos
no significa que o projeto tenha de comear do incio; o patrocinador sabe sempre
em que fase de projeto a equipa se encontra, podendo mexer na configurao desta ou
no processo para que a eficincia seja aumentada.
Os pontos negativos sero o facto de ter tanta sensibilidade falha humana, pois
depende muito da personalidade de cada elemento e dos seus hbitos de trabalho e a
equipa perfeita pode nunca ser encontrada; no pode ser aplicada a projetos de larga
escala; por no ser bem definida, uma metodologia pouco usada pelas equipas de
trabalho.
Por ltimo, importante referir que Crystal Clear uma metodologia que, se aplicada, tem grandes probabilidades de resultar pois foi criada com base na observao
de projetos de sucesso.

Referncias
1. Hastie, S., & Wojewoda, S. (n.d.). Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. Retrieved January 28, 2016, from http://www.infoq.com/articles/standishchaos-2015
2. Filho, H. F. B. P. (2011). Um estudo analtico entre as abordagens de Engenharia de Requisitos nas Metodologias geis XP , SCRUM e Crystal. Recife.
3. Cockburn, A. (2004). A Human-Powered Methodology For Small Teams, including The
Seven Properties of Effective Software Projects. Crystal Clear.
4. Cockburn, A. (n.d.). Software Development as a Co-operative Game. In Agile Software
Development (2nd Editio).
5. Sinsio, Thiago Nunes Homem, Briner Alexandre Correia, Carlos Daniel, A. da S. (2013).
Metodologia Crystal Clear (Crystal Clear Methodologies).