BASE, Uma metodologia ágil voltada para pequenos projetos

BASE, Uma metodologia ágil voltada para pequenos projetos Eduardo M. Vasconcelos, Timóteo S. Brasil Universidade de Pernambuco (UPE) Caruaru PE Brazil eduardo.mvasconcelos@gmail.com, timoteo.brasil@gmail.com Abstract. With the each time bigger definition of processes in software development, arose the need of creating a methodology that could include the idea of definite processes in small projects. Starting with this need, we idealized BASE, an agile development methodology focused on small projects and beginners teams in using processes for software development. Resumo. Com a definição cada vez maior dos processos no desenvolvimento dos softwares, surgiu a necessidade da criação de uma metodologia que possa incluir a idéia de processos definidos em pequenos projetos. Foi a partir desta necessidade que idealizamos o BASE, uma metodologia de desenvolvimento ágil voltada para os pequenos projetos e para equipes que estejam iniciando no uso de processos para o desenvolvimento de softwares. 1. Introdução Com a criação dos computadores, e sua utilização cada vez maior, tanto por usuários comuns que têm apenas o objetivo de se entreterem, como por empresas que precisam cada vez mais de informações para se manterem no extremamente competitivo mercado atual, a produção de software tem se tornado essencial para a evolução dos negócios e se tornado um negócio extremamente lucrativo. Com o passar do tempo, as tecnologias dos computadores se tornaram extremamente complexas, exigindo que os softwares evoluíssem acompanhando estas mudanças tecnológicas. Porém, com as novas exigências do mercado e com as novas tecnologias emergindo de forma acelerada, a produção de software e sistemas se tornou muito complicada, exigindo que técnicas fossem desenvolvidas para melhorar a produção de softwares. A necessidade de encontrar métodos que pudessem ajudar na evolução do processo de construção de software, culminou com o desenvolvimento da Engenharia de Software, tornando os softwares mais voltados para seu escopo, e livre de vários erros. Essa nova abordagem ao processo de construção de software trouxe métodos e técnicas que ajudaram a administrar a complexidade inerente do software. Porém, um dos grandes problemas com a engenharia de software, está nas técnicas pesadas e caras desenvolvidas e empregadas pela maioria das empresas de desenvolvimento de software. As metodologias ágeis para desenvolvimento de software são uma resposta a essas metodologias tradicionais, que são mais pesadas. Mesmo com a evolução dos computadores, das técnicas e ferramentas nos últimos anos, a produção de software confiável, correto e entregue dentro dos prazos e custos estipulados ainda é muito difícil. As metodologias de desenvolvimento tradicionais são muito criticadas no mundo dos desenvolvedores ágeis, pelo fato de serem pesadas e muito burocráticas, é a esse contexto que as metodologias ágeis se opõem. Eles propõem uma nova abordagem de

desenvolvimento, eliminando gastos com documentação excessiva e burocrática, enfatizando a interação entre as pessoas e nas atividades que efetivamente trazem valor e produzem software com Qualidade. Neste contexto alguns processos são definidos para permitir uma maior interação e um desenvolvimento mais ágil na produção de software, dentre estes processos destacam-se: O processo Extreme Programming (XP) está entre os denominados processos ágeis (HIGHSMITH, 2002), que vai contra uma série de premissas adotadas por métodos mais tradicionais de desenvolvimento. XP consiste numa série de práticas e regras que permitem aos programadores desenvolver software de uma forma dinâmica e ágil, com mínimo de documentação; O Scrum se concentra mais nos aspectos gerenciais do desenvolvimento de software, propondo iterações de duas semanas ou 30 dias (chamados Sprints) com acompanhamento diário por meio das Reuniões em Pé (ou stand-up meetings). Por dar menos ênfase aos aspectos técnicos, é geralmente combinada com práticas propostas por XP e compatível com certificações de qualidade como CMMI ou ISO 9001. O objetivo principal deste trabalho é fazer uma análise destas metodologias de desenvolvimento com o objetivo de se entender a base do desenvolvimento ágil, e idealizar uma metodologia extremamente simples, capaz de se adaptar a qualquer projeto permitindo que qualquer equipe sem conhecimento algum em engenharia de software possa entender de forma fácil as regras básicas do desenvolvimento de software, e, a partir deste entendimento, possa de forma mais fácil partir para outras metodologias sem ter que perder muito tempo para entendê-las. Este trabalho também tem a finalidade de idealizar uma metodologia flexível e voltada tanto para projetos extremamente pequenos, tanto para projetos de grande porte. 2. Processos de software e Metodologia de desenvolvimento ágil O desenvolvimento de software é composto por uma variedade de processos que estão atrelados às metodologias de desenvolvimento, a estes processos é dada a denominação de Processos de Software. Muito do que será investigado neste trabalho diz respeito a estes Processos de Software, e para defini-lo, cabe alguma discussão. Existe alguma sobreposição em relação aos termos Processo, Modelo, Método e Metodologia, gerando confusão em algumas circunstâncias. Embora não sejam sinônimos, é comum observar na literatura o uso de um termo em lugar do outro. Assim, é necessário buscar definições para fundamentar o objetivo deste trabalho, que envolve o entendimento de um processo para software. O Processo de Software é definido por Sommerville (1995) como: O processo é um conjunto de atividades e resultados associados que produzem um produto de software. Pressman (1997), oferece a seguinte definição:...definimos um processo de software como um framework para as tarefas que são necessárias para a construção de software de alta qualidade. Estas definições oferecem uma idéia mais clara do que é considerado um processo. Ou seja, a partir destas definições é possível se concluir que:

O processo reúne um conjunto de atividades. Como existem atividades que englobam outras atividades, faz com que o processo assuma uma forma hierárquica com atividades contendo sub-atividades; O processo tem como objetivo desenvolver um produto de software. Todas as atividades realizadas dentro de um cronograma tem por objetivo principal um produto de software. Estas atividades visam a construção de um produto de software de qualidade entregue dentro do prazo estabelecido e sem estourar custo orçado para seu desenvolvimento. O processo direciona as tarefas individuais e do time como um todo. O nível de detalhamento de cada processo depende da equipe envolvida no desenvolvimento do software. Não há processo correto ou incorreto; dependendo da sua aplicação, ambiente e objetivo, um processo específico pode ser vantajoso ou não. 2.1. As Fases existentes no processo de software Pela definição, podemos entender o que é o processo que existem atividades e sub atividades atrelados a estes processos; no entanto, torna-se importante conhecer quais as fases que o compõe: Especificação de Requisitos: são as traduções das necessidades ou requisitos operacionais para uma descrição da funcionalidade a ser executada; Projeto de Sistema: tradução destes requisitos em uma descrição de todos os componentes necessários para codificar o sistema; Programação (codificação): produção do código que controla o sistema e realiza a computação e lógica envolvida; Verificação e Integração (checkout): verificação da satisfação dos requisitos iniciais pelo produto produzido. Evolução (manutenção): alteração do software para atender a novas necessidades do usuário. As fases do software são importantes para o total entendimento do processo de software como um todo, de como a organização dessas fases pode ser de grande ajuda para a construção do produto de software, e que a sua implementação é de essencial importância para o seu desenvolvimento. Porém, estas fases do sistema não são obrigatórias na construção do produto de software, outras fases podem ser acrescentadas dependendo da exigência do projeto, permitindo maior domínio do projeto por parte da equipe desenvolvedora. 2.2. Metodologias de Desenvolvimento Ágeis Fowler (2001) coloca que as metodologias modernas de desenvolvimento, como Extreme Programming (XP) e SCRUM, são uma reação a modelos extremamente conceituais e a metodologias monumentais. Segundo ele, a burocracia existente, nas metodologias tradicionais, e a necessidade de produzir uma quantidade enorme de documentos diminui a velocidade de desenvolvimento do produto, enquanto as metodologias de desenvolvimento ágil tendem a manter um compromisso útil entre nenhum processo e processo demasiado, provendo apenas processo suficiente para fornecer uma vantagem razoável na produção de software.

Esta idéia é muito importante para o entendimento exato do significado da metodologia ágil, que deve ser direta e eficiente para propor a construção de um produto de qualidade feito sem desperdício de esforços, e que as discussões envolvendo estas metodologias mostra a importância em se considerar o desenvolvimento ágil como uma realidade no desenvolvimento de produtos de software. 3. XP (Extreme Programming) XP (Programação Extrema) é um método ágil que tem evoluído dos problemas causados pelos longos ciclos de desenvolvimento dos modelos tradicionais de desenvolvimento. Segundo (Beck, 2000), Extreme Programming (XP) é uma metodologia leve, eficiente, flexível e de baixo risco para times pequenos e médios, que desenvolvem software com requisitos dinâmicos ou em constante mudança. XP é uma metodologia ágil, para o desenvolvimento de projetos de softwares cujas especificações são passíveis a alterações. As iterações do XP costumam ser curtas, provendo constantes versões do produto (releases) para o cliente, que por sua vez provê comentários e opiniões que realimentam a próxima iteração. O objetivo do XP é tornar o projeto flexível, diminuindo o custo a possíveis mudanças. O código produzido é tomado como indicador de progresso do projeto. O ciclo do XP é dividido em seis fases: 1) Exploração: nessa fase o cliente escreve cartões de estórias, cada um contendo uma funcionalidade desejada para o primeiro release. 2) Planejamento: ocorre definição de prioridades entre as estórias junto com o cliente. Nesta etapa os programadores estimam o esforço e o cronograma para cada uma das estórias. 3) Iterações para Release: nessa fase ocorrem diversas iterações até o primeiro release ser completado. Na primeira iteração é criado o sistema com toda a arquitetura, nas iterações seguintes serão adicionadas às funcionalidades de acordo com as prioridades estabelecidas. 4) Validação para Produção (Productionizing): nessa fase são feitos testes extensivos e verificações para validação do software para ser utilizado em ambientes de produção. 5) Manutenção: após o primeiro release para produção, há novas edições do sistema com novas funcionalidades. 6) Morte: quando não há mais estórias a serem implementadas, quando o cliente está satisfeito com o código. O XP também é conhecido pela existência de 12 práticas que guiam o processo de desenvolvimento do projetos: Jogo de planejamento, pequenas versões, metáforas, projeto simples, teste, refactoring, programação em pares, propriedade coletiva, integração contínua, semana de 40 horas, cliente dedicado, e código padrão. 3.1. Considerações Embora existam muitos pontos positivos e negativos no XP a serem analisados, é dado um destaque maior à Comunicação e à simplicidade, pois todos os outros pontos podem ser considerados tanto como positivos como negativos, tais como a jornada de 40 horas semanais que, ao mesmo tempo que permite que desenvolvedores possam ter um

descanso apropriado, pode inibir a genialidade contínua destes. Assim podemos entender que alguns pontos podem ser considerados como opcionais para o objetivo principal deste trabalho. 4. Scrum O Scrum foi desenvolvido para gerenciar o processo de desenvolvimento de software em ambientes em que os requisitos estão em constante mudança. Ele é apropriado para equipes pequenas, com até dez integrantes. (Abrahamsson et al., 2002). O Scrum não exige ou fornece métodos ou práticas específicas de desenvolvimento de software, mas exige certas práticas de gerenciamento, que são descritas por Abrahamsson et al. (2002): Tarefas do Produto (Product Backlog): define tudo o que é necessário no produto final. Contém uma lista priorizada e constantemente atualizada dos requisitos do sistema que está sendo construído ou otimiza. Estimativa de esforço (Effort Estimation): como o Scrum é um processo iterativo a estimativa de esforço para realizar as tarefas deve ser realizada frequentemente. Sprint: procedimento de adaptação às mudanças de variáveis de ambiente, como requisitos, tempo, recursos ou tecnologia. Sprints são intervalos fixos de tempo, em que todo o trabalho é realizado. No Scrum um sprint tem duração de trinta dias. Durante um sprint a equipe Scrum se organiza para produzir um incremento do produto. Essa prática contém: reuniões de planejamento dos sprints (Sprint Planning Meetings), para decidir os objetivos e funcionalidades do próximo sprint; Tarefas do Sprint (Sprint Backlog), que é uma lista de itens de trabalho de produto selecionados para o próximo sprint; Reuniões Scrum diárias (Daily Scrum Meetings), de aproximadamente quinze minutos realizadas para verificar o progresso do projeto e para discutir questões como: o que foi feito desde a última reunião e o que precisa ser feito até a próxima. Reunião de Revisão de Sprint (Sprint Review Meeting): no último dia do sprint, os resultados são apresentados. Segundo Abrahamsson (2002) os papéis identificados no Scrum são: Mestre (Scrum Master), Proprietário do produto (Product Owner), Equipe Scrum (Scrum Team), Cliente (Customer) e Gerência (Management). 4.1. Considerações O Scrum é uma metodologia prática e eficiente, que tem como princípio o de auxiliar equipes que se aventuram em projetos em que os requisitos estão em constante mudança. A definição desta metodologia mostra que a simplicidade de projeto é muito importante para a obtenção da qualidade, principalmente por ser uma metodologia voltada para pequenas equipes. 5. BASE Como foi visto no decorrer deste trabalho, as metodologias ágeis foram desenvolvidas com o intuito de tornar o processo de desenvolvimento mais simples e rápido, eliminando a famosa burocracia das metodologias tradicionais e garantindo qualidade

no desenvolvimento de softwares. A principal crítica às metodologias antigas é a necessidade de construção de uma longa e exaustiva documentação, prendendo o desenvolvimento do projeto à escrita destes documentos, o que para um projeto pequeno com uma equipe pequena não faz muito sentido. As técnicas apresentadas neste trabalho são sem dúvida nenhuma fortes, e não é a toa que elas são largamente utilizadas no mercado, porém, embora sejam técnicas já usadas e aprovadas pelo mercado, são difíceis de serem entendidas e de serem aplicadas por marinheiros de primeira viagem. Por isso, a idéia de se fazer uma metodologia fácil de ser aplicada e entendida por qualquer equipe de desenvolvimento, é essencial para a maturidade de processos desta equipe. A idéia inicial é criar uma metodologia o mais simples possível, capaz de se enquadrar ao projeto mais simples de forma a auxiliar no desenvolvimento e torná-lo mais robusto e fácil de ser implementado. A esta metodologia dá-se o nome da BASE, pois ela tem como principal meta se tornar uma base tanto para o meio acadêmico, como para o desenvolvimento dos diversos métodos ágeis. 5.1. O que é o BASE? BASE é uma metodologia de desenvolvimento ágil, baseado em diversas outras metodologias, e projetado para ser o mais simples método de desenvolvimento existente, capaz de auxiliar equipes de no máximo 5 pessoas em projetos muito pequenos, com o propósito de tornar o projeto mais rápido e de qualidade. O BASE é um conjunto pequeno de processos recomendados que permitem a equipes de desenvolvimento implementar pequenos projetos de forma mais ágil e segura, e assegurar que a manutenção deste produto ou as versões dele possam ser mais facilmente realizadas sem a necessidade de uma longa documentação. O BASE também tem a finalidade de ser de fácil entendimento, ou seja, qualquer pessoa que tenha o mínimo de conhecimento em desenvolvimento de software, seja capaz de ler as suas especificações uma vez, entender e colocar os seus processos em prática, de forma a obter um produto com maior qualidade do que o produto que seria feito sem utilização deste método. No BASE, não se falam em regras, pois o BASE tem a finalidade de ser um método democrático, ou seja, ele permite que a equipe indique o que ela quer fazer, em vez de regras, o BASE aconselha o uso de algumas práticas e processos, que permitem que o desenvolvedor entenda de forma melhor a real finalidade do produto. Na área acadêmica, o BASE é idealizado para ser uma metodologia de introdução aos métodos de desenvolvimento de software. Por ser de fácil aprendizado e assimilação, o BASE seria ideal para que alunos que ainda não pagaram cadeiras de engenharia de software, possam entender o valor de se planejar o desenvolvimento de software, e possam ser introduzidos nesta cadeira mais facilmente. O BASE é um método compreendido por algumas definições, processos e especificações. 5.2. Os quatro pilares do BASE Toda metodologia de desenvolvimento deve ser apoiada em algumas especificações que lhe permitem ter uma direção contínua e constante. No BASE, estas especificações são chamadas de Pilares, pois são os métodos principais para a organização e a condição de qualquer projeto. Sem estas especificações, o projeto poderia balançar e tornar o

produto resultante inseguro ou fora da sua finalidade principal. Por isso a necessidade de definir algumas especificações básicas é tão importante. 5.2.1. Primeiro Pilar: Comunicação Em todo projeto, deve-se haver muita comunicação entre as partes; a comunicação é essencial para que a equipe identifique a existência de problemas, o mal andamento do projeto, a existência de conflitos, e muitos outros problemas normalmente encontrados nos projetos. A comunicação também permite que soluções sejam melhor refinadas dentro da equipe, é por ela se pode definir quais requisitos são essenciais, quais não foram descobertos, e que alguns requisitos que estão sendo implementados e não são necessários para o produto final, e requisitos que devem ser colocados em segundo plano. Muitas vantagens são atribuídas a uma boa comunicação interna e externa dentro de uma equipe. Estas vantagens são cruciais para a excelência do projeto, e a quebra deste pilar pode levar um projeto simples a ficar tão complicado e cheio de falhas, que o projeto pode finalizar antes sem a entrega do produto final, principalmente quando a equipe é iniciante em desenvolvimento. Comunicação interna: todo tipo de comunicação feita da equipe para ela mesma, para os clientes e todas as pessoas envolvidas no projeto. Esta comunicação pode ser em forma de troca de conhecimento, de códigos, de especificações, e até mesmo nos comentários em códigos. Comunicação externa: toda e qualquer comunicação feita pela equipe para entidades não participantes do projeto, como pesquisas, fóruns, referências etc. 5.2.2. Segundo Pilar: Simplicidade de projeto e Documentação Para que o decorrer do projeto seja ágil, é necessário que ele seja simplificado, principalmente em se tratando de projetos pequenos. Uma metodologia ágil deve ajudar no desenvolvimento de um projeto, de forma a torná-lo mais fácil de ser implementado e ter mais qualidade; se for complexo demais, e existirem muitas formalizações desnecessárias a serem implementadas, o tempo pode crescer de forma considerável, o que pode levar as equipes pequenas a se confundirem com o objetivo principal, tornando assim o que era pequeno em um projeto inviável e sem qualidade. A principal finalidade deste Pilar, é tornar o projeto fácil de ser implementado, conciso e coerente com os requisitos a que ele atende. Para que o projeto seja simples, é necessário que a documentação seja pequena e sem rodeios. Documentação é necessário em qualquer projeto, pois sem documentação não é possível se registrar as características do projeto, nem se manter o controle sobre o seu andamento. Por isso a necessidade de se escrever documentos simples e objetivos, em poucas páginas e sem rodeios, sem frases ou palavras que não façam parte das especificações do projeto. Se o documento ficar complicado demais, grande e cansativo de ler, o objetivo principal do documento, que deveria ser descrever as características do projeto e suas especificações, passa a ser uma tortura para os seus participantes. 5.2.3. Terceiro Pilar: Planejamento Em todo projeto deve-se haver planejamento. Sem ele, não é permitido à equipe definir as metas a serem atingidas pelo projeto. Se não houver planejamento não há sentido em se usar uma metodologia de desenvolvimento, a única utilidade em se usar uma técnica para o desenvolvimento de software está em permitir que a equipe planeje

categoricamente os rumos e os objetivos a serem alcançados pelo projeto. Na verdade, o BASE é uma técnica que permite que equipes de iniciantes entendam que planejar é extremamente necessário, e que em projetos maiores, a falta de planejamento pode levar à morte precoce do projeto. Mesmo em projetos pequenos, o não planejamento pode levar à entrega do produto num prazo maior do que ele normalmente seria se fosse corretamente planejado, e certamente, o produto entregue será de má qualidade, pois o não planejamento sem dúvida nenhuma leva aos desenvolvedores uma grande produção de gambiarra no código, ou seja, os famosos POGs, diminuindo assim a confiabilidade do produto e da equipe desenvolvedora. O planejamento pode ser feito da seguinte forma: desenvolver uma política de obtenção de requisitos de forma a atender as necessidades a qual este projeto é direcionado, desenvolver as técnicas, definir as ferramentas a serem utilizadas, os cronogramas, e os procedimentos a serem seguidos. Todas estas especificações podem ser implementadas de forma a atender as necessidades do projeto, e as formas como elas são seguidas dependem muito da maturidade da equipe, equipes com mais experiência podem desenvolver formas diferentes de planejar com base em experiências vividas. 5.2.4. Quarto Pilar: Trabalho Contínuo O Trabalho constante e contínuo da equipe é de muita importância no desenrolar do projeto, é necessário que a equipe respeite aos cronogramas criados no projeto. O trabalho deve ser contínuo, pois permite que a equipe esteja sempre envolvida com o projeto, e se possível for, seria ideal que as pessoas envolvidas no projeto, trabalhassem todos os dias, exceto sábados domingos e feriados. Estas medidas são importantes por fazer com que a equipe esteja constantemente interessadas no projeto, pois longos períodos de tempo longe do projeto podem causar efeitos devastadores no desenvolvimento. Alguns efeitos que podem ser citados podem ser os seguintes: Esquecimento ou enfraquecimento do conhecimento acerca do projeto; Diminuição do interesse do participante pelo projeto; Queda de rendimento da equipe; Desinteresse do restante da equipe. Trabalho contínuo não deve ser confundido com excesso de trabalho, o cronograma deve permitir que as pessoas envolvidas no projeto tenham envolvimento constante sem trabalharem exageradamente, deve-se permitir que as pessoas trabalhem pelo menos uma hora por dia, ou devem ser feitas políticas que se adequem bem as necessidades do projeto e de seus participantes. 5.2.5. Considerações sobre os pilares Os Pilares foram idealizados de forma a permitir o bom andamento do projeto. Estes poderiam ser entendidos como uma base concreta para qualquer projeto, ou seja, em teoria qualquer projeto poderia ser bem conduzido se pudesse manter estes Pilares fortes e sólidos. A idéia envolvida na construção dos Pilares não é a de obrigar os participantes do projeto a seguirem exatamente as suas especificações, e sim a de aconselhar aos participantes que o uso destes pilares podem tornar o projeto mais simples de ser implementado e como conseqüência diminuir o seu tempo de desenvolvimento.

Como cada projeto tem suas características e particularidades, é permitido que alguns pilares sejam fortalecidos ou enfraquecidos. Como um exemplo de como estas alterações poderiam acontecer, imaginemos um projeto pequeno, com apenas uma pessoa na equipe, em que ele é o próprio cliente. Este projeto certamente teria o 1 Pilar enfraquecido, uma forma natural de enfraquecimento; outra situação completamente diferente seria um projeto onde os requisitos são extremamente variáveis, neste contexto o 1 Pilar deveria ser fortalecido para permitir que estes requisitos e suas frequentes alterações fossem detectados o mais rápido possível. A única coisa que não é aconselhável no planejamento do projeto, seria a quebra de alguns destes Pilares. 5.3. Processos No BASE, entende-se por processos, todas as definições e passos necessários para que o projeto possa ter um rumo, ou uma direção. Para o BASE, somente dois processos são realmente importantes, a obtenção de requisitos e a definição do projeto. A definição destes dois processos deve ser bem especificada para permitir que iniciantes adquiram uma base de como podem ser realizados estes processos, permitindo assim que com as experiências adquiridas eles possam melhorar nestes processos e até mesmo definir outras formas de fazer estes processos. 5.3.1. Obtenção de Requisitos Sem dúvida nenhuma, a obtenção de requisitos é a mais importante etapa do processo de desenvolvimento de software. Poderíamos ate nos atrever a dizer que um projeto pode ser conduzido sem a definição de um projeto, porém seria impossível ao projeto ser conduzido sem que nenhum requisito fosse especificado. Os requisitos são a alma do projeto, são eles que ditam o rumo e o sentido do projeto, por isso é importante que haja uma boa política de obtenção de requisitos; economizar tempo nesta fase pode ser um erro sem precedentes, o tempo economizado será futuramente perdido, na proporção da importância dos requisitos não detectados no inicio do projeto. 5.3.1.1. Técnicas de obtenção de requisitos Muitas metodologias ágeis pregam formas diferentes de obtenção de requisitos, porém como o BASE tem por objetivo o de ser simples e de simples aprendizado, ele deve empregar métodos fáceis e eficazes baseados na intensa comunicação entre as partes. Por mais simples que uma metodologia possa ser, ela não pode ser displicente na hora de guiar uma equipe na obtenção dos requisitos, por isso, as técnicas de obtenção de requisitos tem que ser de simples implantação e eficientes o suficiente para que pelo menos os requisitos mais importantes sejam percebidos de inicio. É nessa hora que o Pilar da comunicação é mais importante, é necessário que existam conversas entre a equipe e o cliente, permitindo que todos os principais requisitos sejam reconhecidos. é recomendável que este processo dure alguns dias seguidos, e dependendo da dimensão do projeto estes dias podem se tornar semanas. Mesmo as conversas quase nunca são o suficiente para a obtenção dos requisitos, pois, quase nunca os cliente sabem o que querem; é nessa hora que existe a importância da equipe estar diretamente envolvida com o cliente, se for possível é recomendado que toda a equipe tente se tornar o seu cliente, ou seja, participe da vida do cliente, veja ele exercendo a sua profissão, acompanhe todos os processos exercidos pelo cliente. Esta visão pode dar a equipe algumas visões que o próprio cliente pode não perceber por estar acostumado demais com sua rotina.

Gestos simples assim podem ser de grande significado para o decorrer do projeto, permitindo que a qualidade do produto seja incrementada e que haja uma geração de valor do produto por parte do cliente. Outras formas de obtenção de requisitos podem se acrescidas ao projeto tais como, pesquisas em outros produtos existentes, podem ser usadas outros métodos de outras técnicas, etc. 5.3.1.2. Documentação de requisitos A documentação dos requisitos deve ser simples, porém deve haver a definição de todos os requisitos existentes. A escrita deste documento deve ser de fácil entendimento, de tal forma que se outra equipe pegar estas especificações possa, da mesma forma, criar um produto de semelhante qualidade. Não devem existir padrões de escrita de documento, pois a equipe deve decidir qual o formato que melhor lhe auxilie, porém a utilização de padrões é perfeitamente aceitável, desde que siga a premissa de que o documento deve ser o mais simplificado possível e sem rodeios, pois qualquer confusão causada por algum integrante da equipe quanto aos requisitos pode causar uma quebra na total qualidade do produto. 5.3.2. Definição do Projeto A única coisa que o BASE prega em relação ao projeto é que ele seja simplificado. Uma vez que os requisitos já estão bem definidos e devidamente documentados, a necessidade agora é dar a devida ordem ao andamento do projeto. O BASE não especifica nenhuma regra de processo, mas incentiva os participantes do projeto a criarem as suas regras para que com elas eles possam reger o seu andamento. Estas regras podem ser vistas como uma forma de manter o projeto organizado e seguindo uma certa estrutura. Para melhor entendermos como estas regras funcionam podemos citá-las da seguinte forma: A equipe pode decidir que o produto será entregue em versões, onde são englobados alguns grupos de requisitos a serem implementados, e fazerem o produto de forma incremental; A equipe pode definir regras de trabalho como cronogramas e ferramentas que devem ser utilizadas. Na parte dos cronogramas a equipe pode decidir se o trabalho será especificado por intervalos de horas por dias, ou por intervalo de dias para a entrega de uma parte dos requisitos, ou a equipe ainda pode ditar a melhor forma de criarem seus cronogramas; A equipe pode definir o status de cada participante do projeto delegando algumas responsabilidades para alguns participantes; A equipe pode definir quais documentos são essenciais para o projeto e quais devem ser escritos ou não têm muita importância. Não devemos nos esquecer que cada projeto tem suas características bem definidas, por isso o BASE não possui regras, principalmente pelo fato de ser idealizado para pequenos projetos, onde regras demais podem levar a confusão da equipe, e equipes iniciantes podem se confundir afogados em um monte de regras. Quanto as definições dos cargos da equipe, o BASE prega que só exista um cargo bem definido, ou seja, apenas o papel do gerente deve ser definido como padrão; os outros cargos ficam à disposição da equipe nomear. Esta visão é importante para o desenvolvimento do projeto pois permite que responsabilidades sejam delegadas a alguém.

5.4. Definições do BASE Para que seja bem entendido, são dadas algumas definições que permitem a qualquer desenvolvedor entender o exato significado do BASE. Estas definições são importantes para que equipes que estejam implementando a construção do software com o BASE, não saiam do foco principal da metodologia. Por isso, estas definições têm nomes e especificações bem definidas para permitir o direto compreendimento do BASE. 5.4.1. Fio de Seda O BASE pode ser considerado uma metodologia fio de seda pelo fato de ser projetado para ser extremamente flexível. No BASE não há regras, o que permite que os desenvolvedores tenham total controle sobre o projeto. As únicas coisas que o BASE faz é dar algumas sugestões de como o processo de desenvolvimento do projeto pode ser facilitado, pois estes processos foram baseados em pesquisas e suas definições são o resultado deste processo. Esta flexibilidade permite que equipes com mais experiência possam definir os seus rumos, e também permite que esta metodologia possa ser empregada em projetos maiores, permitindo que a equipe se desprenda das metodologias tradicionais e adaptem o BASE para suas necessidades. 5.4.2. Folha em Branco A definição de folha em branco deve existir pelo fato da idealização inicial do BASE ser exatamente esta, uma metodologia tão simples que pode ser encarada como a ausência de uma metodologia. Essa definição é importante para que desenvolvedores não se prendam aos conceitos, e sim às suas necessidades, por exemplo: podem existir projetos em que não haverá a necessidade de dos 4 Pilares, e os desenvolvedores podem ajustar estes Pilares da melhor forma possível; outro exemplo seria o de um desenvolvedor que simplesmente quer usar apenas 1 Pilar. O BASE assume que cada equipe é responsável pelo seu projeto, por isso ela tem o direito de fazer o que ela quiser da forma que ela quiser. Esta definição também é importante, pois permite que se tenha uma visão mais ampla do BASE, na verdade o BASE é uma folha em branco, onde são postos os Pilares que dão sustentação ao projeto. Sobre estes Pilares é colocada uma plataforma onde são colocados todos os processos; se estes Pilares simplesmente não existirem, onde o projeto poderá se apoiar? Porém como já foi dito, toda equipe é responsável pelo seu projeto, assim a equipe terá total responsabilidade com as conseqüências da construção da metodologia. 5.5. Considerações Embora o BASE seja uma metodologia muito simples e fácil de se aprender, ela pode se tornar uma bomba em projetos grandes, isso pode acontecer simplesmente pelo fato de o BASE em sua forma pura ser voltada para projetos pequenos e para a maturidade dos desenvolvedores em projetos. O BASE deveria ser implantado em projetos pequenos de faculdade ou em projetos domésticos, ou até mesmo em projetos feitos por equipes de desenvolvimento desorganizadas, que não conhecem nem um pouco os conceitos de engenharia de software. 6. Conclusão O BASE é uma metodologia de desenvolvimento ágil que permite com que equipes pequenas e sem experiência no uso de processos no desenvolvimento de softwares,

possam organizar de uma melhor forma e mais facilmente, o desenvolvimento de seus projetos. Isto permite a estas equipes ganharem maturidade no uso dos processos, e com esta maturidade estas equipes podem avançar para outras metodologias, ou simplesmente evoluir seus processos e dar continuidade com o uso do BASE para o desenvolvimento de seus processos. O BASE é uma metodologia idealizada para ser flexível, fácil de ser implementada e entendida, além de oferecer a possibilidade de estender os conhecimentos e ser compatível com o tamanho do projeto, podendo, inclusive, crescer junto com o projeto e a equipe. Devemos ter em mente que o BASE, em sua forma original, foi idealizado para projetos pequenos, que poderiam ser feitos sem a ajuda de nenhuma metodologia, e que, em projetos maiores, poderá ser perigoso se for implantado de forma irresponsável. Para se enquadrar a projetos maiores, o BASE pode ser combinado com outras metodologias ou, dependendo da experiência da equipe, podem ser desenvolvidos outros métodos que melhor se adequem às necessidades do projeto. Referências Boulic, R. and Renault, O. (1991) 3D Hierarchies for Animation, In: New Trends in Animation and Visualization, Edited by Nadia Magnenat-Thalmann and Daniel Thalmann, John Wiley & Sons ltd., England. Dyer, S., Martin, J. and Zulauf, J. (1995) Motion Capture White Paper, http://reality.sgi.com/employees/jam_sb/mocap/mocapwp_v2.0.html, December. Holton, M. and Alexander, S. (1995) Soft Cellular Modeling: A Technique for the Simulation of Non-rigid Materials, Computer Graphics: Developments in Virtual Environments, R. A. Earnshaw and J. A. Vince, England, Academic Press Ltd., p. 449-460. Knuth, D. E. (1984), The TeXbook, Addison Wesley, 15 th edition. Smith, A. and Jones, B. (1999). On the complexity of computing. In Advances in Computer Science, pages 555 566. Publishing Press.