metodologias de desenvolvimento Ágil

8/17/2019 Metodologias de Desenvolvimento Ágil

1/15

Metodologias de Desenvolvimento Ágil: Crystal Clear

Helena Filipa da Cunha Fernandes, nº65352

Mestrado Integrado em Engenharia Eletrónica Industrial e ComputadoresUniversidade do Minho

Campus de Azurém 4800-058 Guimarães, [email protected]

Abstract. A família Crystal é um conjunto de metodologias criada por AlistairCockburn que possui uma abordagem voltada para a gestão de pessoas. Como aqualidade do projeto é sensível a fatores humanos, a família Crystal não é, propositadamente, completamente definida, devendo adaptar-se a cada projeto. Adefinição da melhor metodologia a adotar dependerá do número de pessoas en-volvidas e da complexidade do projeto. Para tal, a família Crystal é definidagraficamente por cores que indicam a densidade da metodologia a adotar.Quanto mais escura é a cor, mais complexo é o projeto e mais densa é a meto-dologia. A Crystal Clear é uma metodologia voltada para equipas entre duas eoito pessoas, a partilhar o mesmo espaço, permitindo uma comunicação osmóti-ca que não aspira a ser a “melhor” metodologia, mas suficiente para levar o projeto até à “zona de segurança”.

Keywords: Metodologia Ágil, Crystal Clear , Código Genético

1 Introdução

Segundo o mais recente estudo realizado pelo CHAOS Report (CHAOS Report2015), pesquisa realizada pela empresa Standish Group1 a 50000 projetos de variadasdimensões e de todo o mundo, apenas 29% tiveram sucesso, isto é, foram entregues atempo, sem exceder o orçamento e com resultados satisfatórios. A percentagem de

projetos que falharam estes três critérios foi de 19%, e os restantes 52% dizem respei-to aos projetos que apenas contemplaram 1 ou 2 dos critérios. A análise dos dados quedatam desde 2011 até 2015 mostram que quanto mais pequenos são os projetos, maiorserá a probabilidade de sucesso.[1]

O estudo apresenta também um ranking de fatores que trabalhados em conjuntocriarão um projeto bem-sucedido. Os três mais importantes são: o suporte executivo, amaturidade emocional e o envolvimento do utilizador. Tem-se suporte executivoquando um executivo ou grupo de executivos assistem e apoiam em pano de fundo,

1 Empresa de consultoria que se dedica ao melhoramento da gestão de projetos de desenvol-vimento de software. Publica todos os anos um relatório (CHAOS Report) sobre o estado daindústria de desenvolvimento de software.

mailto:[email protected]:[email protected]


2/15

quer financeiramente quer emocionalmente, encorajando a conclusão bem-sucedidado projeto. A maturidade emocional diz respeito ao comportamento básico das pesso-as que integram a equipa de trabalho, por exemplo, na rápida tomada de decisões ecooperação entre colegas que trabalham juntos em direção às mesmas metas e objeti-vos. O envolvimento do utilizador/cliente requer que este esteja presente no processode recolha de informação e tomada de certas decisões.

Estes três fatores são claramente voltados para a gestão de pessoas.A família Crystal , conjunto de metodologias que vão ser descritas neste artigo,

possui uma abordagem voltada para essa gestão, onde os talentos e habilidades pesso-ais são fatores decisivos para a finalização de um projeto bem-sucedido. [1]

Este artigo está dividido em 4 secções: na primeira secção encontra-se uma breveintrodução à família Crystal , na segunda, uma descrição do seu código genético, na

terceira, a descrição da Crystal Clear, bem como o processo e constituição de umaequipa e por fim, na quarta secção as conclusões tiradas da reflexão sobre os concei-tos aprendidos na redação deste artigo.

Este artigo foi baseado em artigos, páginas web sobre o tema e em publicações bi- bliográficas do próprio criador da metodologia.

2 Introdução à família Crystal

Criada por Alistair Cockburn, Crystal é uma abordagem ao desenvolvimento de soft-ware voltada para a gestão de pessoas e portanto muito sensível a fatores humanos. Osucesso de um projeto está dependente dos talentos e habilidades pessoais de cadaelemento da equipa, assim como a complexidade do projeto em si e número de pesso-as a trabalhar nele. Sendo assim, esta é uma abordagem propositadamente pouco defi-nida que, além de partilhar o mesmo código genético, é adaptado às necessidades decada projeto.

Em todos os ramos da família, existem três propriedades comuns a todas elas quesão a Entrega Frequente, a Comunicação Cara-a-Cara e a Melhoria por Reflexão.

Alistair caracterizou as diferentes metodologias Crystal por cores, de acordo comdois critérios: o número de pessoas a coordenar e a criticidade do projeto.

Fig. 1. Relação entre as cores e o número de pessoas a coordenar


3/15

Na Fig.1 está ilustrada a relação entre o tamanho da equipa e a cor da metodologiaa adotar. Quanto maior a equipa, mais complexa é a coordenação e comunicação e,

portanto, mais “densa” é a cor da metodologia.[2]Uma segunda dimensão importante a ter em conta para classificar estas metodolo-

gias é a criticidade, o potencial estrago causado por certos defeitos que não foramdetetados: perda de conforto (C), perda de dinheiro discricionário (D), perda de di-nheiro essencial para o projeto (E), e perda de vida do sistema (L). Estes critérios

podem ser verificados no sistema axial da Fig.2.

Fig. 2. Representação da criticidade de cada metodologia num sistema axial[3]

Por exemplo, a caixa C20 significa que uma equipa de 20 elementos está a traba-lhar num sistema de perda de conforto do sistema.

Por observação da figura podemos concluir que esta classificação implica a exis-tência de pelo menos 16 metodologias.

O nome Crystal deriva das duas dimensões consideradas acima, em analogia à ge-ologia dos cristais, que também são classificados conforme duas dimensões: a cor e adureza. O tamanho da equipa corresponde à cor do cristal: transparente, amarelo,laranja, vermelho, marron, azul e violeta; e a criticidade corresponde à dureza domineral: dureza de quartzo quando apenas existe perda de conforto e de diamante para

perda de vida do sistema. [3]

3 Código Genético da Família Crystal

Crystal é uma família de metodologias com um código genético comum. O códigogenético ajuda a desenvolver um novo membro da família que, se todas as conven-ções funcionarem em sintonia, aumenta a probabilidade de sucesso do projeto.

Este código genético que criará a metodologia é “desenhado” no início de cada

projeto e, se necessário, periodicamente durante o mesmo.[4]


4/15

O código genético do Crystal consiste em 6 elementos:

Modelo de Jogo económico-cooperativo; Prioridades selecionadas;

Propriedades selecionadas; Princípios selecionados; Técnicas e estratégias selecionadas; Metodologias-exemplo a copiar;

3.1 Modelo de Jogo económico-cooperativo

Tratar o desenvolvimento de software como um jogo cooperativo de invenção e co-municação liberta a equipa para decidir que “movimento” faz sentido fazer num certo

ponto do projeto e qual a estratégia que criará uma boa posição para a próxima “joga-

da”. Com este elemento do código genético, liberta a equipa também da ilusão de que

existe apenas uma fórmula para usar em todos os projetos.[4]Trabalhar o projeto como sendo uma parte de uma série de jogos interconectados

faz com que se destaque a importância não só de entregar o sistema no final mas tam- bém a importância de ajustar o método de trabalho à medida que este vai evoluindo.Mas o intuito de todos os jogos resume-se à competição. Cada equipa terá de adaptaro seu “jogo” para que a competição se torne uma oportunidade para a colaboração,

onde não é 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. Nasmetodologias Crystal, as prioridades são as seguintes:

Segurança no resultado do projeto (entrega do software); Eficiência do Processo;

Habitabilidade das convenções.

A prioridade mais importante é a primeira. Se o software não for entregue, o projeto falhou.

As outras duas prioridades são conflituosas. Poderá haver um processo que seja o

mais eficiente, mas que a equipa não esteja tão à vontade para o usar. Para que a me-todologia funcione, esta deverá ser aceite pela equipa. Mais uma vez, não existe umafórmula para todos os projetos mas sim um método que se adequa a cada equipa.


5/15

3.3

Propriedades

Alistair chama a estas propriedades as “Sete Propriedades dos Projetos Bem-Sucedidos”. Considera que as propriedades são mais importantes que os procedimen-tos pois estão mais voltadas para a maneira como a equipa funciona, e não para asferramentas com que trabalham. Uma equipa tem a completa noção da sua condição

pois avalia-se mais facilmente, e mais facilmente se adapta às suas condições. A ma-neira como a equipa se adapta para ir ao encontro destas propriedades não são defini-das pela metodologia, mas sim pela equipa.

Então, as sete propriedades que farão uma equipa de sucesso são:

Entregas Frequentes; Melhorias Refletivas;

Comunicação Cara-a-Cara; Segurança pessoal;

Foco; Fácil acesso a utilizadores experientes; Ambiente técnico com testes automatizados, gestão de configuração e frequente

integração.

A família Crystal foca-se nas três primeiras propriedades pois deverão estar pre-sentes em todos os projetos. As outras quatro apenas aumentam a margem da safety

zone.

Nomear estas propriedades melhora também a comunicação da equipa, pois sabe-rão expressar-se com mais clareza, e daí avaliar melhor a sua situação e discutir ma-

neiras de a corrigir, se necessário.

Entregas Frequentes. A propriedade mais importante de qualquer projeto, pequenoou grande, ágil ou não, são as entregas continuadas de código testado a utilizadoresreais. [3]As vantagens desta prática são, entre outras:

─ o patrocinador obtém 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 desenvolvi-mento já efetuado;

─ os programadores mantêm o foco; ─ a equipa mantém-se motivada a cada feedback positivo.

Há que ter em atenção a frequência com que se fazem estas entregas, O cliente poderá não estar disponível para fazer os testes, então terão de se virar para uma co-munidade de utilizadores que, caso as entregas sejam frequentes, esta poderá sentir-seirritada ou, se caso não forem entregues frequentemente, problemas de funcionamento

poderão ser detetados numa fase mais avançada do projeto e por consequência, a falhado mesmo. A solução seria encontrar um utilizador “amigável” que estivesse dispostoa fazer estes testes com a frequência adequada ao ritmo de iteração da equipa.


6/15

Melhorias Refletivas. Por outras palavras, refletir e melhorar. Periodicamente, aequipa terá de se juntar e refletir no que pode melhorar para a próxima iteração. Oobjetivo desta propriedade é tornar o que seriam falhas catastróficas em elementos desucesso. Estas melhorias poderão ser aplicadas aos elementos da equipa, à tecnologiae ferramentas usadas, e à própria metodologia, e esta não estiver a funcionar. Estasreuniões deverão acontecer, pelo menos, a cada entrega efetuada.

Comunicação Cara-a-Cara. Não só a forma mais económica de comunicar, mastambém a maneira mais rápida para se trocar informação. Para isso, basta que a equi-

pa esteja sentada na mesma sala. Se um elemento tiver uma questão acerca do projeto,como toda a gente está na mesma sala, não só a resposta irá ser dada pela pessoa aquem esta foi feita, mas também irá ser ouvida pelos outros membros da equipa, edesta maneira toda a equipa fica informada, caso a dúvida surgisse a outro membro,Também pode ser uma oportunidade para iniciar uma discussão de ideias que poderáser importante para o enriquecimento do projeto. Podemos então dizer que esta é umacomunicação osmótica, onde a informação 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 comunicação; poderãohaver membros da equipa que não conseguem trabalhar num ambiente deste tipo. Paracada um dos casos, deverão ser discutidas estratégias para lidar com estes entraves.

Segurança Pessoal. Essencialmente, falar quando algo está a incomodar, sem medode represálias. É uma propriedade muito importante no que diz respeito a descobrir e

resolver fraquezas que poderão estar a atrasar a equipa. É também um passo impor-tante para construir confiança. Quando os elementos sentem que não podem confiaruns nos outros, atrasa o jogo cooperativo, dificulta a comunicação e a eficiência do

processo fica comprometida. De sublinhar que não se pode confundir Segurança Pes-soal e falta de cortesia. Terá de estar sempre em mente que uma equipa trabalha em

prol dos mesmo objetivos, e para estes serem alcançados é importante reduzir as fra-quezas que possam estar a atrasar o processo.

Foco. O primeiro passo para o foco é primeiramente saber o que se vai fazer, e depoister tempo e paz de espírito para trabalhar nisso. Saber no que trabalhar vem da comu-nicação acerca dos objetivos, e prioridades, tipicamente com o Patrocinador Executi-vo. Tempo e paz de espírito vem de um ambiente onde uma pessoa não é distraída da

sua tarefa e chamada para fazer outra incompatível.[3] É, portanto tarefa do Patroci-nador Executivo clarificar toda a equipa de quais são as suas funções e prioridades ecertificar-se de que toda a gente mantenha o foco no seu trabalho. Idealmente, umaequipa trabalha apenas num projeto de cada vez.

Fácil acesso a utilizadores experientes. Acesso contínuo a estes utilizadores darão àequipa:


7/15

─

um lugar para experimentar e testar as entregas frequentes; ─ rápido feedback da qualidade do seu produto final ─ facilidade na tomada de decisões;Quanto mais a equipa recorre a estes utilizadores reais, mais vantagens podem tirardesses contatos continuados.Até equipas que praticam outras metodologias ágeis poderão deparar-se catastróficosmaus resultados no fim do projeto por negligenciarem o feedback dado no decorrer do

projeto.

3.4 Princípios

Diferentes projetos necessitam de diferentes metodologias. Não existe uma meto-dologia padrão que possa ser utilizada em todos os projetos. Como já foi descrito nasecção I ntr odução àfamília Crystal , para cada projeto terá de se ter em consideração,

primeiro de tudo, o número de elementos que equipa terá. Em segundo, o grau deestrago que poderia advir de um defeito no sistema. Só depois de fazer esta avaliaçãoé que se poderá ajustar a “densidade” de metodologia necessária a cada projeto. Obvi-

amente que se um erro do sistema implicar a perda de vida, como, por exemplo, numacentral nuclear, a metodologia deverá ser discutida ao pormenor e aplicada com rigor.

Equipas maiores precisam de mais elementos de comunicação. O tamanho dasequipas é o ponto crítico que distingue os membros da família Crystal . Crystal Clear ,

por exemplo, só deverá ser aplicado a equipas que conseguem fazer ComunicaçãoOsmótica. Equipas de maior dimensão, que não se consigam juntar na mesma sala,deverão discutir outros canais de comunicação.

Projetos que lidam com maior potencial para danos necessitam de mais elemen-tos de validação. Como já foi descrito no primeiro princípio, num projeto que lidecom perda de vida em caso de falha deverá haver mais cuidado com a escolha dametodologia a seguir. A diferença não estará nos canais de comunicação e na coorde-nação da equipa, mas sim na verificação e validação. Deverá ser feita uma revisãoesmiuçada aos requisitos, à fase de desenvolvimento e aos testes, deixando bem claroque o sistema funciona. Mas para um projeto mais leve, por exemplo, um sistema dereconhecimento facial, não são necessárias tantas revisões que implicam gasto dedinheiro, energia e tempo. Se no decorrer do projeto surgir a necessidade de certasverificações, a flexibilidade da metodologia permite que essas verificações sejamadicionadas ao processo.

Excesso de metodologia fica caro. Nem sempre “quanto mais metodologia, melhor”é verdade. Em certos projetos, o excesso de passos no processo, documentação e rela-tórios de estado significam atraso na entrega do produto final. Quando se substitui


8/15

esse excesso de método com boa comunicação, cortando na burocracia, geralmentesignificam rápidas entregas do produto final e poupança de fundos.

Formalidade, processo e documentação não substituem disciplina, habilidade eentendimento. Pessoas que criam software são pessoas que precisam de inventar ecomunicar as suas ideias, baseando-se nas suas habilidades e entendimento do assun-to. [3] Disciplina, habilidade e entendimento são propriedades intrínsecas de cada

pessoa e não será o preenchimento de relatórios, documentação detalhada do estadocódigo e o facto de seguirem certos passos de desenvolvimento que substituirá a ca-

pacidade de invenção.

Comunicação interativa e cara-a-cara é o canal mais barato e rápido para trocade informação. Aparte de certas vantagens que a comunicação por e-mail , telefone e,eventualmente, papel possa ter (como por exemplo isolamento de reações socio-emocionais), a verdade é que se perde bastante eficiência de comunicação, que setraduz em perda de tempo e aumento de erros. Como quase todos os projetos são sen-síveis a tempo e custo, a comunicação cara-a-cara tira vantagem do facto de ter aequipa toda na mesma sala, com feedback instantâneo, a utilizar uma linguagem maisinformal, a criar laços (muito importante para a metodologia funcionar) e a tirar apon-tamentos num quadro comum a todos onde poderá ser posteriormente ser consultado

por toda a gente. É, portanto um canal rico em informação e emoções que não exigegrandes gastos de tempo e dinheiro.

Mais feedback e comunicação reduzem a necessidade de entregas intermédias. Estas entregas intermédias referem-se a documentação que é entregue aos utilizado-res, patrocinadores e examinadores em conjunto com o sistema parcialmente funcio-nal 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 comunicação for-

matada para ser feita cara-a-cara, com o aumento de feedback e rapidez que advémdeste processo, menos documentação deste tipo é necessária.

Desenvolvimento simultâneo e em série transforma custos em velocidade e flexi-bilidade. Este princípio diz que, se for bem feito, o desenvolvimento simultâneo podeacelerar o processo, apear do salário ser mais alto, em comparação com o desenvol-vimento em série, onde cada tarefa é trabalhada até ao fim e só depois passam para a

próxima. O problema do desenvolvimento em série é que se houver uma falha emalgum ponto do processo, este terá de ser começado do início, significando mais gas-tos de tempo e dinheiro. Para que funcione, os requisitos deverão estar bem definidose claros, para a compreensão de todos. A família Crystal é, portanto, construída sobreo uso do desenvolvimento simultâneo, onde os erros podem ser descobertos e resolvi-dos em tempo real e que requer boa comunicação, propriedade fundamental que faz

parte do código genético desta família.


9/15

3.5

Técnicas e Estratégias

Crystal Clear não requer nenhuma técnica ou estratégia mas são úteis para quem estáa começar um projeto. Poderão haver outras que servirão melhor o propósito masestas são as mais significativamente usadas pelas equipas de desenvolvimento ágil.As estratégias são as seguintes:

Exploratório 360º. Consiste em analisar, em poucos dias ou semanas, os requisitos, planos de projeto, equipa, metodologia e valor do projeto

Early Victory . Pequenas vitórias ajudam o grupo a desenvolver confiança e solidez.

Quanto mais cedo, melhor.

Esqueleto Andante. Para que a equipa alcance pequenas vitórias, implementar uma pequena funcionalidade do início ao fim, de forma a receber feedback o mais rapida-mente possível e corrigir possíveis erros.

Re-arquitetura Incremental. Dividir a arquitetura em fases, mantendo o sistemafuncional à medida que se vai avançando.

Radiadores de Informação. Consistem em deixar a informação exibida num localonde todos possam ter fácil acesso a ela. Deverá estar sempre atualizada e exibida de

forma clara.

As Técnicas são as seguintes:

Metodologias de formação. Reunir informação sobre experiências passadas e usaressa informação para definir as convenções iniciais.

Workshop de Reflexão. Uma pausa no trabalho, de uma hora, depois de cada entrega para refletir no produto, progresso e processo.

Planeamento Relâmpago. Definir tarefas e as suas dependências e dispor as mesmasnuma cronologia.

Estimativa Delphi. No início do projeto, estimar a duração do mesmo.


10/15

Reuniões Diárias. Reunião onde toda a gente, num máximo de 10 minutos, anunciano que cada um está a trabalhar e se for o caso, onde estão a ter dificuldades em avan-çar.

Design Ágil de Interfaces. Num dia ou dois, planear o design da interação do utiliza-dor com o sistema.

Miniatura do Processo. De maneira simplificada e resumida, explicar o processo queestá a ser utilizado.

Programação lado-a-lado. Duas pessoas sentadas lado-a-lado a trabalhar em diferen-tes tarefas, permitindo que estes se ajudem mutuamente.

Burn Charts . Gráfico que mostra quantas tarefas estão completas e quantas faltam.De maneira simplificada informar sobre o andamento do projeto.

3.6 Metodologias-exemplo a copiar

Os humanos, melhor que inventar, são melhores a modificar. Por esta razão, Crystal tem metodologias-exemplo que podem ser copiadas ou modificadas para cada situa-ção. Estes exemplos não foram criados para serem seguidos e implementados à força,

mas para serem modificados, adicionando ou retirando detalhes até que o resultadosirva o propósito. [4] A metodologia que vai ser descrita a seguir (Crystal Clear ) é umexemplo.

4 Crystal Clear

Crystal Clear é um membro de família Crystal que se pode descrever como sendouma metodologia que é usada para projetos pequenos, apenas com o risco de perda deconforto ou perda de dinheiro discricionário em caso de falha, onde são formadaequipas de 6 a 8 elementos, sentados na mesma sala, permitindo comunicação osmó-

tica entre a equipa, as entregas são frequentes, acompanhadas de feedback dado pelosutilizadores especialistas e do próprio cliente, onde a metodologia é flexível e podeser modificada se for necessário. A precisão, no início do projeto é baixa, mas altaquando o produto é o final ou aproximado. Baixa precisão pois a linguagem usada

pela equipa é simples e clara, a informação é exibida num quadro a que toda a gentetem acesso, a comunicação com o patrocinador executivo e com o cliente é feita cara-a-cara, fazendo com que o tempo gasto em burocracia seja convertido em trabalho deinvenção e o foco seja mantido na tarefa que estão a realizar. Alta precisão refere-se a


11/15

demonstrações funcionais, código final, casos de teste, manuais de utilizador ou tex-tos de apoio.

Crystal não foi desenhado para empresas que querem metodologias padronizadas,ou que trabalhem em projetos longos. Foi pensada para organizações que sabem quaissão os seus pontos fortes e fracos, adaptando a Crystal Clear de forma a tomar partidodesses pontos fortes e cobrindo as fraquezas. A Crystal Clear destina-se, em primeirolugar a organizações que querem construir a sua própria metodologia, de maneira a

possibilitar a rápida 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 papéis em Crystal Clear , onde 4 deles terão de ser pessoas diferentes e osoutros 4 podem ser adicionalmente designados às pessoas envolvidas no projeto.Os primeiros quatro papéis são:

Executive Sponsor. É a pessoa que está a alocar ou a defender qual o destino do di-nheiro do projeto. Deverá manter em mente os objetivos a longo prazo, gerindo tam-

bém as prioridades a curto prazo, as entregas, a evolução do sistema e manutenção daequipa. Cabe ao Executive Sponsor tomar decisões a nível dos negócios e criar visibi-lidade para o projeto. Para isso, deverá estar sempre informado do decorrer dos traba-lhos e tomar decisões que sejam relevantes para o avanço dos mesmos.

Ambassador User. É a pessoa que deve estar familiarizado com os procedimentosoperacionais e o sistema em uso. Deve saber quais os modos de operação são maisfrequentemente utilizados, que atalhos são precisos e que informação deverá estarvisível para o sistema poder ser usado. Espera-se que o Ambassador User esteja inti-mamente familiarizado com as atividades dos utilizadores para que o sistema estejaadequadamente adaptado.

Lead Designer. É o líder do trabalho técnico que terá de ter experiência em desen-volvimento de software, terá de estar apto a fazer a arquitetura do sistema, saber se aequipa está no bom caminho e se não estiver, ter a solução para a direcionar no bomcaminho. Deverá ser a pessoa (ou uma das pessoas) mais competente/ fluen-

te/experiente da equipa. Desempenhará também funções de programador, aparte deliderar a “equipa técnica”, se a constituição da equipa assim requerer.

Designer-Programmer. Será a pessoa que irá proceder à implementação do código eantes de o implementar, mais importante que a implementação em si, terá de escrevero sistema em algoritmos pois fazer trabalho de programação exige não só escrever ocódigo como também fazer o design do mesmo.


12/15

Os outros quatro papéis que poderão ser desempenhados pelo resto da equipa, ou

até adicionados às funções anteriores são:

Coordinator. Será a pessoa responsável por tirar apontamentos sobre o planeamentodo projeto e estado do processo, notas essas que serão tornadas públicas no quadrocomum. É um papel que poderá idealmente ser desempenhado pelo Executive Spon-

sor ou Lead Designer , e pode ser rotativo.

Bussiness Expert. Esta pessoa irá responder às questões que a equipa técnica terásobre o núcleo de funcionamento do sistema que estão a desenvolver. Quais a políti-cas envolvidas da área onde o software vai ser usado. O mais usual é ser o Ambassa-dor User a arrecadar esta função, ma poderá ser também qualquer membro da equipaou um especialista externo. De notar que a diferença entre Ambassador User e o Bus-

siness Expert é que o primeiro sabe como o utilizador lida com o sistema e o segundosabe como o negócio lida com o sistema.

Tester. É tarefa do Tester detetar e reportar bugs. O sistema terá de passar primeira-mente pelas mãos desta pessoa antes de chegar aos utilizadores.

Writer. O trabalho do Writer é tratar de escrever textos para ajudar a utilizar o siste-ma, escrever o manual de utilizador e o manual de treino. Mas será a equipa a decidiro 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 vários tamanhos: Desenvolvimen-to, iteração, período de entrega e todo o projeto.[5]

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


13/15

Ciclo do Projeto. Um ciclo de projeto em Crystal Clear tem três partes:

Mapeamento de atividades. Demora alguns dias ou semanas. Durante este tempo irão:○ Construir o núcleo da equipa;○ Fazer o Exploratório 360º;○ Dar forma às convenções 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 emcaso afirmativo, um grupo de pessoas com uma metodologia rascunhada e uma ideiado que vão e estão a fazer.

Um ou dois ciclos de entregas. Que vai ser descrito à frente.

Reflexão sobre o projeto. Refletir sobre o que está a funcionar bem, o que poderiaestar 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 aequipa terá de querer trabalhar junta outra vez. Caso isso aconteça, não só o projetofoi bem-sucedido mas também a metodologia Crystal serviu o seu propósito.

Ciclo de Entrega. Um ciclo de entrega pode ter três ou quatro partes:

Recalibração do plano de Entregas. Na primeira entrega esta recalibração não farásentido, mas após essa entrega e após dado o feedback dos utilizadores, a equipa terá

informação relevante que poderá significar uma revisão aos requisitos e consequentemudança nos planos do projeto.

Séries de uma ou mais iterações. Descritas mais à frente

Entrega a Utilizadores reais. Para que a equipa possa obter informação relevante àcontinuação dos trabalhos.

Reflexão sobre a entrega. Com base no feedback recebido dos utilizadores, discutirsobre que mudanças fazer ao projeto, o que acrescentar, o que manter. De notar quenesta parte irão refletir sobre o produto, e não o processo.

Ciclo de Iteração. No período de iteração a equipa irá

Planear as iterações. Serve para definir as prioridades d equipa para aquela semana.

Realizar as atividades do ciclo de integração. Descritas mais à frente.


14/15

Workshop de Reflexão. Onde deverá ser feita uma reflexão sobre os hábitos de traba-lho, sobre as relações com os outros membros da equipa, o modelo de comunicaçãoem uso, novas técnicas que queiram experimentar, etc.

Ciclo de Integração. Corresponde à integração de pequenos desenvolvimentos do projeto. Requer que toda a equipa saiba o que cada um está a desenvolver para pode-rem integrar a sua parte com a dos outros. É feito também um teste automatizado nofim de cada integração

Desenvolvimento. Na figura representado por “epis.” de episódio. Durante um episó-

dio, uma pessoa trabalha numa pequena tarefa de programação até estar completa e nofim, idealmente, testa-se por processos automatizados. Deverá demorar menos de umdia, dependendo do programador e das convenções do projeto.

5 Conclusões

Crystal Clear é um conjunto de metodologias baseadas em metodologia ágil, focadana gestão das pessoas, onde uma equipa de dois a oito elementos se juntam na mesmasala a trabalhar, fazendo uma comunicação osmótica, as entregas são frequentes, talcomo as reflexões sobre o produto, método de trabalho e convenções 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 direção àsmesmas metas, desenvolvendo pelo caminho confiança no resto da equipa e canais decomunicação que os elementos se sintam totalmente seguros em usar sem medo derepresália. Além de depender das habilidades técnicas dos seus elementos, o sucessodepende também das emoções, personalidade e estado de espirito dos mesmos, sendo

portanto uma metodologia não muito definida e bastante folgada para l idar com esseaspeto. À medida que o projeto vai avançando, a metodologia pode ser redefinida,

bem como os requisitos e a própria equipa. Para um projeto ser considerado bem-sucedido, o produto terá de ser entregue funcional e a equipa terá de estar satisfeitaquer com o resultado final, quer com o processo que foi seguido durante a sua execu-ção.

Devido à sua estrutura pouco padronizada e dependente de uma boa comunicação,

é uma metodologia que não se destina a ser usada em grandes empreendimentos comgrandes equipas, onde possa existir perda de algo mais que não seja conforto em casode falha do sistema.

É uma metodologia que está talhada para ser usada em projetos onde se queirauma entrega rápida, com resultados o mais aproximado possível ao pedido do cliente,que se consegue construindo um bom canal de comunicação entre a equipa e o clientee cortando na burocracia e formalidade.


15/15

Por ser uma metodologia que não usa uma fórmula universal para todos os proje-tos e equipas, e tem de ser dispensado tempo para a planear, as equipas de trabalhonem a chegam a consideram e preferem usar outras metodologias ágeis ou tradicio-nais.

Tem como pontos positivos as entregas serem frequentes que permitem contactoconstante com o cliente; reduz a probabilidade de falha na entrega final; é bastantevolátil, podendo adaptar-se a cada grupo de trabalho e projeto (desde que não muitogrande); utilizando uma linguagem clara, simples e continuada as tarefas estão bemdefinidas e cada um sabe exatamente o que tem de fazer; uma mudança nos requisitosnão significa que o projeto tenha de começar do início; o patrocinador sabe sempreem que fase de projeto a equipa se encontra, podendo mexer na configuração desta ouno processo para que a eficiência seja aumentada.

Os pontos negativos serão o facto de ter tanta sensibilidade à falha humana, poisdepende muito da personalidade de cada elemento e dos seus hábitos de trabalho e a“equipa perfeita” pode nunca ser encontrada; não pode ser aplicada a projetos de largaescala; por não ser bem definida, é uma metodologia pouco usada pelas equipas detrabalho.

Por último, é importante referir que Crystal Clear é uma metodologia que, se apli-cada, tem grandes probabilidades de resultar pois foi criada com base na observaçãode projetos de sucesso.

Referências

1.

Hastie, S., & Wojewoda, S. (n.d.). Standish Group 2015 Chaos Report - Q&A with Jen-nifer Lynch. Retrieved January 28, 2016, from http://www.infoq.com/articles/standish-chaos-2015

2. Filho, H. F. B. P. (2011). Um estudo analítico entre as abordagens de Engenharia de Re-quisitos nas Metodologias Ágeis XP , SCRUM e Crystal. Recife.

3. Cockburn, A. (2004). A Human-Powered Methodology For Small Teams, including TheSeven 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.

Sinésio, Thiago Nunes Homem, Briner Alexandre Correia, Carlos Daniel, A. da S. (2013). Metodologia Crystal Clear (Crystal Clear Methodologies).

metodologias de desenvolvimento Ágil

Documents