Sei sulla pagina 1di 9

FACULDADE DE CIÊNCIAS ADMINISTRATIVAS E DE TECNOLOGIA – FATEC

RAFAEL DE SENA BRITO

FAMÍLIA DE METODOLOGIA CRYSTAL

PORTO VELHO – RO

2011

RAFAEL DE SENA BRITO

FAMÍLIA DE METODOLOGIA CRYSTAL

Trabalho de Processos de Desenvolvimento de Software apresentado a Faculdade de Ciências Administrativas e de Tecnologia – FATEC, para obtenção de nota, sob orientação do Prof.º Haroldo de Lima Arouca.

PORTO VELHO – RO

2011

SUMÁRIO

1 INTRODUÇÃO

4

2 DESENVOLVIMENTO ÁGIL

4

3 FAMÍLIA DE METODOLOGIA CRYSTAL

5

3.1 PROCESSO

6

3.2 PAPÉIS E RESPONSABILIDADE

7

CONCLUSÃO

8

REFERÊNCIAS BIBLIOGRÁFICAS

9

1

INTRODUÇÃO

Abordagens de desenvolvimento ágil de software têm se tornado cada vez mais populares durante os últimos anos. Práticas ágeis têm sido desenvolvidas com o objetivo de entregar software mais rápido e garantir que o software atenda às necessidades dinâmicas dos clientes. Em geral, estas abordagens têm alguns princípios comuns: melhorar a satisfação do cliente, adaptando-se às necessidades das mudanças, muitas vezes fornecendo software de trabalho, e uma estreita colaboração do cliente com os desenvolvedores. Abordagens ágeis são baseadas em iterações curtas, liberando uma nova versão do software a cada 1-3 meses. A família de métodos Crystal foi criada por Cockburn. Nos métodos Crystal, o desenvolvimento de software é visto como um jogo cooperativo de invenção e comunicação, com o principal objetivo de entregar um software útil e funcionando. Dois projetos diferentes devem ser executados de forma diferente. A abordagem Crystal inclui princípios para a adaptação dos métodos em diversas circunstâncias de projetos. Cada método da família Crystal é nomeado com uma cor, que será apropriada para um projeto, baseando-se no seu tamanho e aspecto crítico. Apesar de diferentes, existem regras, valores e características comuns nas metodologias Crystal.

2 DESENVOLVIMENTO ÁGIL

Durante muito tempo as metodologias consideradas pesadas vêm sendo utilizadas para o gerenciamento dos processos de desenvolvimento de software, mesmo com a evolução dos computadores, a maneira de desenvolver software ficou estagnada, nos princípios criados por Winston W. Royce em 1970, denominado modelo cascata. A metodologia ágil é um novo horizonte para a engenharia de software, mostra uma maneira diferente de gerenciar o processo de desenvolvimento. Esta propicia requisitos que aumentam a qualidade, produtividade e a satisfação do cliente que irá receber um produto de acordo com sua real necessidade. Esses métodos tentam diminuir o risco do processo do software, entregando pequenas partes ao usuário final, conhecido como iteração, os quais levam de uma á quatro semanas. Cada iteração é como um pequeno projeto e inclui todos os processos necessários para implantação da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação.

As metodologias ágeis não abdicam os processos e ferramentas, documentação e planejamento, simplesmente expõe que elas estão em segundo plano quando comparado com as pessoas envolvidas e interações.

3 FAMÍLIA DE METODOLOGIA CRYSTAL

A família Crystal de metodologias consiste em um conjunto de metodologias, que

partilham das mesmas bases e práticas, mas que se diferenciam quanto ao seu “peso”. Assim, o aspecto mais importante é o modo de escolher qual a metodologia mais adequada para um projeto.

O autor Alistair Cockburn, famoso metodologista e desenvolvedor desta família de

metodologias, acredita que a metodologia adequada é baseada no tamanho da equipe e nos riscos envolvidos no projeto, e criou então um método para a escolha da metodologia de acordo com a classificação do projeto quanto a estes dados. (Cockburn, 2002).

A classificação da metodologia é dada através de cores. Quanto mais escura a cor,

mais “pesada” a mesma é. A escolha da metodologia apropriada de acordo com o projeto é proposta por Cockburn de acordo com a figura 1.

o projeto é proposta por Cockburn de acordo com a figura 1. Figura 1: A escolha

Figura 1: A escolha da metodologia Crystal Fonte: (Abrahamson et al, 2002).

Esse peso é representado pela quantidade de artefatos e a rigidez da gerência, itens que são absorvidos entre os 13 elementos definidos para cada método: papéis, habilidades, times, técnicas, atividades, processos, artefatos, produtos de trabalho, padrões, ferramentas, personalidades, qualidade e valores da equipe (Highsmith, 2002). Por exemplo, ao observar os

papéis no Crystal Clear, nota-se que existem 6 tipos, enquanto que no Orange existem mais de 14.

Apesar de possuir diversas metodologias, todas possuem diversas características em comum, como, por exemplo, a abordagem iterativa, a ênfase na comunicação e na cooperação entre a equipe (Cockburn, 2002). As metodologias da família Crystal desenvolvidas e utilizadas até hoje são a Crystal Clear e a Crystal Orange.

3.1 PROCESSO

Como visto na classificação anterior, a metodologia Crystal Clear é apropriada para projetos pequenos, de até seis desenvolvedores. Ela é adequada para projetos de baixo risco e os desenvolvedores devem compartilhar a mesma sala, devido às limitações na sua estrutura de comunicação (Cockburn, 2002). Já a Crystal Orange abrange projetos de médio porte, com até 40 colaboradores. Na Orange, os trabalhos são divididos em times multifuncionais diversos e há a criação de artefatos suficientes para a comunicação entre eles. Ambas podem ser utilizadas para projetos um pouco mais críticos que o proposto por Cockburn, com algumas mudanças básicas para evitar alguns dos riscos envolvidos (Abrahamson et al., 2002). Os processos das metodologias Crystal não possuem diferenças drásticas entre si, até por que tanto a Clear quanto a Orange não possuem um processo propriamente dito, apenas atividades, que devem ser executadas em incrementos de um a três meses (podendo chegar a quatro meses na Orange). Isto acontece por que o autor destas metodologias prioriza as pessoas envolvidas e não processos, focando-se apenas nas atividades que devem ser desempenhadas e deixando os ajustes do processo por conta dos envolvidos no mesmo (Fowler, 2003).

Figura 2: Um Incremento na Crystal Orange Fonte: (Abrahamson et al., 2002) Na Crystal Orange

Figura 2: Um Incremento na Crystal Orange Fonte: (Abrahamson et al., 2002)

Na Crystal Orange a etapa em que o Documento de Requisitos é criado é obrigatória, já que é um documento importante para a gerência de vários times. Isto não é tão necessário na Clear, visto que é apropriada para apenas um time trabalhando em um mesmo local. Outras etapas, como Agendamento (Scheduling) e Revisões (Reviews) são mais aprofundadas na Orange, e mais brandas na Clear. As práticas de paralelismo e fluxo, é claro, se aplicam apenas a Crystal Orange, já que na Clear não há múltiplos times, não havendo necessidade de paralelismo nas atividades.

3.2 PAPÉIS E RESPONSABILIDADE

Em uma metodologia baseada em pessoas, invés de processos, os papéis, e suas respectivas responsabilidades, são aspectos muito importantes. Tanto a Crystal Clear quanto a Crystal Orange possuem diversos papéis em comum. É claro que, sendo uma metodologia mais pesada, é natural que a Crystal Orange possua mais papéis. Porém, as diferenças não param por aí: a principal diferença entre estas duas metodologias é o número de times que abrangem. Enquanto a Crystal Clear não possui uma estrutura de comunicação adequada para portar mais de um time, isto não ocorre na Orange, que possibilita, e obriga o uso de diversos times multifuncionais (com profissionais de diversos papéis juntos).

Nas metodologias da família Crystal, uma pessoa pode assumir mais de um papel, acumulando funções. Os principais papéis básicos, necessários para ambas as metodologias são:

Patrocinador: quem financia o projeto;

Usuários: que usam o software desenvolvido;

Programador/Analista Sênior: membro mais experiente em

programação e análise/projeto de sistemas;

Programador/Analista: membro menos experiente, mas capaz de

programar e projetar/analisar um sistema. A Crystal Orange, entretanto, inclui um variado número de papéis a este conjunto, sendo a grande maioria de profissionais mais especializados, como Projetista de Interfaces

com o Usuário, analista de banco de dados, mentor do projeto, arquitetos, analista de requisitos, analista de negócios, entre outros. Entre tantos papéis, são ressaltados dois em (Abrahamson et al., 2002), que merecem um pouco mais de atenção. São eles:

Escritor: Responsável pela produção de documentação externa, como

manual de usuário, por exemplo;

Analista de Negócios: É ele que negocia e se comunica com os usuários

para obter o que deve ser especificado em termos de requisitos e interfaces, e também para revisar o design do projeto. Um time de trabalho na Crystal Orange deve ser composto de no mínimo: Um analista de negócios, um projetista de interfaces com o usuário, dois a três programadores/analistas, um analista de banco de dados e, se possível, um testador (Abrahamson et al., 2002).

CONCLUSÃO

O autor Alistair Cockburn se destaca no mundo acadêmico por seu grande know-how em metodologias e processos de desenvolvimento, e aplicou, como continua aplicando até hoje, todo este conhecimento para desenvolver sua família de metodologias Crystal. Pode-se notar que são metodologias que podem e devem ser ajustadas para se adequar ao projeto, evitando ter que adaptar o projeto à metodologia. Além disto, Cockburn ainda propõe o uso de determinada metodologia para determinado tipo de projeto, dando uma metodologia padrão para cada tipo como ponto de partida. Esta metodologia deve então ser

aplicada ao projeto e, através de reuniões de acompanhamento e revisões, ajustada para o mesmo. Esta ideia dá as metodologias da família Crystal um enorme dinamismo, e uma rápida resposta a mudanças. Porém, exige dos envolvidos no projeto certa experiência no uso de processos e metodologias, pois não há como saber o que deve ser alterado em uma metodologia com clareza sem nenhuma experiência no assunto. Além de tudo isto, a família Crystal é ainda uma família de metodologias em desenvolvimento, o que provoca uma relativa escassez de documentação e pesquisas sobre a mesma, se comparado com metodologias mais conhecidas como o XP e o SCRUM.

REFERÊNCIAS BIBLIOGRÁFICAS

ABRAHAMSSON, Pekka, SALO, Outi, RONKAINEN, Jussi, WARSTA, Juhani. Agile software development methods. Review and analysis. Espoo 2002. VTT Publications.

COCKBURN, Alistair. Agile Software Development: The Cooperative Game. Addison- Wesley: 2002.

FOWLER, Martin, The New Methodology, 2003. Disponível em:

<http://www.martinfowler.com/articles/newMethodology.html>. Acessado em: 27 mai 2011.

HIGHSMITH, J. Retiring Lifecycle Dinosaurs. Software Testing & Quality Engineering 2, n.4, July/August 2000.