Scrum no contexto de processos de desenvolvimento
Transferir como PPTX, PDF1 gostou901 visualizações
O documento explora a evolução do desenvolvimento de software, desde a crise nos anos 60 até a adoção de métodos ágeis, como o Scrum, formalizado em 2001. Detalha a anatomia do Scrum, incluindo papéis, cerimônias e artefatos, destacando a importância da adaptabilidade e do bom senso na escolha do modelo de gerenciamento de projetos adequado. Conclui que o sucesso depende da compreensão das características da equipe e do projeto, além de uma abordagem centrada na melhoria contínua.
Scrum no contexto de processos de desenvolvimento
- 1. SCRUMRalph J. R. Filho
- 4. ContextualizaçãoAnos 60Fase embrionária e artesanal do swCrise do sw: 1965 a 1985Orçamentos estouradosDanos à propriedades (crackers)Vidas humanas (radioterapia)
- 5. ContextualizaçãoFerramentas e métodos passaram a ser adotados para recuperar a reputação do swProgramação estruturada, padrões
- 6. ContextualizaçãoAnos 80Massificação da produção de sw e popularização dos modelos de processo de desenvolvimentoGerenciamento de ProjetosModelo Cascata e Espiral
- 7. ContextualizaçãoAnos 90Popularização da webCresce o número de pequenas empresas produzindo softwareUm grupo de engenheiros de software chama a atenção para a produção artesanal de sw mudando os princípios aboradados pelos grupos de estudo no decorrer da crise do sw
- 8. ContextualizaçãoAnos 2000Diversificação de plataformas de hardware (gadgets) aonde os software são embarcadosEra da computação ubíquaCloudcomputingOffshoring
- 10. ContextualizaçãoModelo Espiral1986Java1994UML e RUP1996HTML 52008FORTRAN / COBOL1957 / 1959Modelo Cascata1970C1972Modelo ER1976
- 11. ContextualizaçãoA tecnologia avança rapidamentePara acompanhar as mudanças é preciso ter a mente aberta e trabalhar com melhoria contínuaVelhos hábitos podem estancar a evolução de uma empresa“A MS está sempre a 18 meses de falir”Bill Gates
- 12. ContextualizaçãoPra quê um modelo/processo?Aplicação de melhores práticas para aumentar a precisão de orçamento e prazosDefinição de escopoFacilitar a evolução/manutenção do software considerando:Rotatividade de recursos humanos (padrões)Complexidade inerente ao tamanho (rastreabilidade)Pontos de integração (regras de negócio)
- 13. ContextualizaçãoPor quê eu devo me importar com isso?Empresas maduras de desenvolvimento de software exigem conhecimento em metodologias de desenvolvimentoPrincipalmente multinacionaisSe você não sabe, vai ter que aprender
- 14. ContextualizaçãoEquipe: 05 pessoasSistema: web-site da TAMPrazo: 03 meses... como fazer?Opção 01: iniciar a codificação (go-horse)Opção 02: seguir um modelo “tradicional”Opção 03: ?Opção “n”: ?
- 15. ContextualizaçãoOpção 01: iniciar a codificaçãoQual é o escopo?Quais são as regras de negócio?Qual o planejamento para um ciclo?Qual a noção de prazo?Qual é a integração entre as telas?..............
- 16. ContextualizaçãoOpção 02: seguir um modelo tradicionalQuantos papéis cada membro da equipe terá que desempenhar?O tempo é suficiente para manter todos os documentos, seguir todas as fases?Todos os documentos são realmente necessários?E se o cliente solicitar uma mudança no fim do prazo?
- 17. Contextualização
- 18. Contextualização
- 19. Contextualização
- 20. Contextualização
- 21. Contextualização
- 23. Manifesto ÁgilConceito introduzido em 2001 por 17 desenvolvedores de softwareConjunto de princípios em comum dos métodos ágeisA motivação foi a formalização de métodos em projetos com alto nível de mudanças, requisitos desconhecidos e equipes pequenas
- 24. Manifesto Ágil
- 25. Métodos Ágeis - MITOSMétodo ágil não precisa documentarMétodo ágil não precisa planejarMétodo ágil é bom/ruimSe eu usar ágeis não posso ter CMMI ou outras certificações
- 26. SCRUM
- 27. SCRUMMétodo para Gerenciamento de ProjetosHarvard Business Review 1986 (Toyota)Proposta inicial em 1995 por Ken Schwaber e Jeff SutherlanFormalizado em 2001
- 28. Princípios do SCRUMEquipes multifuncionaisEquipes auto-organizáveisIterações curtasPapéis, cerimônias e artefatos em número reduzido
- 31. Anatomia do SCRUMO SCRUM pode ser analisado como um conjunto dePapéisCerimôniasArtefatos
- 32. Anatomia do SCRUMPapéisAdministrador de Rede
- 38. Consultor
- 39. Desenvolvedor
- 42. Testador
- 43. ...Cada papel tem seus artefatos associados e atividades pré-definidas
- 44. Anatomia do SCRUMNo SCRUM os papéis sãoDono do ProdutoSCRUM MasterEquipe
- 45. Anatomia do SCRUMDono do ProdutoDefine e prioriza as funcionalidadesDecide as datas de lançamentoAceita ou rejeita os trabalhosNormalmente é um representante do cliente
- 46. Anatomia do SCRUMSCRUM MasterResponsável por garantir que as práticas do SCRUM sejam seguidas por todosResponsável por resolver impedimentosDeve garantir máxima produtividade da equipe e promover a colaboração entre os mesmosProtege a equipe de interferências externas
- 47. Anatomia do SCRUMEquipeRecomenda-se de 05 a 09 pessoasMultifuncionalDedicação integral
- 48. Anatomia do SCRUMArtefatosAnálise e projeto de software
- 53. Implantação
- 55. Teste de SoftwareDocumento ou elemento pertencente a este, que deve ser criado ou alterado
- 56. Anatomia do SCRUMNo SCRUM os artefatos sãoProductBacklogSprint BacklogGráfico Burndown
- 58. Anatomia do SCRUMSprint BacklogLista de funcionalidades do productbacklog que será feito em um ciclo (iteração)Como os itens do productbacklog são priorizados, este parâmetro é utilizado para selecioná-losA prioridade pode ser Alta, média, baixa; EDI; etc.
- 59. Anatomia do SCRUMSprint Backlog
- 60. Anatomia do SCRUMSprint BacklogTrabalhos não são atribuídos, cada um escolhe o que vai fazerTodos podem mexer no escopo da sprintEstimativa de esforço atualizado diariamenteTrabalhos complexos são definidos como um item com uma grande quantidade de tempo e detalhados quando ficam mais conhecidos
- 61. Anatomia do SCRUMCheckpointParece simples?Mas não é!
- 62. Anatomia do SCRUMGráfico BurndownAcompanhamento das tarefas executadasAtualizado diariamentePermite uma visualização simples e clara sobre atrasos e adiantamentos no projeto
- 67. Anatomia do SCRUME o controle de tarefas?
- 71. Apresentação
- 72. Brainstorming
- 73. Planejamento
- 74. Feedback
- 75. Análise de desempenhoEvento planejado e organizado aonde a equipe participa
- 76. Anatomia do SCRUMAs cerimônias do SCRUM sãoSprint planningReunião diáriaSprint retrospectiveSprint review
- 78. Anatomia do SCRUMSprint planningQuebra os itens do productbacklog em tarefasBom senso ao determinar a granularidadeDepende do tamanho da sprint e da capacidade das pessoas envolvidasEstima a duração das tarefas em horas
- 79. Anatomia do SCRUMSprint planning
- 80. Anatomia do SCRUMReunião DiáriaTodos em péHorário fixoDuração de 30 minutos, em médiaToda a equipe participa e respondem a três perguntas
- 81. Anatomia do SCRUMReunião DiáriaO que você fez ontem?O que vai fazer hoje?Tem algo impedindo o seu trabalho?
- 82. Anatomia do SCRUMReunião Diária
- 83. Anatomia do SCRUMSprint reviewDemonstração das funcionalidades desenvolvidas durante a sprintTodos participam, inclusive o Dono do Produto
- 84. Anatomia do SCRUMSprint retrospectiveReunião da equipe para ver o que está funcionando e o que não estáFeita após cada sprint
- 86. Considerações FinaisSCRUM é um modelo ágil, o fato da sua empresa ser pequena, ou os projetos serem de curta duração por si só não significa que ele é o modelo ideal para vocêDeve-se considerar uma série de fatores em conjunto
- 87. Considerações FinaisCultura e política da empresaCultura da regiãoExperiência da equipeMaturidade da equipeTamanho da equipeNatureza dos projetosProximidade com o cliente
- 88. Considerações FinaisO bom senso aplicado sobre todos estes fatores somado ao conhecimento nos modelos disponíveis do mercado e no know-how da empresa serão os maiores subsídios para definir qual modelo será utilizadoPode-se personalizar os modelos
- 89. Considerações FinaisPode-se obter bons resultados usando qualquer cada um dos modelosMuda a forma de gerenciamentoe as técnicas utilizadas
- 94. Considerações FinaisIndícios para usar ágeisEquipe sêniorBaixa criticidadeRequisitos que mudam com frequênciaEquipe pequenaPessoas capazes de se auto-organizar
- 95. Considerações FinaisIndícios para usar tradicionaisEquipe júniorAlta criticidadeRequisitos que não mudam com frequênciaEquipe grandePessoas não são capazes de se auto-organizar
- 96. Considerações FinaisIndependente do formato, é preciso adaptar e usar um processoProcessos são a base para a obtenção de indicadores de qualidade e base de conhecimento, que ajudam a empresa a aprender e a evoluirTambém passa confiança ao cliente
- 97. Dúvidas?