1.
Introdução a Métodos Ágeis de Desenvolvimento de Software Daniel Cukier (AgilCoop) twitter.com/danicuki Prof. Dr. Rafael Prikladnicki (PUCRS) twitter.com/rafaelpri

2.
Quem usa Scrum e XP?

3.
Quem usa Scrum e XP?

4.
EUA BR 2 anos! Quem usa Scrum e XP?

5.
Quem usa Scrum e XP?

6.
Quem usa Scrum e XP?

7.
Quem usa Scrum e XP?

9.
Daniel Cukier <ul><ul><li>15 anos de experiência com desenvolvimento do Software </li></ul></ul><ul><ul><li>3 anos como gerente de Desenvolvimento na Locaweb </li></ul></ul><ul><ul><li>Membro da Agilcoop desde 2003 </li></ul></ul><ul><ul><li>Autor do blog www.agileandart.com </li></ul></ul><ul><ul><li>Mestre em Ciência da Computação – IME/USP (2009) </li></ul></ul><ul><ul><li>Palestra em vários eventos </li></ul></ul><ul><ul><li>Encontro Ágil, Oxente Rails, Falando em Ágil , SugarLoafPLoP, etc </li></ul></ul><ul><ul><li>Áreas de atuação acadêmica e profissional: </li></ul></ul><ul><ul><li>Desenvolvedor e líder técnico em vários projetos de software. </li></ul></ul><ul><ul><li>Um dos responsáveis pela implantação de Métodos Ágeis na Locaweb </li></ul></ul><ul><ul><li>Padrões para Introduzir Novas Ideias na Indústria de Software </li></ul></ul><ul><ul><li>Outras não menos importantes: </li></ul></ul><ul><ul><li>Teatro, música, poesia, meditação </li></ul></ul>

10.
Contexto e experiência na AgilCoop <ul><li>Cursos de graduação em XP desde 2001 </li></ul><ul><li>Apresentações </li></ul><ul><ul><li>SBES, SUCESU, SEPAI, SEBRAE, etc. </li></ul></ul><ul><ul><li>Arquivos disponíveis: www.agilcoop.org.br </li></ul></ul><ul><li>Assessorias em métodos ágeis </li></ul><ul><li>Artigos científicos </li></ul><ul><li>Dissertações de Mestrado </li></ul>

11.
<ul><ul><li>Professor da FACIN – PUCRS desde 2004 – www.inf.pucrs.br/~rafael </li></ul></ul><ul><ul><li>Coordenador de Gestão de Projetos da AGT/PUCRS </li></ul></ul><ul><ul><li>Professor do PPGCC desde 2010/1 </li></ul></ul><ul><ul><li>Coordenador do GUMA e do SPIN-POA (Sucesu-RS) </li></ul></ul><ul><ul><li>Certified ScrumMaster (CSM) e Project Mgmt Professional (PMP) </li></ul></ul><ul><ul><li>Mestre em Ciência da Computação – PUCRS (2003) </li></ul></ul><ul><ul><li>Doutor em Ciência da Computação – PUCRS (2009) </li></ul></ul><ul><ul><li>Áreas de atuação acadêmica e profissional: </li></ul></ul><ul><ul><li>Desenvolvimento Distribuído de Software </li></ul></ul><ul><ul><li>Gerência de Projetos </li></ul></ul><ul><ul><li>Melhoria de Processo de Software </li></ul></ul><ul><ul><li>Engenharia de Software Experimental </li></ul></ul><ul><ul><li>Lean e Métodos Ágeis para Desenvolvimento de Software </li></ul></ul>Rafael Prikladnicki

12.
Contexto e experiência na PUCRS www.inf.pucrs.br/munddos Criado em 2001 Registrado no CNPq em 2004 Livros publicados em 2007, 2009 e 2010 2 pesquisadores Formou 11 mestres, 1 doutor Possui 6 mestrandos, 2 doutorandos

13.
Implantação de práticas de DDS nas empresas Desenvolvimento de ferramentas para apoiar DDS Integração de DDS com métodos ágeis Estudo de maneiras de usar Follow-the-Sun (FTS) Formação de profissionais e alunos em DDS Estudo do papel do Brasil no mercado global de TI www.inf.pucrs.br/munddos Contexto e experiência na PUCRS

14.
Contexto e experiência na PUCRS

15.
<ul><ul><li>Introdução e motivação </li></ul></ul><ul><ul><li>O que são Métodos Ágeis? </li></ul></ul><ul><ul><li>Princípios </li></ul></ul><ul><ul><li>Problemas com abordagens tradicionais </li></ul></ul><ul><ul><li>Alguns métodos ágeis </li></ul></ul><ul><ul><li>Conclusão </li></ul></ul>Agenda

16.
<ul><li>Por que teu projeto termina com sucesso? </li></ul><ul><li>Por que teu projeto fracassa? </li></ul><ul><li>Discussão em grupo </li></ul><ul><ul><li>15 minutos </li></ul></ul><ul><ul><li>Agrupar problemas e fracassos em categorias </li></ul></ul>Dinâmica Grupo 2 Grupo n Grupo 1 Grupo 3 Sucesso Fracasso Ref: Henrik Kniberg

17.
Motivação

18.
<ul><li>Como ganhar dinheiro resolvendo problemas que voce não conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se divertindo)? </li></ul>Motivação

19.
Tenho como produzir 100 aviões em 10 minutos? Quantos aviões 10 pessoas produzem em 10 minutos? <ul><li>Tenho, mas: </li></ul><ul><li>Vou verificar tudo ao final </li></ul><ul><li>Posso ter baixa qualidade </li></ul><ul><li>Posso ter retrabalho </li></ul><ul><li>Posso não ter entendido o escopo </li></ul><ul><li>Então por que deixar tudo para o final? </li></ul>

20.
Tenho como produzir 100 aviões em 10 minutos? E se produzirmos um pouco a cada 2 minutos? E se melhorarmos a cada ciclo? E se o cliente fornecer feedback a cada ciclo? E se a equipe encontrar a melhor forma de trabalhar? Quantos aviões 10 pessoas produzem em 10 minutos?

21.
Motivação

22.
Motivação

23.
<ul><li>Sociedade demanda </li></ul><ul><ul><li>grande quantidade de sistemas/aplicações </li></ul></ul><ul><ul><li>software complexo, sistemas distribuídos, heterogêneos </li></ul></ul><ul><ul><li>requisitos mutantes (todo ano, todo mês, todo dia) </li></ul></ul><ul><li>Mas, infelizmente, </li></ul><ul><ul><li>não há gente suficiente para desenvolver tanto software com qualidade </li></ul></ul>Novos ventos no desenvolvimento de software

24.
<ul><li>Resultado dos projetos em 2004 </li></ul>Relatório do Chaos ( Chaos Report )

25.
<ul><li>Resultado dos projetos em 2004 </li></ul>Relatório do Chaos ( Chaos Report ) 1994 2004 Projetos não concluídos ------------ 31% Proj etos bem sucedidos ----- 16% Estouro médio de custo -----------------------> 180% Estouro médio de prazo -----------------------> 164% Proje tos não concluídos ------- 18% Projetos bem sucedidos ----------- 29% Estouro méd io de custo ----------------- 56% Estouro médio de prazo ------------------------- 84%

26.
Evitar desperdício <ul><li>Estudo do The Standish Group conclui (Chaos Report): Pesquisa sobre a utilização das funcionalidades do software ... </li></ul>Mais de 64% de um sistema de software quase nunca não é utilizado!

27.
<ul><li>Com métodos tradicionais/clássicos de desenvolvimento </li></ul><ul><ul><li>Supõem que é possível prever o futuro </li></ul></ul><ul><ul><li>Pouca interação com os clientes </li></ul></ul><ul><ul><li>Ênfase em burocracias </li></ul></ul><ul><ul><ul><li>(documentos, formulários, processos, controles rígidos, etc.)‏ </li></ul></ul></ul><ul><ul><li>Avaliação do progresso baseado na evolução da burocracia e não do código </li></ul></ul><ul><li>Com software </li></ul><ul><ul><li>Grande quantidade de erros </li></ul></ul><ul><ul><li>Falta de flexibilidade </li></ul></ul>Problemas

28.
<ul><li>Melhores Tecnologias </li></ul><ul><ul><li>Padrões de Projeto (reutilização de idéias) </li></ul></ul><ul><ul><li>Componentes (reutilização de código) </li></ul></ul><ul><ul><li>Middleware/frameworks (aumenta a bstração) </li></ul></ul><ul><li>Melhores Metodologias </li></ul><ul><ul><li>Métodos Ágeis (o foco deste mini-curso) </li></ul></ul><ul><ul><li>outras... (abordados em outros cursos de ES) </li></ul></ul>Como resolver o impasse?

29.
<ul><li>Erro comum: olhar para software como apenas um desses itens e ignorar os demais </li></ul>O que é desenvolvimento de software? Por Alistair Cockburn: (Gabriel) Arte (Knuth) Artesanato (Cockburn) Poesia (Humphreys) Disciplina (Meyer) Engenharia (Jacobson) Modelagem

30.
<ul><li>Agile is not a set of practices, but a core set of beliefs and principles </li></ul><ul><li>Jim Highsmith </li></ul>O que são métodos ágeis?

31.
<ul><li>Retorno de investimento </li></ul><ul><li>Inovação </li></ul><ul><li>Melhoria de processo </li></ul><ul><li>Pessoas </li></ul><ul><li>Cultura </li></ul><ul><li>Comunicação </li></ul><ul><li>Adaptação x Antecipação </li></ul>Princípios

32.
<ul><li>Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. </li></ul><ul><li>Questionam e se opõem a uma série de mitos e práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos. </li></ul><ul><li>Manifesto Ágil: </li></ul><ul><ul><li>Assinado por 17 desenvolvedores em Utah em fevereiro/2001. </li></ul></ul><ul><ul><li>http://agilemanifesto.org </li></ul></ul>Histórico

33.
Processos e ferramentas Documentação abrangente Negociação de contrato Plano pré-estabelecido mais importante que Agile Manifesto (2001) Indivíduos e interações Software funcionando Colaboração do cliente Resposta às mudanças <ul><ul><li>http://agilemanifesto.org </li></ul></ul>Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick

34.
<ul><li>O mais importante é o software funcionando </li></ul><ul><li>Periodicamente a equipe deve refletir sobre como se tornar mais efetivo </li></ul><ul><li>Profissionais motivados </li></ul><ul><li>Suporte às necessidades da equipe e a mbiente necessário para desenvolvimento das atividades </li></ul><ul><li>Confiança no trabalho da equipe </li></ul>Alguns princípios

35.
<ul><li>O gerente de projeto concorda em prosseguir sem que todos os requisitos estejam bem definidos </li></ul><ul><li>Os desenvolvedores concordam em prosseguir sem ter todos os requisitos documentados </li></ul><ul><li>Os membros da equipe sabem que alguém vai ajudar quando ocorrerem problemas </li></ul>Em um projeto ágil ideal...

36.
<ul><li>Os gerentes percebem que não precisam dizer à equipe o que fazer, ou garantir o que vai ser feito </li></ul><ul><li>A equipe percebe que ninguém vai dizer o que fazer, isto faz parte do trabalho da equipe </li></ul><ul><li>Não existem mais a impressão de divisão (testers and programmers), todos são desenvolvedores </li></ul>Em um projeto ágil ideal...

37.
Mudança de Postura Equipe Equipe Equipe Equipe GP Equipe Equipe Equipe Equipe GP Tradicional Ágil Cross-funcional Auto-organização

38.
<ul><li>0. Levantamento de Requisitos </li></ul><ul><li>1. Análise de Requisitos </li></ul><ul><li>2. Desenho da Arquitetura </li></ul><ul><li>3. Implementação </li></ul><ul><li>4. Testes </li></ul><ul><li>5. Produção / Manutenção </li></ul>Enquanto isso, num projeto tradicional...

39.
<ul><li>É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema </li></ul><ul><li>É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la </li></ul><ul><li>É necessário testar o sistema completamente antes de mandar a versão final para o cliente </li></ul>Premissas básicas do modelo tradicional

40.
Cascata é como uma bala de canhão

41.
Interface Cliente Servidor BD C Iterativo = não espere ter tudo correto na primeira vez Incremental = construa em ”pedaços” verticais ( features ) ao invés de horizontais (camadas) Desenvolvimento monolítico Desenvolvimento incremental Talvez não seja necessário construir o resto C Interface Cliente Servidor BD Iterativo e Incremental Ref: Henrik Kniberg 1 2 3 4 1 2 3

42.
Iterativo e Incremental Produto ?

43.
O que muda? Custo da mudança Intensidade e stress Tempo Tempo Tempo Entrega de valor Transparência Envolvimento do cliente Tempo Ref: Henrik Kniberg Tradicional Ágil

44.
Metodologias ágeis são uma tentativa de refinar as metodologias iterativas, tirando o foco do processo em si e dando mais ênfase para a contribuição das pessoas

45.
<ul><li>Metodologias ágeis é uma febre? Uma onda passageira? </li></ul>É o início de uma mudança na forma de trabalho...

46.
Evitar incerteza x Gerenciar para incerteza Ref: Luiz Cláudio Parzianello

47.
<ul><li>Visão tradicional </li></ul><ul><ul><li>“ Tudo é importante, vamos fazer tudo ao mesmo tempo!” </li></ul></ul><ul><li>Visão ágil </li></ul><ul><ul><li>“ Prioriza e foca naquilo que é mais importante!” </li></ul></ul>O paradoxo da multitarefa Ref: Henrik Kniberg Jan Feb Mar Abr Mai Jun Jul Jan Feb Mar Abr Mai Jun Jul A B C

48.
<ul><li>Métodos tradicionais </li></ul><ul><ul><li>O planejamento deve propiciar a prevenção de mudanças </li></ul></ul><ul><li>Métodos ágeis </li></ul><ul><ul><li>A mudança é incorporada ao escopo </li></ul></ul><ul><li>Razões </li></ul><ul><ul><li>Necessidades de negócio </li></ul></ul><ul><ul><li>Novas oportunidades </li></ul></ul><ul><ul><li>Mudanças de legislação </li></ul></ul><ul><ul><li>Requisitos incompletos </li></ul></ul>O que muda?

49.
<ul><li>A atitude dos desenvolvedores de software seria completamente diferente: </li></ul><ul><ul><ul><li>Tomaríamos as grandes decisões o mais tarde possível </li></ul></ul></ul><ul><ul><ul><li>Implementaríamos agora somente o que precisamos agora </li></ul></ul></ul><ul><ul><ul><li>Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades) </li></ul></ul></ul>E se fosse essa a realidade?

50.
<ul><li>Orientação a Objetos : facilita e cria oportunidades para mudanças </li></ul><ul><li>Técnicas de Refatoração </li></ul><ul><li>Testes automatizados : nos dão segurança quando fazemos mudanças </li></ul><ul><li>Prática / cultura de mudanças : aprendemos técnicas e adquirimos experiência em lidar com código mutante </li></ul>E essa é a nova realidade (em muitos casos)

51.
<ul><li>Adaptative Software Development (ASD) </li></ul><ul><ul><li>Jim Highsmith </li></ul></ul><ul><li>Crystal Clear (Crystal) </li></ul><ul><ul><li>Alistar Cockburn </li></ul></ul><ul><li>Extreme Programming (XP) </li></ul><ul><ul><li>Kent Beck, Eric Gamma </li></ul></ul><ul><li>Scrum </li></ul><ul><ul><li>Ken Schwaber, Jeff Sutherland, Mark Beedle </li></ul></ul><ul><li>Lean Software Development </li></ul><ul><ul><li>Mary e Tom Poppendieck </li></ul></ul><ul><li>Feature Driven Development (FDD) </li></ul><ul><ul><li>Peter Coad, Jeff DeLuca </li></ul></ul><ul><li>Test Drive Development (TDD) </li></ul><ul><li>Kanban </li></ul>Principais Métodos Ágeis

52.
<ul><li>Agile Project Management – Jim Highsmith, 2008 </li></ul><ul><li>Agile Enterprise Framework </li></ul>Governança e Portfólio Gerência de Projeto Gerência de Iterações Práticas Técnicas ROI, Progresso, Risco, Investimento Release, aquisição, PMBOK, externo Interno, Scrum XP, FDD, etc Mudança de perspectiva

53.
<ul><li>1. David Rico (2008) </li></ul><ul><ul><li>Survey de artigos acadêmicos e científicos publicados </li></ul></ul><ul><li>2. VersionOne (2008) </li></ul><ul><ul><li>Survey online com mais de 3.000 pessoas </li></ul></ul><ul><li>3. QSMA (Michael Mah 2008) </li></ul><ul><ul><li>Comparação rigorosa de 26 projetos ágeis com uma base de 7.500 projetos “tradicionais” </li></ul></ul><ul><ul><li>Equipes ágeis variando entre 26 e 1.000 pessoas </li></ul></ul><ul><li>4. Dr. Dobb’s Journal (2008) </li></ul><ul><ul><li>Survey online com 642 pessoas </li></ul></ul>Métodos ágeis funcionam?

54.
Fonte: Mah 2008. Agile projects are 16% more productive at a statistically significant level of confidence. Métodos ágeis funcionam?

55.
<ul><li>Satisfação no trabalho </li></ul><ul><ul><li>Após 15 meses de adoção do Scrum, 86% dos colabroadores da Salesforce.com estavam tendo um “good time” ou o “best time” </li></ul></ul><ul><ul><li>Apenas 40% disseram isto antes de adotar Scrum </li></ul></ul><ul><ul><li>92% recomendariam métodos ágeis para outras pessoas </li></ul></ul><ul><li>Time to Market </li></ul><ul><ul><li>VersionOne </li></ul></ul><ul><ul><ul><li>64% disseram que o time to market melhorou </li></ul></ul></ul><ul><ul><ul><li>23% disseram que melhorou significativamente </li></ul></ul></ul><ul><ul><li>Michael Mah </li></ul></ul><ul><ul><ul><li>Projetos ágeis tem um time to market 37% mais rápido com um nível de confiança estatisticamente significante </li></ul></ul></ul>Métodos ágeis funcionam?

56.
Fonte: Mah 2008. Métodos ágeis funcionam?

57.
<ul><li>Melhoria na satisfação dos stakeholders </li></ul><ul><ul><li>Dr. Dobb’s </li></ul></ul><ul><ul><ul><li>47% disseram que a satisfação foi “ somewhat higher ” </li></ul></ul></ul><ul><ul><ul><li>31% disseram que foi “ much higher ” </li></ul></ul></ul><ul><ul><li>Version One </li></ul></ul>Métodos ágeis funcionam? Improved Significantly Improved Enhanced ability to manage changing priorities 41% 51% Improved project visibility 42% 41% Improved alignment of IT and business goals 39% 27% Reduced project risk 48% 17%

58.
<ul><li>5 motivos para NÃO usar métodos ágeis? </li></ul>

59.
<ul><li>Motivo 1 </li></ul><ul><li>Eu sei e defino todos os requisitos no início do projeto </li></ul>Cinco Motivos para não usar Métodos Ágeis Não preciso de ciclos iterativos Qual projeto de software possui todos os requisitos definidos (corretamente) no início?

60.
<ul><li>Motivo 2 </li></ul><ul><li>Os objetivos do meu projeto estão muito claros desde o início </li></ul>Cinco Motivos para não usar Métodos Ágeis O cliente descobre o que quer ao longo do caminho

61.
<ul><li>Motivo 3 </li></ul><ul><li>Meu projeto envolve baixa incerteza </li></ul>Cinco Motivos para não usar Métodos Ágeis Qual projeto de software envolve baixa incerteza?

62.
<ul><li>Motivo 4 </li></ul><ul><li>Minha estimativa está toda definida e com índice de erro muito baixo </li></ul>Cinco Motivos para não usar Métodos Ágeis Em qual projeto de software consigo ter estimativas precisas?

63.
<ul><li>Motivo 5 </li></ul><ul><li>Meu processo é rígido e controlado (comando-controle) </li></ul>Cinco Motivos para não usar Métodos Ágeis As tarefas são delegadas, equipes ficam desmotivadas mais facilmente Qual equipe gosta de trabalhar desmotivada?

64.
<ul><li>Requisitos definidos desde o início </li></ul><ul><li>Objetivos claros desde o início </li></ul><ul><li>Comando-controle </li></ul><ul><li>Baixa incerteza </li></ul><ul><li>Estimativas precisas </li></ul><ul><li>Qual projeto de desenvolvimento de software possui estas características? </li></ul>Cinco Motivos para não usar Métodos Ágeis

65.
<ul><li>Requisitos definidos desde o início </li></ul><ul><li>Objetivos claros desde o início </li></ul><ul><li>Comando-controle </li></ul><ul><li>Baixa incerteza </li></ul><ul><li>Estimativas precisas </li></ul><ul><li>Qual projeto de desenvolvimento de software possui estas características? </li></ul>E os Cinco Motivos? Entao NÃO faz sentido NÃO usar metodologias ágeis na grande maioria dos casos. Mas não APENAS metodologias ágeis!!!

66.
<ul><li>SCRUM </li></ul>

67.
Scrum - Jogada de Rugby

68.
Ref.: 3rd Annual ”State of Agile Development” Survey June-July 2008 3061 respondentes, 80 países Quem usa Scrum?

69.
Requisitos Longe de um acordo Perto de um acordo Tecnologia Perto da certeza Longe da certeza Simples Complicado Complexo Anarquia Ref. : Strategic Management and Organizational Dynamics by Ralph Stacey, in Agile Software Development With Scrum by Ken Schwaber and Mike Beedle. Mesmo que o produto seja complexo... ... Tente manter uma iteração simples Como resolver

70.
Adaptativo E C D A Planejado Tradicional Ágil B C D A B D A B A B Sem 1 Sem 2 Sem 3 Sem 4 Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 Sem 7 Sem 8 Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 Sem 7 Sem 8

71.
<ul><li>Princípio </li></ul><ul><ul><li>Características desconhecidas </li></ul></ul><ul><ul><li>Prioridades devem ser consideradas </li></ul></ul><ul><ul><li>Escopo irá mudar! </li></ul></ul><ul><li>Essência do SCRUM </li></ul><ul><ul><li>Inspeção </li></ul></ul><ul><ul><ul><li>Verificar o que foi feito no período </li></ul></ul></ul><ul><ul><li>Adaptação </li></ul></ul><ul><ul><ul><li>Melhorar o processo </li></ul></ul></ul><ul><li>Planejar </li></ul><ul><ul><li>Planejar o sprint </li></ul></ul><ul><li>Desenvolver </li></ul><ul><ul><li>Realizar o sprint </li></ul></ul><ul><li>Inspecionar ( check ) </li></ul><ul><ul><li>Sprint review e retrospectiva </li></ul></ul><ul><li>Adaptar </li></ul><ul><ul><li>Lições para o próximo planejamento </li></ul></ul>Ênfase: processo empírico PLAN DO ACT CHECK

72.
O Framework do Scrum

73.
<ul><li>Product Owner e Cliente </li></ul><ul><li>Visão do produto </li></ul><ul><ul><li>Requisitos funcionais e não funcionais </li></ul></ul><ul><ul><li>Restrições e User stories (prática do XP) </li></ul></ul><ul><li>Criação do product backlog </li></ul><ul><ul><li>Conjunto de funcionalidades do sistema </li></ul></ul><ul><ul><li>Priorização das funcionalidades </li></ul></ul><ul><li>Preparação da base necessária para o desenvolvimeto </li></ul><ul><ul><li>Mecanismos de comunicação e coordenação </li></ul></ul><ul><ul><li>Formação das equipes </li></ul></ul>Planejamento e preparação

74.
<ul><li>User stories </li></ul><ul><ul><li>Identificação de atores envolvidos </li></ul></ul><ul><ul><li>Como um [papel do usuário] quero [funcionalidade] para [valor de negócio] </li></ul></ul><ul><ul><li>I.N.V.E.S.T. (independente, negociável, valorizável, estimável, small e testável) </li></ul></ul><ul><ul><li>Quebrar grandes e juntar pequenas </li></ul></ul><ul><ul><li>Definição do conceito de DONE (testes) </li></ul></ul><ul><ul><ul><li>Diferentes perspectivas </li></ul></ul></ul><ul><ul><li>Prioridades das user stories </li></ul></ul><ul><ul><ul><li>Valor entre 1 e 150? </li></ul></ul></ul><ul><ul><ul><ul><li>Must have </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Should have </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Could have </li></ul></ul></ul></ul>User Stories

75.
<ul><li>Product Owner , ScrumMaster e Equipe </li></ul><ul><li>Análise e organização do Product Backlog </li></ul><ul><ul><li>Refinamento das funcionalidades </li></ul></ul><ul><ul><li>Estimativas </li></ul></ul><ul><ul><li>Escolha das funcionalidades para o sprint </li></ul></ul><ul><ul><li>Formalização do sprint backlog </li></ul></ul><ul><ul><li>Identificação das tarefas </li></ul></ul><ul><ul><li>Organização da taskboard </li></ul></ul>Desenvolvimento 2-4 hs 2-4 hs

76.
<ul><li>Estimativas </li></ul><ul><ul><li>Tempo e/ou complexidade? </li></ul></ul><ul><ul><li>Fibonacci </li></ul></ul><ul><ul><ul><li>1, 2, 3, 5, 8, 13, 21… </li></ul></ul></ul><ul><ul><li>Planning poker </li></ul></ul><ul><ul><ul><li>As duas estratégias de uso de planning poker </li></ul></ul></ul><ul><ul><ul><ul><li>Jogar as cartas para cada estória </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Colocar cada estória embaixo de uma carta </li></ul></ul></ul></ul><ul><ul><li>Algumas práticas utilizadas: </li></ul></ul><ul><ul><ul><li>Pontos para funcionalidades e horas para tarefas </li></ul></ul></ul><ul><ul><ul><li>1- day tasks (máximo 2 e mínimo 1/2) </li></ul></ul></ul><ul><ul><ul><li>Considerar tarefas como teste, pesquisas, documentação, etc. </li></ul></ul></ul>Desenvolvimento

77.
<ul><li>Tempo ou Complexidade </li></ul><ul><ul><li>4 pessoas trabalhando 4 semanas </li></ul></ul><ul><ul><li>Equipe: 640 horas </li></ul></ul><ul><ul><li>2 junior, 2 senior </li></ul></ul><ul><ul><ul><li>Produzem 25 pontos de complexidade </li></ul></ul></ul><ul><ul><li>4 pessoas trabalhando 4 semanas </li></ul></ul><ul><ul><li>Equipe: 640 horas </li></ul></ul><ul><ul><li>4 senior </li></ul></ul><ul><ul><ul><li>Produzem 60 pontos de complexidade </li></ul></ul></ul>Desenvolvimento

78.
Planning poker 1 Muito pequeno! 2 3 5 8 13 21 40  Férias!  Mais detalhes!  Nem idéia!  Intervalo!

79.
<ul><li>Planning Poker na PRÁTICA! </li></ul><ul><ul><li>Avaliar distância entre </li></ul></ul><ul><ul><li>Argentina e Mongólia </li></ul></ul><ul><ul><li>Chile e Itália </li></ul></ul><ul><ul><li>Japão e Austrália </li></ul></ul><ul><ul><li>Índia e Alemanha </li></ul></ul><ul><ul><li>EUA e Rússia </li></ul></ul><ul><ul><li>Ucrânia e China </li></ul></ul>Planning poker

80.
VALOR COMPLEXIDADE Alta Baixa Alta Baixa UStory1 UStory2 UStory3 UStory4 Priorização e classificação do backlog

81.
40 30 30 28 30 31 30 30 Estimado Realizado 40 30 40 30 40 30 40 30 50 30 60 30 40 35 35 30 30 25 30 25 20 Calibrando a velocidade Estimado Realizado Estimado Realizado Estimado Realizado

82.
Calibrando a velocidade Início da sprint 8 5 3 5 5 5 3 5 5 8 Backlog do produto 8 5 3 5 5 Backlog da sprint Final da sprint 8 5 3 5 5 Feito! Feito! Feito! Quase Nem iniciamos Velocidade real = 18 Backlog da sprint Velocidade estimada = 26

83.
Administrate users Register new user Edit existing user Delete user Find user 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format Register new user Edit existing user Delete user Find user 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format Dividindo user stories

84.
Dividindo user stories Administrate users Register new user Edit existing user Delete user Find user User admin User admin User admin User admin Do GUI design Write failing test Do integration test Create DB schema Write server-side logic Write form validation Dividir Quebrar em tarefas durante a reunião de sprint planning 13 5 3 8 2 Ref: Henrik Kniberg Como priorizar itens do backlog? Como planejar as tarefas?

85.
<ul><li>ScrumMaster e Equipe </li></ul><ul><li>Dia-a-dia do SCRUM </li></ul><ul><ul><li>Sprint </li></ul></ul><ul><ul><ul><li>2 semanas a 4 semanas </li></ul></ul></ul><ul><ul><li>Daily meetings (Daily Scrum) </li></ul></ul><ul><ul><li>Impedimentos </li></ul></ul><ul><ul><ul><li>Obstáculos ao trabalho da equipe </li></ul></ul></ul><ul><ul><li>Manter a taskboard </li></ul></ul><ul><ul><ul><li>Burndown </li></ul></ul></ul><ul><ul><ul><li>Tarefas e estimativas </li></ul></ul></ul><ul><ul><ul><li>Tarefas não-planejadas </li></ul></ul></ul>Desenvolvimento

86.
O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Gráfico de Burndown de uma Sprint de duas semanas Vamos terminar antes

87.
O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Gráfico de Burndown de uma Sprint de duas semanas Não vamos conseguir cumprir a meta desta sprint

88.
O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Não estamos atualizando o gráfico de burndown Gráfico de Burndown de uma Sprint de duas semanas

89.
O Gráfico de Burndown 100 200 300 400 Trabalho que resta no projeto (pontos de user story) Nro de sprints 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 O projeto vai terminar entre os sprints 14 e 16 Gráfico de Burndown da release ou do projeto

90.
<ul><li>Daily Meetings (Daily Scrum) </li></ul><ul><ul><li>Reunião diária de 15 minutos </li></ul></ul><ul><ul><li>Mantém equipe informada e integrada </li></ul></ul><ul><ul><ul><li>O que você fez ontem? </li></ul></ul></ul><ul><ul><ul><li>O que pretende fazer para amanhã? </li></ul></ul></ul><ul><ul><ul><li>Quais são seus impedimentos? </li></ul></ul></ul><ul><ul><li>Questões técnicas </li></ul></ul><ul><ul><ul><li>No final da reunião </li></ul></ul></ul><ul><ul><li>Não se resolve problema, apenas se identifica </li></ul></ul>Desenvolvimento

91.
<ul><li>Para ajudar na execução ( taskboard ) </li></ul>Desenvolvimento

92.
<ul><li>Cliente, PO, SM e Team </li></ul><ul><li>Apresentação do produto </li></ul><ul><li>Foco no QUE foi feito e não COMO foi feito </li></ul><ul><li>Aceite formal e feedback do cliente </li></ul><ul><li>Melhoria na forma de priorização? </li></ul>Sprint review

93.
<ul><li>Lições aprendidas </li></ul><ul><ul><li>Alimentam o próximo sprint </li></ul></ul><ul><ul><ul><li>Velocidade da equipe </li></ul></ul></ul><ul><ul><ul><li>Erros x acertos </li></ul></ul></ul><ul><ul><ul><li>Previsto x realizado </li></ul></ul></ul><ul><ul><ul><li>Fator de foco da equipe </li></ul></ul></ul><ul><ul><li>Repositório de lições </li></ul></ul><ul><ul><li>Disseminação na empresa </li></ul></ul><ul><li>Usar parte do sprint anterior para planejar o próximo sprint </li></ul>Próximo sprint Lições aprendidas

94.
Sprint 2-4 semanas ??? Objetivo do Sprint Produto a ser entregue (ou seu incremento) ‏ Backlog do produto Cupons Embrulho 24 horas Fluxo do Scrum Cancel Gift wrap Return Backlog da Sprint Cupons Cancelar Sprint Planning 1 Sprint Planning 2 Daily Scrum Sprint Review Retrospectiva

95.
<ul><li>XP </li></ul>

96.
<ul><li>Lembram disto? </li></ul><ul><li>Como Métodos Ágeis podem ajudar a resolver ou minimizar os motivos de fracasso identificados? </li></ul>Dinâmica Grupo 2 Grupo n Grupo 1 Grupo 3 Sucesso Fracasso Ref: Henrik Kniberg

97.
<ul><li>Quando temos problema em cronograma, modelos tradicionais cortam testes, modelos ágeis cortam histórias. Um reduz a qualidade, o outro reduz o escopo. </li></ul><ul><li>A questão não é documentar, é entender. </li></ul><ul><li>Não existem melhores práticas. Existem boas práticas para determinadas situações. </li></ul><ul><li>Entregue hoje. Adapte amanhã. </li></ul><ul><li>Adaptação é uma resposta à mudança. </li></ul><ul><li>Equipes auto-gerenciáveis não são equipes sem liderança, são equipes com outro estilo de liderança. </li></ul><ul><li>Uso de técnicas como Refatoração, Testes, Modelagem Ágil são fundamentais para constante mudança do código </li></ul><ul><li>Plans are nothing; Planning is everything </li></ul>Conclusões

98.
twitter.com/danicuki twitter.com/rafaelpri

99.
Dinâmica Analista Projetista Programador Testador Cliente Ref: Luiz Cláudio Parzianello  Æ Œ

100.
Dinâmica … … … … Ref: Luiz Cláudio Parzianello … … … … Pequenos Lotes Grandes Lotes   Æ    Æ Œ  Æ  Æ  Æ Œ ™  Æ Œ  Æ Œ  Æ Œ ™  Æ Œ ™   Æ  Æ Œ  Æ Œ ™

101.
<ul><li>Qual é o arranjo logístico mais rápido ? </li></ul><ul><li>Qual equipe apresentou o maior esforço por projeto? </li></ul><ul><li>Quais as vantagens de cada abordagem? </li></ul><ul><li>Quais as desvantagens de cada abordagem? </li></ul><ul><li>Qual a justificativa para manter os grandes lotes? </li></ul>Dinâmica