ANÁLISE DE SISTEMAS SCRUM

Apresentação em tema: "ANÁLISE DE SISTEMAS SCRUM"— Transcrição da apresentação:

1 ANÁLISE DE SISTEMAS SCRUM
Ministério da Educação Secretaria de Educação Profissional e Tecnológica Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Campus Presidente Epitácio ANÁLISE DE SISTEMAS SCRUM Professora Andrea Padovan Jubileu Aluno: Maycon Douglas Santos Quast Erhardt Junho 2016 1

2 Scrum 2

3 HISTÓRIA DO SCRUM A metodologia SCRUM, como outras metodologias consideradas ágeis, foi fortemente influenciada por boas práticas adotadas pela indústria japonesa. (“HONDA & TOYOTA”). Em um artigo feito por TAKEUCHI e NONAKA EM aonde eles descrevem projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados; 3

4 HISTÓRIA DO SCRUM Associaram estas equipes altamente eficazes à formação Scrum do Rugby(Forma de recomeçar o jogo quando acontece uma infração ou quando a bola sai para fora do jogo). O uso desta terminologia parece adequada porque no Rugby cada time age em conjunto. Cada membro desempenha um papel importante. Jeff Sutherland vice-presidente de engenharia da Easel. Percebeu que seu time de software precisava de uma metodologia mais adequada. Contou com a ajuda de John Scumniolates e Jeff Mackenna e concebeu, documentou e implementou o SCRUM. 4

5 O QUE É O SCRUM É um framework simples para gerenciar projetos complexos; Ele é uma metodologia ágil; Possui 3 pilares fundamentais: Transparência=> dos processos e dos requisitos e entrega; Inspeção=> de tudo que está sendo feito; Adaptação=> tanto no processo, quanto no produto e mudanças. 5

6 Práticas do Scrum 6

7 Stakeholders Os interessados no projeto.
São os que vão utilizar o Sistema; dar suporte; ou que vão ser afetados de alguma forma por ele. As necessidades dos Stakeholders são expressar por historias de usuário (User Stories). 7

8 User Stories User Stories são similares a casos de uso. Aonde ambos são usados para organizar requisitos. Diferença de caso de uso para User Stories Os casos de uso descrevem ações de interação seguindo uma narrativa impessoal entre o usuário e o sistema. Já nas User Stories o foco é nos objetivos do usuário e como o sistema alcançara esses objetivos. User Stories devem ser curtas e claras. 8

9 User Stories 9

10 Product Owner Possui o poder total sobre o produto.
Decide quais recursos e funcionalidades, e qual a ordem que será feito. Responsável por manter a comunicação entre as partes. Deve colaborar ativamente com o Scrum Master e Time de Desenvolvimento. 10

11 Product Owner Características:
1º Saber como gerenciar com sucesso as expectativas dos stakeholders. 2º Ter uma visão clara e conhecimento do produto. 3º Saber como transformar a visão de um produto em um backlog do produto. 4º Estar disponível para participar ativamente com a equipe. 5º Ser bem organizado. Que consiga manusear múltiplas atividades. 11

12 Scrum Master É responsável por ajudar a todos os envolvidos a entender e abraçar os valores, princípios e práticas do Scrum. Ele age como um técnico, executando a liderança do processo. Tem o papel de facilitador. Ele deve ajudar a equipe a resolver o problema. Responsável por proteger a equipe contra interferências externas. 12

13 Scrum Master Assume um papel de liderança na remoção de impedimentos que podem atrapalhar a produtividade. Age como um líder, não como gerente. 13

14 Scrum Master Características:
1º Ter um conhecimento aprofundado, na teoria e na prática. 2º Excelentes habilidades de líder; 3º Fortes habilidades organizacional; 4º Ótimas habilidades de comunicação; 5º Ótimas habilidades de apresentação; 6º Habilidades de resolução de conflitos; 14

15 Time Scrum No desenvolvimento tradicional de software são abordados vários tipos de trabalhador, tais como: arquiteto, programador, testador, administrador de banco de dados, Designer, e assim por diante. Time de Desenvolvimento é a junção de todas estas pessoas em uma equipe multidisciplinar. 15

16 Time Scrum E responsável pela concepção, construção e testes de produto. A ideia principal é que a equipe de desenvolvimento se auto organiza para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo Product Owner. 16

17 Time Scrum Um time de desenvolvimento tem tipicamente entre 5 a 9 pessoas; e seus membros devem ter todas as habilidades necessárias para produzir com qualidade o produto. 17

18 Atividades e Artefatos Principais
Visão => o Product Owner tem uma visão do que ele deve criar para atender aos stakeholders. Product Backlog => funcionalidades do produto. É feito a primeira reunião de Planejamento de Sprint, para definir o Sprint Backlog. 18

19 SCRUM - Processo 19

20 Product Backlog 20

21 Product Backlog O Product Owner, em conjunto com as demais partes interessadas no produto, definem os itens do Product Backlog. Em seguida, ele garante que os itens do Backlog sejam colocados na ordem correta(valor, custo, conhecimento e risco), de modo que os itens de alto valor, aparecera no topo do Backlog. 21

22 Product Backlog O Product Backlog é um documento que sempre está evoluindo. Os itens podem ser adicionado, excluídos e revisados pelo Product Owner por conta de mudanças de negócios. 22

23 Sprint Planning O product backlog pode representar muitas semanas ou até meses de trabalho. Serve para determinar quais itens do Product Backlog é importante para construção do Sprint. Product Owner, junto com o time de desenvolvimento e ScrumMaster, devem realizar o Sprint Planning (planejamento de sprint ). 23

24 Sprint Planning Tanto o Product Owner quanto a equipe de desenvolvimento devem chegar um acordo sobre o Objetivo da Sprint. Tendo o objetivo em mãos deve-se determinar quais itens vão ter maior prioridade no Backlog da sprint. 24

25 SCRUM - PROCESSO 25

26 Sprint Backlog Uma lista de tarefas que o Scrum Team se compromete a fazer em uma sprint. A equipe define a quantidades de itens do Product Backlog para o Sprint Backlog. Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. É usado um grafico chamado Burndown Chart para gerenciar este processo. 26

27 Burndown Chart. Burndown chart – Mede o progresso da sprint e dá indicativos do processo de trabalho da equipe. Representa diariamente o processo do trabalho desenvolvido. 27

28 Burndown Chart. 28

29 Sprints O trabalho é realizado em interações ou Ciclos que dura 2 à 4 semanas chamados de Sprints. Cada trabalho realizado nas Sprints deve criar algo de valor tangível para o cliente ou usuário. São timeboxed (duração fixa) para que tenham sempre um início e fim. 29

30 Sprints 30

31 Daily Scrum Todos os dias uma reunião é marcada no mesmo horário.
Os membros de desenvolvimento devem realizar uma reunião de duração de 15 minutos ou menos. 31

32 Daily Scrum 3 Perguntas básicas da reunião diária:
1º O que fiz ontem que ajudou o time a atingir a meta do sprint? 2º O que vou fazer hoje para ajudar o time a atingir a meta do sprint? 3º Existe algum impedimento que não permita a mim ou ao time atingir a meta do sprint? Ao término destas perguntas todos conseguem visualizar como está o desenvolvimento do sprint em relação à meta. 32

33 Daily Scrum 33

34 SCRUM - PROCESSO 34

35 Sprint Review O objetivo desta atividade é verificar e adaptar o produto que está sendo construído. Está é uma reunião informal. Apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração. 35

36 SCRUM - PROCESSO 36

37 Sprint Retrospective O objetivo do Sprint Retrospective é verificar necessidade de adaptação no processo de trabalho. Diferente do Sprint Review que o objetivo é buscar necessidade de adaptação no produto. Ocorre antes da reunião de planejamento do próximo Sprint. 37

38 SCRUM - PROCESSO 38

39 Kanban Board É uma tabela que serve para determinar tarefas exemplo: para executar, em andamento ou finalizada. Kanban permite um controle detalhado de produção com informações sobre quando, quanto e o que produzir. 39

40 Kanban Board 40

41 Definição de Pronto É considerado como resultado do Sprint.
Para saber quando uma finalidade do produto está concluída é utilizado Definition of Done (DoD). Este documento consiste em uma lista de todas as atividades que são necessárias para a entrega do produto. 41

42 O Que é Ganho Com Isso? O ScrumTeam e os demais stakeholders do projeto passam a utilizar um vocabulário único, seguro e irrestrito para a palavra 'Pronto’. A confiança dos demais stakeholders aumenta em relação ao ScrumTeam. Os Releases passam a ser mais previsíveis em termos de qualidade (Aquele susto ao final do projeto deixa de existir). 42

43 O Que é Ganho Com Isso? Qualquer impedimento é rapidamente identificado. Para o Time Scrum “PRONTO” é usado para quando o trabalho está completo no incremento do produto. 43

44 SCRUM - PROCESSO 44

45 Referencias. Disponível em: < Acesso em 24 de Maio de 2016. Disponível em: < >. Acesso em 24 de Maio de 2016. Disponível em: < Acesso em 24 de Maio de 2016. Disponível em: < >Acesso em 24 de Maio de 2016. Disponível em: < Acesso em 24 de Maio de 2016. Disponível em: < Acesso em 24 de Maio de 2016. Disponível em: < Acesso em 24 de Maio de 2016. Disponível em: < Acesso em 24 de Maio de 2016. 45

46 Referencias. SCROCCO; JOSÉ, Henrique Teixeira. METODOLOGIA ÁGEIS: Engenharia de Software. 1 ed. São Paulo: érica,2014. ANDREW, Phan; PHUONG-VAN, Pham. SCRUM EM AÇÃO: Gerenciamento e Desenvolvimento Ágil de Projeto de Software. 1 ed. São Paulo: Novatec Editora ltda, 2011. MIKE, Cohn. DESENVOLVIMENTO DE SOFTWARE COM O SCRUM: Aplicando Métodos Ágeis com Sucesso. 1 ed. São Paulo, 46