Scrum IT Depends on Common Sense. Motivadores 1.Temos que introduzir no processo de desenvolvimento um grande aumento de produtividade para conseguir.

Apresentação em tema: "Scrum IT Depends on Common Sense. Motivadores 1.Temos que introduzir no processo de desenvolvimento um grande aumento de produtividade para conseguir."— Transcrição da apresentação:

1 Scrum IT Depends on Common Sense

2 Motivadores 1.Temos que introduzir no processo de desenvolvimento um grande aumento de produtividade para conseguir atender à demanda prevista de sistemas; 2.Temos que garantir a qualidade do que é produzido. 3.Temos que caracterizar a mútua responsabilidade na construção / testes dos sistemas – o processo de desenvolvimento é uma tarefa que exige colaboração de desenvolvedores, definidores de sistemas e usuários de funcionalidades.

3 Motivadores 4. Temos que migrar da atual realidade onde os sistemas são construídos sem planejamento, para um método de trabalho que permita planejar e controlar os trabalhos. A transparência do processo tem de ser total, para todos os envolvidos (dono do produto, facilitador e equipe:usuários e informatas)

4 Martian Tourist Brochure Backlog Create cover art, brand, and/or logo Define major topics for Martian tourism Describe “Art Interests in Europe” tour Describe a tour based on photosynthesis Outline a “7 wonders of the world” expedition Set prices for the tours Outline warning messages (gravity, oxygen, fungi,etc.) Suggest clothing options Explain travel options to/from Mars Describe a “Human Sports” tour Outline refund policy Suggest related services Define advertisers Define a 12-month campaign Set-up how to get more information Create cover art, brand, and/or logo Define major topics for Martian tourism Describe “Art Interests in Europe” tour Describe a tour based on photosynthesis Outline a “7 wonders of the world” expedition Set prices for the tours Outline warning messages (gravity, oxygen, fungi,etc.) Suggest clothing options Explain travel options to/from Mars Describe a “Human Sports” tour Outline refund policy Suggest related services Define advertisers Define a 12-month campaign Set-up how to get more information GOAL: DELIVER A BROSCHURE FOR THE EARTH TOURIST BOARD LOCATED ON MARS Timebox: 25 min. GOAL: DELIVER A BROSCHURE FOR THE EARTH TOURIST BOARD LOCATED ON MARS Timebox: 25 min. NOVOS REQUISITOS OBRIGATÓRIOS: - Roteiro: Corrida do ouro no Egito - Roteiro: Olimpíadas Pequim - Opção de viagem passando pelo Sol (descrever o valor) NOVOS REQUISITOS OBRIGATÓRIOS: - Roteiro: Corrida do ouro no Egito - Roteiro: Olimpíadas Pequim - Opção de viagem passando pelo Sol (descrever o valor)

5 Retrospective "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand" (Kerth, Project Retrospectives, 2001) O que aconteceu?

6 Scrum

7 2.1. Manifesto Ágil O desenvolvimento ágil descreve abordagens de desenvolvimento que seguem os seguintes princípios: "Estamos descobrindo maneiras 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ção entre eles mais 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ças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda."

8 2.2. O que é o Scrum?

9 Gerenciamento empírico e controle de processo Inspeção e adaptação com base em feedback Usado para gerenciar projetos complexos desde 1990 Entrega de funcionalidades de negócio em 30 dias Escalabilidade na distribuição de projetos grandes e longos Compatível com CMM Level 3 e ISO 9001 Extremamente simples mas de difícil implementação

10 2.3. Princípios Equipes auto-organizáveis

11 2.3. Princípios Time responsável e comprometido Honestidade Transparência Partes potencialmente entregáveis Timebox

12 www.glogerconsulting.de 2.4. SMART Objectives S pecific - específicos M easurable - mensuráveis A achivable - alcançáveis R ealistic - realísticos T imed - programado

13 www.glogerconsulting.de Exercício: A arte do possível Explore a diferença entre planejar uma festa iniciando todas as frases com: “sim, mas” “sim, e”

14 3. Papéis no Scrum AtividadePapelResponsabilidade Gerencia a visão Product Owner O Product Owner estabelece, mantem viva e comunica a visão do produto. Ele demonstra que o projeto é alcançável e o financia criando a visão dos releases e do Product Backlog inicial. Gerencia o ROI Product Owner O Product Owner monitora o projeto, mantém de acordo com o ROI estabelecido. Ele atualiza as prioridade do Product Backlog para assegurar-se que as tarefas de maior valor funcional sejam produzidas primeiro. Ele prioriza o Product Backlog and mede o sucesso para assegurar que o projeto está no caminho certo. Gerencia as iterações de desenvolvimento Team Durante uma iteração o time seleciona e desenvolve os requisitos de maior prioridade do Product Backlog. Coletivamente, o time expande os itens do Product Backlog para tarefas mais explícitas no Sprint Backlog e gerenciam o trabalho e a sua própria organização para entregar os itens desejados naquela iteração. O time se gerencia para cumprir o compromissos. Gerencia o processo Scrum Master O Scrum Master é responsável por ajustar a equipe acima tentando assegurar o sucesso do projeto e otimizar a cultura organizacional para encontrar os objetivos no projeto. Isto envolve organizar a Sprint Planning Meeting, a Sprint Review Meeting, protegendo a equipe dos distúrbios externos, realizando as Daily Scrum Meetings, e removendo impedimentos para o progresso do projeto. Gerencia os releases Product Owner O Product Owner toma decisões sobre quando criar um release oficial. Por uma série de razões não é desejável liberar um realease a cada incremento. O Product Owner toma esta decisões de maneira consistente com base na visão de investimento que foi estabelecida para o projeto.

15 3.1. Questionamento a respeito dos papéis O que ocorre quando o Scrum Master faz parte do time? O que ocorre quando o Scrum Master assume o papel de Product Owner? Tempo: 5 minutos (Timebox)

16 3.1. Questionamento a respeito dos papéis O que David deve fazer? 05 Product Owner 01 Scrum Master

17 4. Fluxo do Scrum

18 4.1. O que é um Backlog Item? Como eu quero para que

19 4.2. Product Backlog Lista de funcionalidades, tecnologia a ser aplicada, issues Issues são situações/assuntos do projeto que terão o trabalho definido mais tarde Itens priorizados e estimados Maior detalhamento sobre os itens de maior prioridade O Product Owner é responsável pela priorização Qualquer um da equipe pode contribuir Mantido e fixado em local visível Derivado do plano de negócio e da visão estabelecida, que tem que ser criada em conjunto com o cliente Estimation Meeting

20 Planning Poker Chile Argentina Venezuela Brasil Uruguai Paraguai Egito Itália 1, 2, 3, 5, 8, 13, 21

21 4.3. Sprint Planning 1 Definir o Sprint Goal e o Selected Product Backlog Para cada Backlog Item do Product Backlog – O Product Owner deve explicar a história por trás do item – Cada membro da equipe deve mostrar a sua estimativa para o item – Se as estimativas da equipe forem diferentes, o menor e o maior valor devem ser explicados até que cheguem em um acordo

22 4.4. Sprint Planning 2 Define as tarefas para realizar o Sprint Backlog e alinha ao Sprint Goal Junta a estimativa com a realidade da equipe e do projeto Design é detalhado nesta sessão Vamos ao quadro!

23 4.6. Monitor the task board Sprint Burndown Product Burndown Velocity per Sprint Chart: business value evolution

24 4.5. Daily Meeting Objetivo: Sincronizar a equipe – Quais as tarefas foram realizadas ontem? – Quais as tarefas serão desempenhadas hoje? – Quais os impedimentos encontrados durante o seu trabalho? Mover as tarefas dentro do quadro de acordo com a sua execução Resultados – Atualização do Impediment Backlog – Atualização do Sprint Backlog – Atualização dos gráficos Burndown Novas funcionalidades que surgirem serão armazenadas para avaliação ao final do Sprint

25 Done! Quando uma tarefa esta realmente concluída?

26 4.9. Impediments Backlog Backlog de Impedimentos (podem ser para a equipe ou para a organização resolver) RecursosSkills Prazo impossívelInfra-estrutura Ausência de feedback pelo clienteEscopo não definido Escopo em constante mudançaProblemas contratuais Falta de prioridadeFalta de unidade entre equipes Burocracia

27 4.7. Sprint Abnormal Termination Sprints podem ser cancelados antes do final do Sprint

28 4.8. Sprint Review O team deve apresentar os resultados do Sprint e as novas funcionalidades desenvolvidas Se surgirem novas funcionalidades ou alteração, os novos itens irão para o Backlog para serem estimados e priorizados O team deve reportar os impedimentos durante o desenvolvimento Ao final todos envolvidos no projeto devem entender a evolução do projeto e os impedimentos

29 4.10. Sprint Retrospective O processo é aprimorado ao final de cada Sprint Facilitado pelo ScrumMaster O que aconteceu de bom que nóspodemos utilizar como melhoria? ScrumMaster basea a prioridade de acordo com o team A equipe planeja a solução dos problemas de sua responsabilidade

30 4.11. Listagem de artefatos Product Backlog Sprint Backlog Impediments Backlog Bugs Backlog Chart: business value evolution Product Burndown Sprint Burndown Velocity per Sprint

31 Escalabilidade no SCRUM

32 Chickens and Pigs

33 Velocity Game GO GO GO!

34 Retrospectiva AINFO “Independente do que nós descubramos, nós compreendemos e acreditamos verdadeiramente que todos fizeram o melhor trabalho que poderiam, naquele momento deram o que sabiam, seus conhecimentos e suas habilidades, os recursos disponíveis, e a situação disponível.”

35 Timeline

36 Retrospectiva O que ocorreu bem? O que pode ser melhorado? – Dividir em “Team” e “Organization”

37 Questionamentos Quais os melhores candidatos para: – Product Owner – Scrum Master Quem decide se uma pessoa pode ficar dedicada full-time em um projeto? E a manutenção? Como se encaixa nesta visão? Projetos paralelos em série. “Adequar e usar” ou “Usar e adequar” o scrum? Novas constraints? Extreme Programming? – Simple design, testing, refactoring, pair programming, colective ownership, continuous integration, coding standards. Custo x Beneficio e ROI das metodologias agéis, como medir?