Metodologias Ágeis

1. Metodologias Ágeis Desenvolvimento Ágil aplicado aos Projetos de Software Ana paulaalves de lima

2. Por que ser ágil? • Crescentes pressões do mercado por: • Inovação, • Produtividade (prazos cada vez mais curtos), • Flexibilidade, • Melhoria no desempenho/qualidade dos projetos de desenvolvimento de SW • O ágil surgiu dado a necessidade de melhorarmos a forma como estamos desenvolvendo SW e nosso foco principal é satisfazer o cliente.

3. Quem usa isso?

4. História • 75 anos atrás • IIDD – Desenho e desenvolvimento interativo e incremental • Aumentar satisfação do cliente • Evitar o desencorajamento da Gestão • Década de 80 • Aprimoramento da Engenharia de Software • Diversificação das linguagens de programação • Década de 90 • Maturação dos processos de desenvolvimento de Software • Semente dos modernos processos de Desenvolvimento Ágil • 2001 - 17 especialistas se reúnem nos EUA para discutir modernas formas de se desenvolver Software • Estabelecida a Aliança Ágil • Manifesto Ágil • Princípios comuns compartilhados por todos os métodos de sucesso aplicados pelos especialistas durante suas carreiras

5. Disponível em agilemanifesto.org

6. Guarda Chuva Ágil

8. Por que usar?

9. Por que usar? • Dos 63% restantes: • 2/3 possuem problemas • Estouro de Prazo • Não atendem as necessidades • Estão cheio de defeitos • 1/3 é um total fracasso • Cancelado/engavetado • Nunca colocado em produção ou utilizado pelo cliente • Dos casos de sucesso, em geral apenas 20% das funcionalidades são realmente úteis.

10. Por que usar? • Suposições de início de projeto • Os requisitos são 100% conhecidos e foram minuciosamente detalhados • O Desenvolvedor sabe construir • Nada irá mudar ao longo do caminho • Realidade que deve ser observada : • “Um processo rígido ou resistente a mudanças produz produtos medíocres. Os clientes podem até receber o que eles solicitaram primeiramente, mas é esse o produto que eles realmente querem logo quando eles o recebem? Coletando todos os requisitos no início e escrevendo-os sobre pedra, o produto é condenado a ser tão bom quanto a idéia inicial, ao invés de ser o melhor uma vez que as pessoas aprendem ou descobrem como fazer melhor.” [Jeff Sutherland] • Idéias, novas tecnologias e opções surgem no decorrer do projeto. Desta forma uma nova idéia não deveria ser mau vista pela equipe/gestor. • Sim, as coisas mudam durante o caminho

12. SCRUM

13. Porque Scrum? • “O Scrum não é um processoprevisível, elenão define o que • fazeremtodas as circunstâncias” KEN SCHWABER (2004) • É um framework ágil leve que gerencia e controla o desenvolvimento do software aumentando a produtividade e reduzindo o tempo para obter excelentes resultados; • Bastanteobjetivo • Papéis e Responsabilidadesbemdefinidas • Fáciladaptação • Curva de aprendizadobaixa • Não é um processoprevisível • É um framework, um conjunto de práticas • O Scrum nãovaidizerexatamente o quefazer, nãoirá resolver • todososseusproblemas, mas com certezaosproblemasserãomaisfacilmenteidentificados.

14. Elementos do Scrum – EQUIPE DE ATÉ 6 PESSOAS • PAPÉIS • Product Owner • ScrumMaster • Time • REUNIÕESouCERIMÔNIAS • Sprint Planning • Daily Scrums • Sprint Review • Sprint Retrospective • ARTEFATOS • Product Backlog • Sprint Backlog • Burndown Chart

15. O que é Sprint • No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. • O Sprint representa um tempo definido dentro do qual um conjunto de atividades deve ser executado. • O trabalho é dividido em iterações, que no Scrum são chamadas de Sprints e geralmente duram de 2 a 4 semanas.

17. Papéis • Define as funcionalidades do produto • Define as datas dos releases • Responsável pelo retorno do investimento (ROI) do projeto • Priorizaas funcionalidades de acordo com seu valor de negócio • Ajusta o productbacklog a cada sprint, se necessário. • Pode ser o representante de um cliente, ou o próprio cliente. • ProductOwner (PO)

18. Papéis • Multi-disciplinar, com 7 (+-2) membros • Define o Sprinte define como será feito o trabalho • Tem o direito de fazer o que estiver ao seu alcance para alcançar o Sprint • Auto-gerenciado: o time se organiza e se gerencia • Demonstrao que foi feito para o Product Owner ao fim de cada Sprint • Time

19. Papéis • Responsável pelo processo, incluindo a realização do Daily Scrum e datas e horários das reuniões • Remove os impedimentos • Garante que o time está sempre funcionando e produtivo • Facilita a cooperação entre todos os membros do time • Protege o time das interrupções externas • Scrum Master

20. PLANEJAMENTO • Entendimento do Escopo • Estimativas de complexidade • Definição do Sprint Reuniões - Sprint Planning • Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective

21. Sprint Planning O Sprint Planning Meeting é umareuniãonaqualestão presentes o Product Owner, o Scrum Master e todo o Time, bemcomoqualquerpessoainteressadaqueesteja representando a gerênciaou o cliente. Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maiorprioridadepara a equipe. A equipefazperguntasdurante a reunião de modo quesejacapaz de quebrar as funcionalidadesemtarefas técnicas, após a reunião. Essastarefasirãodarorigemao Sprint Backlog. Coletivamente, o Time e o Product Owner definem um objetivopara o Sprint, que é umabrevedescriçãodaquilo que se tentaráalcançar no Sprint. O sucesso do Sprint será avaliadomaisadiante no Sprint Review Meeting emrelação aoobjetivotraçadopara o Sprint.

22. 3 PERGUNTAS • 1. O quefoi feito desde o último DS? • 2. O queserá feito hoje? • 3. O queestaimpedindo? • Peer-pressure (empé) • Máximo de 15 minutos • Comprometimento Reuniões – DailyScrum • Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective

23. DEMONSTRAÇÃO • Apresentação das funcionalidades • Aceitação do Product Owner Reuniões – SprintReview • Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective

24. REVISÃO • O quefoibom? • O quepodeserMelhorado? Reuniões – SprintRetrospective • Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective

25. Artefatos • ProductBacklog • Sprint Backlog • BurndownChart

26. Product Backlog • O Backlog do Produto é umalistacontendotodas as • funcionalidadesdesejadaspara um produto. O conteúdodestalista é definidopelo Product Owner. • O Product Backlog nãoprecisaestarcompleto no início de um projeto. Pode-se começarcom tudoaquiloque é maisóbvioem um primeiromomento. • Com o tempo, o Backlog cresce e muda à medidaquese aprendemaissobre o produto e seususuários. • A partir dele origina-se o Backlog do Sprint que é o queseráfeitonaquelatarefa.

27. Quadro de Acompanhamento – Sprint Backlog

28. BurnDownChart • O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.

29. Metodologias Ágeis XP(eXtreme Programming) Pós-Graduação em Engenharia de Software

31. Indivíduos e interações ao invés de processos e ferramentas Software executável ao invés de documentação.

32. Colaboração do clienteao invés de negociação de contratos. Respostas rápidasa mudanças ao invés de seguir planos.

33. O Garotinho chamado CLIENTE Software – Aperto de mão Cliente – Um abraço Garra – Gargalhada Bem Vindos - Palmas

34. O que é o XP? Metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Criar sistemas de melhor qualidade. Produzidos em menos tempo e de forma mais econômica que o habitual. Identificou o que tornava simples e o que dificultava o desenvolvimento de software.

35. Como fazer? Pequeno conjunto de valores e práticas • A Programação Extrema é uma das metodologias ágeis mais conhecidas e utilizadas na atualidade. • Desenvolvidas para: • Equipes médias e pequenas (2 a 12 pessoas); Baseada em cinco valores, alguns princípios e várias práticas que ocorrem no decorrer das atividades;

36. Comunicação Coragem Feedback Respeito Simplicidade

37. Comunicação Para que um projeto seja um sucesso é necessário muita interação entre as equipes: programadores, clientes e treinador; VS

38. Coragem “A única constante em um projeto de software é a mudança” Alterar um código em produção sem causar bugs, com agilidade, exige muita coragem e responsabilidade;

39. Feedback Quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar As respostas às decisões tomadas devem ser rápidas e visíveis.

40. Respeito Dá sustentação a todos os demais valores Todos têm a sua importância dentro da equipe e devem ser respeitados e valorizados.

41. Simplicidade Apenas aquilo que é claramente necessário É um dos valores mais importantes. Normalmente o que o cliente quer é mais simples.

42. Papéis

43. Papéis... Programadores Treinador (ou coach) Acompanhador (ou tracker) Cliente

44. Programadores Foco central da metodologia, mas sem hierarquia.

45. Treinador (coach) Pessoa com experiência no time, é responsável por lembrar aos outros das práticas e valores do XP.

46. Acompanhador (tracker) Responsável por trazer informações que mostrem o andamento do projeto que ajudem a tomar decisões de implementação.

47. Cliente O Cliente faz parte da equipe!!

48. Práticas

49. Práticas... Testes Refatoração Programação Pareada (em pares) Propriedade Coletiva Integração Contínua Semana de 40 horas Cliente junto aos desenvolvedores Padronização do código

50. Testes Desenvolvimento orientado a Testes Os testes devem ser escritos antes do desenvolvimento.