Metodologia Ágil THOBER CORADI DETOFENO, MSC. Aula 04 JOINVILLE 2016 Universidade do Estado de Santa Catarina – CCT/UDESC.

Slides:



Advertisements
Apresentações semelhantes
Garantia da Qualidade Mário Eduardo.
Advertisements

Garantia da Qualidade Mário Eduardo. 2 Desafios & Soluções.
SCRUM para Gerência de Projetos
Administração Estratégica
Rational Unified Process(RUP)
Gestão Ágil de Projetos
Desenvolvimento ágil: eXtreme Programming vs SCRUM Tiago Rodrigues de Mello CCO-230 – ENGENHARIA DE SOFTWARE / 2010.
Israel M. Santos Rafael Mendonça
Control Objectives for Information and related Technology
FDD.
O mundo ágil do SCRUM Alexsandro Marques 02/09/2009.
Alunos: Artulanez Souza Iony Melo
KANBAN Por: Jessica Nunes e Karine Oliveira.
Ari Stopassola Daniel #
Métodos Ágeis e SCRUM VISÃO GERAL
Métodos Ágeis Agile Modeling, ou AG
Técnicas e Projeto de Sistemas
Desafios do desenvolvimento de software
Michele de Vasconcelos Leitão Orientadora: Cristine Gusmão
Sumário Motivação Metas Metodologias Ágeis Caso de Estudo: Ambiente
Michele de Vasconcelos Leitão Orientadora: Cristine Gusmão
Michele de Vasconcelos Leitão Orientadora: Cristine Gusmão
Implantando SCRUM na Simplestec Equipe Tributária
Michele de Vasconcelos Leitão Orientadora: Cristine Gusmão
Implantando SCRUM na Simplestec Equipe Tributária
SCRUM Equipe Amauri Cleverson Daiane Mauri Mauricio.
Capability Maturity Model (CMM)
Engenharia de Software
Gerência de Projetos de TI 15
CURSO TÉCNICO EM SEGURANÇA DO TRABALHO
PSBD II Projeto de Sistemas de Banco de Dados II
Metodologia Ágil SCRUM
Administração de Recursos Humanos II
CONTEÚDO PROGRAMÁTICO
Bruno Silva Desenvolvido a partir de
Scrum Visão Geral Janeiro/2010.
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
Scrum.
Processo de Desenvolvimento de Software – PDS C Construção - PAS
Trabalho de Engenharia de Software II
Técnicas e Projeto de Sistemas
SCRUM Processo de Desenvolvimento de Software
Engenharia de Software
Metodologias Ágeis Para o Desenvolvimento de Software
SCRUM Lílian Simão Oliveira.
Gerenciamento de Equipes com Scrum Curso de Verão 2008 – IME/USP Dairton Bassi Danilo Sato 24/Jan/2008.
Trabalho de PAW Scrum Nome: Jaila Cíntia.
SCRUM Metodologia para o Desenvolvimento Ágil de Software Rafael Rodrigues, Rafael Rost.
Metodologias Ágeis Para o Desenvolvimento de Software
Métodos Ágeis e Programação Extrema (XP)
Engenharia de Software
SCRUM.
Gestão Ágil de Projetos
SISTEMA DE MONITORAMENTO DA TECNOLOGIA DA INFORMAÇÃO.
 confidencial restrito Reunião de Retrospectiva  O que foi bem?  Envolvimento do usuário e apoio de TI  O que deveria ser melhor?
Scrum Gestão ágil de projetos. Ana Rouiller Glaucia Peres Igor Macaúbas Marcos Pereira.
PSP - Aula 02 Vanilson Burégio.
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
Metodologias Ágeis – Leandro Rafael
Uma Análise no ciclo de vida de Gestão de Projetos com foco em Melhoria de Processos Híbridos para o desenvolvimento de software Hugo Vieira Lucena de.
Robson Godoi Grupo de Estudos em Processos de Desenvolvimento CIN - UFPE Outubro 2002.
Utilizando práticas do PMBOK para implantar o Scrum
SCRUM.
Gerenciamento de riscos
Gerenciamento de Escopo
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
SCRUM Development Process Universidade Federal de Pernambuco Lenylda Albuquerque
GERENCIAMENTO DE PROCESSOS AGÉIS: SCRUM
Pós-Graduação em Análise, Projeto e Gerência de Sistemas Centro Universitário Estácio do Ceará.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

Metodologia Ágil THOBER CORADI DETOFENO, MSC. Aula 04 JOINVILLE 2016 Universidade do Estado de Santa Catarina – CCT/UDESC

Metodologia Ágil Metodologia ágil é uma metodologia baseada na prática para modelagem efetiva de software; A metodologia é uma coleção de práticas, guiadas por princípios e valores que podem ser aplicados por profissionais de software no dia a dia. A metodologia não é um processo prescritivo, ela não define procedimentos detalhados de como criar um dado tipo de modelo, ao invés ela provê conselhos de como ser efetivo como modelador.

O que é (e não é) Metodologia Ágil ? 1. é uma atitude, não um processo prescritivo. 2. é um suplemento aos métodos existentes, ele não é uma metodologia completa. 3. é uma forma efetiva de se trabalhar em conjunto para atingir as necessidades das partes interessadas no projeto. 4. é efetivo e é sobre ser efetivo. 5. é uma coisa que funciona na prática, não é teoria acadêmica. 6. não é uma bala de prata. 7. é para o desenvolvedor médio mas não é um substituto de pessoas competentes. 8. não é um ataque à documentação, pelo contrário AM aconselha a criação de documentos que tem valor. 9. não é um ataque às ferramentas CASE. 10. não é para todos

Introdução ao Scrum Scrum vem sendo utilizado para o desenvolvimento de produtos complexos desde o início dos anos 90. Scrum não é um processo ou uma técnica para o desenvolvimento de produtos. Scrum é um framework dentro do qual você pode empregar diversos processos e técnicas

Teoria do Scrum Scrum, que é fundamentado na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Três pilares sustentam qualquer implementação de controle de processos empíricos: – Transparência – Inspeção – Adaptação

Teoria do Scrum Existem três pontos para inspeção e adaptação em Scrum. – A Reunião Diária é utilizada para inspecionar o progresso em direção à Meta e para realizar adaptações que otimizem o valor do próximo dia de trabalho; – As reuniões de Revisão da Sprint e de Planejamento da Sprint são utilizadas para inspecionar o progresso em direção à Meta; – A Retrospectiva da Sprint é utilizada para revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante.

Conteúdo do Scrum O framework Scrum consiste em um conjunto formado por: – Times Scrum e seus papéis associados; – Eventos com Duração Fixa (Time-Boxes); – Artefatos; e – Regras.

Papeis no Scrum Uma galinha e um porco estão juntos quando a galinha diz: “Vamos abrir um restaurante!” O porco reflete e então diz: “Como seria o nome desse restaurante?” A galinha diz: “Presunto com Ovos!” O porco diz: “Não, obrigado, eu estaria comprometido, mas você estaria apenas envolvida!”

Papeis no Scrum Times Scrum são projetados para otimizar flexibilidade e produtividade. E les são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada Time Scrum possui três papéis: – 1) o ScrumMaster, que é responsável por garantir que o processo seja entendido e seguido; – 2) o Product Owner, que é responsável por maximizar o valor do trabalho que o Time Scrum faz; e – 3) o Time, que executa o trabalho propriamente dito.

ScrumMaster O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda o Time Scrum e a organização a adotarem o Scrum. O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo. O ScrumMaster ajuda o Time Scrum a entender e usar autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não gerencia o Time Scrum; o Time Scrum é auto-organizável.

Product Owner O PO é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time. Mantém o Backlog do Produto e garante que ele está visível para todos. O Product Owner é uma pessoa, e não um comitê. Para que o PO obtenha sucesso, todos na organização precisam respeitar suas decisões.

O Time Times de desenvolvedores transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Times também são interdisciplinares Membros do Time frequentemente possuem conhecimentos especializados. As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem a Times. Todos contribuem, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. Não há títulos em Times, e não há exceções a essa regra. Os Times também não contém subtimes;

Time-Boxes Os Eventos com Duração Fixa (Time-Boxes) no Scrum são: – Reunião de Planejamento da Versão; – Sprint, – Reunião de Planejamento da Sprint; – Revisão da Sprint; – Retrospectiva da Sprint; e – Reunião Diária.

Reunião de Planejamento da Sprint O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas que o Time Scrum e o resto da organização possam entender e comunicar. O planejamento da versão para entrega responde às questões: – Como podemos transformar a visão em um produto vencedor da melhor maneira possível? – Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?

A Sprint A Sprint é uma iteração. Sprints são eventos com duração fixa. Durante a Sprint, o ScrumMaster garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint. As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint.

Reunião de Planejamento da Sprint A Reunião de Planejamento da Sprint é quando a iteração é planejada. É fixada em oito horas de duração para uma Sprint de um mês. Ou aproximadamente 5% do tamanho total da Sprint. Ela consiste de duas partes: – A primeira parte é quando é decidido o que será feito na Sprint. – A segunda parte é quando o Time entende como desenvolverá essa funcionalidade em um incremento do produto durante a Sprint.

Revisão da Sprint Ao final da Sprint, é feita uma reunião de Revisão da Sprint. Durante a Revisão da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanças no Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas. Essa é uma reunião informal.

Retrospectiva da Sprint Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, o Time Scrum tem uma reunião de Retrospectiva da Sprint. ScrumMaster encoraja o Time a revisar, dentro do modelo de trabalho e das práticas do processo do Scrum, seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint

Reunião Diária Cada time se encontra diariamente para uma reunião de 15 minutos chamada Reunião Diária; Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints. Durante a reunião, cada membro explica: – O que ele realizou desde a última reunião diária; – O que ele vai fazer antes da próxima reunião diária; – Quais obstáculos estão em seu caminho.

Artefatos do Scrum Os artefatos do Scrum incluem: – Backlog do Produto; – Backlog da Sprint.

Backlog do Produto Os requisitos para o produto que o(s) Time(s) está(ão) desenvolvendo estão listados no Backlog do Produto; O Product Owner é o responsável pelo Backlog do Produto, por seu conteúdo, por sua disponibilidade e por sua priorização. Backlog do Produto nunca está completo. O Backlog do Produto evolui à medida que o produto e o ambiente em que ele será usado evoluem, o Backlog é dinâmico. O Backlog do Produto representa tudo que é necessário para desenvolver e lançar um produto de sucesso. Um único Backlog do Produto é usado para descrever o trabalho a ser realizado no produto

Backlog da Sprint O Backlog da Sprint consiste nas tarefas que o time executa para transformar itens do Backlog do Produto em um incremento “pronto”. Muitas delas são elaboradas durante a Reunião de Planejamento da Sprint. O Backlog da Sprint é todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. O Time modifica o Backlog da Sprint no decorrer da Sprint, bem como surge Backlog da Sprint durante a Sprint.