métodos Ágeis

CIÊNCIA DA COMPUTAÇÃO - FCG

Qualidade de Software

Aula 08: Metodologias Ágeis

(Adaptação do capítulo 10 de Koscianski & Soares, 2006)

Prof.º Msc. Sidney Roberto de Sousa

Ciência da Computação - FCG 2

Metodologias de desenvolvimento de software

Nas últimas décadas, várias metodologias foram criadas a fim de sistematizar o desenvolvimento de software

Tais metodologias podem ser divididas em: Tradicionais: ênfase na documentação de cada

passo do desenvolvimento do software Ágeis: paradigma mais recente de engenharia de

software, o qual promete melhorias de produtividade e qualidade


Especificação: definição das funcionalidades e demais características do produto

Projeto e Implementação: produção do software de acordo com as especificações. Propõe-se modelos os quais serão implementados em alguma linguagem de programação

Validação:revisão e testes quem visam a garantia de cumprimento dos requisitos

Evolução: manutenção ou criação de novas funcionalidade a fim de adaptar o software a novas necessidades do cliente

Atividades comuns a metodologias


Metodologias Tradicionais

Consideradas por muitos com ”pesadas” ou ”orientadas a documentação”

Surgiram em um contexto de desenvolvimento de software muito diferente do atual → baseado em mainframes e terminais burros

Em tal época, o custo de manutenção era muito caro → dificuldade de acesso a computadores e a escassez de ferramentas de apoio ao desenvolvimento de software

Assim, todo o software era planejado e documentado antes de ser implementado


Modelo Cascata

Também conhecido como modelo clássico, é considerada a principal metodologia tradicional

Estabele uma sequência de etapas Após o término de cada etapa é criada uma

documentação que deve ser aprovada para que a próxima etapa possa ser iniciada


Modelo Cascata


Modelo Cascata

Divide o projeto em fases de forma inflexível Ex.: após a fase de desenvolvimento não são

previstas mudanças de requisitos O modelo espiral permite o retorno a etapas

anteriores, porém não dá suporte à execução de etapas de forma paralela

Este paralelismo é necessário em alguns tipos de projeto → ex.: desenvolvimento de módulos concorrentes


Modelo Cascata

Assim, o modelo cascata é recomendável em projetos com requisitos estáveis → Isto existe?


Custo de modificação no Modelo Cascata


Modelo Cascata

O modelo cascata dominou a forma de se desenvolver software até o inícios dos anos 90

Tal dominância ocorreu mesmo sob advertência de pesquisadores de engenharia de software e o relato negativo de desenvolvedores de software

Autores como Brooks (Brooks, 1986) demonstraram como a idéia de se especificar um software por inteiro antecipadamente pode ter riscos sérios


Experiências da indústria

Dados de 1994 usando como base 8380 projetos mostram que apenas 16,2% destes foram entregues respeitando prazos, custos e requisitos

Cerca de 31% foram cancelados antes de seu término e 52,7% foram entregues → com prazos e custos maiores OU com diminuição de requisitos

Causa? Pressão sobre desenvolvedores → quadruplica o número de erros!

Modelo cascata → dificuldades em alterar requisitos



No fim da década de 90, pesquisas mostraram resultados mais ”animadores”

15% dos projetos terminaram sem mostrar resultados

66% dos projetos não atenderam as necessidades dos usuários

Média de atrasos caiu para 63%

Projetos custaram em média 45% a mais que o planejado

28% dos projetos cumpriram o planejado → porém, a maioria destes projetos foram superestimados – exageros de até 150%



Dentre os motivos da melhoria, o principal foi o uso de ferramentas CASE no processo de modelagem e implementação

As ferramentas de gestão de requisitos também foram responsáveis pela melhoria

Por fim, também ajudou a melhoria da qualidade dos processos de desenvolvimento

As pesquisas do final dos anos 90 recomendaram o desenvolvimento de software baseado em modelos incrementais → evitar falhas


Métodos ágeis

Adequados para situações em que a mudança de requisitos é frequente

Um método ágil aceita a mudança ao invés de tentar prever o futuro

O termo se tornou comum em 2001, quando 17 especialistas em processos de desenvolvimento de software – representando as metodologias XP, Scrum, DSDM, Crystal, entre outros, estabeleceram os princípios comuns compartilhados por todos estes métodos

Criou-se assim a Aliança Ágil e o Manifesto Ágil


Métodos ágeis


Métodos ágeis

O Manifesto Ágil não rejeita processos e ferramentas, documentação, negociação de contratos ou planejamento

Porém, ele mostra que estes tem menos importância que os indivíduos, o software executável, a colaboração dos clientes e as respostas rápidas às mudanças

Aproximação da forma como pequenas e médias empresas trabalham e respondem às mudanças


Conceitos-chave do Manifesto Ágil

Indivíduos e interações ao invés de processos e ferramentas

Software executável ao invés de documentação Colaboração com o cliente ao invés de

negociações de contratos Respostas rápidas a mudanças ao invés de

seguir planos


Extreme Programming (XP)

Método ágil para equipes pequenas/médias que desenvolvem software baseado em requisitos vagos e rapidamente mutáveis

Principais diferenças entre a XP e as metodologias clássicas:

Feedback contínuo Abordagem incremental Encorajamento da comunicação interpessoal


Extreme Programming (XP)

As práticas da XP podem ser ”chocantes” à primeira vista → ou mesmo não fazer sentido, se observadas de forma isolada

Porém, a sintonia do seu conjunto que faz com que a metodologia seja sucessiva

A XP enfatiza o desenvolvimento rápido do projeto, a garantia de satisfação do cliente e o cumprimento das estimativas

Suas práticas/valores oferecem um ambiente agradável de desenvolvimento de software aos seus seguidores → conduzindo-os por quatro valores: comunicação, simplicidade, feedback e coragem


XP - Comunicação

Manter o melhor relacionamento possível entre clientes e desenvolvedores

Prefere-se conversas pessoais ao invés de outros meios de comunicação

A comunicação entre desenvolvedores e gerente de projeto também é encorajada


XP - Simplicidade

Permitir a criação de código enxuto, que não deve possuir funções desnecessárias

Código simples → implementar o software com o menor número possível de componentes como classes e métodos

Preocupação com requisitos atuais, evitando-se adicionar funcionalidades que não são úteis no momento → escopo bem definido

XP aposta na implementação rápida de um produto simples → espera-se que alterações e evoluções futuras custarão menos do que criar desde o início um software grande e complexo


XP – Feedback constante

Programador deve ter informações constantes sobre o código e o cliente

A informação sobre o código é obtida por testes constantes → indicação de erros unitários e de integração

O cliente obtem frequentemente incrementos de software funcionais para que posso avaliá-los

Com isto, o cliente tem subsídios para sugerir novas características e informação aos desenvolvedores

Não-conformidades são identificadas rapidamente e corrigidas em novas versões/incrementos

O produto tende a estar de acordo com as reais expectativas do cliente


XP - Coragem

Necessária para implantar os três valores anteriores

Nem todas as pessoas tem facilidade de comunicação e têm bom relacionamento

A coragem também é necessária para experimentar a simplificidade no software implementado

Por fim, é preciso coragem para ouvir o feedback do cliente!


Práticas da XP

A XP baseia-se em 12 práticas Não exige-se a implementação simultânea de

todas as práticas → recomenda-se que sejam aplicadas gradativamente

Algumas práticas não são inovadores → na verdade, são usadas há anos na indústria de software


Prática 1 - Planejamento

Decidir o que é necessário fazer 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

Procura-se evitar problemas de relacionamento entre a área de negócios e a de desenvolvimento → ambas devem cooperar para o sucesso e cada uma deve focar partes específicas do projeto

Área de negócios → escopo, composição das versões e as datas de entrega

Desenvolvedores → estimativas de prazo, processo de desenvolvimento e cronograma detalhado


Prática 2 – Entregas frequentes

Construir software simples e atualizado à medida que novos requisitos surgem

Cada incremento deve ser o mais compacto possível → apenas os requisitos mais valiosos

Incrementos devem ser entregues a cada mês ou no máximo a cada dois meses → feedback mais rápido do cliente

Evita-se surpresas → grandes modificações

Torna as avaliações mais precisas e aumenta a chance da concordância do software com as necessidades do cliente


Prática 3 - Metáfora

Descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o seu

desenvolvimento


Prática 4 – Projeto simples

O software deve ser o mais simples possível e satisfazer os requisitos atuais

Possíveis requisitos futuros só são adicionados ao projeto quando sua implementação é realmente necessária → K.I.S.S.

Oposto ao raciocínio ”implemente para hoje e projete para amanhã”


Prática 5 - Testes

Foco na validação do projeto durante todo o processo de desenvolvimento

Os desenvolvedores implementam o software cirando primeiramente os casos de testes → TDD


Prática 6 – Programação em pares

Implementação de software feita em dupla → 2 devs em um único computador

Um dev implementa; o outro revisa continuamento o trabalho feito → procura-se identificar erros sintáticos e semânticos, além de planejar refatorações

Estes dois papéis devem ser trocados continuamente

Desenvolvedores aprendem juntos

Maior possibilidade de corretude de código

Possibilidade de revisões já na fase de implementação


Prática 7 - Refatoração

Foco no aperfeiçoamento do projeto do software

Presente em todo o desenvolvimento Deve ser feita sempre que possível A idéia é simplificar código sem que haja perda

de funcionalidades


Prática 8 – Propriedade coletiva

O código é de todos os membros da equipe!

Qualquem membro pode agregar valor ao código → mesmo que não o tenha desenvolvido (desde que realize os testes necessários)

Todos são responsáveis pelo software inteiro!

Caso um membro da equipe deixe o projeto (momentânea ou definitivamente) antes de sua conclusão, a equipe ainda é capaz de continuar o projeto com poucas dificuldades

Menor dependência de heróis individuais


Prática 9 – Integração contínua

O código (testado) produzido por uma equipe deve ser integrado ao sistema, o qual também deve ser testado

O software é construído e verificado continuamente

Maior facilidade de isolar erros e suas causas Recomenda-se utilizar uma única máquina de

integração, o qual pode ser acessado livremente por toda a equipe


Prática 10 – Trabalho semanal de 40 horas

Horas extras não devem se tornar um costume

Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema no projeto!

Tal problema não deve ser resolvido com mais horas de trabalho → e sim com planejamento

Focos na pessoas → não em processos e planejamentos

Alteração dos planos Vs. Sobrecarga de pessoal


Prática 11 – Cliente presente

O cliente DEVE participar durante todo o projeto O cliente DEVE estar sempre disponível para

sanar todas as dúvidas sobre requisitos Evita atrasos e implementações errôneas O cliente pode ser mantido como parte

integrande da equipe do desenvolvimento → ex.: escrevendo história de usuário

Pergunta: o que são histórias de usuário? (BDD)


Prática 12 – Código padrão

Regras de escrita → estilo, formato de comentários, nomenclatura de variáveis, etc.

Favorece o trabalho em equipe e a propriedade coletiva do código


Planejamento na XP

O cliente participa ativamente no processo de desenvolvimento → pode até fazer parte da equipe de desenvolvimento

Esclarecimento de dúvidas facilitado → uso de histórias

Cada tarefa/requisito é descrito como uma história → possivelmente, pelo cliente

As história são distribuídas aos desenvolvedores, os quais se encarregam de implementar as funcionalidades descritas


Scrum

… na próxima aula! ;)


Conclusões – Métodos ágeis

Pesquisas mostram que projetos utilizando métodos ágeis obtiveram melhores resultados em termos de cumprimento de prazos, custos e padrões de qualidade

Cada vez mais projetos/equipes maiores tem utilizado métodos ágeis

Outras pesquisas mostraram que o uso adequado de XP pode ajudar organizações alcançarem os níveis CMM 2 e 3 → Boeing, por exemplo, alcançou o nível CMM 5 sem muitas alterações após adotar o XP


Conclusões – Vantagens da XP

XP é ideal a projetos em que os stakeholders não sabem exatamente o que desejam

O feedback contínuo permite a rápida adaptação do produto

Entregas frequentes do software executável e funcional → diminuir a ansiedade do cliente e obter o seu feedback a respeito do trabalho realizado

Integração e testes contínuos → melhoria e garantia de qualidade


Conclusões – Algumas desvantagens da XP

Muitos acreditam que seja a volta do processo caótico de desenvolvimento de software → ”codifica-remenda”

O uso errôneo da XP pode ”mascarar” práticas positivas de desenvolvimento → ex., análise de problemas utilizando diagramas

Alguns clientes podem não gostar da informalidade no levantamento de requisitos

Além disso, alguns clientes podem enxergar a refatoração como amadorismo ou mesmo incompetência


Bibliografia

KOSCIANSKI, A., SOARES, M. S. Qualidade de Software. Segunda edição. Editora Novatec. São Paulo, 2006.

BROOKS, F. P. No Silver Bullet – Essence and Accident in Software Engineering. Proceedings of IFIP Tenth World Computing Conference, H.-J. Kugler, ed., Elsevier Science B. V., Amsterdam, NL (1986) pp. 1069-1076.

métodos Ágeis

Technology