SlideShare uma empresa Scribd logo
METODOLOGIAS ÁGEIS:
 GRUPO 4:
CAIO VINICIUS MENESES SILVA
JOÃO GABRIEL LEITE LIMA
LAYS CRUZ LOPES
LIZIANNE M. GOMES MENEZES SALES
MAICON MATHEUS SANTANA
ROBSON CORREIA LUZ
ROTEIRO
 1. Contextualização
 2. Kanban
 3. Scrum
 4. Xp
 5. Comparativo
 6. Considerações finais
 7. Referências
 8. Dúvidas
 Metodologia: fornece praticamente tudo que é necessário para
condução de um projeto. Diz o que e como fazer.
 Framework: apenas indica qual a trajetória, mas não indica
exatamente como fazer, existindo a possibilidade de ser
empregado juntamente com outros processos e técnicas.
1. METODOLOGIA X FRAMEWORK
1.1. SURGIMENTO DAS METODOLOGIAS ÁGEIS
 Na década de 1990 começaram a emergir modelos de
desenvolvimento;
 Alternativa a métodos dirigidos a planos;
 Pesquisas apontavam que apenas 16% dos projetos obtinham
sucesso;
 Modelos tradicionais foco maior na análise de requisitos;
 Modelos ágeis priorizam o software em si;
1.2 O QUE SÃO METODOLOGIAS ÁGEIS?
 Uma alternativa à gestão tradicional de projetos;
 Buscam promover um processo de gerenciamento de projetos
que incentiva a inspeção e adaptação frequente;
 Incentiva o maior trabalho em equipe, a auto-organização, a
comunicação frequente, o foco no cliente e a entrega de valor;
 Basicamente, os métodos ágeis são um conjunto de práticas
eficazes que se destinam a permitir a entrega rápida e de alta
qualidade do produto.
3.1. HISTÓRIA
 No final da década de 40, a Toyota começa e estudar
supermercados com a ideia de aplicar técnicas de prateleira;
 Os engenheiros da Toyota perceberam um processo que
refletia de acordo com os anteriores;
 A partir de então passaram a usar um cartão visão(Kanban)
para sinalizar passos em seu processo de fabricação.
3.1. HISTÓRIA
 O Kanban só foi utilizado como um método de
desenvolvimento ágil em 2007, na Corbis.
 O diretor de engenharia, David Anderson e sua equipe
projetam o Kanban para substituir a abordagem utilizada até
então.
 Com o passar dos meses fizeram uma serie de lançamentos
bem sucedidos junto com melhorias no processo.
 Desde então o Kanban vem ganhando respeito na comunidade
de desenvolvimento de software e mais empresas passaram a
adota-lo.
3.1. HISTÓRIA
3.2. CONCEITO
 É um método para implantação de mudanças que não descreve
práticas específicas.
 Ao invés, oferece princípios que buscam melhorar o
desempenho e reduzir o desperdício.
 Visa melhorar o desempenho e reduzir o desperdício,
eliminando atividades que não agregam valor para a equipe.
 O Kanban ajuda a assimilar e controlar o progresso de suas
tarefas devido a sua natureza visual.
3.2. CONCEITO
“Uma imagem vale mais que mil palavras” – Autor Desconhecido
 Fácil de ser implementado;
 Pouco prescritivo;
 Adaptável a qualquer ambiente.
3.2. CONCEITO
3.3. PRINCÍPIOS
Visualizar o fluxo de trabalho (workflow)
 O modelo visual gera benefícios como foco no “todo”,
transparência, identificação de desperdícios;
 Enxergando o contexto do outro se aumenta a comunicação e
colaboração;
 O Kanban proporciona uma visão ampla do que está sendo
feito, em qual etapa se encontra, quanto está pronto e o quanto
a equipe consegue entregar.
 Concede previsibilidade, tendo em mãos maior planejamento
e ciência de quando assumir responsabilidades.
3.3. PRINCÍPIOS
Limitar a quantidade de trabalho em andamento (WIP)
 Ao limitar o WIP, o ritmo da equipe se torna equilibrado,
sem se comprometer com muito trabalho de uma vez só;
 Reduz o tempo gasto em um item;
 Evita problemas com alternância de tarefas.
3.3. PRINCÍPIOS
Gerenciar e medir o fluxo
 Pode-se otimizar o Kanban coletando métricas e
indicadores de problemas futuros;
 Para se descobrir onde é preciso olhar e entender como o
trabalho está fluindo, analisar áreas problemáticas e
implementando mudanças que favoreçam a melhoria.
3.3. PRINCÍPIOS
Usar modelos para reconhecer oportunidades de melhoria
 Este princípio diz que se você não está melhorando
continuamente, mas está cumprindo todos os outros
requisitos do método Kanban, você está fazendo errado;
 É como utilizar uma metodologia ágil, mas não ser ágil;
 O Kanban sugere que modelos sejam usados para
implementar mudanças contínuas, incrementais e evolutivas;
 Exemplo: TOC, System thinking, 3 ms.
3.3. COMO É NA PRATICA
3.3. COMO É NA PRATICA
 Basicamente o KABAN possui três campos:
 To Do (para fazer);
 Doing (Em execução);
 Done (Finalizado).
 Kanban port;
 Os campos são abastecidos com cartões;
 Cada cartão deve conter apenas um tarefa.
3.3. COMO É NA PRATICA
3.3. COMO É NA PRATICA
 O kanban implementa conceitos da Teoria das Restrições
(TOC – Theory of Constraints) através de um modelo de
sistema “puxado”, procurando identificar e administrar
restrições que limitam a performance do sistema;
 Produção em um sistema de Just-in-Time (JIT).
O Just-in-Time é um sistema de administração da produção
que determina que nada deve ser produzido, transportado ou
comprado antes da hora exata. Ele pode ser aplicado em
qualquer organização, para reduzir estoques e os custos
decorrentes. Esse sistema também é um dos pilares do
toyotismo.
3.3. COMO É NA PRATICA
 O kanban pode ser utilizado em diversas áreas, como por
exemplo, desenvolvimento de software, gestão de TI, novos
negócios, design, finanças, marketing, operações, entre
outras.
UMA FORMA SIMPLES DE IMPLANTAR KANBAN
 Equipe;
 Identificando Estágios de Trabalho;
 Priorização;
 Medição e Melhoria Contínua.
UMA FORMA SIMPLES DE IMPLANTAR KANBAN
 Equipe
 É importante que a equipe esteja preparada para assimilar
os conceitos e princípios do kanban;
 Apresente os conceitos, princípios, e um exemplo básico
de uso do kanban e dos benefícios que a equipe poderá
obter com seu uso;
 Sempre é bom lembrar que, independentemente da
ferramenta, a equipe é a parte mais importante. Uma
equipe capacitada funciona bem com qualquer ferramenta,
enquanto que uma equipe incapaz geralmente falha
utilizando até mesmo o melhor dos métodos.
UMA FORMA SIMPLES DE IMPLANTAR KANBAN
 Identificando Estágios do Trabalho
 Identifique os Estágios de Trabalho que sua equipe segue
para concluir um produto, projeto ou serviço. O fluxo mais
comum começa em “TO DO” e termina em “DONE”,
geralmente com “WIP” (Working In Progress) no meio,
mas pode ser alterado para o que melhor se adaptar ao seu
contexto;
 Identifique as Classes de Trabalho, como, por exemplo
[user storie], [bug], [defeito], [melhoria], [teste],
[requisito], etc. que vão ajudar a categorizar o trabalho e
melhor organizar o quadro;
 Tente definir limites de tempo que cartões podem ficar em
determinados estágios, por exemplo, um cartão não pode
ficar mais que duas horas em “TO DO” se for do tipo
[defeito].
Exemplo de kanban com tarefas
UMA FORMA SIMPLES DE IMPLANTAR KANBAN
 Priorização
 Posicione o que é mais prioritário (tem que ser feito antes)
sempre na parte superior do kanban. Se desejar, pode
separar o quadro em categorias, mas mantendo entre elas
essa estrutura de priorização;
 Mantenha um controle constante do que é prioritário
identificando, sempre que possível, mudanças na ordem ou
novos cartões que sejam necessários. Dessa forma você
melhora a qualidade e reduz os custos, eliminando/adiando
o trabalho desnecessário.
UMA FORMA SIMPLES DE IMPLANTAR KANBAN
 Medição e Melhoria Contínua
 Estabeleça um sistema de medição simples como: trabalho
que precisa ser feito e o que foi feito até o instante;
 Simule os riscos durante a execução do trabalho,
procurando encontrar os gargalos antes que eles apareçam.
Isso ajuda a determinar planos de ação preventivos, que
diminuem consideravelmente os riscos.
UMA FORMA SIMPLES DE IMPLANTAR KANBAN
Backlog Análise Desenvolvimento Teste Entregue
NA PRÁTICA
3.4. APLICANDO KANBAN
 Para você aplicar o kanban nos processos da sua empresa é
preciso, antes de mais nada, engajar toda a sua equipe;
 É responsabilidade de cada um manter o painel escolhido
sempre atualizado e completo.
3.4. APLICANDO KANBAN
CONCLUSÃO
 O sistema kanban apresenta uma série de vantagens para os
funcionários e para a empresa.
 O kanban é um sistema autocontrolado e extremamente
simples de ser implementado;
 O kanban elimina a necessidade de controles por meio de
documentos formais, ele contribui para a desburocratização;
 O kanban valoriza o colaborador, fazendo com que ele
possa contribuir com sua experiência para o sucesso do
sistema;
 O kanban tem baixo custo de implantação.
4. ORIGEM
 A origem do termo Scrum vem do
Rugby. É o momento do jogo quando
a equipe está toda unida com um único
propósito em uma formação específica
onde a participação de todos é
essencial, a falta de comprometimento
de um membro pode fazer a formação
cair.
 A analogia do termo do Rugby para o
gerenciamento é simples. Ambos são
formados por uma equipe
estrategicamente definida, treinada e
organizada com um objetivo único.
4.1. HISTÓRICO
4.2. O QUE É SCRUM?
 O Scrum é um Framework dentro do qual pessoas
podem tratar e resolver problemas complexos e
adaptativos, enquanto produtiva e criativamente
entregam produtos com o mais alto valor possível.
4.2. CARACTERÍSTICAS
 Baseado no empirismo;
 Trabalha de forma iterativa e incremental ;
 Equipes multifuncionais e auto organizáveis;
Foco em:
 Prioridade: saber onde começar e o que é mais prioritário;
 Objetividade: metas menores atingíveis e claras;
 Visibilidade: do que está completo e as pendências;
4.3. COMO É NA PRÁTICA
4.2. O TIME SCRUM
 Product Owner
 Scrum Master
 Time de Desenvolvimento
4.2. PRODUCT OWNER - GERENCIA O PRODUCT
BACKLOG
Responsável por maximizar o valor do produto e do
trabalho do time.
 Representa todos os demais stakeholders;
 Responsável por definir a funcionalidade do produto;
 Responsável pelo gerenciamento do Product Backlog;
 Responsável pelo aceite do produto;
 Não é um comitê mas uma única pessoa;
 É o único responsável pela manutenção do Backlog;
 Não pode ser o Scrum Master;
 Define pra onde o time deve ir mas não como chegar lá.
4.2. SCRUM MASTER- GERENCIA O PROCESSO
Responsável por garantir que o Scrum seja entendido e aplicado.
 Garantir que as práticas do Scrum estão sendo seguidas;
 Treinar a equipe para que seja auto gerenciável e multifuncional;
 Garantir que o Product Owner está desempenhando seu trabalho;
 Remover impedimentos, visíveis e não-visíveis, internos e externos;
 Motivar e manter o trabalho em equipe;
 Assegurar a melhoria contínua;
 Gerenciar as expectativas.
4.2.TIME DE DESENVOLVIMENTO -
GERENCIAM A SI MESMO
Realiza o trabalho de entregar uma versão usável que potencialmente
incrementa o produto.
 Responsável por transformar os requisitos em um produto para o
usuário;
 Responsável pela entrega do produto e pela qualidade do mesmo;
 Compartilham as responsabilidades;
 Trabalham em equipe para desenhar, codificar, testar e o produto de
SW;
 Composto por membros necessários para tomar decisões e realizar
as tarefas;
 Em média de 6 a 10 pessoas.
4.3. BACKLOG DO PRODUTO
 É uma lista ordenada de tudo
que deve ser necessário no
produto;
 É uma origem única dos
requisitos para qualquer
mudança a ser feita no produto;
 Nunca está completo – é
dinâmico;
 Responsável: Product Owner;
 Seus itens possuem: Descrição,
ordem, estimativa e valor.
4.3. BACKLOG DA SPRINT
 É um conjunto de itens de Backlog do Produto selecionados
para a Sprint , e o plano para atingir o objetivo da Sprint;
 Pode ser alterado durante toda a Sprint;
4.3. EVENTOS SCRUM
 São previamente definidos;
 São utilizados para criar uma rotina e diminuir a necessidade
de reuniões não definidas no Scrum;
 Todo evento tem uma duração máxima;
 Sprint
 Reunião de Planejamento da Sprint;
 Reunião Diária;
 Trabalho de desenvolvimento;
 Revisão da Sprint;
 Retrospectiva da Sprint;
4.3. EVENTOS SCRUM
 Sprint:
 Plano de projeto (flexível) é definido;
 Duração: Um mês ou menos;
 Cancelamento da Sprint:
 Pode ocorrer se o seu objetivo se tornar obsoleto (Product Owner);
 Consome recursos, são traumáticos e incomuns.
4.3. EVENTOS SCRUM
 Reunião de Planejamento da Sprint:
 Criação de um plano com a colaboração de todo o time Scrum;
 Duração: Oito horas – para Sprints de um mês;
 Scrum Master;
 Questionamentos:
 O que pode ser entregue como resultado do incremento da próxima
Sprint? (Time de desenvolvimento)
 Como o trabalho necessário para entregar o incremento será
realizado? (Time de desenvolvimento)
4.3. EVENTOS SCRUM
 Reunião Diária: Time de desenvolvimento + Scrum Master
 Duração: 15 minutos;
 Objetivo: Sincronizar as atividades e criar o plano para as
próximas 24horas;
 Realização sempre no mesmo local e horário;
Esclarecimentos:
 O que eu fiz ontem que ajudou o Time de
Desenvolvimento a atender a meta da Sprint?
 O que eu farei hoje para ajudar o Time de
Desenvolvimento a atender a meta da Sprint?
 Eu vejo algum obstáculo que impeça a mim ou o Time de
Desenvolvimento no atendimento da meta da Sprint?
4.3. EVENTOS SCRUM
 Revisão da Sprint:
 Duração: 4 horas – Sprint de um mês;
 Objetivo: Verificar o incremento, e adaptar o backlog do
produto (se necessário);
 Resultado: Sprint + Backlog do produto revisados;
4.3. EVENTOS SCRUM
 Retrospectiva da Sprint:
 Duração: 3 horas – Sprint de um mês;
 Objetivo:
 Inspecionar como a última Sprint foi em relação às pessoas,
ao relacionamentos, aos processos e ferramentas;
 Identificar e ordenar os principais itens que foram bem e as
potenciais melhorias;
 Criar um plano para implementar melhorias no modo que o
Scrum faz seu trabalho;
 Ao final: Melhorias devem ser levantadas para serem aplicadas nas
próximas Sprints.
4.3. ARTEFATOS DO SCRUM
 Incremento:
 É a soma de todos os itens do Backlog do Produto
completados durante a Sprint;
 Ao final de uma Sprint, um novo incremento deve está
“Pronto”;
 “Pronto”: Versão incremental potencialmente utilizável.
4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING DE
VÍDEO PARA A INTERNET
 Time: Proprietário do Produto: Marcelo
ScrumMaster: Hugo
Equipe de Desenvolvimento: Moyses, Stelvio, Tiago;
 “User story”:
“O software será um sistema Web de streaming de vídeo, que permitirá
usuários na Internet mandem seus vídeos, que serão armazenados no
sistema e poderão ser gerenciados por seus donos e vistos pelo resto do
mundo através das visitas ao site. O sistema terá como funcionalidades
principais a conversão dos vídeos mandados para um codec leve que
permite qualidade e rapidez na visualização pela Internet; cadastro de
usuários; interface de gerenciamento de vídeos; comentários para os
vídeos e usuários; notas para vídeos; sistema de busca; reconhecimento
de sons dos vídeos; proteção contra SPAM; sistema de legendagem de
vídeos feitos por usuários; canais (grupos) de vídeos e usuários.”
4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING
DE VÍDEO PARA A INTERNET
Product Backlog
Reunião de Planejamento do Sprint
4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING
DE VÍDEO PARA A INTERNET
Modelagem de dados
Cadastro e gerenciamento de usuários
Conversão de vídeo para visualização na Internet (Codec)
Cadastro e gerenciamento de vídeos pelos usuários
Sprint1
4.4 APLICAÇÃO: SISTEMA WEB DE STREAMING
DE VÍDEO PARA A INTERNET
 Sendo assim, o ScrumMaster Hugo, junto à equipe de
desenvolvimento, define o Sprint Backlog, quebrando as
tarefas grandes em pequenas tarefas:
4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING
DE VÍDEO PARA A INTERNET
 Reuniões diárias SCRUM
O ScrumMaster Hugo irá acompanhar o desenvolvimento
através de reuniões diárias para se certificar que os
desenvolvedores Moyses, Stelvio e Tiago estejam
completando suas tarefas, estejam bem de saúde, bem
comprometidos com o projeto e se esforçando.
4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING
DE VÍDEO PARA A INTERNET
 Revisão final do Sprint
 Ao final do ciclo de desenvolvimento (Sprint), toda a
equipe se reune e vê quais são os resultados.
 O Proprietário do Produto Marcelo identifica todo o
progresso e revisa o programa. Ele, junto com o cliente,
concorda que os itens especificados para o Sprint foram
completos e esta primeira versão do sistema web é
satisfatória.
 Dá-se como concluído todos os itens do Sprint 1 no
Product Backlog.
4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING
DE VÍDEO PARA A INTERNET
 O processo inicia novamente!
 Agora no Sprint 2.
 Define-se os prazos e prioridades, e monta-se o plano de
desenvolvimento para o próximo ciclo de desenvolvimento
SCRUM.
5.1. HISTÓRIA
 Tem marco de criação em 1996 por Kent Beck e Ward
Cunningham, considerada uma metodologia nova e que está
em evolução;
 Porém a junção de princípios e boas práticas de programação
são frutos de um processo de evolução de pelo menos uma
década em que Kent e Ward trabalharam na Tektronixs, Inc.
como consultores de problemas em SmallTalk.
 Renega todos os paradigmas do desenvolvimento tradicional
de software;
 Ganhou destaque a partir da OOPLSA 2000 (a maior
conferência internacional de Orientação a Objetos);
 A primeira reação, foi bem complicada pois houve uma divisão
entre apoiadores e críticos que acusavam a metodologia de
avacalhamento de regras, o programador ficava muito livre.
5.1. HISTÓRIA
5.2. CONCEITO
 Segundo Beck (2000), XP é uma metodologia ágil para equipes
pequenas e médias (até 12 desenvolvedores), desenvolvendo
software com requisitos vagos ou que mudam frequentemente;
 Pode-se dizer também que, XP é uma metodologia para
desenvolvimento de software ágil, com qualidade e que atenda
as necessidades do cliente. Alguns praticantes definem a XP
como a prática e a perseguição da mais clara simplicidade,
aplicado ao desenvolvimento de software;
 A XP Busca o máximo de valor a cada dia de trabalho da equipe
para o seu cliente (entregas em curtos prazos) propondo
acompanhamento e reavaliação constante do código e do
projeto. Estando aberto a novos ajustes quando necessário.
 Se sustenta em cinco valores, que são:
COMUNI-
CAÇÃO
SIMPLICI-
DADE FEEDBACK CORAGEM RESPEITO
FEEDBACK RÁPIDO
PRESUNÇÃO
DE
SIMPLICIDADE
MUDANÇAS
INCREMENTAI
S
ABRAÇAR
MUDANÇAS
TRABALHAR
COM FOCO EM
QUALIDADE
 E reflete em cinco princípios, que são:
5.2. CONCEITO
5.3. PRÁTICA DO XP
 Para entendermos o funcionamento precisamos conhecer os
principais papéis presentes no XP.
GERENTE
DE
PROJETO
PROGRAMA-
DOR
TREINADOR
(COACH)
ACOMPANHA-
DOR
(TRACKER)
CLIENTE
 Para entendermos como é o funcionamento do XP vamos
estudar as práticas que o XP defende e propõe.
• Planejamento;
• Fases Pequenas;
• Design Simples;
• Testes;
• Refatoração;
• Programação em Pares.
5.3. PRÁTICA DO XP
 Para entendermos como é o funcionamento do XP vamos estudar
as práticas que o XP defende e propõe.
• Cliente Sempre Presente;
• Padronizações;
• Propriedade Coletiva;
• Integração Contínua;
• Semana de 40 horas.
 Por serem muitas práticas é difícil colocar todas em produção,
então é sugerido que seja iniciado com 3 ou 4 práticas e fazer um
plano para inserção das demais sempre avaliando se as práticas
inseridas anteriormente estão acontecendo da forma correta.
5.3. PRÁTICA DO XP
5.3. PRÁTICA DO XP
5.4. EXEMPLO DE APLICAÇÃO
 Ford Motors Company – Projeto de desenvolvimento do
VCAPS System, que era um Sistema de cálculo de custo de um
veículo. Usando metodologias tradicionais eles passaram
quarto anos e não tinham feito nem 30% do projeto. Após
adotar testes automatizados, integração contínua e outros
valores do XP, em um ano, o sistema foi desenvolvido e
evoluído constantemente sem maiores problemas.
 Chrysler – Utilizado no desenvolvimento do seu sistema de
folha de pagamento global que envolvia seus 90 mil
empregados ao redor de todo o mundo. Esse projeto tem 2.000
classes e 30.000 métodos, e foi para produção sem nenhum
atraso.
5.4. EXEMPLO DE APLICAÇÃO
5.5. EMPRESAS QUE UTILIZAM XP ATUALMENTE
 Objective Solutions: Empresa pioneira no uso de XP no Brasil. Sediada
em São Paulo, utilizando métodos ágeis, desenvolve sistemas de software
em Smalltalk e Java para várias empresas de médio e grande porte como,
por exemplo, a SKY Brasil.
 Paggo: Uma jovem empresa que desenvolve um produto inovador:
pagamentos com cartão de crédito através de telefone celular; o cartão de
crédito é operado pela própria operadora de telefonia móvel. O interessante
é que não só o sistema de software é desenvolvido usando XP mas também
todo o funcionamento da empresa é fortemente influenciado por métodos
ágeis. XP foi introduzido na empresa pelo AgilCooper Alexandre Freire em
2003.
 Caelum: A Caelum oferece treinamentos em desenvolvimento ágil para
Web 2.0 e também desenvolve soluções de negócio agilmente.
Desenvolvem o VRaptor, um arcabouço livre para desenvolvimento ágil de
aplicações Web em Java.
 LocaWeb: Maior empresa de hospedagens de sites da América Latina,
passou a utilizar Scrum e XP a partir de 2007.
 Forte Informática: Empresa de Fortaleza adotando práticas de XP.
6. SCRUM KABAN XP
Scrum Kanban XP
Objetivo
Uso de equipes multifuncionais, auto
organizadas e capacitadas que
dividem seu trabalho em curtos e
concentrados ciclos de trabalho
chamados Sprints.
Para aliviar os
impedimentos que
nos levam a levar
mais tempo para
entregar, não remover
peças necessárias do
processo.
Organizar as pessoas
para produzir software
de qualidade superior
de forma mais
produtiva.
Funções
Funções principais: Product Owner,
Scrum Master e
Scrum Team (Equipe)
Nenhuma função
existente. Algumas
equipes exigem a
ajuda de um treinador
ágil.
Acompanhador
(Tracker), Cliente,
Programador,
Treinador (coach),
Gerente de projeto.
Scrum Kanban XP
Principais
métricas
Velocidade de Sprint (2 semanas). Tempo de ciclo.
Tempo de iteração (2
semanas).
Mudança de
filosofia
As equipes devem se esforçar para
não fazer alterações na previsão de
sprint durante a sprint. Isso
compromete as aprendizagens em
torno da estimativa.
A mudança pode
acontecer a qualquer
momento.
Um alto grau de
disciplina de
desenvolvedores junto
com o envolvimento
contínuo do cliente
durante todo o projeto.
Cadência
Sprints regulares de comprimento
fixo.
Fluxo contínuo. Iteração.
Metodologia
de liberação
No final de cada sprint se aprovado
pelo proprietário do produto.
Entrega contínua ou a
critério da equipe.
No final da iteração.
6. SCRUM KABAN XP
7. E AGORA? QUAL METODOLOGIA ADOTAR?
KANBAN
8. REFERÊNCIA BIBLIOGRÁFICA
 http://blog.locaweb.com.br/artigos/metodologias-ageis/programacao-
extrema-extreme-programming-ou-simplesmente-xp/. Acesso em: 9
mar. de 2017.
 https://www.projectmanagement.com/blog-post/23006/Scrum-vs-
Kanban-vs-XP. Acesso em: 13 mar. de 2017.
 http://ccsl.ime.usp.br/agilcoop/empresas_ágeis. Acesso em: 13 mar. de
2017.
 http://www.devin.com.br/modelo-scrum/>. Acesso em: 13 de março de
2017.
 https://www.culturaagil.com.br/kanban-do-inicio-ao-fim/. Acesso em:
12 de março de 2017.
 https://www.culturaagil.com.br/o-que-sao-metodos-ageis/. Acesso em:
14 de março de 2017.
 http://www.devmedia.com.br/kanban-4-passos-para-implementar-em-
uma-equipe/30218. Acesso em: 13 de março de 2017.

Mais conteúdo relacionado

Mais procurados

Aula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de ProjetosAula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de Projetos
AyslanAnholon
 
Novembro Azul - VI SIPAT EMI 2014
Novembro Azul - VI SIPAT EMI 2014Novembro Azul - VI SIPAT EMI 2014
Novembro Azul - VI SIPAT EMI 2014
Carlos Lima
 
O Método Kanban
O Método KanbanO Método Kanban
O Método Kanban
Adriel Viana
 
Dinamica fabrica avioes 2.0
Dinamica fabrica avioes 2.0Dinamica fabrica avioes 2.0
Dinamica fabrica avioes 2.0
Thiago Torres MBA, ACP, PMP, CSM
 
Gerenciamento de projetos - Iniciação
Gerenciamento de projetos - IniciaçãoGerenciamento de projetos - Iniciação
Gerenciamento de projetos - Iniciação
Paulo Junior
 
Novembro Azul: Faça parte desse movimento!
Novembro Azul: Faça parte desse movimento!Novembro Azul: Faça parte desse movimento!
Novembro Azul: Faça parte desse movimento!
Oncoguia
 
PMBOK
PMBOKPMBOK
Novembro azul
Novembro azulNovembro azul
Cancer de Próstata
Cancer de PróstataCancer de Próstata
Cancer de Próstata
Ivanilson Gomes
 
Gestao De Projetos
Gestao De ProjetosGestao De Projetos
Scrum
ScrumScrum
A Fábrica de Aviões
A Fábrica de AviõesA Fábrica de Aviões
A Fábrica de Aviões
Leandro Faria
 
Aula 1 - Gestão da Qualidade
Aula 1 - Gestão da QualidadeAula 1 - Gestão da Qualidade
Aula 1 - Gestão da Qualidade
Unidade Acedêmica de Engenharia de Produção
 
Metodologia ágil das Desenvolvimento Adaptativo Software
Metodologia ágil das   Desenvolvimento Adaptativo SoftwareMetodologia ágil das   Desenvolvimento Adaptativo Software
Metodologia ágil das Desenvolvimento Adaptativo Software
Marilainny Martins da Silva
 
Gerenciamento dos Riscos em Projetos
Gerenciamento dos Riscos em ProjetosGerenciamento dos Riscos em Projetos
Gerenciamento dos Riscos em Projetos
Mauro Sotille, MBA, PMP
 
Mercado de Trabalho em TI
Mercado de Trabalho em TIMercado de Trabalho em TI
Mercado de Trabalho em TI
Norton Guimarães
 
Centralização vs Descentralização / Funções Administrativas
Centralização vs Descentralização / Funções AdministrativasCentralização vs Descentralização / Funções Administrativas
Centralização vs Descentralização / Funções Administrativas
Admturmapita
 
Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!
Annelise Gripp
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
Adolfo Neto
 
Slide novembro azul
Slide novembro azul Slide novembro azul
Slide novembro azul
amanda moura neris
 

Mais procurados (20)

Aula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de ProjetosAula Pronta - Gerenciamento de Projetos
Aula Pronta - Gerenciamento de Projetos
 
Novembro Azul - VI SIPAT EMI 2014
Novembro Azul - VI SIPAT EMI 2014Novembro Azul - VI SIPAT EMI 2014
Novembro Azul - VI SIPAT EMI 2014
 
O Método Kanban
O Método KanbanO Método Kanban
O Método Kanban
 
Dinamica fabrica avioes 2.0
Dinamica fabrica avioes 2.0Dinamica fabrica avioes 2.0
Dinamica fabrica avioes 2.0
 
Gerenciamento de projetos - Iniciação
Gerenciamento de projetos - IniciaçãoGerenciamento de projetos - Iniciação
Gerenciamento de projetos - Iniciação
 
Novembro Azul: Faça parte desse movimento!
Novembro Azul: Faça parte desse movimento!Novembro Azul: Faça parte desse movimento!
Novembro Azul: Faça parte desse movimento!
 
PMBOK
PMBOKPMBOK
PMBOK
 
Novembro azul
Novembro azulNovembro azul
Novembro azul
 
Cancer de Próstata
Cancer de PróstataCancer de Próstata
Cancer de Próstata
 
Gestao De Projetos
Gestao De ProjetosGestao De Projetos
Gestao De Projetos
 
Scrum
ScrumScrum
Scrum
 
A Fábrica de Aviões
A Fábrica de AviõesA Fábrica de Aviões
A Fábrica de Aviões
 
Aula 1 - Gestão da Qualidade
Aula 1 - Gestão da QualidadeAula 1 - Gestão da Qualidade
Aula 1 - Gestão da Qualidade
 
Metodologia ágil das Desenvolvimento Adaptativo Software
Metodologia ágil das   Desenvolvimento Adaptativo SoftwareMetodologia ágil das   Desenvolvimento Adaptativo Software
Metodologia ágil das Desenvolvimento Adaptativo Software
 
Gerenciamento dos Riscos em Projetos
Gerenciamento dos Riscos em ProjetosGerenciamento dos Riscos em Projetos
Gerenciamento dos Riscos em Projetos
 
Mercado de Trabalho em TI
Mercado de Trabalho em TIMercado de Trabalho em TI
Mercado de Trabalho em TI
 
Centralização vs Descentralização / Funções Administrativas
Centralização vs Descentralização / Funções AdministrativasCentralização vs Descentralização / Funções Administrativas
Centralização vs Descentralização / Funções Administrativas
 
Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!Scrum - Fundamentos, teorias e práticas!
Scrum - Fundamentos, teorias e práticas!
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
 
Slide novembro azul
Slide novembro azul Slide novembro azul
Slide novembro azul
 

Destaque

Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Rogerio P C do Nascimento
 
Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW
Rogerio P C do Nascimento
 
Métricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de SoftwareMétricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de Software
Rogerio P C do Nascimento
 
Gestão de Configuração de Software
Gestão de Configuração de Software Gestão de Configuração de Software
Gestão de Configuração de Software
Rogerio P C do Nascimento
 
Ferramentas CASE
Ferramentas  CASEFerramentas  CASE
Ferramentas CASE
Rogerio P C do Nascimento
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
Jéssica Silveira
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
Matheus Costa
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBR
affonsosouza
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Control
azarael2607
 
Apresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e KanbanApresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e Kanban
Manoela Oliveira
 
Plano de Projeto
Plano de ProjetoPlano de Projeto
Plano de Projeto
Anne Caroline
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
Matheus Mendonça
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
Instituto Federal de Sergipe
 
Powerful Questions for the Scrum Professional
Powerful Questions for the Scrum ProfessionalPowerful Questions for the Scrum Professional
Powerful Questions for the Scrum Professional
Carlton Nettleton
 
XP And Scrum Practices
XP And Scrum PracticesXP And Scrum Practices
XP And Scrum Practices
Naresh Jain
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Matheus Costa
 
Risk Management by Roger Pressman
Risk Management by Roger PressmanRisk Management by Roger Pressman
Risk Management by Roger Pressman
Rogerio P C do Nascimento
 
Introducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanIntroducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and Kanban
Dimitri Ponomareff
 
Slide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAFSlide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAF
Edton Lemos
 

Destaque (19)

Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e Planificações
 
Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW
 
Métricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de SoftwareMétricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de Software
 
Gestão de Configuração de Software
Gestão de Configuração de Software Gestão de Configuração de Software
Gestão de Configuração de Software
 
Ferramentas CASE
Ferramentas  CASEFerramentas  CASE
Ferramentas CASE
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBR
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Control
 
Apresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e KanbanApresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e Kanban
 
Plano de Projeto
Plano de ProjetoPlano de Projeto
Plano de Projeto
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Powerful Questions for the Scrum Professional
Powerful Questions for the Scrum ProfessionalPowerful Questions for the Scrum Professional
Powerful Questions for the Scrum Professional
 
XP And Scrum Practices
XP And Scrum PracticesXP And Scrum Practices
XP And Scrum Practices
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
 
Risk Management by Roger Pressman
Risk Management by Roger PressmanRisk Management by Roger Pressman
Risk Management by Roger Pressman
 
Introducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanIntroducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and Kanban
 
Slide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAFSlide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAF
 

Semelhante a Seminário - Scrum , Kaban e XP

Kanban em 10 passos.pdf
Kanban em 10 passos.pdfKanban em 10 passos.pdf
Kanban em 10 passos.pdf
MAPTreinamentoseDese
 
Kanban em 10 Passos
Kanban em 10 PassosKanban em 10 Passos
Kanban em 10 Passos
Bruno Feitosa
 
Processos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBanProcessos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBan
Samuel Cavalcante
 
ebook-kanban.pdf
ebook-kanban.pdfebook-kanban.pdf
ebook-kanban.pdf
ssuser55a1f81
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
Adriano Bertucci
 
Mini-curso Scrum e Kanban WES 2015
Mini-curso Scrum e Kanban WES 2015Mini-curso Scrum e Kanban WES 2015
Mini-curso Scrum e Kanban WES 2015
Stéfano H. dos Santos
 
Workshop Agile Planning para Coaches
Workshop Agile Planning para CoachesWorkshop Agile Planning para Coaches
Workshop Agile Planning para Coaches
Josemar Santos
 
Kanban & flight levels
Kanban & flight levelsKanban & flight levels
Kanban & flight levels
Thiago Lopes
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)
Caroline Seara
 
Método Kanban - Introdução ao sistema ágil adaptativo
Método Kanban - Introdução ao sistema ágil adaptativoMétodo Kanban - Introdução ao sistema ágil adaptativo
Método Kanban - Introdução ao sistema ágil adaptativo
Jefferson Affonso - PMP®, ITIL®, MCTS®, MBA
 
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...
Silvio Gonçalves
 
Kanban - Agilidade Fora da TI - Case Riachuelo
Kanban - Agilidade Fora da TI - Case RiachueloKanban - Agilidade Fora da TI - Case Riachuelo
Kanban - Agilidade Fora da TI - Case Riachuelo
Fábio Micheletti
 
Slides do vt1 kanban
Slides do vt1 kanbanSlides do vt1 kanban
Slides do vt1 kanban
Jônatas Ferreira
 
Sobre o Scrum
Sobre o ScrumSobre o Scrum
Sobre o Scrum
Juliana Amorim
 
Desenvolvimento Ágil de Software
Desenvolvimento Ágil de SoftwareDesenvolvimento Ágil de Software
Desenvolvimento Ágil de Software
Francke Peixoto
 
Metodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de SistemaMetodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de Sistema
Ricardo Antunes Fernandes
 
APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...
APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...
APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...
Luiz Carlos Monteiro Lopes Filho
 
Processos Ágeis
Processos Ágeis Processos Ágeis
Processos Ágeis
ProfThiagoAAlves
 
Benchmarking
BenchmarkingBenchmarking
Benchmarking
Rita de Cassia
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
Paulo Ricardo Dalmagro Vinck
 

Semelhante a Seminário - Scrum , Kaban e XP (20)

Kanban em 10 passos.pdf
Kanban em 10 passos.pdfKanban em 10 passos.pdf
Kanban em 10 passos.pdf
 
Kanban em 10 Passos
Kanban em 10 PassosKanban em 10 Passos
Kanban em 10 Passos
 
Processos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBanProcessos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBan
 
ebook-kanban.pdf
ebook-kanban.pdfebook-kanban.pdf
ebook-kanban.pdf
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
Mini-curso Scrum e Kanban WES 2015
Mini-curso Scrum e Kanban WES 2015Mini-curso Scrum e Kanban WES 2015
Mini-curso Scrum e Kanban WES 2015
 
Workshop Agile Planning para Coaches
Workshop Agile Planning para CoachesWorkshop Agile Planning para Coaches
Workshop Agile Planning para Coaches
 
Kanban & flight levels
Kanban & flight levelsKanban & flight levels
Kanban & flight levels
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)
 
Método Kanban - Introdução ao sistema ágil adaptativo
Método Kanban - Introdução ao sistema ágil adaptativoMétodo Kanban - Introdução ao sistema ágil adaptativo
Método Kanban - Introdução ao sistema ágil adaptativo
 
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...
 
Kanban - Agilidade Fora da TI - Case Riachuelo
Kanban - Agilidade Fora da TI - Case RiachueloKanban - Agilidade Fora da TI - Case Riachuelo
Kanban - Agilidade Fora da TI - Case Riachuelo
 
Slides do vt1 kanban
Slides do vt1 kanbanSlides do vt1 kanban
Slides do vt1 kanban
 
Sobre o Scrum
Sobre o ScrumSobre o Scrum
Sobre o Scrum
 
Desenvolvimento Ágil de Software
Desenvolvimento Ágil de SoftwareDesenvolvimento Ágil de Software
Desenvolvimento Ágil de Software
 
Metodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de SistemaMetodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de Sistema
 
APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...
APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...
APLICAÇÃO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E KANBAN NO GERENCIAMENTO...
 
Processos Ágeis
Processos Ágeis Processos Ágeis
Processos Ágeis
 
Benchmarking
BenchmarkingBenchmarking
Benchmarking
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
 

Último

Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Annelise Gripp
 
Por que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdfPor que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdf
Ian Oliveira
 
Como fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptxComo fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptx
tnrlucas
 
Teoria de redes de computadores redes .doc
Teoria de redes de computadores redes .docTeoria de redes de computadores redes .doc
Teoria de redes de computadores redes .doc
anpproferick
 
PRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product ownerPRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product owner
anpproferick
 
Orientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço BrasilOrientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço Brasil
EliakimArajo2
 
Gestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefíciosGestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefícios
Rafael Santos
 

Último (7)

Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
 
Por que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdfPor que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdf
 
Como fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptxComo fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptx
 
Teoria de redes de computadores redes .doc
Teoria de redes de computadores redes .docTeoria de redes de computadores redes .doc
Teoria de redes de computadores redes .doc
 
PRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product ownerPRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product owner
 
Orientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço BrasilOrientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço Brasil
 
Gestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefíciosGestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefícios
 

Seminário - Scrum , Kaban e XP

  • 1. METODOLOGIAS ÁGEIS:  GRUPO 4: CAIO VINICIUS MENESES SILVA JOÃO GABRIEL LEITE LIMA LAYS CRUZ LOPES LIZIANNE M. GOMES MENEZES SALES MAICON MATHEUS SANTANA ROBSON CORREIA LUZ
  • 2. ROTEIRO  1. Contextualização  2. Kanban  3. Scrum  4. Xp  5. Comparativo  6. Considerações finais  7. Referências  8. Dúvidas
  • 3.  Metodologia: fornece praticamente tudo que é necessário para condução de um projeto. Diz o que e como fazer.  Framework: apenas indica qual a trajetória, mas não indica exatamente como fazer, existindo a possibilidade de ser empregado juntamente com outros processos e técnicas. 1. METODOLOGIA X FRAMEWORK
  • 4. 1.1. SURGIMENTO DAS METODOLOGIAS ÁGEIS  Na década de 1990 começaram a emergir modelos de desenvolvimento;  Alternativa a métodos dirigidos a planos;  Pesquisas apontavam que apenas 16% dos projetos obtinham sucesso;  Modelos tradicionais foco maior na análise de requisitos;  Modelos ágeis priorizam o software em si;
  • 5. 1.2 O QUE SÃO METODOLOGIAS ÁGEIS?  Uma alternativa à gestão tradicional de projetos;  Buscam promover um processo de gerenciamento de projetos que incentiva a inspeção e adaptação frequente;  Incentiva o maior trabalho em equipe, a auto-organização, a comunicação frequente, o foco no cliente e a entrega de valor;  Basicamente, os métodos ágeis são um conjunto de práticas eficazes que se destinam a permitir a entrega rápida e de alta qualidade do produto.
  • 6.
  • 8.  No final da década de 40, a Toyota começa e estudar supermercados com a ideia de aplicar técnicas de prateleira;  Os engenheiros da Toyota perceberam um processo que refletia de acordo com os anteriores;  A partir de então passaram a usar um cartão visão(Kanban) para sinalizar passos em seu processo de fabricação. 3.1. HISTÓRIA
  • 9.  O Kanban só foi utilizado como um método de desenvolvimento ágil em 2007, na Corbis.  O diretor de engenharia, David Anderson e sua equipe projetam o Kanban para substituir a abordagem utilizada até então.  Com o passar dos meses fizeram uma serie de lançamentos bem sucedidos junto com melhorias no processo.  Desde então o Kanban vem ganhando respeito na comunidade de desenvolvimento de software e mais empresas passaram a adota-lo. 3.1. HISTÓRIA
  • 10. 3.2. CONCEITO  É um método para implantação de mudanças que não descreve práticas específicas.  Ao invés, oferece princípios que buscam melhorar o desempenho e reduzir o desperdício.  Visa melhorar o desempenho e reduzir o desperdício, eliminando atividades que não agregam valor para a equipe.  O Kanban ajuda a assimilar e controlar o progresso de suas tarefas devido a sua natureza visual.
  • 11. 3.2. CONCEITO “Uma imagem vale mais que mil palavras” – Autor Desconhecido
  • 12.  Fácil de ser implementado;  Pouco prescritivo;  Adaptável a qualquer ambiente. 3.2. CONCEITO
  • 13. 3.3. PRINCÍPIOS Visualizar o fluxo de trabalho (workflow)  O modelo visual gera benefícios como foco no “todo”, transparência, identificação de desperdícios;  Enxergando o contexto do outro se aumenta a comunicação e colaboração;  O Kanban proporciona uma visão ampla do que está sendo feito, em qual etapa se encontra, quanto está pronto e o quanto a equipe consegue entregar.  Concede previsibilidade, tendo em mãos maior planejamento e ciência de quando assumir responsabilidades.
  • 14. 3.3. PRINCÍPIOS Limitar a quantidade de trabalho em andamento (WIP)  Ao limitar o WIP, o ritmo da equipe se torna equilibrado, sem se comprometer com muito trabalho de uma vez só;  Reduz o tempo gasto em um item;  Evita problemas com alternância de tarefas.
  • 15. 3.3. PRINCÍPIOS Gerenciar e medir o fluxo  Pode-se otimizar o Kanban coletando métricas e indicadores de problemas futuros;  Para se descobrir onde é preciso olhar e entender como o trabalho está fluindo, analisar áreas problemáticas e implementando mudanças que favoreçam a melhoria.
  • 16. 3.3. PRINCÍPIOS Usar modelos para reconhecer oportunidades de melhoria  Este princípio diz que se você não está melhorando continuamente, mas está cumprindo todos os outros requisitos do método Kanban, você está fazendo errado;  É como utilizar uma metodologia ágil, mas não ser ágil;  O Kanban sugere que modelos sejam usados para implementar mudanças contínuas, incrementais e evolutivas;  Exemplo: TOC, System thinking, 3 ms.
  • 17. 3.3. COMO É NA PRATICA
  • 18. 3.3. COMO É NA PRATICA  Basicamente o KABAN possui três campos:  To Do (para fazer);  Doing (Em execução);  Done (Finalizado).  Kanban port;  Os campos são abastecidos com cartões;  Cada cartão deve conter apenas um tarefa.
  • 19. 3.3. COMO É NA PRATICA
  • 20. 3.3. COMO É NA PRATICA  O kanban implementa conceitos da Teoria das Restrições (TOC – Theory of Constraints) através de um modelo de sistema “puxado”, procurando identificar e administrar restrições que limitam a performance do sistema;  Produção em um sistema de Just-in-Time (JIT). O Just-in-Time é um sistema de administração da produção que determina que nada deve ser produzido, transportado ou comprado antes da hora exata. Ele pode ser aplicado em qualquer organização, para reduzir estoques e os custos decorrentes. Esse sistema também é um dos pilares do toyotismo.
  • 21. 3.3. COMO É NA PRATICA  O kanban pode ser utilizado em diversas áreas, como por exemplo, desenvolvimento de software, gestão de TI, novos negócios, design, finanças, marketing, operações, entre outras.
  • 22. UMA FORMA SIMPLES DE IMPLANTAR KANBAN  Equipe;  Identificando Estágios de Trabalho;  Priorização;  Medição e Melhoria Contínua.
  • 23. UMA FORMA SIMPLES DE IMPLANTAR KANBAN  Equipe  É importante que a equipe esteja preparada para assimilar os conceitos e princípios do kanban;  Apresente os conceitos, princípios, e um exemplo básico de uso do kanban e dos benefícios que a equipe poderá obter com seu uso;  Sempre é bom lembrar que, independentemente da ferramenta, a equipe é a parte mais importante. Uma equipe capacitada funciona bem com qualquer ferramenta, enquanto que uma equipe incapaz geralmente falha utilizando até mesmo o melhor dos métodos.
  • 24. UMA FORMA SIMPLES DE IMPLANTAR KANBAN  Identificando Estágios do Trabalho  Identifique os Estágios de Trabalho que sua equipe segue para concluir um produto, projeto ou serviço. O fluxo mais comum começa em “TO DO” e termina em “DONE”, geralmente com “WIP” (Working In Progress) no meio, mas pode ser alterado para o que melhor se adaptar ao seu contexto;  Identifique as Classes de Trabalho, como, por exemplo [user storie], [bug], [defeito], [melhoria], [teste], [requisito], etc. que vão ajudar a categorizar o trabalho e melhor organizar o quadro;  Tente definir limites de tempo que cartões podem ficar em determinados estágios, por exemplo, um cartão não pode ficar mais que duas horas em “TO DO” se for do tipo [defeito].
  • 25. Exemplo de kanban com tarefas UMA FORMA SIMPLES DE IMPLANTAR KANBAN
  • 26.  Priorização  Posicione o que é mais prioritário (tem que ser feito antes) sempre na parte superior do kanban. Se desejar, pode separar o quadro em categorias, mas mantendo entre elas essa estrutura de priorização;  Mantenha um controle constante do que é prioritário identificando, sempre que possível, mudanças na ordem ou novos cartões que sejam necessários. Dessa forma você melhora a qualidade e reduz os custos, eliminando/adiando o trabalho desnecessário. UMA FORMA SIMPLES DE IMPLANTAR KANBAN
  • 27.  Medição e Melhoria Contínua  Estabeleça um sistema de medição simples como: trabalho que precisa ser feito e o que foi feito até o instante;  Simule os riscos durante a execução do trabalho, procurando encontrar os gargalos antes que eles apareçam. Isso ajuda a determinar planos de ação preventivos, que diminuem consideravelmente os riscos. UMA FORMA SIMPLES DE IMPLANTAR KANBAN
  • 28. Backlog Análise Desenvolvimento Teste Entregue NA PRÁTICA
  • 29. 3.4. APLICANDO KANBAN  Para você aplicar o kanban nos processos da sua empresa é preciso, antes de mais nada, engajar toda a sua equipe;  É responsabilidade de cada um manter o painel escolhido sempre atualizado e completo.
  • 31. CONCLUSÃO  O sistema kanban apresenta uma série de vantagens para os funcionários e para a empresa.  O kanban é um sistema autocontrolado e extremamente simples de ser implementado;  O kanban elimina a necessidade de controles por meio de documentos formais, ele contribui para a desburocratização;  O kanban valoriza o colaborador, fazendo com que ele possa contribuir com sua experiência para o sucesso do sistema;  O kanban tem baixo custo de implantação.
  • 32.
  • 33. 4. ORIGEM  A origem do termo Scrum vem do Rugby. É o momento do jogo quando a equipe está toda unida com um único propósito em uma formação específica onde a participação de todos é essencial, a falta de comprometimento de um membro pode fazer a formação cair.  A analogia do termo do Rugby para o gerenciamento é simples. Ambos são formados por uma equipe estrategicamente definida, treinada e organizada com um objetivo único.
  • 35. 4.2. O QUE É SCRUM?  O Scrum é um Framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.
  • 36. 4.2. CARACTERÍSTICAS  Baseado no empirismo;  Trabalha de forma iterativa e incremental ;  Equipes multifuncionais e auto organizáveis; Foco em:  Prioridade: saber onde começar e o que é mais prioritário;  Objetividade: metas menores atingíveis e claras;  Visibilidade: do que está completo e as pendências;
  • 37. 4.3. COMO É NA PRÁTICA
  • 38. 4.2. O TIME SCRUM  Product Owner  Scrum Master  Time de Desenvolvimento
  • 39. 4.2. PRODUCT OWNER - GERENCIA O PRODUCT BACKLOG Responsável por maximizar o valor do produto e do trabalho do time.  Representa todos os demais stakeholders;  Responsável por definir a funcionalidade do produto;  Responsável pelo gerenciamento do Product Backlog;  Responsável pelo aceite do produto;  Não é um comitê mas uma única pessoa;  É o único responsável pela manutenção do Backlog;  Não pode ser o Scrum Master;  Define pra onde o time deve ir mas não como chegar lá.
  • 40. 4.2. SCRUM MASTER- GERENCIA O PROCESSO Responsável por garantir que o Scrum seja entendido e aplicado.  Garantir que as práticas do Scrum estão sendo seguidas;  Treinar a equipe para que seja auto gerenciável e multifuncional;  Garantir que o Product Owner está desempenhando seu trabalho;  Remover impedimentos, visíveis e não-visíveis, internos e externos;  Motivar e manter o trabalho em equipe;  Assegurar a melhoria contínua;  Gerenciar as expectativas.
  • 41. 4.2.TIME DE DESENVOLVIMENTO - GERENCIAM A SI MESMO Realiza o trabalho de entregar uma versão usável que potencialmente incrementa o produto.  Responsável por transformar os requisitos em um produto para o usuário;  Responsável pela entrega do produto e pela qualidade do mesmo;  Compartilham as responsabilidades;  Trabalham em equipe para desenhar, codificar, testar e o produto de SW;  Composto por membros necessários para tomar decisões e realizar as tarefas;  Em média de 6 a 10 pessoas.
  • 42. 4.3. BACKLOG DO PRODUTO  É uma lista ordenada de tudo que deve ser necessário no produto;  É uma origem única dos requisitos para qualquer mudança a ser feita no produto;  Nunca está completo – é dinâmico;  Responsável: Product Owner;  Seus itens possuem: Descrição, ordem, estimativa e valor.
  • 43. 4.3. BACKLOG DA SPRINT  É um conjunto de itens de Backlog do Produto selecionados para a Sprint , e o plano para atingir o objetivo da Sprint;  Pode ser alterado durante toda a Sprint;
  • 44. 4.3. EVENTOS SCRUM  São previamente definidos;  São utilizados para criar uma rotina e diminuir a necessidade de reuniões não definidas no Scrum;  Todo evento tem uma duração máxima;  Sprint  Reunião de Planejamento da Sprint;  Reunião Diária;  Trabalho de desenvolvimento;  Revisão da Sprint;  Retrospectiva da Sprint;
  • 45. 4.3. EVENTOS SCRUM  Sprint:  Plano de projeto (flexível) é definido;  Duração: Um mês ou menos;  Cancelamento da Sprint:  Pode ocorrer se o seu objetivo se tornar obsoleto (Product Owner);  Consome recursos, são traumáticos e incomuns.
  • 46. 4.3. EVENTOS SCRUM  Reunião de Planejamento da Sprint:  Criação de um plano com a colaboração de todo o time Scrum;  Duração: Oito horas – para Sprints de um mês;  Scrum Master;  Questionamentos:  O que pode ser entregue como resultado do incremento da próxima Sprint? (Time de desenvolvimento)  Como o trabalho necessário para entregar o incremento será realizado? (Time de desenvolvimento)
  • 47. 4.3. EVENTOS SCRUM  Reunião Diária: Time de desenvolvimento + Scrum Master  Duração: 15 minutos;  Objetivo: Sincronizar as atividades e criar o plano para as próximas 24horas;  Realização sempre no mesmo local e horário; Esclarecimentos:  O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?  O que eu farei hoje para ajudar o Time de Desenvolvimento a atender a meta da Sprint?  Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint?
  • 48. 4.3. EVENTOS SCRUM  Revisão da Sprint:  Duração: 4 horas – Sprint de um mês;  Objetivo: Verificar o incremento, e adaptar o backlog do produto (se necessário);  Resultado: Sprint + Backlog do produto revisados;
  • 49. 4.3. EVENTOS SCRUM  Retrospectiva da Sprint:  Duração: 3 horas – Sprint de um mês;  Objetivo:  Inspecionar como a última Sprint foi em relação às pessoas, ao relacionamentos, aos processos e ferramentas;  Identificar e ordenar os principais itens que foram bem e as potenciais melhorias;  Criar um plano para implementar melhorias no modo que o Scrum faz seu trabalho;  Ao final: Melhorias devem ser levantadas para serem aplicadas nas próximas Sprints.
  • 50. 4.3. ARTEFATOS DO SCRUM  Incremento:  É a soma de todos os itens do Backlog do Produto completados durante a Sprint;  Ao final de uma Sprint, um novo incremento deve está “Pronto”;  “Pronto”: Versão incremental potencialmente utilizável.
  • 51. 4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING DE VÍDEO PARA A INTERNET  Time: Proprietário do Produto: Marcelo ScrumMaster: Hugo Equipe de Desenvolvimento: Moyses, Stelvio, Tiago;  “User story”: “O software será um sistema Web de streaming de vídeo, que permitirá usuários na Internet mandem seus vídeos, que serão armazenados no sistema e poderão ser gerenciados por seus donos e vistos pelo resto do mundo através das visitas ao site. O sistema terá como funcionalidades principais a conversão dos vídeos mandados para um codec leve que permite qualidade e rapidez na visualização pela Internet; cadastro de usuários; interface de gerenciamento de vídeos; comentários para os vídeos e usuários; notas para vídeos; sistema de busca; reconhecimento de sons dos vídeos; proteção contra SPAM; sistema de legendagem de vídeos feitos por usuários; canais (grupos) de vídeos e usuários.”
  • 52. 4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING DE VÍDEO PARA A INTERNET Product Backlog Reunião de Planejamento do Sprint
  • 53. 4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING DE VÍDEO PARA A INTERNET Modelagem de dados Cadastro e gerenciamento de usuários Conversão de vídeo para visualização na Internet (Codec) Cadastro e gerenciamento de vídeos pelos usuários Sprint1
  • 54. 4.4 APLICAÇÃO: SISTEMA WEB DE STREAMING DE VÍDEO PARA A INTERNET  Sendo assim, o ScrumMaster Hugo, junto à equipe de desenvolvimento, define o Sprint Backlog, quebrando as tarefas grandes em pequenas tarefas:
  • 55. 4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING DE VÍDEO PARA A INTERNET  Reuniões diárias SCRUM O ScrumMaster Hugo irá acompanhar o desenvolvimento através de reuniões diárias para se certificar que os desenvolvedores Moyses, Stelvio e Tiago estejam completando suas tarefas, estejam bem de saúde, bem comprometidos com o projeto e se esforçando.
  • 56. 4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING DE VÍDEO PARA A INTERNET  Revisão final do Sprint  Ao final do ciclo de desenvolvimento (Sprint), toda a equipe se reune e vê quais são os resultados.  O Proprietário do Produto Marcelo identifica todo o progresso e revisa o programa. Ele, junto com o cliente, concorda que os itens especificados para o Sprint foram completos e esta primeira versão do sistema web é satisfatória.  Dá-se como concluído todos os itens do Sprint 1 no Product Backlog.
  • 57. 4.4. APLICAÇÃO: SISTEMA WEB DE STREAMING DE VÍDEO PARA A INTERNET  O processo inicia novamente!  Agora no Sprint 2.  Define-se os prazos e prioridades, e monta-se o plano de desenvolvimento para o próximo ciclo de desenvolvimento SCRUM.
  • 58.
  • 59. 5.1. HISTÓRIA  Tem marco de criação em 1996 por Kent Beck e Ward Cunningham, considerada uma metodologia nova e que está em evolução;  Porém a junção de princípios e boas práticas de programação são frutos de um processo de evolução de pelo menos uma década em que Kent e Ward trabalharam na Tektronixs, Inc. como consultores de problemas em SmallTalk.
  • 60.  Renega todos os paradigmas do desenvolvimento tradicional de software;  Ganhou destaque a partir da OOPLSA 2000 (a maior conferência internacional de Orientação a Objetos);  A primeira reação, foi bem complicada pois houve uma divisão entre apoiadores e críticos que acusavam a metodologia de avacalhamento de regras, o programador ficava muito livre. 5.1. HISTÓRIA
  • 61. 5.2. CONCEITO  Segundo Beck (2000), XP é uma metodologia ágil para equipes pequenas e médias (até 12 desenvolvedores), desenvolvendo software com requisitos vagos ou que mudam frequentemente;  Pode-se dizer também que, XP é uma metodologia para desenvolvimento de software ágil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prática e a perseguição da mais clara simplicidade, aplicado ao desenvolvimento de software;  A XP Busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente (entregas em curtos prazos) propondo acompanhamento e reavaliação constante do código e do projeto. Estando aberto a novos ajustes quando necessário.
  • 62.  Se sustenta em cinco valores, que são: COMUNI- CAÇÃO SIMPLICI- DADE FEEDBACK CORAGEM RESPEITO FEEDBACK RÁPIDO PRESUNÇÃO DE SIMPLICIDADE MUDANÇAS INCREMENTAI S ABRAÇAR MUDANÇAS TRABALHAR COM FOCO EM QUALIDADE  E reflete em cinco princípios, que são: 5.2. CONCEITO
  • 63. 5.3. PRÁTICA DO XP  Para entendermos o funcionamento precisamos conhecer os principais papéis presentes no XP. GERENTE DE PROJETO PROGRAMA- DOR TREINADOR (COACH) ACOMPANHA- DOR (TRACKER) CLIENTE
  • 64.  Para entendermos como é o funcionamento do XP vamos estudar as práticas que o XP defende e propõe. • Planejamento; • Fases Pequenas; • Design Simples; • Testes; • Refatoração; • Programação em Pares. 5.3. PRÁTICA DO XP
  • 65.  Para entendermos como é o funcionamento do XP vamos estudar as práticas que o XP defende e propõe. • Cliente Sempre Presente; • Padronizações; • Propriedade Coletiva; • Integração Contínua; • Semana de 40 horas.  Por serem muitas práticas é difícil colocar todas em produção, então é sugerido que seja iniciado com 3 ou 4 práticas e fazer um plano para inserção das demais sempre avaliando se as práticas inseridas anteriormente estão acontecendo da forma correta. 5.3. PRÁTICA DO XP
  • 67. 5.4. EXEMPLO DE APLICAÇÃO  Ford Motors Company – Projeto de desenvolvimento do VCAPS System, que era um Sistema de cálculo de custo de um veículo. Usando metodologias tradicionais eles passaram quarto anos e não tinham feito nem 30% do projeto. Após adotar testes automatizados, integração contínua e outros valores do XP, em um ano, o sistema foi desenvolvido e evoluído constantemente sem maiores problemas.
  • 68.  Chrysler – Utilizado no desenvolvimento do seu sistema de folha de pagamento global que envolvia seus 90 mil empregados ao redor de todo o mundo. Esse projeto tem 2.000 classes e 30.000 métodos, e foi para produção sem nenhum atraso. 5.4. EXEMPLO DE APLICAÇÃO
  • 69. 5.5. EMPRESAS QUE UTILIZAM XP ATUALMENTE  Objective Solutions: Empresa pioneira no uso de XP no Brasil. Sediada em São Paulo, utilizando métodos ágeis, desenvolve sistemas de software em Smalltalk e Java para várias empresas de médio e grande porte como, por exemplo, a SKY Brasil.  Paggo: Uma jovem empresa que desenvolve um produto inovador: pagamentos com cartão de crédito através de telefone celular; o cartão de crédito é operado pela própria operadora de telefonia móvel. O interessante é que não só o sistema de software é desenvolvido usando XP mas também todo o funcionamento da empresa é fortemente influenciado por métodos ágeis. XP foi introduzido na empresa pelo AgilCooper Alexandre Freire em 2003.  Caelum: A Caelum oferece treinamentos em desenvolvimento ágil para Web 2.0 e também desenvolve soluções de negócio agilmente. Desenvolvem o VRaptor, um arcabouço livre para desenvolvimento ágil de aplicações Web em Java.  LocaWeb: Maior empresa de hospedagens de sites da América Latina, passou a utilizar Scrum e XP a partir de 2007.  Forte Informática: Empresa de Fortaleza adotando práticas de XP.
  • 70. 6. SCRUM KABAN XP Scrum Kanban XP Objetivo Uso de equipes multifuncionais, auto organizadas e capacitadas que dividem seu trabalho em curtos e concentrados ciclos de trabalho chamados Sprints. Para aliviar os impedimentos que nos levam a levar mais tempo para entregar, não remover peças necessárias do processo. Organizar as pessoas para produzir software de qualidade superior de forma mais produtiva. Funções Funções principais: Product Owner, Scrum Master e Scrum Team (Equipe) Nenhuma função existente. Algumas equipes exigem a ajuda de um treinador ágil. Acompanhador (Tracker), Cliente, Programador, Treinador (coach), Gerente de projeto.
  • 71. Scrum Kanban XP Principais métricas Velocidade de Sprint (2 semanas). Tempo de ciclo. Tempo de iteração (2 semanas). Mudança de filosofia As equipes devem se esforçar para não fazer alterações na previsão de sprint durante a sprint. Isso compromete as aprendizagens em torno da estimativa. A mudança pode acontecer a qualquer momento. Um alto grau de disciplina de desenvolvedores junto com o envolvimento contínuo do cliente durante todo o projeto. Cadência Sprints regulares de comprimento fixo. Fluxo contínuo. Iteração. Metodologia de liberação No final de cada sprint se aprovado pelo proprietário do produto. Entrega contínua ou a critério da equipe. No final da iteração. 6. SCRUM KABAN XP
  • 72. 7. E AGORA? QUAL METODOLOGIA ADOTAR? KANBAN
  • 73. 8. REFERÊNCIA BIBLIOGRÁFICA  http://blog.locaweb.com.br/artigos/metodologias-ageis/programacao- extrema-extreme-programming-ou-simplesmente-xp/. Acesso em: 9 mar. de 2017.  https://www.projectmanagement.com/blog-post/23006/Scrum-vs- Kanban-vs-XP. Acesso em: 13 mar. de 2017.  http://ccsl.ime.usp.br/agilcoop/empresas_ágeis. Acesso em: 13 mar. de 2017.  http://www.devin.com.br/modelo-scrum/>. Acesso em: 13 de março de 2017.  https://www.culturaagil.com.br/kanban-do-inicio-ao-fim/. Acesso em: 12 de março de 2017.  https://www.culturaagil.com.br/o-que-sao-metodos-ageis/. Acesso em: 14 de março de 2017.  http://www.devmedia.com.br/kanban-4-passos-para-implementar-em- uma-equipe/30218. Acesso em: 13 de março de 2017.

Notas do Editor

  1. Comunicação – para um projeto de sucesso é necessária muita interação entre os membros da equipe, programadores, cliente, treinador. Para desenvolver um produto, o time precisa ter muita qualidade nos canais de comunicação. Conversas cara-a-cara são sempre melhores do que telefonemas, e-mails, cartas ou fax. Simplicidade – para atender rapidamente às necessidades do cliente, quase sempre um dos valores mais importantes é simplicidade. Normalmente o que o cliente quer é muito mais simples do que aquilo que os programadores constroem. Feedback – as respostas às decisões tomadas devem ser rápidas e visíveis. Todos devem ter, o tempo todo, consciência do que está acontecendo. Coragem – alterar um código em produção, sem causar bugs, com agilidade, exige muita coragem e responsabilidade. Respeito – todos têm sua importância dentro da equipe e devem ser respeitados e valorizados. Isso mantém o trabalho energizado
  2. 1 - Gerente de projeto - responsável por filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras. 2 - Programadores – foco central da metodologia, sem hierarquia. 3 - Treinador (ou coach) – pessoa mais experiente do time, responsável por lembrar os outros das regras do jogo (que são as práticas e os valores de XP). O treinador não precisa necessariamente ser o melhor programador da equipe e sim o que mais entende da metodologia XP. 4 - Acompanhador (ou tracker) – responsável por trazer para o time dados, gráficos, informações que mostrem o andamento do projeto e ajudem a equipe a tomar decisões de implementação, arquitetura e design. Algumas vezes o próprio coach faz papel de tracker. Outras o time escolhe sozinho quem exercerá este papel. 5 - Cliente – em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto para responder às dúvidas dos programadores.
  3. Planejamento – assim como no Scrum, existe uma fase de planejamento, quando desenvolvedores e cliente se encontram para priorizar e estimar histórias. Fases Pequenas – cada fase é chamada de iteração (Sprint no Scrum). Elas devem durar no máximo 30 dias, mas o ideal é que seja 15 ou até 7 dias. Design Simples – Nada de matar formigas com canhão! Testes – Kent Beck diz que código sem teste não existe. Os testes devem ser escritos de preferência antes do desenvolvimento (TDD – test driven development) e sempre devem rodar de forma automatizada. Refatoração – melhorar o design, entendimento do código e a capacidade de manutenção. Programação em Pares - fortalece o surgimento de melhores ideias. (Duas cabeças juntas são melhores do que 2 separadas) 1 piloto e 1 copiloto – melhor qualidade de código, revisão constante de código, nivelamento de equipe.
  4. Cliente Sempre Presente – muitas interações entre os steakholders. Padronizações – se todo o time seguir padrões pré-acordados de codificação, fácil será manter e entender o que já está feito. O uso de padrões é uma das formas de reforçar o valor comunicação. Propriedade Coletiva – O código fonte não pertence a um único programador. -- Resolvemos deixar em destaque pois nos ambientes atuais o código não pertence aos programadores, a depender do contrato ou é da empresa contratante ou da empresa desenvolvedora. Integração Contínua – depois dos testes, todas funcionalidades devem ser difundidas entre todos os desenvolvedores. – Em algumas empresas essa prática não é utilizada por ter alto custo no projeto onde só os lideres da equipe participam dessa integração contínua. Semana de 40 horas – perda de produtividade. – Quando se passa disso o bônus da produção é menor do que o ônus. Sabe-se também que, não se produz 40horas, o objetivo é buscar o número mais próximo 40h produtivas.