Preparatório para a Certificação EXIN Agile Scrum Foundation

Transcrição

1 Preparatório para a Certificação EXIN Agile Scrum Foundation

2 Visão Geral Introdução EXIN Agile Scrum Fundamentos é uma certificação que valida o conhecimento de um profissional na combinação das metodologias ágeis com as práticas Scrum. O Agile Scrum ensina como trabalhar em conjunto para alcançar um objetivo com sucesso. As metodologias ágeis são abordagens populares no desenvolvimento de software e que estão cada vez mais sendo utilizadas em outras áreas. As práticas Scrum incluem o estabelecimento de times multifuncionais e auto gerenciáveis, produzindo uma entrega de trabalho ao final de cada iteração ou Sprint. Contexto O exame EXIN Agile Scrum Fundamentos é parte do programa de qualificação EXIN e foi desenvolvido em cooperação com especialistas internacionais da área. Público alvo A filosofia ágil é mais conhecida na área de desenvolvimento de software, mas os seus princípios estão cada vez mais sendo aplicados em outros tipos de projetos. O Scrum é a metodologia ágil mais utilizada e é apropriada para todos os profissionais que procuram manter seus conhecimentos atualizados com os últimos desenvolvimentos das áreas de TI e gerenciamento de projetos, particularmente aqueles que lideram e participam de projetos. Em particular, a certificação é apropriada para os profissionais que trabalham nas áreas de: Gerenciamento de Projetos, Desenvolvimento de Software, Gerenciamento de Serviços de TI e Gerenciamento de Negócios.

3 Visão Geral Pré-requisito(s) Nenhum, mas os candidatos são aconselhados a realizar o treinamento. Tipo do exame Questões de múltipla escolha realizadas online pelo computador ou impressas em papel. Indicação de tempo de estudo 60 horas, dependendo do conhecimento pré-existente. Exercício(s) prático(s) Não se aplica Tempo permitido para o exame 60 minutos Detalhes do exame Número de questões: 40 Índice mínimo para aprovação: 65% (26 de 40) Permitido consultas de livros/notas: Não Permitido utilizar equipamentos eletrônicos: Não

4 Conceitos de Agile e Scrum

5 Manifesto Ágil

6 Manifesto Ágil Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. O método mais eficiente e eficaz de transmitir informações para, e por dentro de um equipe de desenvolvimento, é através de uma conversa cara a cara.

7 Manifesto Ágil Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, ritmos constantes. Contínua atenção à excelência técnica e bom design, aumenta a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitos e designs emergem de equipes auto organizadas. Em intervalos regulares, a equipe reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

8 Conceitos de Agilidade Cenários Aplicação de metodologias ágeis é recomendada para cenários complexos onde existem incertezas com relação aos requerimentos e/ou tecnologia. Traduzido e adaptado de John Decoster: johandecoster.wordpress.com

9 Traduzido e adaptado de Mike Griffiths: Traduzido e adaptado de BigVisible:

10

11 Métodos Ágeis Métodos Ágeis Crystal Feature-Driven Development (FDD) Dynamic Systems Development Method (DSDM) Lean Agile Unified Process (AUP) Extreme Programming (XP) Scrum

12 Crystal Família de metodologias designadas para projetos dirigidos por pequenas equipes desenvolvendo sistemas de baixa criticidade (Crystal Clear) até grandes equipes desenvolvendo sistemas de alta criticidade (Crystal Magenta).

13 Crystal Princípios: Entrega frequente Construção de incrementos da solução. Melhorias reflexivas Regularmente checar por caminhos de melhoria e implementá-los. Comunicação osmótica Equipes colocadas compartilhando informação. Segurança pessoal Ambiente seguro para as pessoas levantarem problemas ou questões. Foco Saber no que e como trabalhar.

14 FDD FDD = Feature-Driven Development

15 FDD Práticas comuns: Equipes exploram o domínio ou o ambiente de negócio do problema a ser solucionado. Desenvolvimento por funcionalidade (feature), com entregas curtas. Propriedade individual de código. Equipes montados por feature. Inspeções para garantia de qualidade. Gerenciamento de configuração (versionamento). Compilação frequente. Visibilidade de progresso e resultado.

16 DSDM DSDM = Dynamic Systems Development Method Traduzido e adaptado de Marcel Douwe Dekker Licenciado por Creative Commons Attribution-ShareAlike 3.0 Unported License (CC BY SA)

17 DSDM 8 princípios: Foco na necessidade de negócio. Entrega no prazo. Colaboração. Nunca comprometer qualidade. Construção incremental. Desenvolvimento iterativo. Comunicação clara e contínua. Demonstrar controle.

18 Lean Lean = Princípios da manufatura que foram introduzidos no conceito de desenvolvimento de software

19 Lean 7 Conceitos: Eliminar desperdício Evitar trabalho parcialmente feito, atrasos, funcionalidades desnecessárias. Fortalecer a equipe Evitar micro gerenciamento e respeitar o conhecimento técnico da equipe. Entregas rápidas Maximiza o ROI (Return Of Investiment) através de entregas rápidas de valor. Otimiza o todo O sistema é mais que a soma das partes. Construir qualidade Construir qualidade no produto e garantir a qualidade no processo através de técnicas como refatoração, integração contínua e testes unitários. Adiar decisões Deixar as decisões para o momento onde o comprometimento será assumido. Amplificar conhecimento Comunicação e feedback constante.

20 AUP AUP = Agile Unified Process Iteração de Release de desenvolvimento resulta em implantação para área de homologação/qa Iteração de Release de produção resulta em implantação para área de produção Disciplinas Modelagem Implementação Testes Implantação Gerenciamento da Configuração Gerenciamento de Projeto Ambiente

21 XP = Extreme Programming XP

22 XP 5 valores: Simplicidade Comunicação Feedback Coragem Respeito 13 práticas: Whole Team Representados pelas figuras do cliente ( customer ), equipe (desenvolvedores, analistas de negócio, QA) e coach que devem trabalhar sentados próximos como membros de uma única equipe ( Whole Team ). Planning Games Planejamento das iterações (entregas) e releases (lançamentos para o usuário final). Small Releases Releases em curtos períodos de tempo para obter feedback.

23 XP Customer Tests Cliente final descreve os testes necessários para aceitação e a equipe constrói ferramentas para automação de testes. Collective Code Ownership O código não possui um dono. Toda a equipe pode trabalhar no código. Code Standards Criar padronização de código para que todos possam ter o mesmo entendimento. Promove desacordo construtivo. Sustainable Pace Trabalhar em ritmo sustentável, evitando muitas horas extras. Metaphor Criar metáforas para compartilhar designs e visão técnica. Continuous Integration Testes automatizados cada vez que um código é atualizado no repositório. Test-Driven Development (TDD) Desenvolvimento orientado a teste.

24 XP Refactoring Refatorar o código melhorando a codificação existente sem alterar o comportamento da funcionalidade. Eliminar código duplicado (DRY Don t Repeat Yourself) Simple Design Focar na simplicidade. Pair Programming Programação em par. Enquanto uma pessoa escreve o código outra pessoa está junto orientando e dando feedback. Ajuda a compartilhar conhecimento.

25 Scrum

26 Scrum Pilares do processo empírico Transparência Todo e qualquer fator ou acontecimento relacionado ao processo de entrega, que possa impactar o resultado final do projeto (produto), deve ser visível e do conhecimento de todos envolvidos, inclusive o cliente. Inspeção Todos os aspectos do processo de entrega que possam impactar o resultado final do projeto devem ser inspecionados frequentemente, para que qualquer variação prejudicial possa ser identificada e corrigida o mais rápido possível. Adaptação Toda vez que uma variação prejudicial é identificada, o processo deve ser ajustado imediatamente, como forma de evitar outros desvios.

27 Qual método usar? Tailoring Tailoring : Identificar qual é o melhor método ou mesmo como extrair o melhor de cada método de acordo com o projeto que está sendo conduzido. Conceito Shu-ha-ri: Shu: Obedecer Ha: Romper Ri: Superar

28 Papéis no Scrum

29 Papéis

30 Product Owner (P.O.) Dono do Produto Cria a visão do produto Cria e gerencia o backlog do produto Garante o valor/roi dos requisitos Captura necessidades e expectativas dos stakeholders Trabalha de forma colaborativa com o Time Scrum Somente uma pessoa assume o papel do Product Owner por projeto

31 Scrum Master Atua como coach, facilitador e removedor de impedimentos do Time Scrum Dissemina o conhecimento de Scrum na organização Orienta e apoia o Product Owner

32 Time Scrum Equipe auto-organizada e multidisciplinar Composta de 3 a 12 integrantes Cria tarefas para desenvolver os requisitos do produto Alto comprometimento Comunicação e sinergia entre os próprios membros do Time Scrum e também com o P.O.

33 Cerimônias do Scrum

34 Timebox Timebox = Intervalo curto de tempo e com duração fixa. Exemplos: Reunião Daily Scrum tem Timebox de 15 minutos. As Sprints do novo projeto possuem Timebox de 2 semanas.

35 Sprint Evento com timebox de 1 a 4 semanas. Evento onde o Time Scrum transforma os requisitos em potencial incremento de produto que atenda a definição de pronto. Uma Sprint sempre deve entregar valor ao produto.

36 Daily Scrum / Daily StandUp Sincronizar as tarefas e montar plano para as próximas 24h Deve ser realizada todos os dias Timebox: 15 minutos Participantes: Time Scrum e Scrum Master Perguntas a serem respondidas: O que eu fiz ontem? O que farei hoje? Quais os impedimentos?

37 Revisão da Sprint Reunião realizada no último dia da Sprint Demonstração do incremento do produto para Product Owner e stakeholders Participantes: Product Owner, Time Scrum, Scrum Master e stakeholders que o Product Owner julgar necessário Timebox: Sprints de 4 semanas 4 horas Sprints de 3 semanas 3 horas Sprints de 2 semanas 2 horas Sprints de 1 semana 1 hora

38 Retrospectiva da Sprint Reunião que ocorre ao final de cada Sprint, onde os membros da equipe identificam como melhorar seus processos e sua forma de trabalhar. Participantes: Product Owner, Time Scrum e Scrum Master Timebox: Sprints de 4 semanas 3 horas Sprints de 3 semanas 2 horas e 15 minutos Sprints de 2 semanas 1 hora e 30 minutos Sprint de 1 semana 45 minutos

39 Product Backlog

40 Product Backlog Artefato que contém os requisitos do produto priorizados e ordenados Criado e gerenciado única e exclusivamente pelo Product Owner Estimado pelo Time Scrum Pode conter: Requisitos funcionais Requisitos não funcionais Casos de uso User Stories Páginas Wiki

41 User Stories Descrições simples que descrevem uma funcionalidade. Escritas segundo o ponto de vista do(s) usuário(s) ou cliente(s) finais do produto. Deve ter como características: 3Cs (Cards / Conversation / Confirmation) INVEST (Independent / Negotiable / Valuable / Estimatable / Small / Testable) Formato: Como <<ator>> Quero <<ação>> Então <<resultado ou benefício>> [opcional]

42 Traduzido e adaptado de Roman Pichler: Licenciado por Creative Commons Attribution-ShareAlike 3.0 Unported License (CC BY SA)

43 Traduzido e adaptado de Roman Pichler: Licenciado por Creative Commons Attribution-ShareAlike 3.0 Unported License (CC BY SA)

44 Métodos e Práticas Scrum

45 Refatoração Prática do XP que ajuda na qualidade do produto. Melhorar o código sem alterar sem comportamento Remover código duplicado (DRY Don t Repeat Yourself)

46 Programação em Par Prática do XP que ajuda na qualidade do produto. Dois membros do Time Scrum desenvolvendo na mesma estação de trabalho

47 Integração Contínua Prática do XP que ajuda na qualidade do produto. Integração contínua é um processo de desenvolvimento de software. Integração contínua usa ferramentas automatizadas para iniciar o processo de integração quando o código é "checado" ou em intervalos de tempo. GERENCIAMENTO DE CONFIGURAÇÃO

48 Desenvolvimento Orientado a Testes Técnica da indústria de desenvolvimento de software.

49 Testes Ágeis vs. Testes Convencionais Traduzido e adaptado de Scott Ambler:

50 Spike Traduzido e adaptado de Julian Everett: julianeverett.wordpress.com

51 Definição de Pronto Todos os envolvidos no projeto deverão ter o mesmo entendimento sobre requisito pronto (Done). Pronto = Desenvolvido? Testado? Homologado?

52 Planejamento Scrum

53 Roadmap do Produto Panorama visual dos releases do produto e suas principais funcionalidades. Visão de alto-nível do produto criada pelo Product Owner.

54 Minimally Marketable Feature - MMF MMF = Conjunto mínimo de funcionalidades que torna o produto utilizável pelo cliente, embora não represente o produto final a ser gerado pelo projeto. Exemplos: MMF de um celular = Aparelho que faça e receba chamadas. MMF de uma caneta = Objeto que permita escrever em um pedaço de papel.

55 Elaboração Progressiva Elaboração Progressiva / Sucessão Elaboração progressiva é o processo de adicionar mais detalhes ao projeto conforme a informação emerge. Também conhecido como sucessão em projetos de arquitetura de software.

56 Entregas Incrementais Time Scrum regularmente entrega incrementos do produto ao decorrer do projeto. Oportunidade de obter rápido feedback do produto e permitir adequações sem que o custo da mudança seja alto. Oportunidade de aproveitar os benefícios do produto logo cedo e começar a obter o ROI.

57 Priorizando Requisitos Priorização Orientada a Valor Esquemas Simples: 1, 2 e 3. Alta, Média e Baixa. Essencial e Desejável Método dos 100 pontos: Atribuir nota de 0 a 100, onde 100 é a prioridade máxima. MoSCoW: Must Have = Fundamental Should Have = Importante Could Have = Agrega Valor Won t Have = Desejável, mas não afeta o valor do produto se não tiver

58 Priorizando Requisitos Monopoly Money Atribuir valores monetários aos requisitos. Análise de Kano Exciters: Novidades do produto que agradam ao cliente. Satisfiers: Quanto mais melhor. Dissatisfiers: Funcionalidade que se não tiver pode prejudicar o valor do produto, mas se tiver talvez não agregue tanto. Indifferent: Tanto faz.

59 Estimativas Ágeis Horas Ideais Quantidade de horas que efetivamente serão gastas no projeto, descontando as horas gastas em outros tipos de trabalho ou distrações (ex: ler s, atender telefone, tomar café).

60 Estimativas Ágeis Story Points Métrica relativa utilizada para estimar o esforço de cada um dos requisitos do projeto. Métrica relativa baseada na sequência de Fibonacci ( 0, 1, 2, 3, 5, 8, 13, 21, etc. ), atribuindo um número da sequência baseado em esforço, complexidade e riscos.

61 Estimativas Ágeis Estimativas por Afinidade Estimativa por afinidade é o processo de agrupar requisitos em categorias ou coleções. Traduzido e adaptado de Chris Sterling:

62 Planning Poker Estimativas Ágeis

63 Estimativas Ágeis Velocidade Velocidade é a quantidade de esforço concluído pelo Time Scrum a cada Sprint. Estimada pelo Time Scrum. Podem ser utilizadas como unidades de métrica: horas, dias ou story points

64 Estimativas Ágeis Exercício: Um Time Scrum executou 5 Sprints com as seguintes velocidades: 40, 48, 52, 59 e 51 story points. Faltam 600 story points para serem completadas. Qual a expectativa de Sprints restantes para completar o projeto? Resposta: Velocidade acumulada = = 250. Velocidade média = 250 / 5 Sprint = 50 story points/sprint. Sprints restantes = 600 / 50 = 12 Sprints.

65

66 Decomposição Orientada a Valor Processo de decomposição dos requisitos é feito: Da visão do produto para o roadmap do produto Do roadmap do produto para o backlog do produto. Do backlog do produto para o plano de release. Do plano de release para as metas das Sprints. Das metas das Sprints para o backlog da Sprint (Sprint Backlog) e o plano diário. Decomposição e priorização dos requisitos do projeto são feitos no último momento responsável (Last Responsible Moment).

67

68 Planejamento de Release Planejamento dos lançamentos do produto. Elaborado pelo Product Owner Um projeto pode conter um ou mais releases. Um release pode conter uma ou mais Sprints. Pode ser conduzido a entregas por datas (Quais funcionalidades poderão ser entregues nas datas fixadas). Pode ser conduzido a entregas por funcionalidades. A velocidade do Time Scrum pode ser utilizada para calcular quantas Sprints serão necessárias para completar o release. Exemplo: Para o release, o Product Owner selecionou user stories que somadas resultam em 100 story points. O Time Scrum tem uma velocidade média de 50 story points por Sprint. Logo: 100 / 50 = 2 Sprints.

69 Planejamento de Sprint Planejamento de Sprint

70 Planejamento de Sprint Cerimônia realizada no primeiro dia de cada Sprint Evento dividido em 2 partes de acordo com o Timebox abaixo: Sprints de 4 semanas 8 horas (divididas em 2 partes de 4 horas) Sprints de 3 semanas 6 horas (divididas em 2 partes de 3 horas) Sprints de 2 semanas 4 horas (divididas em 2 partes de 2 horas) Sprint de 1 semana 2 horas (divididas em 2 partes de 1 hora) Parte I Participantes: Product Owner, Time Scrum, Scrum Master Objetivo: Definir meta da Sprint Escopo: Planejamento das user stories priorizadas pelo Product Owner que podem ser desenvolvidas, testadas e entregues dentro de uma Sprint. Product Owner lista as user stories que deseja para a Sprint. Time Scrum assume compromisso dentro de sua capacidade e velocidade. Parte II Participantes: Time Scrum, Scrum Master Objetivo: Criar o backlog da Sprint (Sprint Backlog) com as tarefas necessárias p/ atingir a meta da Sprint (SBI Sprint Backlog Items) Escopo: Time Scrum discute o entendimento sobre a meta da Sprint e define as tarefas (SBIs) necessárias, sem definir responsáveis individuais pelas tarefas. Obs: o backlog da Sprint é de responsabilidade única e exclusiva da Time Scrum.

71 Monitorando Projetos com Scrum

72 Gráficos Burn Up e Burn Down Gráficos que exibem o progresso e ajudam a identificar variações e tendências do projeto. Gráfico Burn Down mostra o esforço remanescente para finalizar o projeto. Gráfico Burn Up mostra o esforço que já foi concluído. Não identificam as causas das variações.

73

74 Kanban/Quadro de Tarefas Atua como um radiador de informação.

75 Controlando Qualidade Defeitos Defeitos que não são detectados durante os processos de testes e validação e são detectados quando o produto já se encontra com o cliente. O custo da mudança para este tipo de defeito é o mais caro. Defeitos devem ser monitorados por algum tipo de métrica (dias, semanas, meses, Sprints e releases). Traduzido e adaptado de Managing Americans:

76 Engajamento dos Stakeholders Radiadores de Informação Tornar informações do projeto visível em áreas de circulação ( War Room, Sala do café, corredores, etc.).

77 Conceitos Avançados de Scrum

78 Scrum em Equipes Grandes Vários Times Scrum de até 9 integrantes atuando no desenvolvimento de PBIs de um único Product Backlog.

79 Scrum em Suporte de Sistemas Criar um Product Backlog com os itens de melhorias e correções. Ter um membro do Time Scrum dedicado na resolução de incidentes emergenciais. Restante do Time Scrum focado na Sprints de melhorias e correções.

80 Práticas de Aumento de Desempenho da Equipe Espaço da Equipe Espaço da equipe (Team Space) é o ambiente designado onde os membros da equipe irão conduzir os trabalhos do projeto. O ambiente deve favorecer a comunicação face-a-face e promover: Comunicação osmótica Conhecimento tácito

81 Práticas de Aumento de Desempenho da Equipe Equipes Distribuídas Para gerenciamento de equipes distribuídas: Manter uma metáfora. Manter a comunicação frequente. Intensificar facilitação da informação. Manter os conference calls efetivos e produtivos.

82 Práticas de Aumento de Desempenho da Equipe Calendário Niko-Niko Calendário que reflete o estado de espírito dos membros do Time Scrum dia-a-dia

83 Contratos Ágeis Contrato DSDM Adequado para o propósito do negócio, testes passáveis mais que corresponder a uma especificação. Fixed Price Work Package Contrato a preço fixo mas fechado a cada pacote de trabalho/sprint. Elaborar um SOW (Statement Of Work) para cada pacote de trabalho ou Sprint.

84 Transição para Scrum Para transição de equipes e projetos para Scrum, deve-se levar em consideração: Começar com projetos curtos e que não sejam considerados missão-crítica Avaliar se o uso do Scrum atenderá a causa-raiz que motivou a adoção do Scrum Se realmente trará benefícios ao projeto e à organização ou se é um benefício pessoal Começar aos poucos. Usar uma Sprint como experimento Revisar os efeitos colaterais na reunião de retrospectiva da Sprint

85 Fim Boa sorte no exame ASF