Metodologias ágeis
Diversas metodologias foram criadas para sistematizar o desenvolvimento de software. Essas metodologias podem ser divididas em tradicionais, que enfatizam a documentação de cada passo do desenvolvimento do software, ou ágeis, conside radas um paradigma novo de desenvolvimento de software. As metodologias ágeis prometem melhorias na produção de software e em sua qualidade.
Uma metodologia de desenvolvimento de software é um conjunto de atividades que, auxiliam a produção de software. O resultado dessas atividades é um produto que reflete a forma como todo o processo foi conduzido. Embora tenham sido criada várias metodologias para o desenvolvimento de software, existem atividades fundamentais comuns a todas elas.
Metodologias tradicionais
As metodologias tradicionais são também chamadas de pesadas ou orientadas a documentação. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado em mainframes e terminais burros [Royce, 1970]. Na época, o custo de fazer alterações e correções era muito alto, uma vez que o acesso aos computadores era limitado e não existiam ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Em razão disso, o software era todo planejado e documentado antes de ser implementado. A principal metodologia tradicional, muito utilizada até hoje, é o modelo clássico.
Metodologias ágeis
As metodologias ágeis são adequadas para situações em que a mudança de requi sitos é freqüente. Para ser realmente considerada ágil, a metodologia deve aceitar a mudança em vez de tentar prever o futuro.Pode-se traçar uma comparação esquemática entre as metodologias clássicas e ágeis por meio da Figura abaixo, onde se analisa a relação entre custo de mudança e a fase em que esta ocorre. A linha pontilhada representa essa relação para uma metodologia clássica, enquanto a linha contínua mostra como se espera que a relação melhore nas metodologias ágeis.
O termo metodologias ágeis tornou-se popular em 2001, quando 17 especialistas em processos de desenvolvimento de software, representando os métodos Extreme Programming (XP), Scrum, DSDM, Crystal, entre outros, estabeleceram princípios
_______ Metodologias ágeis ---Metodologias clássicas Custos das Mudanças
Comparação do custo de mudanças entre metodologias clássicase ágeis.
comuns compartilhados por todos esses métodos. O resultado foi a criação da Aliança Ágil e o estabelecimento do Manifesto Ágil [Beck et al., 2001]. Enquanto as metodologias ágeis variam em termos de práticas e ênfases, compartilham algu mas características como desenvolvimento iterativo e incremental, comunicação e redução de produtos intermediários, como documentação extensiva.
Os conceitos-chave do Manifesto Ágil são:
• indivíduos e interações em vez de processos e ferramentas; • software executável em vez de documentação;
• colaboração do cliente ao invés de negociação de contratos; • Respostas rápidas a mudanças em vez de seguir planos.
O Manifesto Ágil não rejeita processos e ferramentas, documentação, negociação de contratos nem planejamento, mas simplesmente mostra que estes têm importância secundária quando comparados com os indivíduos, com o software executável, com a colaboração dos clientes e as respostas rápidas às mudanças. Esses conceitos aproximam-se melhor da forma como as pequenas e médias empresas trabalham e respondem às mudanças.
Dentre as várias metodologias ágeis existentes, as mais conhecidas são a Extreme Programming [Beck,1999] e a Scrum [Schwaber e Beedle, 2002].
Extreme Programming
A Extreme Programming (XP) é uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que são modificados rapidamente. Entre as principais diferenças da XP em relação às demais metodologias estão:
• feedback constante; • abordagem incremental;
• a comunicação entre as pessoas é encorajada.
A maioria das práticas da XP causa polêmica à primeira vista e muitas não fazem sentido se aplicadas isoladamente. É a sinergia de seu conjunto que sustenta o sucesso de XP, encabeçando, segundo seus criadores, uma verdadeira revolução no desenvolvimento de software.
A XP enfatiza o desenvolvimento rápido do projeto e visa a garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas. As práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem.
A finalidade da comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação. A comunicação entre os desenvolvedores e o gerente do projeto também é encorajada. A simplicidade visa a permitir a criação de código enxuto que não deve possuir funções desnecessárias. Por código simples entende-se implementar o software com o menor número possível de componentes como classes e métodos. Por simplicidade também se
entende a preocupação com requisitos atuais, evitando-se adicionar funcionalidades que talvez só venham a ser importantes no futuro. Dessa maneira, a XP aposta na implementação rápida de um produto simples: espera-se que alterações e extensões futuras custarão menos do que fabricar desde o início um software grande e complexo. A prática do feedback constante significa que o programador terá informações constantes sobre o código e o cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Em relação ao cliente, o feedback constante significa que ele terá freqüentemente uma parte do software totalmente funcional para avaliar. Com isso, o cliente constantemente sugerirá novas características e informações aos desenvolvedores. Eventuais erros e não-conformidades serão rapidamente identificados e corrigidos nas versões seguintes. Desta forma, a tendência é que o produto final esteja de acordo com as expectativas reais do cliente.
É necessário coragem para implantar os três valores anteriores. Por exemplo, não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento. A coragem também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentá-la. Além disso, é preciso coragem para obter feedback constante do cliente. Por exemplo, ao cliente testar uma parte executável constantemente, o cliente poderá querer aumentar as funcionalidades a serem implementadas, ocasionando alterações no escopo inicial do software.
Práticas da XP
A XP baseia-se em 12 práticas descritas a seguir. Não é necessária a implementação dessas práticas simultaneamente, recomendando-se que sejam aplicadas gradati-vamente. Algumas delas não são novas, sendo usadas há muitos anos na indústria de software.
• Planejamento: consiste em decidir o que é necessário fazer e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais reais para desenvolvimento de software, não em possíveis requisitos futuros. Além disso, a XP procura evitar os problemas de relacionamento entre a área de negócios e a área de desenvolvimento. Ambas as áreas devem cooperar para o sucesso e cada uma deve focar partes específicas do projeto. Desta forma, enquanto a área de negócios deve decidir sobre o escopo, a composição das versões e as datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma detalhado para que o software seja entregue nas datas especificadas.
• Entregas freqüentes: visam à construção de um software simples, atualizado à medida que novos requisitos surgem. Cada versão deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente, devem ser entregues versões a cada mês ou, no máximo, a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas como a necessidade de grandes modificações após vários meses de trabalho, torna mais precisas as avaliações e aumenta a probabilidade de o software final estar de acordo com as necessidades do contratante.
• Metáfora: são as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o desenvolvimento do software.
• Projeto simples: o programa deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que realmente existirem, evitando-se que funcionalidades sejam implementadas sem necessidade. Esta forma de raciocínio se opõe ao "implemente para hoje e projete para amanhã":
• Testes: a XP focaliza a validação do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando
pri-meiramente os casos de testes.
• Programação em pares: a implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. O desenvolvedor que está com o controle do teclado e do mouse implementa o código, enquanto o outro observa continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos e semânticos e pensando estrategicamente em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser alterados continuamente. Uma grande vantagem da programação em dupla é a possibilidade de os desenvolvedores aprenderem um com o outro. O código possui maior probabilidade de estar correto, uma vez que duas pessoas estão preocupadas em sua implementação. A programação em pares possibilita que revisões sejam feitas já durante a implementação do software.
• Refatoração: focaliza o aperfeiçoamento do projeto do software e está presente em todo o desenvolvimento. A refatoração deve ser feita sempre que for possível simplificar uma parte do software, sem que seja perdida nenhuma funcionalidade. • Propriedade coletiva: o código do projeto pertence a todos os membros da
equipe. Qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que não o tenha desenvolvido, pode fazê-lo, desde que realize a bate ria de testes necessária. Isto é possível porque na XP todos são responsáveis pelo software inteiro. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes de concluí-lo, a equipe conseguirá terminá-lo com poucas dificuldades, visto que todos conhecem o software, mesmo que não seja de forma detalhada. Um benefício adicional é a menor dependência de um autor específico, como no caso de um programador "herói".
• Integração contínua: uma vez testado e validado, o código produzido por uma equipe deve ser integrado ao sistema e este, por sua vez, também deve ser testado. Dessa maneira, o software é construído e verificado gradativamente, possivelmente sendo mais fácil isolar erros e suas causas. Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ser de livre acesso a todos os membros da equipe.
• Trabalho semanal de 40 horas: a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, há um problema sério no projeto que deve ser resolvido não com o aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prática procura ratificar o foco nas pessoas e não em processos e planejamentos. Preferencialmente, os planos devem ser alterados, em vez de sobrecarregar as pessoas.
• Cliente presente: é fundamental a participação do cliente durante todo o de-senvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos. Isto evita atrasos e até mesmo construções errôneas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento, por exemplo, escrevendo as histórias do usuário.
• Código-padrão: recomenda-se a adoção de regras de escrita, por exemplo no estilo e formato de comentários e no uso de identificadores (Capítulo 15). A padronização favorece o trabalho em equipe e a propriedade coletiva do código. Planejamento na XP
É comum que os gerentes de projetos "queiram distância" do cliente. Afinal, o cliente normalmente entra em contato por dois motivos: para pedir mudanças nos requisitos ou para reclamar de algo, como atrasos ou problemas na interface. Na XP, por outro
lado, o cliente pode participar tão ativamente do processo de desenvolvimento que pode fazer parte da equipe de programadores. Isso permite esclarecer imediatamente dúvidas sobre os requisitos, descritos nas histórias de usuário.
Normalmente, espera-se que uma história seja dividida em algumas tarefas. Tarefas menores devem ser agrupadas e as maiores, divididas, obedecendo à estimativa dos desenvolvedores. Cada tarefa é escrita em um cartão de tarefas. Tais cartões são, então, distribuídos entre os desenvolvedores, que se encarregam de implementar as funcionalidades descritas.
A história do usuário deve durar em média três semanas, para que uma iteração seja feita por mês, com a entrega de uma parte do software executável. A última semana pode ser usada, por exemplo, para refatorar o código, realizar mais testes integrados ou mesmo começar uma nova iteração.
A Tabela abaixo sugere um padrão que pode ser utilizado para descrever as histó rias do usuário. Para cada equipe e/ou projeto, o padrão pode variar, mas deve ser seguido por todos quando for definido. A descrição deve ser feita em alto nível, sem muitos detalhes. No caso de um profissional técnico ou um membro da equipe de desenvolvimento especificar a história, deve-se procurar evitar termos muito técnicos ou mesmo detalhar os procedimentos com algoritmos. O acompanhamento pode ser feito diariamente ou em um intervalo de poucos dias. Neste caso, anota-se o status da tarefa (por exemplo, iniciando, implementando, testando etc), o que ainda precisa ser feito e comentários gerais.
Um padrão de história do usuário
Data:__________ Tipo de história:_____Nova____Melhoria____Debug
Número:_______ Prioridade:_______ Riscos:________ Estimativa:_______ Descrição:
Notas:
Acompanhamento:
Data Status A fazer Cometário
Um padrão de cartão de tarefas
Data:__________ Número:___________ Estimativa:____________
Responsável 1:___________________ Responsável 2:__________________ Descrição:
Notas:
Acompanhamento:
Data Status A fazer Cometário
Comparando os Métodos Ágeis com a Metodologia Tradicional, o primeiro mostrou melhores resultados de cumprimento de prazos, custos e padrões de qualidade. A XP é
ideal para ser usada em projetos onde os stakeholders não sabem exatamente o que desejam e mudam muito de opinião durante o desenvolvimento.
Vantagens da XP
Feedback constante permite a adaptação rápida do produto; Entregas frequentes de software executável;
Integração e testes contínuos: Melhora a qualidade. Desvantagens da XP
Codifica-Remenda;
Informalidade no levantamento de requisitos pode gerar insegurança para clientes; A refatoração pode ser interpretada como amadorismo;
