ARA0152 - MÉTODOS ÁGEIS COM SCRUM - CONSOLIDADO

Prévia do material em texto

RAUL QUEIRÓS
ARA0152 - MÉTODOS ÁGEIS COM SCRUM
AULA 01
FORMAÇÃO / EXPERIÊNCIA
FORMAÇÃO ACADÊMICA
Mestrando – Engenharia da Produção – CEFET 
Mestre em Sistemas de Gestão – UFF
 MBA – Gerenciamento de Projetos com Ênfase em TI – FGV
 MBA – Administração Estratégica – Estácio de Sá
 Tecnologia em Análise e Desenvolvimento de Sistemas – Univercidade
 Ciências Econômicas – Universidade Cândido Mendes
EXEPRIÊNCIA PROFISSIONAL
Gerente de Projetos – Grupo ENERGISA 
Consultor de Processos – Rede Globo 
Consultor de Qualidade – Farmanguinhos /FIOCRUZ
PMO – Resource IT – Implantação do SAP em Farmaguinhos/FIOCRUZ
Gerente de Projetos em Governança – Lojas Americanas S/A. 
Gerente de Projetos em TI – Contax S/A
Gerente de TI – Marlin Internet
EXPERIÊNCIA ACADEMICA
Docente Universidade Estácio de Sá – Graduação e Pós
Docente FIOCRUZ – Mestrado e Pós-Graduação 
Docente UNIABEU – Pós-Graduação – Finanças e Empresarial
Docente Escola do Exercito – Pós em Gestão de Saúde 
Docente das Faculdades São José – Graduação
Orientador de TCC – Pós-Graduação – UFRJ
AGENDA
CRÉDITO DIGITAL
PLANO DE ENSINO (PE)
PLANOS DE AULA (PA)
CONCEITOS DE PROJETOS 
GESTÃO TRADICIONAL x METODOS AGEIS
O QUE É CRÉDITO DIGITAL?
DISCIPLINAS AURA
CRÉDITO DIGITAL – http://estudante.estacio.br
GERENCIAMENTO DE PROJETOS
CRÉDITO DIGITAL – http://estudante.estacio.br
PLANO DE ENSINO E PLANOS DE AULAS
CRÉDITO DIGITAL – http://estudante.estacio.br
CRÉDITO DIGITAL
CRÉDITO DIGITAL
CRÉDITO DIGITAL – http://estudante.estacio.br
CRÉDITO DIGITAL – http://estudante.estacio.br
CRÉDITO DIGITAL – http://estudante.estacio.br
MATERIAIS DE AULAS
CRÉDITO DIGITAL – http://estudante.estacio.br
TRABALHOS E ATIVIDADES
PLANO DE ENSINO (PE)
TÓPICOS DE APRENDIZAGEM
PLANO DE ENSINO (PE)
TÓPICOS DE 
APRENDIZAGEM
PROCEDIMENTO 
DE AVALIAÇÃO
BIBLIOGRAFIA
PLANO DE AULA (PA)
PRIMEIRO CONCEITO
“O QUE SERVE PARA UMA EMPRESA PODE NÃO SERVIR PARA OUTRA!”
NÃO EXISTE RECEITA DE BOLO ! ! !
CONCEITOS BÁSICOS
DE PROJETOS
CONCEITOS BÁSICOS DE PROJETOS
Mas o que é um PROJETO?
RAULZINHO
CONCEITOS BÁSICOS DE PROJETOS
CONCEITOS BÁSICOS DE PROJETOS
“Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”
CONCEITOS BÁSICOS DE PROJETOS
“Um processo único, consistindo de um grupo de atividades coordenadas e controladas com datas para início e término, empreendido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos.”
CONCEITOS BÁSICOS DE PROJETOS
Otimização dos Recursos
Dois projetos possuem uma atividade igual, 
que tem o prazo estimado de execução de 15 dias. 
SEM PLANEJAMENTO
0
15
30
COM PLANEJAMENTO
0
15
30
Recursos A e B
Recursos A
Recursos A
PARA QUE SERVE O GERENCIAMENTO PROJETO?
PARA QUE SERVE O GERENCIAMENTO DE PROJETO?
Aumentar a eficiência e eficácia;
Diminuir os riscos;
Atender o negócio de forma mais flexível e acertada;
Justificar o Investimento.
NÃO EXISTE ALMOÇO DE GRAÇA
PARA QUE SERVE O GERENCIAMENTO DE PROJETO?
Gestão de projetos, gerência de projetos ou gerenciamento de projetos ou, ainda, administração de projetos é a área da administração que aplica os conhecimentos, as habilidades e as técnicas para elaboração de atividades relacionadas a um conjunto de objetivos pré-definidos, num certo prazo, com um certo custo e qualidade, através da mobilização de recursos técnicos e humanos.
NÃO EXISTE ALMOÇO DE GRAÇA
PARA QUE SERVE O GERENCIAMENTO DE PROJETO?
PLANEJADO
REALIZADO
X
CONCEITOS BÁSICOS DE PROJETOS
PROCESSOS
São procedimentos contínuos e repetitivos em uma organização, como por exemplo:
Compra de materiais;
Fabricação de um carro;
Gerenciamento da rede de computadores;
Manutenção preventiva da planta industrial;
Venda de produtos; 
Pagamento de fornecedores.
CONCEITOS BÁSICOS DE PROJETOS
EXEMPLO DE PROCESSO
GESTÃO DA MANUTENÇÃO 
CONCEITOS BÁSICOS DE PROJETOS
Histórico do Gerenciamento de Projetos
O gerenciamento de projetos não é novo. Tem sido usado por centenas de anos. Entre alguns exemplos de resultados de projeto estão:
As Pirâmides de Gizé;
Os Jogos Olímpicos,
A Grande Muralha da China;
O Taj Mahal;
A publicação de um livro infantil;
O Canal do Panamá;
O desenvolvimento de aviões comerciais;
A vacina contra a pólio;
Os seres humanos aterrissando na lua;
Os aplicativos de software comerciais;
Os dispositivos portáteis capazes de usar o sistema de posicionamento global (GPS); e
A colocação da Estação Espacial Internacional na órbita da Terra.
CONCEITOS BÁSICOS DE PROJETOS
Projetos são empreendidos em todos os níveis organizacionais. Um projeto pode envolver um único indivíduo ou um grupo. Um projeto pode envolver uma única organização ou múltiplas unidades organizacionais de múltiplas organizações.
Exemplos de projetos incluem, mas não estão limitadas a:
Desenvolvimento de um novo produto farmacêutico para o mercado;
Expansão de um serviço de guia turístico;
Fusão de duas organizações;
Melhoria de um processo de negócio em uma organização;
Aquisição e instalação de um novo sistema de hardware de computador para ser usado em uma organização;
Exploração de petróleo em uma região;
Modificação de um programa de software usado em uma organização;
Realização de pesquisas para desenvolver um novo processo de fabricação; e
Construção de um edifício.
CONCEITOS BÁSICOS DE PROJETOS
Empreendimento temporário. A natureza temporária dos projetos indica que eles têm um início e um término definidos. Temporário não significa necessariamente que o projeto seja de curta duração. O final do projeto é alcançado quando ocorrer um ou mais dos fatores a seguir:
Os objetivos do projeto foram alcançados;
Os objetivos não serão ou não poderão ser cumpridos;
Os recursos estão esgotados ou não estão mais disponíveis para alocação ao projeto;
A necessidade do projeto não existe mais (por exemplo, o cliente não quer mais o projeto concluído, uma mudança de estratégia ou prioridade encerram o projeto, o gerenciamento organizacional fornece uma instrução para terminar o projeto);
Recursos humanos e físicos não estão mais disponíveis; ou
O projeto é finalizado por motivo legal ou por conveniência.
CONCEITOS BÁSICOS DE PROJETOS
Os projetos trazem mudanças para as organizações
CONCEITOS BÁSICOS DE PROJETOS
O Projetos tem que agregar Valor.
Os projetos permitem a criação de valor de negócio. PMI define o valor de negócio como o benefício líquido quantificável derivado de um empreendimento de negócio. O benefício pode ser tangível, intangível ou ambos. 
O valor de negócios em projetos refere-se ao benefício que os resultados de um projeto específico fornece às suas partes interessadas. O benefício dos projetos pode ser tangível, intangível ou ambos.
Exemplos de elementos tangíveis:
Ativos monetários,
Capital acionário,
Serviços públicos,
Instalações,
Ferramentas, e
Participação de mercado.
Exemplos de elementos intangíveis:
Boa-fé,
Reconhecimento da marca,
Benefício público,
Marcas registradas,
Alinhamento estratégico, e
Reputação.
CONCEITOS BÁSICOS DE PROJETOS
De onde surgem, nas organizações, os PROJETO?
RAULZINHO
CONCEITOS BÁSICOS DE PROJETOS
Como nascem os Projetos?
CONCEITOS BÁSICOS DE PROJETOS
CONCEITOS BÁSICOS DE PROJETOS
E o Gerenciamento de Projetos para que serve?
RAULZINHO
CONCEITOS BÁSICOS DE PROJETOS
Aumentar a eficiência e eficácia;
Otimização dos Recursos;
Maior Controle das Atividades;
Diminuir os Riscos.
NÃO EXISTE ALMOÇO DE GRAÇA
CONCEITOS BÁSICOS DE PROJETOS
Aumentar a Eficiência e Eficácia
Eficiência: conseguir o melhor rendimento com o mínimo de erros e/ou dispêndios.
Eficácia: produzir atividades de forma competente. 
CONCEITOS BÁSICOS DE PROJETOS
Aumentar a Eficiência e Eficácia
Fazer Correto!!!!
Fazer Mais com Menos!!!!
CONCEITOS BÁSICOS DE PROJETOS
Otimização dos Recursos
CONCEITOS BÁSICOS DE PROJETOS
Maior Controle das Atividades
CONCEITOS BÁSICOS DE PROJETOSMaior Controle das Atividades
CONCEITOS BÁSICOS DE PROJETOS
Maior Controle das Atividades
EXEMPLO – CENÁRIO 1
Você contrata um pintor para pintar o quarto da sua filha, pois ela irá nascer. O pintor informa que o prazo para execução do serviço é de 4 dias (um dia para cada parede). 
No final do primeiro dia você liga para ele, e pergunta como está andando o trabalho. Ele responde que está PINTANDO!
No final do segundo dia você liga para ele, e pergunta como está andando o trabalho. Ele responde que está PINTANDO!
VOCÊ ESTÃ CONTROLANDO AS ATIVIDADES?
CONCEITOS BÁSICOS DE PROJETOS
Maior Controle das Atividades
EXEMPLO – CENÁRIO 2
Você contrata um pintor para pintar o quarto da sua filha, pois ela irá nascer. O pintor informa que o prazo para execução do serviço é de 4 dias (um dia para cada parede). O seguinte cronograma foi entregue: 
CONCEITOS BÁSICOS DE PROJETOS
Maior Controle das Atividades
EXEMPLO – CENÁRIO 2 
No final do primeiro dia você liga para ele, e pergunta se ele pintou a PAREDE 01! Se a resposta for SIM, o projeto está conforme planejado, se NÃO o projeto está 25% atrasado.
No final do segundo dia você liga para ele, e pergunta se ele pintou a PAREDE 02!
No final do segundo dia você liga para ele, e pergunta se ele pintou a PAREDE 03!
No final do segundo dia você liga para ele, e pergunta se ele pintou a PAREDE 04!
VOCÊ ESTÃ CONTROLANDO AS ATIVIDADES?
CONCEITOS BÁSICOS DE PROJETOS
DIMINUIR OS RISCOS
Probabilidade de algo ocorrer, positivo ou negativo.
CONCEITOS BÁSICOS DE PROJETOS
GERENCIAMENTO DE PROJETOS EFICAZ
Ajuda indivíduos, grupos e organizações públicas e privadas a:
Cumprirem os objetivos do negócio;
Satisfazerem as expectativas das partes interessadas;
Serem mais previsíveis;
Aumentarem suas chances de sucesso;
Entregarem os produtos certos no momento certo;
Resolverem problemas e questões;
Responderem a riscos em tempo hábil;
Otimizarem o uso dos recursos organizacionais;
Identificarem, recuperarem ou eliminarem projetos com problemas;
Gerenciarem restrições (por exemplo, escopo, qualidade, cronograma, custos, recursos);
Equilibrarem a influência de restrições do projeto (por exemplo, o aumento de escopo pode aumentar custos ou o prazo); e
Gerenciarem melhor as mudanças.
CONCEITOS BÁSICOS DE PROJETOS
Os projetos mal gerenciados ou a ausência do gerenciamento de projetos podem resultar em:
Prazos perdidos,
Estouros de orçamento,
Má qualidade,
Retrabalho,
Expansão descontrolada do projeto,
Perda de reputação para a organização,
Partes interessadas insatisfeitas, e
Incapacidade de alcançar os objetivos para os quais o projeto foi empreendido.
GERENCIAMENTO DE PROJETOS MAL EXECUTADO
CONCEITOS BÁSICOS DE PROJETOS
PROJETOS, PROGRAMA E PORTIFÓLIO
CONCEITOS BÁSICOS DE PROJETOS
	Gerenciamento de Projetos Organizacionais			
		Projetos	Programas	Portfólios
	Definição	Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado único.	Um programa é um grupo de projetos, programas subsidiários e atividades de programa relacionados, gerenciados de modo coordenado visando a obtenção de benefícios que não estariam disponíveis se eles fossem gerenciados individualmente.	Um portfólio é um conjunto de projetos, programas, portfólios subsidiários e operações gerenciados em grupo para alcançar objetivos estratégicos.
CONCEITOS BÁSICOS DE PROJETOS
SUBPROJETOS
Para um melhor planejamento e controle, um projeto pode ser dividido em subprojetos. Subprojeto, portanto, é um subconjunto de um projeto e pode ser gerenciado por um membro da equipe, empresa externa ou por outra unidade funcional da empresa. A figura abaixo demonstra o relacionamento entre programa, projetos e subprojetos:
CONCEITOS BÁSICOS DE PROJETOS
STAKEHOLDERS
Pessoas e organizações, como clientes, patrocinadores, organizações executoras e o público, que estejam ativamente envolvidas no projeto ou cujos interesses possam ser afetados de forma positiva ou negativa pela execução ou término do projeto. Elas podem também exercer influência sobre o projeto e suas entregas. 
CONCEITOS BÁSICOS DE PROJETOS
SPONSOR
É o Patrocinador e Responsável direto pelo projeto. Normalmente, pode ser o presidente da empresa (CEO) ou o diretor de operações ou alguém ligado diretamente ao presidente. Em projetos diferentes do projeto de implantação, o Sponsor poderá ser o diretor ou superintendente da TI.
CONCEITOS BÁSICOS DE PROJETOS
O que é um PROJETO de sucesso?
RAULZINHO
CONCEITOS BÁSICOS DE PROJETOS
PROJETO DE SUCESSO
É o que atende todas as expectativas das partes envolvidas no projeto (Stakeholders).
CONCEITOS BÁSICOS DE PROJETOS
CAUSAS DE SUCESSO DO PROJETO
Os detalhes são cuidadosamente administrados
O panorama geral é compreendido
As decisões são tomadas rapidamente
A comunicação é desenfreada
Os riscos são mantidos sob controle
As expectativas são adequadamente gerenciadas
Aprovações e autorizações são respeitadas
Todos estão envolvidos durante o andamento do projeto
Reuniões são realizadas regularmente
São cultivados bons relacionamentos patrocinadores do projeto
CONCEITOS BÁSICOS DE PROJETOS
CAUSAS DE SUCESSO DO PROJETO
Estudo de Viabilidade incompleto ou incorreto. 
Frequentes mudanças de escopo 
Frequentes alterações de prioridade entre os projetos da carteira, vindas da alta administração 
Prazos inexequíveis 
Tamanho da carteira de projetos muito além da capacidade de atendimento do setor. 
Comprometimento insuficiente ou inadequado das áreas usuárias envolvidas.
Comprometimento insuficiente ou inadequado da alta administração 
Falta de recursos humanos, financeiros e materiais. 
Precariedade de método, ferramentas e técnicas para o gerenciamento dos projetos. 
Insuficiente capacidade gerencial dos Gerentes de Projetos 
Habilidade técnica da equipe, em T.I., insuficiente ou inadequada para os desafios 
Riscos não adequadamente gerenciados 
CONCEITOS BÁSICOS DE PROJETOS
CAUSAS DE SUCESSO DO PROJETO
CONCEITOS BÁSICOS DE PROJETOS
TRÍPLICE RESTRIÇÃO PARA PROJETOS
CONCEITOS BÁSICOS DE PROJETOS
CICLO DE VIDA DO PROJETO
CONCEITOS BÁSICOS DE PROJETOS
MUDANÇAS NAS EMPRESAS – EMPRESAS MATRICIAL
CONCEITOS BÁSICOS DE PROJETOS
MUDANÇAS NAS EMPRESAS – EMPRESAS PROJETIZADA
ESTUDO DE CASO
ESTUDO DE CASOS SEM SUCESSO
Uma grande rede varejos, em franca expansão (com mais de 1000 lojas no Brasil), está abrindo mais uma loja em um shopping do Rio de Janeiro, onde a empreiteira, instala 1000m2 de piso errado, de quem é o erro? 
ESTUDO DE CASOS SEM SUCESSO
ERRO: Não existia documentado um método de controle de requisitos, entre as práticas de gerenciamento do projeto.
ESTUDO DE CASOS SEM SUCESSO
A mesma rede de varejo, recebeu o mobiliário da loja sem o piso estar pronto, de quem é o erro? 
ESTUDO DE CASOS SEM SUCESSO
ERRO: Falta de relação entre as atividades, e comunicação no projeto. 
Status Report 
 02/10/2013
LOJAS AMERICANAS
Segregação de Funções
‹nº›
Onde estamos ?
	Fase	Atividade	Julho			Agosto				Setembro					Outubro				Novembro				Dezembro			
			15	22	29	5	12	19	26	2	9	16	23	30	7	14	21	28	4	11	18	25	2	9	16	23
	Planejamento	Cronograma (EY)																								
	Matriz e Diagnóstico de SoD	Matriz e Diagnóstico de SoD
(LASA e EY)																								
	Remediação de Perfis	Elaboração dos templates do Plano de Remediação (EY)																								
		Agendamento das Reuniões com Responsáveis (LASA)																								
		Elaboração do Plano de Remediação e Instrução de Ajuste (LASA e EY)																								
		Validação do Plano de Remediação / Instrução de Ajuste (LASA)																								
		Ajuste e teste dos Perfis (LASA)																								
		Transporte dos Perfis para PRD (LASA)																								
	Remediação de Usuários	Remediação de Usuários (LASA e EY)																								
	Governança de TI	Elaboração do Relatório de GAP Análise de Governança de TI (EY)																								
	Encerramento	Apresentação dos Resultados (EY)Gerenciamento do Projeto	Reuniões de Checkpoint (LASA e EY)																								
Relatório Final e Aceite dos Serviços EY.
Planejado
Andamento
Atividades LASA
Replanejado
Legenda:
Hoje – 39%
Planejado – 40%
Entregáveis (Milestones)




‹nº›
Como estamos ?
	Etapas	Status	% Plan	% Real
	Planejamento		100	100
	Atualização da Matriz de SoD e Diagnóstico de SoD		100	100
	Remediação de Perfis		10	8
	Remediação de Usuários	-	-	-
	Governança de TI (Atividade Antecipada)		100	100
	Encerramento	-	-	-
	Legenda	
	Concluído	
	Em andamento	
	Atrasado	
‹nº›
LASA - Segregação de Funções
Planejado	41470	41477	41484	41491	41498	41505	41512	41519	41526	41533	41540	41547	41554	41561	41568	41575	41582	41589	41596	41603	41610	41617	41624	41631	0	1	2	3	7	17	27	33	34	36	37	40	44	51	56	64	69	75	76	78	81	87	93	99	Realizado	41470	41477	41484	41491	41498	41505	41512	41519	41526	41533	41540	41547	41554	41561	41568	41575	41582	41589	41596	41603	41610	41617	41624	41631	0	1	2	5	11	20	30	33	34	36	37	39	
	Atividades Realizadas/Em andamento		Próximos Passos
	Frente III – Remediação de Perfis
 Agendamento de reuniões com responsáveis (LASA);
 Reuniões de Remediação (LASA/EY).
 Validação dos planos de remediação (LASA).
		Frente III – Remediação de Perfis
 Continuação da atividades iniciadas na semana anterior (EY).
	Pontos de Atenção		Pontos Pendentes
	 A área de comercial ficou responsável por verificar com seus profissionais as transações utilizadas e não utilizadas por eles. Foi estabelecido o dia 02/10/2013 para o retorno destas informações e realização de nova reunião de remediação;
 Verificar com LASA o andamento da implementação do processo de Governança de TI;
 Foi identificado um desalinhamento entre Função(Role) x Perfil(Profile);
 A área de logística ficou responsável por verificar com os CD’s as transações utilizadas e não utilizadas por eles. Foi estabelecido o dia 30/09/2013 para retorno destas informações e realização de nova reunião de remediação;
 Validação do plano de Remediação dos perfis de RH:
 - Validação do Funcional – OK
 - Validação do Gestor – NOK (27/09/2013)
		 Nenhum ponto pendente até o momento.
Visão Geral
Concluído
Em andamento
Atrasado
‹nº›
Próxima Reunião
Próximo encontro Dia 09/10/2013
‹nº›
Juntos podemos ir mais longe.
Status Report
Semana 63 de 112 – 11-05-2015
Agenda do Status Report
Pendências Críticas
Status Geral
Variação do SPI
Cronograma Macro
Entregáveis por fase
Status dos BBP´s, ESF´s e CMD´s
Geral de Pendências 
Principais Riscos
Solicitações de Mudança
Pendências Críticas
	2	Indefinição dos Cenários de Testes por parte dos usuários-chave (Unitários e Integrados)	15/04
22/04
30/04
	5	Planilha de Carga de Materiais (e demais CMDs – 43)	10/06
	4	Lay-out do arquivo do SIAFI e credenciais de comunicação	17/04
22/04
27/04
30/04
	6	Salas de Treinamento	06/05
	3	Definição do WF de Cadastro de Materiais e Fornecedores	05/05
	1	Assinatura dos BBPs	31/12
Status Geral
Sumário Executivo
	Escopo		Cronograma	
	Riscos		Participação	
	Status Geral .			
 OK
 Atenção
 Problema
	Principais realizações	Principais Pendências	Próximos passos
	Continuação dos Testes Unitários
Workshop de Processos (usuários chave) 
	Ver slide de pendências críticas e pendências gerais	Validar Especificações e Migrações (de acordo com disponibilidade)
Acelerar Migrações de dados
Finalização dos Testes Unitários
Refinamento da Grade de Treinamento
Sumário por Área de Negócio
	Almoxarifado		Projetos	
	Compras		PCP / Produção	
	Financeiro		Qualidade	
	Manutenção		Vendas	
	Planejamento		GMO	
	SPI	0,94	
Variação do SPI (*)
Geração de nova linha base
	JAN
01 15 31	FEV
01 15 28	MAR
01 15 31	ABR
01 15 30	MAI
01 15 31	JUN
01 15 30
						
Cronograma Macro – Fase 3 Realização
Elaborar Caso de Testes Unitário
Executar Teste Unitários
Executar Migração e Limpeza de Dados
Testes Integrados
Executar Construção da Solução e Executar Testes Funcionais
Planejar Testes Integrados
Cut-over
Definir Estratégia e Regras de Limpeza de Dados
Treinamento Usuários Finais
Preparar ambiente
Preparar Material
Montar Grade
Convo-car
Fase de Realização ---------> Planejado: 90%
Executado: 85%
Entregáveis por Fase do Projeto
Templates PMI e SAP (BBP´s, BMD´s)
Estrutura de Processos
Análise de GAPs
F1 - PLANEJAMENTO
F2 - BUSINESS BLUEPRINT
F4 - PREPARAÇÃO FINAL
F5 – GO-LIVE E SUPORTE
F3 – REALIZAÇÃO
Construção
Transferência de Conhecimento
Execução do Cutover
Estratégia de Migração de Dados
Mapas de Extração
Métodos de Extração & Carga
Limpeza & Conversão
Planejamento e Simulação do Cutover
Treinamento de Usuários-finais
Instruções de Trabalho (BPP)
Materiais de Treinamento
Entregas Resource
Entregas Resource + FAR)
Entregas FAR (apoio Resource)
Desenvolvimentos ABAP
Configuração / Especificações Funcionais
Planejamento de Testes Integrados
Testes Unitários
(1º Ciclo)
Casos de Testes (TCRs Variantes)
Suporte 2º nível (Sistêmico e Funcional )
Casos de Testes (TCRs Padrão)
Testes Integrados (Ciclo 1)
Testes Integrados (Ciclo 2)
Cronograma Macro
Plano do Projeto
Termo de Abertura
Testes Integrados
Suporte de 1º nível (Negócios e Sistêmico)
Testes Unitários (2º Ciclo)
Carga de Dados para Testes Integrados
Testes Funcionais
Status Atual dos BBP´s, CMD´s e ESF´s
Obs.: BBP – Business Blue Print
CMD – Conceito de Migração de Dados
ESF – Especificações Funcionais
BBP´s
ESF´s	
A Entregar	Aguarda reunião	Aguarda Assi. Usuário	Vista Final TI	Assinados VD	0	0	0	39	37	
CMD´s
CMD´s	
A Entregar	Entregues	Aguarda Assinatura	Finalizados	4	34	21	0	
ESF´s
ESF´s	
Entregar	Pós GoLive	Entregues	Aprovados	2	34	70	23	
GAP´s de Edital
 Parametrizações/Desenvolvimento identificados no BBPs que não são standard no SAP sem requisitos correspondentes no Edital
	ESF_05_07_01 - Preço de Compras do Material	SRM
	ESF_05_07_05 - Docs Subsequentes do Carrinho de Compras	SRM
	ESF_05_08_04 - Comissão de Licitação	SRM
	ESF_05_08_05 - Replicação de Pessoa de Contato	SRM
	ESF_05_07_04 - Tipos de Carrinho de Compras	SRM
	ESF_05_09_07 - Interface de Pedido de Compras SRM-ECC	SRM
	ESF_05_09_04 - Workflow de Validação de Minuta de Edital	SRM
	ESF_05_09_10 - Carga de Pedidos do legado para SRM	SRM
	ESF_05_08_14 - Atualização do Orç. a partir do Mapa Comparativo	SRM
	ESF_05_07_08 - Formulário de Carrinho de Compras	SRM
	ESF_05_07_10 - Workflow de Atualização de Orçamento	SRM
	ESF_05_09_06 - Criação automatica de um pedido de compra	SRM
	ESF_05_09_09 - Carga de Pedidos do legado para ECC	SRM
	ESF_05_08_16 - Conversão de Licitações Ativas	SRM
	ESF_07_03_06 - Atribuir Automaticamente Tempo de Guarda	DMS
	ESF_07_03_05 - Trava de Documento Cancelado	DMS
	ESF_05_01_01 - Informações de Lote_GRC	GRC
	ESF_05_01_02 - Impressão DANFE Recebida_GRC	GRC 
	ESF_07_01_03 - Boletim Analítico	QM
	ESF_07_02_03 - E-mail Informativo de Expiração de Reg. Info	QM
	ESF_07_01_06 - Envio de E-mail no Encerramento de Operação	QM
	ESF_07_08_01 - Lotes Fabricantes X Lotes Fabricados	QM
	ESF_07_01_02 - Instrução de Amostra	QM
	ESF_07_09_06 - Relatório de Recolhimento de Produto	QM
	ESF_07_09_05 - Registro de Reposição para Cliente Final	QM
	ESF_07_06_02 - Enviar E-mail com Atividades aos Responsáveis	QM
	ESF_03_05_01_Relatório das fases do processo de vendas diretas	SD
	ESF_03_01_01_Relatórios de comprovação de devolução do canhoto	SD
	ESF_03_02_01_Exit no cadastro de Preço	SD
	ESF_03_03_01_Relatório com informações condições do recebimento físico do cliente	SD
Requisitos Críticos
Pendências
Riscos
Solicitações de Mudança
Obrigado !!
Mário José Vieira
Gerente de Projeto
(11) 9-7370-6173
mario.vieira@resource.com.br
Raul Queiros
PMO
(21) 9-9368-8875
raul.queiros@resource.com.br
TEORIA DA 
COMPLEXIDADE
TEORIA DA COMPLEXIDADE
COMPLEXO
COMPLICADO
CAÓTICO
OBVIO
Construção compostade numerosos elementos interligados ou que funcionam como um todo
Em que há confusão; cuja compreensão é difícil; que não é fácil de se apreender.
Situação de caos; confuso, desordenado, desarrumado
Fácil de descobrir, de ver, de entender; que salta à vista; manifesto, claro, patente.
TEORIA DA COMPLEXIDADE
COMPLEXO
COMPLICADO
CAÓTICO
OBVIO
Explora – Sente – Responde 
(Experimenta)
Práticas Emergentes
Sente – Analisa – Responde 
Boas Práticas
Age – Sente – Responde 
Práticas Inovadoras
Explora – Categoriza – Responde 
Melhores Práticas
Se executar uma atividade tem certeza do resultado
Consegue prever o comportamento, mas com um determinado esforço, nem sempre vai funcionar.
Não consegue prever o comportamento das variáveis no futuro. Previsão mas não com exatidão. Aplicar prática e sentir o resultado. 
Não existe controle de nada. Projeto tradicional no final e o escopo não está sendo entregue, se coloca numa sala de guerra e todos trabalhando o mais rápido possível. 
TEORIA DA COMPLEXIDADE
COMPLEXO
COMPLICADO
CAÓTICO
OBVIO
Explora – Sente – Responde 
(Experimenta)
Práticas Emergentes
Sente – Analisa – Responde 
Boas Práticas
Age – Sente – Responde 
Práticas Inovadoras
Explora – Categoriza – Responde 
Melhores Práticas
Se executar uma atividade tem certeza do resultado
Consegue prever o comportamento, mas com um determinado esforço, nem sempre vai funcionar.
Não consegue prever o comportamento das variáveis no futuro. Previsão mas não com exatidão. Aplicar prática e sentir o resultado. 
Não existe controle de nada. Projeto tradicional no final e o escopo não está sendo entregue, se coloca numa sala de guerra e todos trabalhando o mais rápido possível. 
PROJETOS DE CONHECIMENTO (SOFTWARE) TRANSITA ENTRE O COMPLEXO E COMPLICADO 
 
PROCESSOS 
PREDITIVOS x EMPÍRICOS
O que são Processos Preditivos e Empíricos?
RAULZINHO
PROCESSOS PREDITIVOS
Modelo preditivo é aplicado ao comportamento dos clientes, os modelos de decisão são usados para prever os resultados de decisões de negócio complexas. Essa análise é usada para mapear todas as variáveis envolvidas em um processo de decisão e, assim, identificar quais são os resultados possíveis.
PROCESSOS EMPIRICOS
Processos Empíricos nós não fixamos o escopo do produto e nem os processos de como construí-lo. Em vez disso, em ciclos curtos, criamos uma pequena parte lançável do produto, inspecionamos como o criamos, adaptamos o produto e a forma como construí-lo e criamos mecanismos de transparência para permitir uma inspeção clara.
PROCESSOS PREDITIVOS
No começo do projeto tenta-se prever tudo o que irá ocorrer ao longo de todo o projeto. 
Planejamento 
Preditivo
Planejam o projeto com base em diversas premissas e projeções.
Determinam o custo e o prazo do projeto
Consideram a adequação ao plano como sucesso do projeto.
Alterações no plano são vistas como resultado de mau planejamento.
Mudanças são desencorajadas – longo processo de controle de mudanças
Planos de projeto detalhados
Sucesso é o cumprimento do plano!
PROCESSOS PREDITIVOS
A abordagem não é ruim. Apenas não se encaixa adequadamente para ambientes complexos.
Necessidades
do Produto
Andamento do trabalho no modelo prescrito
Usuários dão feedback tardio, após eles receberem o produto.
Fatores externos, receptividade do mercado e premissas também podem ter mudado.
Produto
(Grande Versão)
Potencial de alto retrabalho.
Oportunidades de melhoria perdidas.
Produto obsoleto.
Especificar
Desenvolver
Testar
Liberar
Longo período para as entregas
Detalhar ao máximo
PROCESSOS EMPÍRICOS
Para trabalhos complexos, o controle empírico de processos, ou empirismo, é a abordagem mais adequada, na qual há mais coisas que não sabemos do que sabemos
Necessidades
do Produto
Incremento do Produto
Direção
Feedback
Iteração
No final de cada iteração pode-se mudar a direção dos trabalhos (agilidade)
Observação
Informações são obtidas pela observação e não pela previsão
CONTROLE EMPÍRICO DE PROCESSOS
Significa trabalhar de maneira baseada em fatos, experiências e evidências
RAUL QUEIRÓS
ARA0152 - MÉTODOS ÁGEIS COM SCRUM
AULA 02
AGENDA
O MANIFESTO ÁGIL, SEUS VALORES PRINCÍPIOS – AGILE IS MINDSET
GERENCIAMENTO DE PROJETOS: TRADICIONAL VERSUS ÁGIL
 
METODOLOGIAS AGEIS E A ENTREGA FREQUENTE
METODOLOGIAS ÁGEIS
METODOLOGIAS ÁGEIS
Metodologias Ágeis são aquelas que permitem adaptar o modo de trabalhar às condições do projeto, alcançando flexibilidade e rapidez na resposta para adaptar o projeto e seu desenvolvimento às circunstâncias específicas do ambiente.
Em essência, as empresas que optam por essa metodologia gerenciam seus projetos de forma flexível, autônoma e eficaz, reduzindo custos e aumentando sua produtividade. 
O QUE SÃO METODOLOGIAS ÁGEIS?
METODOLOGIAS ÁGEIS
As metodologias ágeis melhoram a satisfação do cliente, uma vez que irá envolvê-lo e engajá-lo durante todo o projeto. A cada etapa o cliente será informado das conquistas e progressos do mesmo, com a visão de envolvê-lo diretamente para agregar sua experiência e conhecimento, e assim, otimizar as características do produto final, obtendo em todos os momentos uma visão completa de seu estado.
POR QUE UTILIZAR E QUAIS AS SUAS VANTAGENS?
METODOLOGIAS ÁGEIS
Melhoria da motivação e envolvimento da equipe de desenvolvimento. Mas essa melhoria não é acidental: as metodologias ágeis permitem que todos os membros da equipe conheçam o status do projeto a qualquer momento, assim, os compromissos são negociados e aceitos por todos os membros da equipe.
POR QUE UTILIZAR E QUAIS AS SUAS VANTAGENS?
METODOLOGIAS ÁGEIS
A escolha da aplicação do gerenciamento ágil economiza tempo e custos. O desenvolvimento ágil funciona de maneira mais eficiente e rápida e, com isso, o orçamento e os prazos acordados dentro de um projeto são cumpridos rigorosamente.
POR QUE UTILIZAR E QUAIS AS SUAS VANTAGENS?
METODOLOGIAS ÁGEIS
Trabalho com maior velocidade e eficiência. Uma das máximas de sua aplicação é que ela funciona através de entregas parciais do produto, desta forma, é possível entregar uma versão muito mais funcional do produto no menor tempo possível.
POR QUE UTILIZAR E QUAIS AS SUAS VANTAGENS?
METODOLOGIAS ÁGEIS
Graças às entregas parciais (focadas em fornecer as funcionalidades que fornecem valor primeiro) e ao envolvimento do cliente, será possível eliminar quaisquer recursos desnecessários do produto.
POR QUE UTILIZAR E QUAIS AS SUAS VANTAGENS?
METODOLOGIAS ÁGEIS
Permitem melhorar a qualidade do produto. A interação contínua entre desenvolvedores e clientes visam garantir que o produto final seja exatamente o que o cliente procura e precisa. Com essa abordagem, é possível adotar a excelência tecnológica, obtendo assim um produto tecnologicamente superior. 
POR QUE UTILIZAR E QUAIS AS SUAS VANTAGENS?
METODOLOGIAS ÁGEIS
Permitem rentabilizar nossos investimentos, ou seja, graças à realização de entregas antecipadas, o cliente terá acesso rápido às funcionalidades que agregam valor, acelerando o retorno do investimento.. 
POR QUE UTILIZAR E QUAIS AS SUAS VANTAGENS?
Quais são as Metodologias Ágeis mais utilizadas?
RAULZINHO
METODOLOGIAS ÁGEIS
O Scrum é um framework de gerenciamento de projetos, da organização ao desenvolvimento ágil de produtos complexos e adaptativos com o mais alto valor possível, através de várias técnicas, utilizado desde o início de 1990 e que atualmente é utilizado em mais de 60% dos projetos ágeis em todo o mundo.
METODOLOGIAS ÁGEIS MAIS UTILIZADAS
METODOLOGIAS ÁGEIS
Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é considerada uma metodologia ágil pois se ajusta bem a pequenas e médias em desenvolvimento de software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.
METODOLOGIAS ÁGEIS MAIS UTILIZADAS
METODOLOGIAS ÁGEIS
Feature-driven development (FDD), ou Desenvolvimento Dirigido por Funcionalidades,é um método leve e iterativo para desenvolvimento de software. Criado por Jeff de Luca e Peter Coad, combina gestão de projetos com boas práticas de engenharia de software.
METODOLOGIAS ÁGEIS MAIS UTILIZADAS
METODOLOGIAS ÁGEIS
Metodologia de Desenvolvimento de Sistemas Dinâmicos (Dynamic Systems Development Method - DSDM) é uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usuário.
Seu objetivo é entregar softwares no tempo e com custo estimados através do controle e ajuste de requisitos ao longo do desenvolvimento. DSDM é um dos modelos de Metodologia Ágil de desenvolvimento de software.
METODOLOGIAS ÁGEIS MAIS UTILIZADAS
METODOLOGIAS ÁGEIS
O Lean parte do princípio de que toda iniciativa precisa ser baseada no consumidor final. O propósito é criar valor para este público. Para isso, é preciso que as lideranças, CEOs, especialistas e os times da sua empresa, de variados setores, estejam por dentro dessa sistemática de gestão. O primeiro passo para adoção desse novo modelo acontece quando são encontradas as respostas para as seguintes questões: “Como melhorar o trabalho?”, “Qual é o problema que precisamos resolver?” e “Como desenvolver pessoas?”.
METODOLOGIAS ÁGEIS MAIS UTILIZADAS
METODOLOGIAS ÁGEIS
O Kanban é uma estrutura popular usada para implementar o desenvolvimento do software Agile. Ele requer comunicação de capacidade em tempo real e transparência total de trabalho. Os itens de trabalho são representados visualmente em um quadro Kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento
METODOLOGIAS ÁGEIS MAIS UTILIZADAS
MANIFESTO ÁGIL
O que é Manifesto Ágil?
RAULZINHO
METODOLOGIAS ÁGEIS
O Manifesto Ágil: é uma declaração de princípios que fundamentam o desenvolvimento ágil de software. 
Inicialmente, contou com 17 signatários, nomeadamente: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
De acordo com as experiências de desenvolvimento de software e ajudando os outros a desenvolver, os dezessete signatários do manifesto ágil definiram os quatro valores do desenvolvimento ágil:
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
OS QUATRO VALORES:
Os indivíduos e suas interações acima de procedimentos e ferramentas: Ferramentas e processos são importantes, mas é mais importante ter pessoas competentes trabalhando juntas de forma eficiente.
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
OS QUATRO VALORES:
O funcionamento do software acima de documentação abrangente: Uma boa documentação é útil para ajudar pessoas a entender como o software é criado e como usá-lo, mas o ponto principal do desenvolvimento é criar o software, não a documentação.
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
OS QUATRO VALORES:
A colaboração com o cliente acima da negociação e contrato: Um contrato é importante mas não é um substituto para um trabalho próximo aos clientes para descobrir o que eles precisam.
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
OS QUATRO VALORES:
A capacidade de resposta a mudanças acima de um plano pré-estabelecido: Um plano pré-estabelecido é importante, mas não deve ser muito rígido para acomodar mudanças na tecnologia ou no ambiente, as prioridades das partes interessadas e a compreensão das pessoas sobre o problema e sua solução.
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
OBS:
Não se trata, como poderia parecer à primeira vista, de um desprezo aos elementos e ferramentas tradicionais do desenvolvimento de software, mas sim do estabelecimento de uma escala de valores, na qual a flexibilidade e a colaboração são mais relevantes do que a rigidez de processos e planejamento clássicos..
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
Os 12 princípios do desenvolvimento ágil são os seguintes:
Garantir a satisfação do cliente, entregando rápida e continuamente software funcional.
Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
Software funcional é entregue frequentemente (semanal ou mensal - o menor intervalo possível);
Cooperação constante entre as pessoas que entendem do 'negócio' e os desenvolvedores;
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
Os 12 princípios do desenvolvimento ágil são os seguintes:
Projetos surgem por meio de indivíduos motivados, devendo existir uma relação de confiança.
A melhor forma de transmissão de informação entre desenvolvedores é através da conversa 'cara a cara'
Software funcional é a principal medida de progresso do projeto;
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
Os 12 princípios do desenvolvimento ágil são os seguintes:
Novos recursos de software devem ser entregues constantemente. Clientes e desenvolvedores devem manter um ritmo até a conclusão do projeto.
Design do software deve prezar pela excelência técnica;
Simplicidade – a arte de maximizar a quantidade de trabalho que não é feito – é essencial;
MANIFESTO ÁGIL
METODOLOGIAS ÁGEIS
Os 12 princípios do desenvolvimento ágil são os seguintes:
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento.
MANIFESTO ÁGIL
DECLARAÇÃO DE INTERDEPENDÊNCIA 
DE PROJETOS ÁGEIS 
Você conhece a Declaração de Interdependência de Projetos Ágeis?
RAULZINHO
METODOLOGIAS ÁGEIS
Em 2004, um grupo de notáveis se reuniu para discutir o que a gestão ágil de projetos deveria significar e o que um bom gerente de projetos deveria entregar em seus projetos considerando o cenário de extrema incerteza. Tomando como base os desdobramentos do Manifesto Ágil de 2001 para desenvolvimento de software, essa discussão deu origem a um documento que foi publicado em fevereiro de 2005 com o nome de Declaração de Interdependência (DOI).
DECLARAÇÃO DE INTERDEPENDÊNCIA DE PROJETOS ÁGEIS
METODOLOGIAS ÁGEIS
Segundo David Anderson, um dos signatários da declaração, seu objetivo foi definir um sistema de valores pelo qual os gerentes de projeto do século 21 devem se guiar e devem usar como base para desenvolver uma comunidade em torno da aplicação geral do gerenciamento ágil de projetos.
DECLARAÇÃO DE INTERDEPENDÊNCIA DE PROJETOS ÁGEIS
METODOLOGIAS ÁGEIS
Apesar de pouco conhecida, a DOI estabelece aspectos importantes que vale ressaltarmos:
Somos uma comunidade de líderes de projetos altamente bem-sucedidos na entrega de resultados. Para alcançar estes resultados:
DECLARAÇÃO DE INTERDEPENDÊNCIA DE PROJETOS ÁGEIS
METODOLOGIAS ÁGEIS
Aumentamos o retorno do investimento, fazendo com que o fluxo contínuo de valor seja o nosso foco.
Fornecemos resultados confiáveis ao envolver os clientes em interações frequentes e propriedade compartilhada.
Esperamos incerteza e administramos isso por meio de iterações, antecipações e adaptações.
DECLARAÇÃO DE INTERDEPENDÊNCIA DE PROJETOS ÁGEIS
METODOLOGIAS ÁGEIS
Desencadeamos a criatividade e a inovação, reconhecendo que os indivíduos são a fonte suprema de valor e criando um ambiente onde eles podem fazer a diferença.
Aumentamos o desempenho através da responsabilidade do grupo por resultados e responsabilidade compartilhada pela eficácia da equipe.
Melhoramos a eficácia e a confiabilidade por meio de estratégias, processos e práticas específicos da situação.”
DECLARAÇÃO DE INTERDEPENDÊNCIA DE PROJETOS ÁGEIS
METODOLOGIAS ÁGEIS
Infelizmente, o DOI não estimulou e não atingiu a comunidade de gerentes de projeto assim como o Manifesto Ágil, apesar de estabelecer valores extremamente relevantes. Enquanto o Manifesto Ágil lida com desenvolvimento de software, a Declaração de Interdependência focaliza mais o gerenciamento de projetos.
DECLARAÇÃO DE INTERDEPENDÊNCIA DE PROJETOS ÁGEIS
MITOS E VERDADES
METODOLOGIAS ÁGEIS
01. Agilidade é novidade (ou coisa nova)
Novidade? Na verdade o manifesto ágil foi publicado em2001, lá se vão mais de 15 anos. Mesmo sendo publicado em 2001, os Métodos Ágeis no Brasil, chegaram com mais força por volta de 2004 a 2007.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
02. Métodos Ágeis significa não ter que criar documentação
Muitas pessoas acreditam que ao adotar os métodos ágeis, que não terão mais que produzir documentação. E isso é dificilmente é a verdade, você pode acabar sendo obrigado a criar o tanto de documentação, quando linhas de código.
Mas a prática é diferente de uma abordagem waterfall, onde é necessário criar toda a documentação antes de qualquer linha de código, já nos métodos ágeis a documentação vai surgir juntamente as entregas de software funcionando. Afinal de contas ela também é um entregável.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
03. Ser ágil é não ter que se preocupar com o design
Não. Totalmente pelo contrário, se você adotou os métodos ágeis você também deve abraçar o design e seus princípios de experimentação, adaptação e evolução. Design deve estar envolvido em tudo, nas plannings e muito mais, como auxiliando a direcionar para o objetivo do produto e/ou projeto.
Devemos abraçar os princípios do design emergente que aparece mais claramente na refatoração de código, onde o desenvolvedor melhoram o design do seu código. Design é algo onipresente nos métodos ágeis e não apenas uma fase inicial de projeto.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
04. Métodos Ágeis tem pouco planejamento
Se existe uma verdade é que, visitar o planejamento nos métodos ágeis é algo que acontece naturalmente a todo momento.
Nos métodos ágeis você tem o plano de todo o projeto, que deve ser visitado ao final de cada iteração refletindo nele os progressos realizados, ainda temos o planejamento da iteração, onde se tem um plano detalhado do que vai ser desenvolvido e temos o planejamento diário que acontece na Daily.
Assim podemos afirmar planejar é algo natural e constante no cotidiano de todos os envolvidos no projeto.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
05. Tamanho e/ou padrão certo de User Story
Não existe o mesmo modelo de User Story para todos os times. Cada time tem o seu e ainda podendo variar dentro do que julgarem necessário.
Existe uma boa prática que diz que, uma boa User Story deve durar no máximo de 2 a 3 dias de desenvolvimento. Eu gosto dessa abordagem e acredito que ela ainda deve conseguir ser independente, testável e entregável.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
06. Tudo deve caber dentro do Sprint
Existe uma grande mentira que é: as estórias não devem ser quebradas. A consequência desse mito é de ter um Sprint Backlog inchado e que possivelmente o time não irá conseguir cumprir, por mais que assuma o compromisso da entrega.
Quebrar User Stories que são maiores que uma Sprint, não deveria traumático, mas também não deve ser a regra, onde toda estoria é maior que seu ciclo de desenvolvimento. 
Uma excelente prática é quebrar ordenadas por negócio as grandes estórias, garantido sempre um entregável funcionando.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
07. Desenvolvedores fazem o que querem
Se você está fazendo isso então, a má noticia é que você está fazendo isso errado.
Desenvolvedores não fazem o que querem e sim seguem algo estipulado pelo cliente e/ou Product Owner. Logo, se seu time está fazendo o que quer ou o que acham melhor, você está com uma enorme chance de entregar algo que seu cliente não precisa.
Equipes ágeis são equipes bem disciplinadas e focadas no que o cliente e PO direcionam para atingir o maior valor de negócio possível.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
08. Scrum e Kanban são inimigos!
Por mais que ainda exista algumas afirmações como: “Ou você utiliza Scrum, ou utiliza Kanban”. Scrum e Kanban estão longe de serem inimigos, até mesmo por compartilharem da mesma base de valores.
Por exemplo, um bom Kanban pode amplificar a transparência dentro do Scrum e promover a melhoria continua do seu fluxo produtivo.
Existem livros que definem ScrumBan como mais uma metodologia, como o do Corey Ladas.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
09. Método Ágil não funciona com deadlines
Métodos Ágeis funcionam melhor COM deadlines.
Quando temos deadlines bem definidos, vai ser natural um empoderamento do time, que vai trazer maior motivação e engajamento. Outro ganho é a eliminação do desperdício, com deadline definido e conhecido, só será desenvolvido o necessário.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
10. Agilidade não funciona em sistemas legados e caóticos!
Uma abordagem ágil vai fazer milagre nesse tipo de ambiente. Podemos até afirmar que, os Métodos Ágeis nasceram para controlar o caos, e quando empoderamos as pessoas e deixamos o conhecimento no legado imergir conforme a jornada é realizada, os resultados passam a ser incríveis.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
11. Vamos esperar o momento certo
Não existe de um projeto “certo” para começar, você pode criar inúmeras desculpas ou até encontrar um bom motivo para não mudar. Você deve fazer isso quando achar que é o momento e não quando encontrar o seu projeto perfeito para tal.
Normalmente, o melhor momento é quando se busca fazer mais e melhor do que está acostumado a fazer. Com certeza os Métodos Ágeis vão te dar muita flexibilidade e agilidade no tempo de resposta.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
12. É necessário todos no mesmo local físico
Métodos Ágeis enfatiza o forte envolvimento de todos os envolvidos em um projeto. Como isso esse mito vem a tona e as começam a associar que as pessoas devem estar no mesmo local físico, para que se tenha sucesso no projeto.
Comunicação é historicamente um desafio em projetos e até com todos no mesmo lugar, não é assertiva. Mas esse problema é mais presente por um histórico de “cada um por si” do que pela habilidade de comunicação das pessoas.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
13. Só funciona em projetos pequenos
Como os times ágeis normalmente são pequenos, o que se costuma a associar é que por esse motivo métodos ágeis só funcionam para projetos pequenos. O que é um mito que absurdo! O que existe de projetos ágeis com 100, 200 e até 500 pessoas é normal.
Na agilidade o lema em grandes projetos deve ser: Dividir para conquistar, organizar os times por funcionalidade ou temas de negócio e criar times focados na evolução da arquitetura irão diminuir a dependência e redundância.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
14. Usando métodos ágeis, não sabemos quando vai estar pronto
O modelo tradicional temos todo o planejamento detalhado antes da primeira linha de código escrita. Embora seja comodo e até de certa maneira útil ter todo os detalhes conhecidos. Qualquer mudança de plano no decorrer do desenvolvimento vai acabar custando muito mais caro.
A abordagem ágil é menos detalhada e se tem um planejamento macro, baseado ainda em incertezas que serão removidas por verdades absolutas ao longo do desenvolvimento. No modelo ágil, os detalhes do plano são refinados de acordo com o progresso realizado do projeto.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
15. Método Ágil = Scrum
Scrum é sem dúvida nenhuma o “processo” ágil mais difundido e utilizado no mundo, e isso pelo seus próprios méritos, em conseguir se encaixar muito bem em ambientes complexos.
Métodos Ágeis não se resumem somente ao Scrum, existem várias outras abordagens como Kanban, XP, Agile UP e etc.
O que deve se avaliar é qual o melhor para o seu contexto de trabalho e tentar adotar o que melhor se encaixa. Minha experiência diz que devemos começar com um processo “by the book” e ir adaptando e criando o seu próprio modelo hibrido de agilidade.
MITOS OU VERDADES?
METODOLOGIAS ÁGEIS
16. É a cura para todos os seus problemas
Agilidade traz um alinhamento das partes interessadas, te ajuda a identificar problemas mais cedo, reduz o tempo de entrada em produção, ou seja, são muitas vantagens em relação a outras abordagens.
Assim, algumas pessoas começam a acreditar que os métodos ágeis funcionam em qualquer situação, o queé falso. Existem muitos motivos para projetos falharem e talvez o principal dele é a execução errada do modelo de desenvolvimento.
Existem situações onde os métodos ágeis não irão funcionar, como por exemplo em projetos que não se conseguem quebrar as funcionalidades em pequenos itens de trabalho, ou em projetos não existe o envolvimento do cliente.
MITOS OU VERDADES?
CASES DE SUCESSO
METODOLOGIAS ÁGEIS
Sony, empresa fabricante de hardwares e softwares de excelência a metodologia ágil deu grande apoio para estabelecer rapidamente um processo de gerenciamento de projetos e desenvolvimento de software robusto e que funcione com base na abordagem SCRUM em um projeto que possui um contexto e riscos de projeto altamente complexos.
A introdução do SCRUM levou ao objetivo de ter um processo definido de gerenciamento e desenvolvimento do projeto. Conseguiram um alto nível de trabalho em equipe a colaboração com parceiros de projetos. Hoje a equipe de software é reconhecida como uma das equipes de projeto mais eficazes.
CASES DE SUCESSO - SONY
METODOLOGIAS ÁGEIS
A famosa empresa de brinquedos LEGO iniciou sua abordagem ágil começando pelas equipes. Com 20 equipes de produtos trabalhando na organização no início da implementação ágil, transformou 5 delas em equipes Scrum auto-organizadas. Aos poucos as outras equipes foram sendo progressivamente transformadas a medida em que o Scrum surtia efeito.
Como resultados, depois de capacitar os desenvolvedores a gerenciar seu próprio trabalho, deu adeus ao exército de “gerentes com planilhas”. Os desenvolvedores passaram a fornecer estimativas mais precisas e os resultados se tornam mais previsíveis, ou seja, havia um maior controle sobre as ações da empresa.
CASES DE SUCESSO - LEGO
METODOLOGIAS ÁGEIS
A implementação ágil foi colocada em uma Fábrica Digital da Simens com cerca de 50 funcionários. A função desta planta é desenvolver sistemas de automação de software, usados ​​por fabricantes em todo o mundo. Até 2015, essa divisão de alta tecnologia líder de mercado, com o objetivo de fornecer soluções inovadoras para seus clientes, enfrentaria novos desafios em termos de flexibilidade devido aos futuros desenvolvimentos de tendências futuras no mercado industrial, impulsionados principalmente pela tendência de digitalização. Para manter a posição de liderança no mercado, a equipe do projeto teve que tomar o próximo nível de evolução.
CASES DE SUCESSO - SIMENS
METODOLOGIAS ÁGEIS
Essas mudanças não apenas inspiraram uma mudança de comportamento, mas também começaram a nutrir atitudes e cultura mais profundas, mais adequadas a uma abordagem iterativa e incremental; cooperação, experimentação, confiança e responsabilidade.
CASES DE SUCESSO - SIMENS
METODOLOGIAS ÁGEIS
A implementação ágil na CISCO tratou de um produto específico – a Plataforma de cobrança de assinaturas.
A equipe realizava as Daily’s, uma reunião de 15 minutos todo início de dia para alinhamento de progresso e determinar os itens de trabalho. Com o SAFe, eles obtiveram maior transparência: cada equipe sabia o que as outras equipes estavam fazendo e as equipes eram capazes de gerenciar a si mesmas, promovendo a responsabilidade por meio de atualizações e conscientização de status.
CASES DE SUCESSO - CISCO
METODOLOGIAS ÁGEIS
Depois que a Cisco começou a seguir a metodologia SAFe, introduziu a Integração Contínua (CI), eles obtiveram reduções de 40% nos defeitos críticos e principais. Além disso houve uma diminuição de 16% na RRD (taxa de defeitos rejeitados) e uma melhoria de 14% no DRE (eficiência de remoção de defeitos) graças ao CI e mais interação entre equipes internacionais.
CASES DE SUCESSO - CISCO
METODOLOGIAS ÁGEIS
A Mitsubishi é outra empresa que não ficou de fora na metodologia Ágil. A empresa atua em mais de 120 países no setor aeroespacial, semicondutores, geração e distribuição de energia, comunicações e tecnologia da informação, eletrônicos de consumo, automação industrial e serviços de construção.
A abordagem ágil para a Mitsubishi foi feita por meio de workshops sobre a metodologia ágil que ensinaram práticas e abordagens da metodologia, onde os funcionários foram envolvidos e conseguiram implementar em cada uma das plantas da empresa.
CASES DE SUCESSO - MITSUBISHI
DESMISTIFICANDO 
METODOLOGIAS ÁGEIS
METODOLOGIAS ÁGEIS
CASES DE SUCESSO - iTAÚ
METODOLOGIAS ÁGEIS
CASES DE SUCESSO - iTAÚ
 
SCRUM 
O que é o Scrum?
RAULZINHO
O QUE É SRUM
O QUE É SCRUM?
Um framework dentro do qual pessoas podem tratar e resolver problemas COMPLEXOS e ADAPTATIVOS, enquanto produtivamente e criativamente entregam produtos com o maior valor possível. 
NÃO É APENAS PARA DESENVOLVIMENTO DE SOFTWARE 
Pesquisa e identificação de mercado
Hardware
Governo
Desenvolvimento de processos
Marketing
...
 
SRUM E A ENTREGA FREQUENTE
 
EVENTOS DO SRUM
 
ARTEFATOS DO SRUM
 
PAPÉIS DO SRUM
 
CONCEITO DE “PRONTO” DO SRUM
Definição de Pronto (DoD): lista das atividades a serem executadas para que estejam “pronto”.
 
O FRAMEWORK SRUM
 
O FRAMEWORK SRUM
 
HANS ON – SCRUM 
 
BACKLOG DO PRODUTO – SCRUM 
História de Usuário
Épico
 
REFINAMENTO DO BACKLOG DO PRODUTO – SCRUM 
Objetivo do Refinamento: 
Tamanho pequeno
Entendido pelo Time de Desenvolvimento
Estimado pelo Time de Desenvolvimento
 
BACKLOG DO PRODUTO X PLANEJAMENTO DA PRINT – SCRUM 
 
BACKLOG DO PRODUTO X PLANEJAMENTO DA PRINT – SCRUM 
 
BACKLOG DO PRODUTO X PLANEJAMENTO DA PRINT – SCRUM 
 
BACKLOG DO PRODUTO X PLANEJAMENTO DA PRINT – SCRUM 
 
BACKLOG DO PRODUTO X PLANEJAMENTO DA PRINT – SCRUM 
 
BACKLOG DA SPRINT– SCRUM 
 
REUNIÕES DIÁRIAS– SCRUM 
 
REUNIÕES DIÁRIAS x REVISÃO DA SPRINT – SCRUM 
 
BACKLOG DO PRODUTO x RESTROSPECTIVA DA SPRINT – SCRUM 
 
VALORES DO SCRUM 
 
AUTO-ORGANIZAÇÃO – SCRUM 
 
TIME DE DESENVOLVIMENTO – SCRUM 
 
COMO INICIAR COM SCRUM? 
raul.queiros@estacio.br
RAUL QUEIRÓS
ARA0152 - MÉTODOS ÁGEIS COM SCRUM
AULA 03
AGENDA
COMO FUNCIONA O SCRUM, SEU FLUXO FUNDAMENTAL E VANTAGENS
EQUIPES, PAPÉIS E RESPONSABILIDADES: DONO DO PRODUTO (PO), SCRUM MASTER (SM) E EQUIPE SCRUM (ES)
ANATOMIA 
DO SCRUM
RESPONSABILIADES
Dono de Produto: é responsável por maximizar o valor do produto resultante do trabalho do Time Scrum.
Scrum Master: é responsável pela implementação do Scrum tal como definido no Guia do Scrum.
Desenvolvedores: são as pessoas do Time Scrum que estão empenhadas em criar qualquer aspeto de um Incremento utilizável em cada Sprint.
EVENTOS
Sprint: são eventos de duração fixa de um mês ou menos para criar consistência. Podemos dizer que são as iterações.
Planejamento da Sprint: é onde é determinado qual será o trabalho a ser realizado.
Daily Scrum (Scrum diário): é um evento de 15 minutos para os Desenvolvedores com o objetivo de inspecionar o progresso rumo ao Sprint Goal e adaptar o Sprint Backlog conforme necessário, ajustando o trabalho planeado que se aproxima.
EVENTOS
Revisão da Sprint: é o momento de inspecionar o resultado da Sprint e determinar adaptações futuras, com foco no produto que foi entregue.
Retrospectiva da Sprint: planear formas de aumentar a qualidade e a eficácia. É um evento para gerar melhoria contínua.
ARTEFATOS
Backlog do Produto: é uma lista emergente e ordenada do que é necessário para melhorar o produto. É a única fonte de trabalho levada a cabo pelo Time Scrum.
Backlog da Sprint: é um plano de e para os Desenvolvedores. O Backlog da Sprint é composto pela Meta da Sprint (porque), o conjunto de itens selecionados do Backlog do Produto para a Sprint (o que), bem como um plano acionável para a entrega do Incremento (como).
Incremento do Produto: representa aquilo que foi produzido ao longo das sprints. Cada Incremento é acrescentado a todos os Incrementos anteriores e cuidadosamente verificado, assegurando que todos eles funcionem em conjunto. A fim de fornecer valor, o Incremento deve ser utilizável.
VISÃOGERAL DO FUNCIONAMENTO DO SCRUM
– 1 –
Construção de um Backlog de Produto minimamente ordenado e refinado
– 2 –
Time Scrum se reúne para planejar o escopo da Sprint atual.
Evento: Planejamento da Sprint
A saída desta reunião é o Backlog da Sprint.
– 3 –
O trabalho inicia diariamente com os Desenvolvedores.
Evento: Daily
A saída desta reunião status das atividades
– 4 –
No último dia da Sprint ocorre a Revisão da Sprint.
Evento: Revisão da Sprint
A saída desta reunião é o incremento de produto é inspecionado e o backlog de produto adaptado
– 5 –
inicia-se a Retrospectiva da Sprint.
Evento: Retrospectiva da Sprint
ações de melhoria tanto no processo quanto nas relações do time
PILARES DO SCRUM
TRANSPARÊNCIA
Exige que aspectos significativos do processo e do projeto estejam visíveis para os responsáveis pelos resultados, sempre!
As informações devem ser passadas de forma clara e precisa, possibilitando que todos tenham o mesmo entendimento.
É um pilar que deve ser praticado por todos os papéis e envolvidos no projeto sem exceção!
Ter transparência é falar a mesma coisa independente de quem fez a pergunta.
INSPEÇÃO
Significa que os processos, práticas e atividades devem ser analisados com frequência suficiente para que as variações inaceitáveis sejam detectadas o mais cedo possível.
Evita que o cliente receba um produto com qualidade inadequada.
INSPEÇÃO
Significa que sempre que um evento não desejado ocorrer, deve-se adaptar o que for necessário no processo para evitar a sua recorrência.
Inspeção e adaptação costumam ocorrer juntas.
O time é que deve realizar.
Adaptação depende de inspeção e inspeção depende de transparência. 
PESSOAS E TIMES SCRUM
PROBLEMAS COM EQUIPES TRADICIONAIS
Trabalhar em silos pode impactar seriamente o seu negócio. Eles causam conflitos internos e podem despertar a falta de confiança dentro da empresa, o que resulta em ineficiência e redundâncias no interior dos departamentos.
DONO DO PRODUTO
O Dono de Produto também é responsável pelo gerenciamento eficaz do Backlog do Produto, o que inclui:
Desenvolver e comunicar explicitamente a meta do produto;
Criar e comunicar claramente os itens do Backlog do Produto;
Ordenar os itens do Backlog do Produto;
Garantir que o Backlog do Produto seja transparente, visível e compreensível.
DESENVOLVEDORES
Desenvolvedores são as pessoas do Time Scrum que estão comprometidas em criar qualquer aspecto de um Incremento utilizável a cada Sprint.
As habilidades específicas necessárias aos Desenvolvedores geralmente são amplas e variam de acordo com o domínio de trabalho. No entanto, eles são sempre responsáveis por:
Criar um plano para a Sprint, o Sprint Backlog;
Introduzir gradualmente qualidade aderindo a uma Definition of Done;
Adaptar seu plano a cada dia em direção à meta da Sprint; e,
Responsabilizar-se mutuamente com os demais profissionais.
SCRUM MASTER
O Scrum Master é responsável por estabelecer o Scrum conforme definido no Guia do Scrum. Ele faz isso ajudando todos a entender a teoria e a prática do Scrum, tanto no Scrum Team quanto na organização.
Trata-se do responsável pela eficácia do Scrum Team. Ele faz isso possibilitando que o Time Scrum melhore suas práticas dentro do framework Scrum.
O Scrum Master não é chefe dos Desenvolvedores ou Dono de Produto. Ele também não é um Gerente de Projetos. É um verdadeiro líder que serve:
A QUEM O SCRUM MASTER SERVE
O Scrum Master serve ao Time Scrum de várias maneiras, incluindo:
Treinar os membros do time em autogerenciamento e cross-funcionalidade;
Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que atendam à Definition of Done;
Provocar a remoção de impedimentos ao progresso do Scrum Team;
Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos dentro do Timebox.
A QUEM O SCRUM MASTER SERVE
O Scrum Master serve ao Dono de Produto de várias maneiras, incluindo:
Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;
Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog claros e concisos;
Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo;
Facilitar a colaboração dos stakeholders, conforme solicitado ou necessário.
A QUEM O SCRUM MASTER SERVE
O Scrum Master serve à Organização de várias maneiras, incluindo:
Liderar, treinar e orientar a organização na adoção do Scrum;
Planejar e aconselhar implementações de Scrum dentro da organização;
Ajudar os funcionários e os stakeholders a compreenderem e aplicarem uma abordagem empírica para trabalhos complexos;
Remover barreiras entre stakeholders e Scrum Teams.
raul.queiros@estacio.br
RAUL QUEIRÓS
ARA0152 - MÉTODOS ÁGEIS COM SCRUM
AULA 04
AGENDA
GERENCIAMENTO DE ESCOPO ÁGIL
BACKLOG DO PRODUTO
PRODUCT BACKLOG ITEM
PRIMEIRO CONCEITO
“O QUE SERVE PARA UMA EMPRESA PODE NÃO SERVIR PARA OUTRA!”
NÃO EXISTE RECEITA DE BOLO ! ! !
GERENCIAMENTO DE ESCOPO ÁGIL
COMO FUNCIONA O GERENCIAMENTO DE ESCOPO NO SCRUM?
GERENCIAMENTO 
DE ESCOPO
Os clientes e usuários pedem o que é mais importante e de forma progressiva. 
O Dono do Produto então registra essas solicitações no Backlog do Produto. 
Uma vez que se tenha um backlog inicial, começa o desenvolvimento de forma iterativa, realizando a Sprint 1, a 2, a 3 e assim por diante.
BACKLOG DO PRODUTO
BACKLOG DO PRODUTO
O Backlog do Produto mostra todo o trabalho que está previsto para o desenvolvimento do projeto. É uma lista ordenada de tudo aquilo que pode ser necessário no produto.
Qualquer intervenção necessária para ou no produto deve estar no Backlog do Produto e o que estiver fora dele não será desenvolvido. O Product Backlog traz à tona todo o trabalho, desenvolvimento, premissas e restrições com os quais um time tem que lidar a fim de criar um produto pronto e potencialmente liberável
BACKLOG DO PRODUTO
O Backlog do Produto pode compreender itens funcionais e não funcionais, melhorias, correções, ideias, atualizações e outros requisitos.
META DO PRODUTO
META DO PRODUTO 
A Meta do Produto descreve um estado futuro do produto que pode servir como um alvo para o Time Scrum planejar. Ela está no Product Backlog, que emerge para definir “o que” cumprirá a Meta do Produto.
A Meta do Produto serve para aumentar o foco e a transparência. Ela é o objetivo de longo prazo para o Scrum Team, que deve cumprir (ou abandonar) um objetivo antes de assumir o próximo.
PRODUCT BACKLOG ITEM
PRODUCT BACKLOG ITEM
Um item de backlog de produto é algo que precisa ser feito no produto ou para o produto. Pode ser uma funcionalidade, uma característica, uma correção de erro, uma ideia, uma necessidade ou qualquer outra coisa que quando realizada agregue valor para clientes, usuários ou stakeholders.
PRODUCT BACKLOG ITEM
Descrição: 
É o que precisa ser feito, o que necessita ser desenvolvido pelos Desenvolvedores. Sempre que possível, deve ser escrita na linguagem de negócio, ou seja, o item é orientado pelas necessidades de negócio e não pelas de tecnologia. Evitar entrar em detalhes técnicos de como fazer o item. 
PRODUCT BACKLOG ITEM
Valor: 
É o valor de cada item na perspectiva do negócio. É o quão valioso é o item para clientes e usuários. Falando de outra forma, é o benefício daquele item na perspectiva do cliente. Por exemplo: este item tem um benefício muito alto, porque ele vai permitir que os usuários façam o seu trabalho na metade do tempo.
PRODUCT BACKLOG ITEM
Esforço ou outra forma de dimensionamento de tempo e/ou custo: 
É o custo para se fazer cada item. Normalmente, utilizam-se pontos de complexidade (ou user point) para estimar os itens. Por exemplo: fazer determinado item custa 8 pontos. Este outro custa 13 e assim por diante.
PRODUCT BACKLOG ITEM
Ordem: 
É a ordem em que cada um dos itens será desenvolvido.Itens com prioridade maior recebem mais atenção do Dono de Produto e dos Desenvolvedores.
O PRODUCT BACKLOG ITEM pode ter outras informações?
ORDENANDO O BACKLOG DO PRODUTO
raul.queiros@estacio.br
RAUL QUEIRÓS
ARA0152 - MÉTODOS ÁGEIS COM SCRUM
AULA 05
AGENDA
Sprint & DoD & Timebox
PRIMEIRO CONCEITO
“O QUE SERVE PARA UMA EMPRESA PODE NÃO SERVIR PARA OUTRA!”
NÃO EXISTE RECEITA DE BOLO ! ! !
Sprint & DoD & Timebox
A Definição de Pronto (DoD)
A Definição de Pronto (DoD)
A Definição de Pronto (DoD)
A Definição de Pronto (DoD)
SPRINT
SPRINT
SPRINT
A duração da Sprint deve ser de 1 mês ou menos. Alguns times utilizam durações de 1 e outros de 4 semanas. Não há uma regra única e derradeira sobre como definir o tamanho da Sprint. O que é certo para uma pode não ser para outra.
A definição da duração da Sprint deve ser guiada pelos seguintes fatores:
1. O espaço de tempo entre uma liberação e outra.
2. A quantidade de incerteza.
3. A facilidade de obter feedback.
4. Quanto tempo prioridades podem permanecer inalteradas.
5. A sobrecarga (overhead) de cada Sprint.
6. Qual o senso de urgência que se deseja estabelecer.
SPRINT
Cada Sprint deve produzir ao menos um incremento pronto e potencialmente liberável. Alguns times criam a Sprint zero para preparar o Backlog do Produto e outras coisas necessárias, incluindo configurar o ambiente de trabalho, ferramentas de configuração etc.
Nesse sentido, a Sprint zero não produz nenhum incremento pronto e potencialmente liberável. Se não há incremento pronto, não há oportunidade para feedback, inspeção e adaptação. E sem o feedback não podemos avaliar o retorno sobre o investimento feito durante a Sprint.
Portanto, não existe Sprint 0 para o Scrum ou qualquer outro tipo de Sprint que não produza um incrementoverdadeiramente pronto e que possa ser inspecionado.
PLANEJAMENTO DA SPRINT
PLANEJAMENTO DA SPRINT
FLUXO DE PLANEJAMENTO DA SPRINT
FLUXO DE PLANEJAMENTO DA SPRINT
FLUXO DE PLANEJAMENTO DA SPRINT
FLUXO DE PLANEJAMENTO DA SPRINT
FLUXO DE PLANEJAMENTO DA SPRINT
FLUXO DE PLANEJAMENTO DA SPRINT
FLUXO DE PLANEJAMENTO DA SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
DURANTE A SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
FINALIZANDO UMA SPRINT
raul.queiros@estacio.br
 
ATIVIDADEDIA 01DIA 02DIA 03DIA 04
Pintar PAREDE 01
Pintar PAREDE 02
Pintar PAREDE 03
Pintar PAREDE 04
Percentual do Projeto25%25%25%25%
Data Apuração1/108/1015/1022/1029/105/1112/1119/1126/113/1210/1217/1227/13/210/224/23/310/317/324/331/37/414/421/428/45/512/5
SPI 0.990.990.990.990.980.980.980.980.960.960.940.940.940.940.940.940.710.760.760.810.740.790.840.850.920.950.94
Target
1111111
1.00
1111111111111111111
0.990.980.980.960.940.940.710.760.760.740.790.850.920.950.940.700.800.901.001.101.20
1/108/1015/1022/1029/105/1112/1119/1126/113/1210/1217/1227/13/210/224/23/310/317/324/331/37/414/421/428/45/512/5
Variação do SPI do Projeto Evolução
SPITargetSPITarget