Desenvolvimento ágil de software

Engenharia de SoftwareUnidade III – Desenvolvimento Ágil de Projetos de Software

Objetivo: Enfatizar o modelo e as práticas ágeis de desenvolvimento de software

Prof. Nécio de Lima Veras

Roteiro...

Manifesto Ágil Agilidade e Processos Ágeis

Frameworks TDD BDD User Stories Velocity

Modelos Ágeis SCRUM e XP;

Manifesto Ágil

Um grupo em fevereiro de 2001, chamado de Agile Alliance, começou a descobrir maneiras melhores e mais leves de desenvolver software valorizando: pessoas e interações ao invés de processos e

ferramentas; softwares funcionando no lugar de documentações

abrangentes; colaborações com clientes do que negociações de

contratos e respostas à mudanças por planos fechados.

Manifesto Ágil

O modelo é baseado em mudanças abrangentes;

O desenvolvedor deve melhorar

continuamente um protótipo incompleto até que o cliente fique feliz com o resultado;

O Manifesto Ágil está reforçado com outros DOZE princípios que regem a filosofia de criar softwares com agilidade [BECK, 2001].

Os doze princípios

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.

2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Os doze princípios

5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

7. Software funcionando é a medida primária de progresso.

8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Os doze princípios

9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.

10.Simplicidade (a arte de maximizar a quantidade de trabalho não realizado) é essencial.

11.As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

12.Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Agilidade e Processos Ágeis Frameworks TDD BDD User Stories Velocity

Agilidade

Você não tem que escolher entre agilidade e engenharia de software.

Em vez disso, defina uma abordagem de engenharia de software que seja ágil.

Test Driven Development

“A grande maioria das pessoas já teve alguma experiência com um software que não funcionou como esperado. Softwares que não funcionam corretamente podem levar a muitos problemas, incluindo financeiro, tempo e reputação das empresas. Podendo, inclusive, chegar a influenciar na integridade das pessoas” [ISTQB 2011].


Podemos associar a qualidade de um software à quantidade de falhas percebidas no mesmo; O teste de software ajuda a medir e/ou garantir essa

qualidade;

Níveis de Teste: Unidade (componente) Integração (interface entre componentes) Sistema (comportamento) Aceitação (apropriado para uso).


Modos de Testar: Manual

Ex.: Inspeção manual de Código

Automático Ex.: Asserção com JUnit

No contexto de testes automáticos se sobressaem duas abordagens: TDD (Testing-Driven Development) ou Desenvolvimento dirigido por

testes BDD (Behavior-Driven Design) ou Projeto guiado por comportamento

TDD

TDD se apoia nos passos: Escreva o teste, para a funcionalidade, antes de

estar implementada (os testes irão falhar) Escreva o código de modo a fazer os teste

passar Refatore o código Repita o processo

Behavior Driven Development

Sobre BDD podemos fazer as seguintes considerações [Fox e Patterson 2012]: BDD faz perguntas sobre comportamentos antes e

durante o desenvolvimento, visando reduzir falhas na comunicação dentro do projeto.

Requisitos são escritos como estórias de usuários. São criadas descrições simples de como a aplicação deve ser utilizada.

BDD se concentra no comportamento da aplicação versus a implementação da aplicação e os testes são conduzidos utilizando TDD.


Um exemplo simples considerando a seguinte narrativa: Como um usuário Eu quero comprar produtos em promoção E então receber um email de confirmação

Scenario: Verificar produtos em promoção Given Que uma loja possui 10 produtos and Que 5 estão em promoção When Eu verifico quais estão em promoção Then Preencho minha sacola apenas com produtos

em promoção

Behavior Driven Developmentpublic class PromocaoSteps extends PtBRSteps { Loja loja = new Loja(); Sacola sacola = new Sacola(); List<Produto> listaProdutoPromocao; int quantidadeProdutoPromocao; @Given("Que uma loja possui $quant produtos") public void populaLoja(Integer quantidade) { loja.inicializaProdutos(quantidade); } @Given("Que $quant estão em promoção") public void informaProdutosPromocao(Integer quantidade) { loja.colocaProdutosPromocao(quantidade); quantidadeProdutoPromocao = quantidade; } @When("Eu verifico quais estão em promoção") public void verificaProdutosPromocao() { listaProdutoPromocao = loja.retornaProdutosPromocao(); } @Then("Preencho minha sacola apenas com produtos em promoção") public void populaSacola() { sacola.populaSacola(listaProdutoPromocao); Assert.assertEquals(listaProdutoPromocao.size(), quantidadeProdutoPromocao); }}


Assim temos: “Given” é a condição inicial “When” é a ação realizada para a obtenção do

resultado “Then” a conclusão/comportamento esperado

User Story

Story vem de conto (estória) e não de história (relato de fatos);

É basicamente uma lista de requisitos, funções que o dono do negócio solicita e que espera que elas sejam entregues, descritas em linguagem coloquial.

Aspectos críticos: Deve ser escrita em cartões (ou post-its), pois devem ser pequenas; Deve identificar uma funcionalidade; Deve ser definida uma forma de validação. Devem ser independentes umas das outras; Não são contratos, mas sim lembretes. Por isso devem ser

informais; Devem agregar valor ao cliente; Devem ser estimáveis; Devem ser testáveis.

User Story - Exemplos

Velocity

Uma das mais importantes métricas para um time Ágil; Em termos de gerenciamento de projetos, Velocity é o “valor

de trabalho” que um time precisa completar em um dado período de tempo (entre 1 e 4 semanas);

Este “valor de trabalho” é número total de estórias que o time estimou;

Assim, Velocity é simplesmente o trabalho dividido pelo time;

Para isso é feito um cálculo de produtividade baseado no total de funcionalidades codificadas, seu grau de importância e o tempo gasto;

Modelos ágeis:SCRUM e XP

Scrum

É um modo ágil de processo que foi desenvolvido por Jeff Sutherland e por sua equipe no início da década de 1990.

Nos últimos anos foi realizado desenvolvimento adicional de métodos Scrum por Sewaber e Beedle.

Scrum

Princípios: Pequenas equipes de trabalho são organizadas

de modo a “maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal”.

O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios “para garantir que o melhor produto possível seja produzido”.

O processo produz frequentes incrementos do software “que podem ser inspecionados, ajustados, testados, documentados e expandidos”.

Scrum

Princípios: O trabalho de desenvolvimento e o pessoal que o

realiza é dividido “em partições claras de baixo acoplamento, ou em pacotes”.

Testes e documentação constantes são realizados à medida que o produto é construído.

O processo Scrum fornece a “habilidade de declarar o produto ‘pronto’ sempre que necessário (porque a concorrência acabou de entregar, porque a empresa precisa de dinheiro, porque o usuário/cliente precisa das funções, porque foi para essa data que foi prometido.)”

eXtreme Programming

O XP usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento predileto.

Inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades: planejamento, projeto, codificação e teste.

Extreme Programming (XP)

Planejamento: Começa com a criação de

um conjunto de histórias (histórias do usuário) que descrevem as características e funcionalidades requeridas para o software a ser construído.

Cada história é escrita pelo cliente e é colocada em um cartão de indexação.


Planejamento: O cliente atribui um

valor (prioridade) para a história, com base no valor de negócio global da característica ou da função.

Membros da equipe XP avaliam então cada história e lhe atribuem um custo – medido em semanas de desenvolvimento.


Planejamento: Se a história precisar

mais do que três semanas de desenvolvimento, pede-se ao cliente para dividir a história em histórias menores e a atribuição de valor e custo ocorre novamente.

Novas histórias podem ser escritas a qualquer momento.


Planejamento:

Histórias


Projeto: O projeto XP segue rigorosamente o princípio KIS

(keep it simple – mantenha a simplicidade).

Um projeto simples é sempre preferível em relação a uma representação mais complexa.

Além disso, o projeto fornece diretrizes de implementação para uma história como ela está escrita – nada mais e nada menos.

O XP encoraja o uso de cartões CRC (Class Responsability Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos.


Características:

Encoraja a refatoração; A Programação em par; Desenvolvimento incremental; A integração contínua; Testes!!!

Exercícios

Referências

Beck, K., et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. http://agilemanifesto.org/. Acessado em 18 de agosto de 2012.

Fox, A., Patterson, D. (2012). “Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing”, Alpha Edition. Strawberry Canyon LLC, 2012.

Desenvolvimento ágil de software

Documents

Transcript of Desenvolvimento ágil de software