Parte II Processos ágeis

1. Parte IIProcessos ágeis

2. Referências • Agile Alliance - Disponível em: <www.agilealliance.org>. Acesso em: 04 abr. 2012. • Imaster – Disponível em: http://imasters.com.br/artigo/7240/gerencia-de-ti/gerenciamento-de-projetos-web-vamos-de-scrum . Acesso em: 09 abr. 2012. • PHAM, Andrew; PHAM, Phuong-van. Scrum em Ação: Gerenciamento e Desenvolvimento Ágil de Projetos de Sofware. São Paulo: Novatec, 2011. 287 p. • Scrum Alliance –Disponívelem: www.scrumalliance.org/. Acessoem: 15 mar. 2012. • Scrum – Disponível em : http://www.scrum.org/storage/Scrum%20Guide%202011%20-%20PTBR.pdf. Acesso em: 02 abr. 2012. • Mountain Goat Software –Disponívelem www.mountaingoatsoftware.com. Acessoem: 10 mar. 2012.

3. Roteiro • Parte II - Processos Ágeis • Metodologias Tradicionais • Manifesto Ágil • Parte III - Scrum • Histórias conhecidas • Projetos fracassados • Problemas de práticas prescritivas • Onde queremos chegar • História do Scrum • Papéis do Scrum • PO - ProductOwner • SM - Scrum Master • TM - Team Members • Histórias

4. Roteiro(continuação) • Histórias • ProductBacklog • Sprint • Sprint Backlog • Tarefas da Sprint • Impedimentos das tarefas • Sprint Burndown • Quando uma Sprint é cancelada • Cerimônias ou reuniões Scrum • Planejamento da Sprint • Reuniões diárias • Revisão da Sprint • Quadode Kanban • Ciclo de vida do Scrum • Estimativas e entregas • Exercícios

5. MetodologiasTradicionais • Modelo Constrói e Conserta (caótico)

6. MetodologiasTradicionais(continuação) • Modelo Cascata

7. MetodologiasTradicionais(continuação) • Modelo Cascata • Etapassequenciais • Modeloinflexível • Clientesóvalida o quefoidesenvolvido no final do processo • Dificuldadeparaimplementaralterações • Famoso Big Bang

8. MetodologiasTradicionais(continuação) • Modelo Espiral

9. MetodologiasTradicionais(continuação) • Modelo Espiral • Software dividido em versões chamados de incremento • Cliente acompanho o desenvolvimento • Maior facilidade para alterações • Assim como o cascata não permite etapas em paralelo

10. MetodologiasTradicionais(continuação) • Modelo Iterativo e Incremental

11. MetodologiasTradicionais(continuação) • Modelo Iterativo e Incremental • Ciclo de vida iterativo, baseado no aumento e no refinamento sucessivo de um sistema por meio de multiplos ciclos de desenvolvimento. • Atualmente o modelo mais utilizado. • Redução de riscos, custos e prazos. • Equipe focada com os objetivos de cada incremento.

12. MetodologiasTradicionais(continuação) • Nível típico de custos e de pessoal do projeto ao longo do seu ciclo de vida

13. MetodologiasTradicionais(continuação) • Influência das partes interessadas ao longo do tempo

14. MetodologiasTradicionais(continuação) • Seqüência típica de fases no ciclo de vida de um projeto

15. Ciclo de Vida (continuação) • Relação entre o produto e os ciclos de vida do projeto

16. Exemplo de ciclo de vida

17. ProcessosÁgeis • Promovem o desenvolvimento de trabalho em equipe. • Colaboração. • Adaptabilidade durante o ciclo de vida do projeto. • Software dividido em versões (Iterativo e Incremental) realizados de 1 a 4 semanas, passando por todas as etapas. • Minimiza os erros, pois cada versão é validada.

18. ProcessosÁgeis(continuação) • Comunicação cara a cara, todos trabalhando na mesma sala. • Representante do cliente sempre presente nas reuniões esclarecendo dúvidas que podem surgir durante as iterações.

19. Manifesto Ágil • Necessidade de resultados rápidos e precisos. • Fortalecimento da metodologia ágil. • Aliança Ágil -2001 • Ler: http://hp.br.inter.net/jrotta/docs/omanifestoagil.pdf • http://manifestoagil.com.br/

20. Manifesto Ágil(contínuação) • “Estamos descobrindo maneira melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: • Indivíduos e interações entre elesmais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação de contratos; • Responder a mudança mais que seguir um plano. • Ou seja, mesmo havendo valor nos itens a direita, valorizamos mais os itens à esquerda.”

21. 12 Princípios do processo ágil • http://manifestoagil.com.br/principios.html

22. Exemplo de Processos Ágeis • Extreme Programming (XP) • Scrum • FeatureDrivenDevelopment (FDD) • Dynamic Systems DevelopmentMethod (DSDM)

23. Algumas ferramentas que suportam Metodologia Ágil • Agileplatform - http://www.outsystems.com/ • VisionProject- http://www.visionproject.se/ • Pivotaltracker - http://www.pivotaltracker.com/ • TargetProcess - http://www.targetprocess.com/

24. Parte III

25. Scrum • http://www.scrumalliance.org/ • http://www.scrumalliance.org/user_groups/19 • http://www.implementingscrum.com/ • http://pt.wikipedia.org/wiki/Scrum • http://www.scrumalliance.org/scrum_certification

26. Histórias conhecidas • Atraso em projetos • Mudança frequente de escopo • Falta de funcionalidades na entrega • Custos elevados • Clientes insatisfeitos • Falta de cooperação da equipe • Síndrome do estudante • Equipe desmotivada • Funcionalidades demais, uso de menos

27. Problemas • Segundo PMI Brasil, os problemas mais freqüentes em gerenciamento de projetos levantados são: • Não cumprimento de prazos (72%) • Problemas de comunicação (71%) • Mudança de escopo (69%) • Estimativa errada de prazo (66%)

28. Projetos fracassados Fonte Carlos Junior - DevCursos

29. Projetos fracassados (continuação)

30. Projetos fracassados (continuação)

31. Fracasso, porquê? • Falta de envolvimento do usuário • Requisitos e especificações incompletas • Falta de suporte da direção • Falta de pessoas e recursos

32. Problemas de práticas prescritivas • Práticas prescritivas tornou evidente que: • Os detalhes são complexos para as pessoas • Os clientes ou usuários não tem certeza do que eles querem • Eles tem dificuldades de expressar tudo o que querem e pensam

33. Problemas de práticas prescritivas • Práticas prescritivas tornou evidente que: • Muitos detalhes dos que ele querem só serão revelados durante o desenvolvimento • Na medida em que eles veem o produto sendo construído, mudam de idéia • Forças externas (como um produto ou serviço da concorrência) trazem mudanças ou melhorias nos requisitos

34. Precisamos rever nossos conceitos!!!

35. Onde queremos chegar? • Aumento da produtividade. • Melhor qualidade. • Equipe motivada. • Entrega rápida do produto. • Aumento da satisfação do cliente. • Viabilizar inovação. • Foco no retorno de investimento (ROI).

37. História do Scrum • Surgiu em 1986. • Em 1986 IkujiroNonaka e IrotakaTakeuchi escreverão um artigo afirmando que equipes pequenas e com baixo nível de especialização tem melhores resultado que equipes grandes. • O nome Scrum vem do Rugby, quando uma falta é cometida os jogadores se arranjão em uma forma coesa chamada “Scrum”

39. Scrum (continuação) • Iterativo e Incremental. • Framework que facilita a visualização de problemas mesmo que possuem dificuldade elevada. • Tem por objetivo agregar o máximo de valor ao negócio com o menor tempo possível focando no retorno de investimento (ROI).

40. Quem utiliza Scrum

41. Papéis do Scrum • PO - ProductOwner • SM - Scrum Master • TM – Team Members

42. Papéis do Scrum

43. PO - ProductOwner • Responsável pela definição do escopo do projeto. • É ele quem estabelece e comunica a visão do produto e prioriza cada uma de suas funcionalidades • Define o que é necessário e qual a importância de cada uma das funcionalidades.

44. PO - ProductOwner(contiuação) • Garante o ROI • índice que expressa o quanto determinada funcionalidade irá retornar ao cliente quando implementada no produto final. Através do ROI o PO pode priorizar o projeto de maneira a ter o maior retorno em menor tempo.

45. ProductOwner(continuação) • Especificar quais são as funcionalidades esperadas no produto e priorizá-las por ROI. • Estabelecer uma visão compartilhada do produto entre clientes e desenvolvedores. • Definir datas para lançamentos e entregas. • Age como mediador quando o produto deve atender a vários clientes. • Pode dispor de uma equipe de apoio para auxiliar na geração da documentação (artefatos).

46. Quem pode ser um PO? • Um membro extra do time que participa das reuniões de SprintPlanning e SprintReview. • Tipicamente, alguém do Marketing ou um usuário chave em desenvolvimentos internos. • Pode ser um representante do cliente ou um procurador do cliente.

47. SM - Scrum Master • Éa glândula pineal de um time Scrum. • Regulador do ritmo do desenvolvimento. • Facilitador das reuniões.

48. SM – Scrum Master (continuação) • Faz com que a equipe viva os valores e práticas de Scrum • Protege a equipe de: • Riscos e interferências externas • Excesso de otimismo • Resolve os problemas que aparecerem • Logísticos • De conhecimento/habilidade • Também ajuda o PO a manter o ProductBacklog

49. SM – Scrum Master (continuação) • Monitorar o progresso do projeto. • Garantir que impedimentos ao progresso sejam resolvidos. • Remover a barreira entre desenvolvimento e cliente. • Melhorar o dia-a-dia do time facilitando a criatividade e o fortalecimento.

50. SM – Scrum Master (continuação) • Mantém o Backlog do Sprint • Tarefas completadas • Identifica eventuais problemas • Mantém um gráfico de “quanto falta”.