Você está na página 1de 47

Aula 06 - PSI - Métodos Ágeis de Desenvolvimento de Software

Prof. Lucas H. C. de Lima


Processos Tradicionais vs. Ágeis
● Processos tradicionais são baseados
em especificação detalhada dos
requisitos, projeto e testes

● Métodos ágeis têm por objetivo


criar software útil rapidamente
○ Não se preocupam com a
documentação completa em
todas as fases

Projeto de Sistemas (PSI) 2


Por que processos ágeis?
● As regras de negócios mudam rapidamente
○ O software tem que ser adaptado para as novas regras

● Desenvolvimento e entrega rápida são importantes em mercados


competitivos
○ A entrega rápida pode ser tão (ou mais) desejável que a qualidade

Projeto de Sistemas (PSI) 3


Por que processos ágeis?
● Sobre Requisitos
○ Clientes não sabem o que querem (em um software)
○ Funcionalidades são "infinitas" (difícil prever)
○ Mundo muda!
○ Não dá mais para ficar 1 ano levantando requisitos, 1 ano projetando, 1 ano
implementando, etc -- quando o software ficar pronto, ele estará obsoleto!

● Sobre Documentações Detalhadas


○ Podem ser verbosas e pouco úteis
○ Na prática, desconsideradas durante implementação

Projeto de Sistemas (PSI) 4


De onde vem os métodos ágeis?
● Os primeiros processos de desenvolvimento de software — do tipo Waterfall,
propostos ainda na década de 70 — eram estritamente sequenciais

● Décadas de 70 a 90: percebeu-se que softwares eram diferentes de outros


produtos da Engenharia
○ Cronogramas e orçamentos não eram obedecidos

Projeto de Sistemas (PSI) 5


Manifesto Ágil
● Profissionais da indústria se reuniram e
decidiram lançar as bases para um novo
conceito de processo de software
○ Registraram em um documento que
chamaram de Manifesto Ágil (2001)

http://agilemanifesto.org/

Projeto de Sistemas (PSI) 6


Características Gerais
● Atividades de especificação, projeto e implementação são feitas em paralelo
○ Especificação não é detalhada
○ Documentação de projeto é mínima ou gerada automaticamente

● A interface do sistema é criada rapidamente


○ Antes das funcionalidades serem implementadas

● O sistema é desenvolvido por uma série de incrementos


○ Usuários finais (ou representante do cliente)
participam da especificação e validação de cada incremento

Projeto de Sistemas (PSI) 7


Projeto de Sistemas (PSI) 8
Projeto de Sistemas (PSI) 9
Vantagens
● Entrega acelerada de partes dos serviços ao cliente
○ Partes mais importantes podem ser entregues primeiro

● Engajamento dos usuários finais


○ Maior chance dos usuários ficarem satisfeitos com o produto

Projeto de Sistemas (PSI) 10


Problemas
● Gerenciamento
○ Falta documentação para o gerente
● Fechar o contrato com o cliente
○ Não há especificação completa do sistema
● Validar o sistema
○ A equipe de verificação e validação não tem a especificação
● Modificações contínuas podem corromper a estrutura do sistema

● Evite o uso de métodos ágeis em sistemas grandes e complexos, ou em


sistemas críticos: requisitos devem ser completamente especificados

Projeto de Sistemas (PSI) 11


Metodologias: Tradicionais x Ágeis

Projeto de Sistemas (PSI) 12


Projeto de Sistemas (PSI) 13
Hoje: Scrum, proposto por Jeffrey Sutherland e
Ken Schwaber, em um artigo publicado em 1995.

Projeto de Sistemas (PSI) 14


Considerações Importantes
● Nenhum processo é bala de prata

● Processos não são adotados 100% igual ao manual


○ Bom senso é importante
○ Experimentação é importante

Projeto de Sistemas (PSI) 15


Scrum
Métodos Ágeis de Desenvolvimento de Software
Scrum
● Proposto por Jeffrey Sutherland e ● Scrum é uma indústria: livros,
Ken Schwaber (OOPSLA 1995) consultoria, certificações,
marketing

Projeto de Sistemas (PSI) 17


Método Ágil Scrum
● Método ágil que vem ganhando adeptos

● Objetivo: oferecer uma forma de gerenciar


projetos ágeis

● Não é apenas para projetos de software

● Scrum define um processo mais rígido


○ Eventos, papéis e artefatos bem claros

Projeto de Sistemas (PSI) 18


Principal Evento: Sprints
● Desenvolvimento é dividido em Sprints (iterações, ciclos)
● Duração de uma sprint: até um mês, geralmente 15 dias

sprint

Projeto de Sistemas (PSI) 19


O que se faz em uma sprint?
● Implementa-se algumas histórias dos usuários
● Histórias = funcionalidades (ou features) do sistema
● Exemplo: fórum de perguntas e respostas

Bem simples, deve caber em um post-it

Projeto de Sistemas (PSI) 20


Stakeholders

Devs Antes (waterfall)

Analista de
Requisitos
Linguagem natural
(poderia levar anos para ficar
pronto)

Stakeholders PO Devs Hoje (Scrum)

● Durante sprint, PO explica histórias (requisitos) para devs


● Troca-se documentação formal e escrita por documentação verbal e informal
● Conversas entre PO e Devs

Projeto de Sistemas (PSI) 21


Scrum: visão geral do framework

Projeto de Sistemas (PSI) 22


Scrum: Papéis
● Product Owner (PO)
○ Escreve histórias dos usuários; Explica histórias para os devs durante o sprint; Prioriza histórias, mantém o
backlog do produto
○ Modifica requisitos e aprova ou não cada versão do software
● Scrum Master (SM)
○ Especialista em Scrum do time, sendo responsável por garantir que as regras do método estão sendo
seguidas
○ Dá suporte a equipe e acompanha a produtividade. Facilitador dos trabalhos e removedor de impedimentos
○ Não é o líder do time, pois todos em um time Scrum têm o mesmo nível hierárquico.
● Scrum Team
○ Profissionais multifuncionais;
○ Exemplo: no caso de projetos de software, isso inclui desenvolvedores front-end, desenvolvedores back-end,
especialistas em bancos de dados, projetistas de interfaces, etc.

Projeto de Sistemas (PSI) 23


Scrum: Cerimônias

Projeto de Sistemas (PSI) 24


Scrum: Cerimônias
Planning

Quais histórias vão entrar no próximo


sprint?

Essa decisão é tomada no início do sprint em


uma reunião chamada de planejamento do
sprint (planning)

PO propõe histórias que gostaria de ver


implementadas e Devs decidem se têm
velocidade para implementá-las

Projeto de Sistemas (PSI) 25


Scrum: Cerimônias
Planning

1a parte da reunião:
- Definem-se as histórias do sprint;

2a parte da reunião:
- Histórias são quebradas em tarefas;
- Tarefas são alocadas a devs.

Projeto de Sistemas (PSI) 26


Scrum: Cerimônias
Planning

Exemplo:
História: Postar Perguntas
Tarefas:
● Projetar e testar a interface Web, incluindo
layout, CSS templates, etc.
● Instalar banco de dados, projetar e criar tabelas.
● Implementar a camada de acesso a dados.
● Implementar camada de controle, com
operações para cadastrar, remover e atualizar
perguntas.
● Implementar interface Web.

Projeto de Sistemas (PSI) 27


Scrum: Cerimônias
Planning

Estimativa de Tamanho de Histórias de Usuários:


Story Points: unidade (inteiro) para comparação do
tamanho de histórias. Exemplo de escala: 1, 2, 3, 5, 8...

Projeto de Sistemas (PSI) 28


Scrum: Cerimônias
Daily Meeting

● 15 minutos de duração; em pé. Cada


participante diz:
○ o que ele fez ontem
○ o que pretende fazer hoje
○ e se está tendo alguma
dificuldade

● Objetivos:
○ Melhorar comunicação
○ Antecipar problemas

Projeto de Sistemas (PSI) 29


Scrum: Cerimônias
Review e Retrospectiva

Sprint termina com dois eventos:


Review e Retrospectiva

Projeto de Sistemas (PSI) 30


Scrum: Cerimônias
Review

● Time mostra o resultado do sprint


para PO e stakeholders
● Implementação das histórias pode ser:
○ Aprovada
○ Aprovada parcialmente
○ Reprovada
● Nos dois últimos casos, história volta
para o backlog do produto

Projeto de Sistemas (PSI) 31


Scrum: Cerimônias
Retrospectiva

● Último evento do sprint


● Time se reúne para decidir o que
melhorar
○ O que deu certo?
○ Onde precisamos melhorar?
● Não é para "lavar a roupa suja"

Projeto de Sistemas (PSI) 32


Scrum: Cerimônias
Follow-Up

Além destas, é possível ainda ter


também reuniões de Follow-Up
com cliente durante os sprints

Projeto de Sistemas (PSI) 33


Scrum: Artefatos
Backlog do Produto

● Lista de histórias do usuário, que foram escritas pelo PO


● Duas características:
○ Priorizada: histórias do topo têm maior prioridade
○ Dinâmica: histórias podem sair e entrar, à medida que o sistema
evolui

Projeto de Sistemas (PSI) 34


Scrum: Artefatos
Backlog do Sprint

● Lista de tarefas do sprint, com responsáveis e duração estimada

Projeto de Sistemas (PSI) 35


Scrum: Artefatos
Gráfico de Burndown

Esse gráfico mostra quantas horas são necessárias para se implementar as tarefas que
ainda não estão concluídas. Isto é, no dia X do sprint ele informa que restam tarefas a
implementar que somam Y horas.

Projeto de Sistemas (PSI) 36


Scrum: Artefatos
Scrum Board

Projeto de Sistemas (PSI) 37


Mais sobre histórias do usuário
● Nas abordagens ágeis, podemos definir e organizar os requisitos de um sistema
utilizando User Stories (Histórias do Usuário)

● São descrições simples que descrevem uma funcionalidade;


○ É recomendável que sejam escritas segundo o ponto de vista do usuário

● User Stories devem ser curtas, simples e claras. Devemos conseguir


escrevê-las em um simples e pequeno cartão (conhecidos como User Index Cards).
Se não há espaço para escrevê-la em um cartão é porquê devemos
refiná-la mais, e as dividir em outras User Stories.

Projeto de Sistemas (PSI) 38


Mais sobre histórias do usuário
● Histórias devem ser independentes: dadas duas histórias X e Y, deve ser
possível implementá-las em qualquer ordem
● Histórias devem agregar valor para o negócio dos clientes.
● Deve ser viável estimar o tamanho de uma história. Por exemplo, quantos
dias serão necessários para implementá-la.
● Histórias devem ser sucintas.
● Histórias devem ser testáveis, isto é, elas devem ter critérios de aceitação
objetivos.

Projeto de Sistemas (PSI) 39


Escrevendo Histórias de Usuário
Podemos construir User Stories especificando o ator, a ação/meta,
a funcionalidade desejada e os critérios de aceitação

Ator – O proprietário da User Story.


ou Papel de Usuário
De forma simplista é o usuário, o interessado
naquela funcionalidade. Mas é recomendado
descrever de forma específica quem é o ator
para que seja mais fácil identificar o contexto
da história dentro do sistema.

Projeto de Sistemas (PSI) 40


Escrevendo Histórias de Usuário
Podemos construir User Stories especificando o ator, a ação/meta,
a funcionalidade desejada e os critérios de aceitação

Ação – É o que o ator quer fazer.


A partir dessa ação ele espera alcançar seu
objetivo dentro do sistema.

Projeto de Sistemas (PSI) 41


Escrevendo Histórias de Usuário
Podemos construir User Stories especificando o ator, a ação/meta,
a funcionalidade desejada e os critérios de aceitação

Funcionalidade –
É o que o ator espera que aconteça ao
executar a ação.

Projeto de Sistemas (PSI) 42


Escrevendo Histórias de Usuário
Exemplo:

Projeto de Sistemas (PSI) 43


Escrevendo Histórias de Usuário
Exemplo para um aplicativo de ensino:

HISTÓRIA DE USUÁRIO 01: Responder uma questão


Eu, como estudante, quero responder uma questão de múltipla escolha para aprender, a partir do
feedback do aplicativo, se a resposta está correta ou não

HISTÓRIA DE USUÁRIO 02: Desistir (sair) da questão


Eu, como estudante, gostaria de abandonar uma questão para não respondê-la

HISTÓRIA DE USUÁRIO 03:Visualizar uma questão


Eu, como estudante, quero visualizar uma questão de múltipla escolha para ter a opção de respondê-la

Projeto de Sistemas (PSI) 44


Exercício
1. Descreva brevemente os métodos ágeis Extreme Programming (XP) e Kanban.
Discuta pontos de divergência e convergência entre estes métodos e o Scrum.
2. Explique o que é Programação Pareada (Pair Programming). Discuta suas vantagens
e possíveis desvantagens.
3. Escreva pelo menos 05 Histórias de Usuários para um sistema de controle de uma
biblioteca. São exemplos de tipos de usuário: usuário típico, professor e funcionário.

4. Individual/duplas/trios. Entrega em .pdf através do Moodle


5. Entrega até 09/03/2021, às 23:55

Projeto de Sistemas (PSI) 45


Planejamento 4º Bimestre
PSI LPSI

02/03 Abordagens Ágeis para Projetar Sistemas 04/03 Palestra: Metodologia ágil no mercado de trabalho.
16/03 Teste e Qualidade de Software 11/03 Semana de estudos autônomos
30/03 - 18/03 Acompanhamento PI: ajustes finais
31/03/2021 - Término 4o bimestre letivo de 2020 25/03 -
31/03/2021 - Término 4o bimestre letivo de 2020

Atividades Avaliativas 4º Bimestre Valor


Listas de Exercícios Teóricos 10
Aulas de Laboratório Práticas 5
Projeto Integrado - Apresentação Final 15
Total 30

Projeto de Sistemas (PSI) 46


Referências
● Ian Sommerville. Engenharia de Software, 9ª Edição. Pearson
Education, 2011.
● Roger Pressman. Engenharia de Software: Uma Abordagem
Profissional, 7a Edição. McGraw-Hill, 2011.
● Material de aula Prof. Eduardo Figueiredo DCC/UFMG
● Marco Tulio Valente. Engenharia de Software Moderna: Princípios e
Práticas para Desenvolvimento de Software com Produtividade,
2020.

Projeto de Sistemas (PSI) 47

Você também pode gostar