DESENVOLVIMENTO

ÁGIL DE
SOFTWARE

Antonio Francisco do Prado

prado@dc.ufscar.br
Rafael Tomé de Souza
rafaeltomesouza@gmail.com
UFSCAR

Ir p/ primeira
página
NOVOS RUMOS DA ES

PDS

Ir p/ primeira
página
 Novos Rumos da
Computação

 Computação Ubíqua

 WEB 3.0 (tecnologias para

interfaces ricas)‫‏‬

 OO + Padrões + Frameworks

 Serviços - SOA e RestFul

 Computação em Nuvem

Ir p/ primeira
página
Computação
Ubíqua

Ir p/ primeira
página
 Computação
Ubíqua - Implemtação

Ir p/ primeira
página
 Web 3.0
Blogs são poderosos canais de comunicação para
divulgar e coletar feedback sobre as empresas e
seus produtos ou iniciativas.

Ir p/ primeira
página
Wikis são sites que permitem
aos seus usuários facilmente
adicionar, remover ou alterar
parte de seu conteúdo.

Ir p/ primeira
página
Syndication é disponibilizar
conteúdo de um site de modo a
prover um sumário do que foi
adicionado sem que o usuário
navegue até o site.

Ir p/ primeira
página
Mashups combinam serviços e
conteúdos de múltiplos sites
para criar um novo serviço ou
aplicação

Ir p/ primeira
página
Social bookmarks são listas
compartilhadas de sites
organizados através de palavras-
chaves (tags) definidas pelos
usuários.

Ir p/ primeira
página
 Web

“A WEB está se tornando uma

plataforma: tudo roda no
browser!”

“O Google e o Yahoo! São exemplos

dos grandes motores da web – e
incentivadores do uso da web.”

11
Ir p/ primeira
página
 Interfaces Ricas

 XML/XHTML/HTML5: provê
independência de dados, separação e
adaptação do conteúdo.

 JavaScript/Ajax - XMLHttpRequest
 XSLT (eXtensible Stylesheet Language
Transformations).
 CSS (Cascading Style Sheets).
 DOM (Document Object Model).

12
Ir p/ primeira
página
 OO - Padrões e
Frameworks
Visão

Controle

Modelo

Framework

Persistência

BD
Ir p/ primeira
página
Reúso - Componente em
domínio de aplicações

Ir p/ primeira
página
Princípios da OO
 Abstração
 Encapsulamento

 Classe e Objeto

 Mensagem

 Herança

 Escala(Todo-Parte)‫‏‬

 Associação

 Polimorfismo

 Genericidade

Ir p/ primeira
página
 Polimorfismo
MoverFigura Redesenhar
(NovoCentro (NovoCentro
:Ponto)‫;‏‬ :Ponto);

Redesenhar
(NovoCentro
:Ponto);

Ir p/ primeira
página
 Genericidade

T,k: Integer

Array

k..k T

Classe parametrizada ou Template

Ir p/ primeira
página
Tipos Genéricos
em Java
ArrayList list= new ArrayList();

list.add(0, new Integer(2));

int total= ((Integer)list.get(0)).intValue();

/* Usando tipos genéricos */

ArrayList<Integer>list= new

ArrayList<Integer>();

list.add(0, new Integer(2));

int total= list.get(0).intValue(); Ir p/ primeira

página
 Anotações
@ManagedBean (name="pessoafisicaController")
@SessionScoped
public class PessoafisicaController {
private Pessoafisica current;
private DataModel items = null;
@EJB private sessao.PessoafisicaFacade
ejbFacade;

public Pessoafisica getSelected() {

if (current == null) {
current = new Pessoafisica();
selectedItemIndex = -1;
}
return current;
}
...
}
// Na View (Interface)

<h:inputText id="id"
value="#{pessoafisicaController.selected.id}"
Ir p/ primeira
página
SOA – Arquitetura
Orientada a Serviços

Ir p/ primeira
página
 Serviços RestFul
 Abordagem para o desenvolvimento e o fornecimento de

serviços pela Internet.

 Sistemas que com arquitetura flexível.

 O conteúdo acessado a partir de um web service é tratado como

um recurso e é identificado por um URI (Uniform Resource

Identifier)

 URIs são utilizados em conjunto com as operações padrão do

protocolo HTTP (ex: GET, POST, PUT e DELETE) para acesso

aos recursos.

Ir p/ primeira
página
Computação em Nuvem

Ir p/ primeira
página
NOVOS RUMOS DA ES

PDS

Ir p/ primeira
página
FC - Tempo

Ir p/ primeira
página
 O que foi
solicitado pelo
Usuário

O que foi Especificado

pelo desenvolvedor

O que foi
Implementado
pelo
programador

O que era
necessário !

FC - Comunicação Ir p/ primeira
página
 CONSEQUÊNCIAS

 Software não atende as

necessidades do usuário;
 Desentendimentos entre
usuários e desenvolvedor;
 Perda de tempo e dinheiro;
 Problemas judiciários.

Ir p/ primeira
página
ENGENHARIA DE
SOFTWARE
PREOCUPA-SE: Com a
qualidade do Produto e do
Processo de Desenvolvimento
do Produto.
BUSCA: A criação de soluções
econômicas para problemas
práticos.
 COMPREENDE: Uma Metodologia
Integrada para o ciclo de vida do
software, baseada nas disciplinas:
Análise e Especificação
Projeto, Implementação e Teste
 Implantação e Manutenção

Ir p/ primeira
página
Coleta de Fatos

 Documentos
 Entrevistas
 Reuniões
 Questionários
 Observação

Ir p/ primeira
página
Metodologia
R U P - UML

Ir p/ primeira
página
NOVOS RUMOS DA ES

PDS

Ir p/ primeira
página
 Por que Ágil?
• Atualmente: mercado cada vez
mais competitivo -> Necessário
um diferencial que agregue valor
para o cliente e para a empresa.
• Desenvolvimento ágil está cada
vez mais popular.
• Google, Yahoo, IBM, Microsoft e
outras empresas já adotaram.

• O que significa ser ágil? Qual o

principal ganho com isso? Apenas
entregas mais rápidas?
• Um time que nunca trabalhou com
métodos ágeis será mais rápido
ou mais lento?
Ir p/ primeira
página
 Manifesto Ágil
Valorizar:
• Mais indivíduos e interações
do que processos e
ferramentas.
• A Documentação Essencial,
que deve acompanhar o
processo ágil.
• Mais a colaboração do cliente
do que a negociação do
contrato.
• Mais as respostas às
mudanças do que o
seguimento de um plano
previamente definido.
- Kent Beck et al.

Ir p/ primeira
página
 Inovação
• Atualmente o segredo de estar à frente
dos concorrentes é saber inovar.
• Para inovar, é preciso estar atento às
tendências do mercado.
• Agilidade = Respostas rápidas às
mudanças, atendendo às novas
necessidades que surgem.
• Mercado atual -> falsa ideia de que
atualmente todos só podem oferecer o
mesmo e que a diferença está apenas
no preço.
• Ainda há muito a inovar:
http://www.youtube.com/watch?v=Zp-
_oUwdSeY
Ir p/ primeira
página
 Como ser Ágil?
• Ser ágil significa seguir a filosofia do
desenvolvimento ágil.
• Um método ou processo é sempre
uma maneira de se trabalhar.
• Métodos ágeis são processos que
suportam a filosofia ágil. Ex: Scrum,
XP, e outros.
• Métodos ágeis são constituídos de
um conjunto de práticas. Algumas
práticas são: utilização de controle
de versão, determinação de padrões
de código, demonstrações semanais
às partes interessadas, etc. A
maioria das práticas existem há
anos. Os métodos ágeis buscam
selecionar as melhores.
Ir p/ primeira
página
 A equipe Ágil

Quais as principais vantagens em

desenvolver um projeto
individualmente? E em equipe?

Quais os principais desafios em

desenvolver um projeto
individualmente? E em equipe?

Ir p/ primeira
página
 Tamanho da Equipe Ágil
• Seguindo princípios ágeis:
equipes pequenas de 4 a 10
programadores.
• Para novas equipes: até 6
programadores.
• Tamanho total da equipe: até 20
membros, incluindo clientes,
testadores e gerentes de projeto.
• Quais as vantagens de uma
equipe pequena?
• Equipes maiores proporcionam
ganho de produtividade? Por
quê?

Ir p/ primeira
página
Papéis Desempenhados na Equipe

• De maneira geral, é possível

citar os seguintes papéis:
cliente on-site, gerente de
produto, especialista do
domínio, projetista de
interação, analista de
negócios, programador,
arquiteto, especialista técnico,
testador.

• Parte dos papéis citados pode

ser explícita na equipe ou
agregada a outros papéis.

Ir p/ primeira
página
Papéis Desempenhados na Equipe

Cliente: responsável por definir o

software que a equipe constrói. O
restante da equipe pode opinar,
mas o cliente é quem determina o
que tem valor para o produto. Está
sempre em contato com a equipe.
Prioriza o que deverá estar contido
na versão a ser entregue. O cliente
também é a principal fonte de
informações da equipe.
Gerente de Produto: Mantém e
promove a visão do produto. É o
P.O. Atua também como cliente.
Normalmente possui uma visão
profunda do mercado.
Ir p/ primeira
página
Papéis Desempenhados na Equipe

Especialista do domínio: Possui

uma visão profunda das regras de
negócio. Em equipes pequenas, o
gerente de produto também
pode atuar como especialista do
domínio.

Projetista de Interação: Ajuda a

definir a interface do usuário.
Concentra-se em compreender os
usuários, suas necessidades e
como eles irão interagir com o
produto. Algumas vezes o
projetista‫‏‬gráfico‫“(‏‬Designer”)‫‏‬
atua também como projetista
de interação. Ir p/ primeira
página
Papéis Desempenhados na Equipe

Analista de Negócios: Age como

ligação entre os clientes e os
desenvolvedores, esclarecendo e
refinando as necessidades dos
clientes. O Scrum Master pode
atuar como analista de negócios.

Programador ou desenvolvedor:
Elemento importante da equipe.
Contribui diretamente para a
criação do código do produto.
Responsável por minimizar custos,
encontrando maneiras mais
eficazes de entregar artefatos de
software.

Ir p/ primeira
página
 Papéis Desempenhados na Equipe
Arquiteto: Atua como guia ao longo
do projeto, buscando por maneiras
de simplificar projetos complexos.
Se empenha em definir estruturas
mais adequadas para o código e
busca por soluções tecnológicas
que facilitem a tarefa de
desenvolvimento.
Especialista Técnico: Apresenta o
conhecimento amplo em uma
determinada área (rede, banco de
dados, segurança, etc.).
Programador capaz de atuar em
diversas partes de um projeto, mas
que se especializa em uma
determinada área.
Ir p/ primeira
página
Papéis Desempenhados na Equipe

Testador: Ajuda a equipe a

produzir resultados de qualidade
desde o início. Ajuda os clientes a
identificar falhas nos requisitos e
auxilia nos testes de usuário.
Fornece informações sobre
características não funcionais do
código: desempenho,
escalabilidade, estabilidade, etc.

Recomendação: 1 testador para

cada 4 programadores.

Ir p/ primeira
página
 SCRUM
- Processo Ágil, Gerencial e
Incremental:
• Pressão relativa ao tempo;
• Competitividade do
mercado;
• Qualidade; e
• Otimiza Recursos.
- Times de desenvolvimento
pequenos (de 3 a 10 membros).
- Grandes projetos (mais times).
- Revisões frequentes do Processo.
- Trabalho Colaborativo.
Ir p/ primeira
página
 Participantes e Papéis
- Product Owner (PO)
• Ligação entre o cliente e o time
• É um dos mais importantes
Time de desenvolvimento
- Scrum Master:
• Líder que gerencia o time.
• Pode ser um dos desenvolvedores.
• Principal função é resolver “blocks”
que podem interromper o
desenvolvimento.
• Elo quando há um requisito que o
time não entendeu corretamente e
precisa falar com o PO
Ir p/ primeira
página
 Scrum na Prática
 O que fez desde a
reunião anterior.
 Obstáculos
encontrados.
 O que pretende fazer
até a próxima reunião.

Pendências

Ir p/ primeira
página
PDS ÁGIL
Incremental Evolutivo

Modelagem GUI

Requisitos
Projeto BD

Sprint 1
Validação Progamação

Programação
Planning

Ir p/ primeira
página
 Backlogs

- Produto:

• estórias do usuário

- Iterações (dos sprints):

• Tarefas que concretizam as

estórias do usuário

Ir p/ primeira
página
 SCRUM
Primeira Atividade:

- Criação dos times de desenvolvimento.

- Times com 7 membros.

- Os membros devem se apresentar
(nome, o que faz, conhecimentos
técnicos que possui).
- O time deve escolher 1 Scrum Master,
que ficará responsável por servir de
“ponte” entre o P.O e o time.

- Os times devem se apresentar para a

turma (nome de cada membro,
conhecimentos do time na área de
desenvolvimento Web, Scrum Master
escolhido). Ir p/ primeira
página
 Planejamento
- Relativamente curto.
- Design da arquitetura do sistema.
- Estimativas de datas e custos.
Backlog
- Definição de equipes e seus líderes
- Criação do backlog do produto:
• Participação de clientes e dos
times envolvidos na criação do
produto.
• Levantamento dos requisitos e
atribuição de prioridades.
- Definição dos sprints a serem
desenvolvidos.
Ir p/ primeira
página
 Planejamento
- Releases com base nas estórias do

usuário.

- Planejamento das iterações em nível

de tarefas.

• Tempo e esforço em dias

• Mínimo 0.5 dia

• Máximo 2 – 3 dias

Ir p/ primeira
página
 Requisitos
- Estórias do Usuário:
• “Como um usuário eu quero … a
fim de …”
• Critérios de aceitação / Como
demonstrar?
- Story points(para tasks):
• Tamanho abstrato (não
necessariamente associado a
tempo)
• 0, 1, 2, 3, 5, 8, 13 (sequência de
Fibonacci).
• “5” é 2 vezes mais complexo do
que “2” Ir p/ primeira
página
 Início do Sprint

- Equipe seleciona uma das estórias do

sprint e inicia o desenvolvimento.

- Cada membro do time escolhe uma

task e trabalha nela.

- Todo o código é sincronizado no

SVN.

- Equipe utiliza diversos meios de

comunicação durante o
desenvolvimento (skype, msn, telefone,
IRC).

Ir p/ primeira
página
 Início do Sprint

- O progresso do projeto vai sendo

acompanhado pelos stakeholders por
meio de um kanban.

- A cada dia são realizadas as daily

meetings, com duração de cerca de 15
minutos. Para times remotos, é ideal
utilizar recursos de vídeoconferência,
para tornar a reunião mais pessoal.

Ir p/ primeira
página
Kanban

Ir p/ primeira
página
 Sprint em curso
• Tasks em desenvolvimento são
colocadas na coluna “Doing” (ou
“In Progress”) no kanban.

• Tasks finalizadas são colocadas

na coluna “Done”.

• A relação tasks realizadas x

período do sprint pode ser
visualizada por meio de um
burndown chart.

Ir p/ primeira
página
 Sprint

- Cada time recebe uma parte do

backlog do Sprint para desenvolvimento

- O backlog não deve sofrer

modificações durante o Sprint

- Duração de 1 a 4 semanas
(recomendável 2 semanas)

- Sempre apresentam um produto com

funcionalidades que pode ser utilizado
pelo usuário.

Ir p/ primeira
página
 Scrum Diário
- Reuniões de 15 minutos de
duração.
- Gerenciada pelo líder (Scrum
Master) de cada equipe
- Todos respondem às perguntas:
• O que você fez desde o último
encontro diário?
• O que você planeja fazer após
esse e o próximo encontro
diário?
• O que o dificulta ou impede de
cumprir o que planeja (block)?
Ir p/ primeira
página
 Scrum Diário
- Benefícios:

• Maior integração entre os

membros da equipe.

• Rápida solução de problemas

(promove o compartilhamento de
conhecimento).

• Progresso medido continuamente

(minimização de riscos).
• Análise de gráfico de
acompanhamento em relação ao
Sprint.
Ir p/ primeira
página
 Gráfico de
Acompanhamento

Ir p/ primeira
página
 Sprint em curso

- Muitos testes são realizados

(extremamente importante)

- Alguns ajustes podem ser solicitados

pelo P.O e entrarem como tasks do
sprint (requer avaliação do impacto no
desenvolvimento).

- Se o andamento do desenvolvimento
superar as expectativas, algumas tasks
que não pertencem ao sprint podem ser
“puxadas” para o sprint atual.

Ir p/ primeira
página
Correções nas iterações

Ir p/ primeira
página
 Demonstração

- Deve obedecer à data de entrega

• Permitida a diminuição de
funcionalidades

- Apresentação do produto à clientes

e/ou diretores de marketing
• Sugestões de mudanças são
incorporadas ao backlog do
produto.

Ir p/ primeira
página
 Demonstração

- Produto pode até ser lançado no

mercado.

- Benefícios:
• Apresentar resultados concretos
ao cliente.
• Integrar e testar uma boa parte
do software.
• Motivação da equipe.

Ir p/ primeira
página
 Encerramento do Projeto
- Quando satisfaz os requisitos do
negócio.

- Atividades Finais:
• Testes de integração
• Testes de sistema
• Documentação do sistema
• Preparação de material de
treinamento
• Preparação de material de
marketing

Ir p/ primeira
página
 Documentação
Compreende:

• Modelo de Navegação

• User stories

• Arquitetura

• Lógica

• Física

• Modelo de Tipos ->refinado em

Modelo de Classes -> Modelo do
banco de dados

• Documentação de Código

Ir p/ primeira
página
 Documentação
Estória na forma de cartão

Modelo de Navegação
Modelo de Tipos Wire Frames e Mockups

04/02/2014

Vinícius Pereira

Ir p/ primeira
página
 Documentação

Diagrama de
User Story - Teste
Classes

04/02/2014

Ir p/ primeira
página
 Documentação
Modelo de Arquitetura

04/02/2014

68
Ir p/ primeira
página
 Exemplo
Veja SP para Crianças

Scrum na Prática – Interação Inicial

• Reunião com o cliente

• Definição da aplicação
(visão do produto)

• Negociação (escopo,
prazos, custos)

Ir p/ primeira
página
 Veja SP para Crianças
Scrum na Prática – Interação Inicial
- Geração de Mockups das interações
dos atores com a aplicação
- Os Mockups representam as interfaces
da aplicação e descrevem sua
navegação (modelo de navegação).

Ir p/ primeira
página
 Veja SP para Crianças
- Os mockups também podem conter
descrições de requisitos da aplicação
(os principais), facilitando a
comunicação com o usuário e
contribuindo para validar a proposta.

Ir p/ primeira
página
 Scrum na Prática – Startup
Sprint
- Cliente aprova os mockups
- Após a aprovação dos mockups, o
time de desenvolvimento se reúne com
o scrum master para uma discussão
sobre o projeto.
- O Scrum Master apresenta o projeto
- O time levanta pontos importantes
relacionados ao projeto e tira dúvidas
com o P.O.
- São levantadas questões técnicas e o
time busca saná-las antes do primeiro
Sprint. Ir p/ primeira
página
Scrum na Prática – Pré-Jogo
- O desenvolvimento pode ser iniciado.

- 1º passo: Reunião de planning.

• O(s) time(s) de desenvolvimento se

reúne(m).

• O Scrum Master apresenta a lista de

estórias do sistema e esclarece
dúvidas.

• O Backlog da aplicação começa a

ser definido, listando-se as estórias
da aplicação.

• O P.O (durante a reunião ou depois)

prioriza as estórias que deverão ser
atendidas durante o Sprint corrente.
Ir p/ primeira
página
 Veja SP para Crianças
Especificação das Estórias

Seguir o padrão:
Como {papel/ator} eu {verbo} + {requisito} para
{objetivo}

Exemplo:
Como comprador eu quero saber o preço e
disponibilidade para entrega de um livro
identificado pelo seu título e ano da edição.

Ir p/ primeira
página
Veja SP para Crianças – Lista de
Funcionalidades
Segunda Atividade: Elaborar
a lista de
estórias da aplicação SP Kids.
- Trata-se de uma aplicação que gerencia o
acesso a eventos de diversas categorias
que estejam ocorrendo em São Paulo.
- Os usuários conseguem selecionar
categorias e visualizar detalhes de
eventos, bem como buscar por um evento
específico.
- Os usuários podem visualizar o mapa do
local e a rota de acesso ao evento. Além
disso, eles podem telefonar para o local
do evento (se o telefone estiver
disponível) e recomendar o evento em
redes sociais (twitter e facebook).

Ir p/ primeira
página
 Veja SP para Crianças
Estórias e Sprints

Solução Parcial:

Ir p/ primeira
página
 Veja SP para Crianças
- As estórias devem ser priorizadas
junto ao cliente e também em função
das suas dependências;
-As estórias são organizadas em
sprints e particionadas em tasks;

- O time, considerando a priorização

de estórias feita pelo cliente, seleciona
um conjunto de estórias que serão
atendidas no sprint; e

- A quantidade de estórias
selecionada é definida com base na
velocidade do time (quantidade de
story points que o time consegue
“entregar” em um Sprint).
Ir p/ primeira
página
 Veja SP para Crianças
Reunião de planning

• O time estima as estórias segundo Story

Points.

- Lembrar: Uma estória é única para o

time e não pode ser comparada com um
Story Point de outro time.

• Considerar a estória mais “simples” e

atribuir à ela 1 Story Point.

• As estórias são detalhadas em Tarefas.

Ir p/ primeira
página
Divisão das estórias
em tasks

Ir p/ primeira
página
 Veja SP para
Crianças
Terceira Atividade: Elaboração de um
Kanban para as Estórias e suas Tarefas da
aplicação SP Kids.

Ir p/ primeira
página
 Veja SP para Crianças
Reunião de planning

• Estimar as outras estórias tomando

como referência a estória de 1 Story
Point.

• A estimativa deve ser feita jogando o

Planning Poker.

Ir p/ primeira
página
Panning Poker

Ir p/ primeira
página
 Veja SP para Crianças
Quarta Atividade: Planning Poker

- Dica: Embora a correspondência possa

não ser correta, para facilitar a estimativa
pode-se fazer a comparação 1 Story
Point = 1 dia ideal de trabalho.
Ir p/ primeira
página
Veja SP para Crianças
Story Points Definidos

Ir p/ primeira
página
 Veja SP para Crianças
- Se for a primeira Planning ?

- O time procura entrar em um consenso

sobre o número de Story Points que podem
ser atendidos no Sprint e então define a
quantidade de estórias do Sprint.

Ir p/ primeira
página
 Scrum na Prática –
Desenvolvimento (Início do Sprint)
- Equipe seleciona uma das estórias do sprint e
inicia o desenvolvimento.
- Cada membro do time escolhe uma task para
desenvolver.
- Todo o código é sincronizado usando algum
sistema SCM (Source Code Management).
- Equipe utiliza diversos meios de comunicação
durante o desenvolvimento (skype, msn, telefone).
- O progresso do projeto vai sendo acompanhado
pelos stakeholders por meio do kanban.
- A cada dia são realizados daily meetings, com
duração de cerca de 15 minutos. Para times
remotos, é ideal utilizar recursos de
vídeoconferência, para tornar a reunião mais
pessoal. Ir p/ primeira
página
 Veja SP para Crianças
- Tasks em desenvolvimento são colocadas
na coluna “In Progress”

- Tasks finalizadas são colocadas na coluna

“Done”

Ir p/ primeira
página
 Veja SP para Crianças
A relação tasks realizadas x período do
sprint pode ser visualizada por meio de um
burndown chart.

Ir p/ primeira
página
 Veja SP para Crianças
Artefatos
- São elaborados para facilitar a
compreensão do problema.

- Ex: Modelo de Navegação, Modelo de

Classes, Modelo de Banco, Modelo de
Arquitetura (Lógico), e Modelo de
Arquitetura (Físico)

- São utilizados pelo time para esclarecer

dúvidas sobre o projeto.

- Facilitam a manutenção e evolução

futura do software.

Ir p/ primeira
página
 Veja SP para Crianças

Modelo de Classes

Ir p/ primeira
página
 Veja SP para Crianças

Modelo de Banco

Ir p/ primeira
página
 Veja SP para Crianças
Modelo de Arquitetura (Lógico)

Evento.java Model

TelaBusca.jsp View

Controller
BuscaEventoBean.java

EventoDAO.java
Acesso via JPA
com EclipseLink

Base de Dados SP Kids

Ir p/ primeira
página
 Sprint em curso

Modelo de Arquitetura (Físico)

Ir p/ primeira
página
 Scrum na Prática –
Desenvolvimento (Sprint em curso)
- Scrum Master mantém contato com o
P.O.
- Blocks (qualquer coisa que esteja
impedindo a realização de uma task) que
surgem durante o desenvolvimento são
discutidos entre o Scrum Master e o P.O
para viabilizar o desenvolvimento o mais
rápido possível.
- P.O acompanha o desenvolvimento pelo
Kanban e o burndown chart.
- Em alguns casos, builds podem ser
enviadas ao P.O para apreciação antes da
Ir p/ primeira
demo da aplicação. página
 Scrum na Prática –
Desenvolvimento (Sprint em curso)
- Blocks:

Ir p/ primeira
página
 Scrum na Prática –
Desenvolvimento (Sprint em curso)
- O código da aplicação vai sendo
documentado e segue um padrão de
desenvolvimento definido pelo time

• Documentação de classe (descrição

breve e clara).

• Documentação de métodos (descrição

breve e clara).

• Documentação de trechos principais dos

métodos.

• Adoção de padrões para definição de

nomes de pacotes (ex: letras
minúsculas), classes (ex: primeira letra
maiúscula), etc.
Ir p/ primeira
página
 Veja SP para Crianças

Exemplo:

Ir p/ primeira
página
 Veja SP para Crianças
Exemplo:

Ir p/ primeira
página
 Veja SP para Crianças
- Muitos testes são realizados
(extremamente importante) -> Não esquecer
de colocar uma task de Testes para cada
estória.

- Alguns ajustes podem ser solicitados pelo

P.O . Entram como tasks do sprint (requer
avaliação do impacto no desenvolvimento).

- Se o andamento do desenvolvimento
superar as expectativas, algumas tasks que
não pertencem ao sprint podem ser
“puxadas” para o sprint atual.

Ir p/ primeira
página
 Veja SP para Crianças
- Ao final do sprint, é realizada uma reunião
com o P.O (ou o cliente) para uma
demonstração do projeto no estágio atual.

- O Cliente avalia o desenvolvimento e pode

gerar uma lista com débitos técnicos (algo
que ficou faltando) e com as modificações
desejadas.

- O Cliente prioriza as estórias restantes.

- Time recalcula a velocidade da equipe.

- Reinicia-se o novo sprint com a fase de

planning.
Ir p/ primeira
página
 Veja SP para Crianças
- No término do projeto. Gera-se a

Build final -> Será o release da aplicação.

- A aplicação é entregue para o cliente.

- A aplicação é colocada em produção.

Ir p/ primeira
página
Quais Princípios Ágeis Seguir?
• Priorizar a satisfação do cliente
por meio de entregas antecipadas
e contínuas de “software valioso”.
• Ser capaz de se adequar a
mudanças durante o processo de
desenvolvimento
• Integração diária das pessoas de
negócios e dos desenvolvedores.
• Construir projetos com pessoas
motivadas, prezando por um bom
ambiente de trabalho.
• Valorizar conversas “frente a
frente” -> mais rápido e eficiente.
• Atenção contínua à excelência
técnica e ao bom design
Ir p/ primeira
página
Quais Princípios Ágeis Seguir?

• Manter a simplicidade para

maximizar o tempo disponível.
• Refletir sobre como se tornar mais
eficaz, ajustando o comportamento
da equipe de acordo com as
conclusões -> Razão pela qual as
retrospectivas são importantes.
Conclusão: Os princípios ágeis são a
essência a ser seguida ao trabalhar
com métodos ágeis.

Ir p/ primeira
página
 Suporte Computacional

http://www.firescrum.com/

http://www.danube.com/scrumworks

http://www.icescrum.org/

www.pivotaltracker.com

www.github.com

Ir p/ primeira
página
 Plataforma Básica
- Java

- SGBDs

• MySQL e Postgres

- Servidores

• Tomcat

• Jboss

- Frameworks

- SVN para controle de versões

- IDE de desenvolvimento

- TDD

Ir p/ primeira
página
 Conclusão

 Divisão de responsabilidades

 papéis bem definidos

 Processo ágil e flexível

inúmeras mudanças no decorrer do

projeto

 Foco em controles e gerenciamento

minimiza risco

maximiza qualidade

 Times pequenos

 Colaboração

Ir p/ primeira
página
NOVOS RUMOS DA ES

PDS

Ir p/ primeira
página