Baixado 12 vezes
Carregado porRobson David
Compartilhando Conceitos Desenvolvimento Ágil e SCRUM
Este documento resume os principais conceitos do Desenvolvimento Ágil e Scrum. Apresenta a evolução histórica destes métodos, seus pilares e papéis, além de explicar o fluxo de trabalho do Scrum, incluindo planejamento, daily meetings, reviews e retrospectivas.
Compartilhando Conceitos Desenvolvimento Ágil e SCRUM
- 1. Conceitos Desenvolvimento Ágil e SCRUM Robson EduardoDavid, CTFL, PMP, CSM, ITIL Nov/2016 robson.david@itau-unibanco.com.br
- 2.
- 3.
- 4.
- 5.
- 6. Entrega de Soluções •Necessidade de locomoção • Não adianta entregar partes de uma solução (Roda, Chassi) • Meios de locomoção parciais • Feedback antecipado
- 7. O que éser Ágil? Responder a mudanças, sem traumasResponder a mudanças, sem traumas • Bom para projetos parcialmente definidos. • Requisitos mudam, e mudanças são bem-vindas. • Sem neurose contratual. Entregar mais rápido (freqüência)Entregar mais rápido (freqüência) • O cliente não espera muito para ver resultados. • Retorno sobre o investimento vem mais rápido. • Visualização parcial dos resultados diminui o risco. (Não significa necessariamente entregar mais volume). AssertividadeAssertividade •Decisões baseadas em fatos. •Ver algo pronto é melhor do que qualquer previsão. •Decisão distribuída entre os envolvidos no projeto.
- 8. Restrições Só o escopoprioritário é atendido, prazo e custos são mantidos!
- 9. Gestão 3.0 • Gestão1.0 focada na hierarquia comando-e-controle • Gestão 2.0 estrutura top-down Gestão 1.0 “turbinada” Balanced Scorecards Six Sigma TQM • Gestão 3.0 focada na complexidade organizações com redes pessoas e relacionamentos como foco na gestão
- 10.
- 11. Origem do Scrum •Jogo Rugby •Objetivo: recuperar a posse de bola • Só 8 jogadores do time participam • Todos fazem força juntos e ao mesmo tempo.
- 12.
- 13.
- 14.
- 15.
- 17. Fluxo de Trabalho Vision(Visão) é o que deve ser satisfeito ao fim do projeto. Ela é definida pelo PO que colhe informações junto aos clientes, time e stakeholders; Product backlog (Backlog do Produto) é a lista inicial de necessidades que precisam ser produzidas para que a Visão seja atingida. Inclui conteúdo, disponibilidade e priorização. Todos devem contribuir para sua confecção e é evoluído à medida que as seus itens são desenvolvidos; Sprint planning (Planejamento da Sprint) são reuniões em que o time decide O QUE vai ser feito e COMO vai ser feito; Sprint backlog (Backlog da Sprint) é o resultado da fase anterior, contendo itens do backlog, suas respectivas tarefas e meta da sprint (lembrando que, meta é o compromisso assumido pelo time);
- 18. Fluxo de Trabalho Sprinté a efetiva execução dos trabalhos, que pode durar entre 2 e 4 semanas. Durante as sprints, ocorre o daily meeting, que é uma reunião diária com 15 minutos de duração onde o time discute o que foi feito desde a última reunião, o que pretende realizar e se está com algum impedimento; Sprint review (Revisão da Sprint) é a fase em que o PO identifica o que foi feito e o que não foi feito através de questionamento ao time. Ela fornece inputs de valor para as sprints seguintes; Retrospective (Retrospectiva da Sprint) é a última reunião do time antes da entrega final do produto onde é discutido o que foi bom, o que pode ser melhorado e as respectivas ações para melhoria. PO nesta fase apenas se convidado pelo time.
- 19. Planejameno de Releasese Sprints 19 Sprint Sprint Sprint Release Release Release Sprint Sprint Sprint Sprint Sprint Sprint Sprint Release SprintSprint • É frequente, ocorre repetidamente em períodos de 2 a 4 semanas. • Entrega parte do produto pronto para entrar em produção ReleaseRelease • É o momento em que as partes do produto pronto entram em produção. • O momento é definido de acordo com a estratégia de Negócios. VisãoVisão
- 20. Planejameno de Releasese Sprints 20 Sprint são iterativas e incrementaisSprint são iterativas e incrementais IterativoIterativo (repetição):(repetição): IncrementalIncremental (aumento):(aumento):
- 21.
- 22. User Stories Ex. Comoum cliente quero pesquisar valores de passagens aéreas para que eu possa fazer o meu orçamento de viagem Ex. Considero a história atendida se tiver uma tela onde eu possa consultar voos e seus respectivos valores Frente: Como <quem> <quando> <onde>, eu <o que>, porque <por que>. Verso: Considero a história atendida se <condição>
- 23.
- 24. DoR (Definição Preparado)DoD (Definição Pronto)
- 25.
- 26.
- 27. Sprint Planning Meeting 27 •Determinara meta da Sprint •Determinar o Sprint Backlog •Determinar as tarefas para atingir o Sprint. Planejar o trabalho da sprintPlanejar o trabalho da sprint ParticipantesParticipantes •Product Owner – necessário •Scrum Master – necessário •Team – necessário InputsInputs •Product Backlog priorizado •Velocidade do time •Incremento do produto da Sprint Anterior. AgendaAgenda •Acontece ao início de cada Sprint •8 horas divididas em duas partes de 4 horas.
- 28. Sprint Planning Meeting 28 1ªparte – 4 hs1ª parte – 4 hs Determinar meta Ajustar Prioridades Determinar velocidade Selecionar backlog Revisar estimativas Sprint Backlogt A fazer Fazendo Pronto Determinar tarefas Estimar tarefas 2ª parte – 4 hs2ª parte – 4 hs
- 29. Sprint Planning Meeting Osistema deve controlar os clientes 8 O cliente deve conseguir tirar um Extrato 13 Meta: Clientes consultan do extrato
- 30. Daily meeting (oustand-up meeting) 30 •Todos tem oportunidade de saber como podem ajudar • É atualizado o quadro de gestão visual e burndown • O Scrum Master atua como mestre de cerimônia Compartilhar informaçõesCompartilhar informações ParticipantesParticipantes •Product Owner – opcional •Scrum Master – necessário •Team – necessário InputsInputs •Informações sobre o trabalho de cada integrante do time AgendaAgenda •Reunião diária. •15 minutos, independente do tamanho da equipe •Feita, de preferência em pé, para que seja rápida.
- 31. Daily Meeting O quevocê fez desde a última reunião diária, que ajudou a equipe para atender a meta da sprint? Os membros do time respondem às questões:Os membros do time respondem às questões: O que você fará entre agora a próxima reunião diária, que vai ajudar a equipe para atender a meta da sprint? O que impede você de realizar seu trabalho com ao maior efetividade possível, para o atendimento da meta da sprint?
- 32. Sprint Review Meeting 32 •Resultadoé produto funcionando •No ambiente mais próximo a produção e sem truques •Quem apresenta, recebe elogios ou críticas é o time. Apresentar os resultados da SprintApresentar os resultados da Sprint ParticipantesParticipantes •Product Owner – necessário •Convidados do PO - opcionais •Scrum Master – opcional •Team – necessário InputsInputs •Incremento de produto funcionando AgendaAgenda •Ocorre ao final da Sprint •Restrita a 4 horas de duração, mas pode durar menos.
- 33. •Quais foram suasimpressões? •Quais as mudanças desejadas? •Qual é a prioridade dessas mudanças no Product Backlog? Ao final da apresentaçãoAo final da apresentação o Scrum Master solicitao Scrum Master solicita aos stakeholders que relatem:aos stakeholders que relatem: Sprint Review Meeting
- 34. Sprint Retrospective Meeting 34 •Todociclo de melhoria contínua tem um feedback • Os pontos de melhoria são implementados já no próximo sprint Colher resultados para melhorarColher resultados para melhorar ParticipantesParticipantes •Product Owner – opcional •Scrum Master – necessário •Team – necessário InputsInputs •Informações da Sprint AgendaAgenda •Ocorre ao final da Sprint, após a Sprint Review meeting. •Tem duração de 3 horas
- 35. Sprint Retrospective meeting •Oque foi bem sucedido durante o último Sprint? •O que poderia ser melhorado no próximo Sprint? Antes reunião,Antes reunião, o Scrum Master solicita aoso Scrum Master solicita aos membros do time que preencham um formuláriomembros do time que preencham um formulário dizendo:dizendo:
- 36. Considerações Gestão tradicional AbordagemScrum Escopo O escopo é definido pelo Product Backlog e Sprint Backlog Custos O custo é dado por Sprint, não por projeto. A priorização do Backlog é voltada ao ROI, equipes fixas, tempos fixos. Tempo Definição de time-boxes Comunicação Fortemente baseada nas cerimônias. Não exige planejamento, exige disciplinado Scrum. Integração O próprio framework SCRUM força a integração das disciplinas, pois aborda indiretamente todas elas. Recursos Humanos Times auto-gerenciados. Papéis claros (scrum master, product owner e time) Qualidade Inspeção constante. Cerimônias de revisão e retrospectiva Riscos Estratégia de aceitação. A abordagem é que, se tudo der errado , o prejuízo máximo é de 1 mês de trabalho. Aquisições Por não definir o escopo com rigidez, o tipo de contrato firmado geralmente é “Time and Material”.
- 37. Coaching Ágil –Substituindo os fundamentos básicos do gerenciamento de projetos
- 38. Analogia... Cenário Tradicional Ágil MetodologiaRUP Waterfall Scrum Órgão PMI Scrum Alliance Guia de Referência PMBOK The Scrum Guide Certificação PMP CSPO; CSM; CSD
- 39. Informações para consulta ScrumGuide http://www.scrumguides.org/ Manifesto Ágil http://manifestoagil.com.br/ Scrum Alliance http://www.scrumalliance.org/pages/what_is_scrum PMI http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx Jurgen Appelo http://jurgenappelo.com/ http://jurgenappelo.com/management-30/
- 41. ” Nas grandesbatalhas da vida, o primeiro passo para a vitória é o desejo de vencer. ” Mahatma Gandhi ” Não se pode ensinar alguma coisa a um homem; apenas ajudá-lo a encontrá-lo dentro de si mesmo. ” Galileu Galilei
Notas do Editor
- #2 Robson, trabalho a SQT, Gerência Testes Funcionais – Enoch e Camila Não sou expert no assunto; em 2010 ... CSM... Estudando... Em 2015 ... Prática no Itaú ... Novo Sispag – Canal + Core Venho conversando sobre este assunto com Gestores e Colegas, relação total com as Comunidades compartilhar essas informações com vocês Passar alguns conceitos Disponibilizar fonte para pesquisa Reflexões se pode nos ajudar: nossos projetos, nossa área e banco Perguntas, comentários e dúvidas = interromper a qualquer momento
- #3 Um pouco da história ... Não é algo novo, mas agora sendo utilizando de forma mais intensa por grandes empresas no Brasil e no Mundo
- #4 Based on the principles of Scrum and the Agile Manifesto, Scrum.org provides comprehensive training, assessments and certifications to improve the profession of software development. Throughout the world, our solutions and community of Professional Scrum Trainers empower people and organizations to achieve agility through Scrum. Ken Schwaber, the co-creator of Scrum, founded Scrum.org in 2009 as a global organization, dedicating himself to improving the profession of software development by reducing the gaps so the work and work products are dependable. Mission: To improve the profession of Software Development. Vision: A world in which all software developers love their work, and their customers love working with them. Goals and Strategies By 2020, Scrum.org will have made a positive and measurable impact on the development of software around the world, by working in partnership with others to: . Maintain the integrity and relevance of the Scrum framework, . Develop tools and curriculum that teach people how to use Scrum, . Teach organizations to deliver more value with the products and systems they build, . Develop a global community that supports professionalism in software development.
- #5 Eu tinha um conceito equivocado.. Sem documentação, mão na massa, sem planejamento, retrabalho... NÃO É NADA DISSO !! - Em fevereiro de 2001, 17 pessoas que já trabalhavam com Extreme Programming, Scrum, ou outros dos chamados Métodos Leves (Lightweight Methods) de desenvolvimento de software reuniram-se em um hotel nas montanhas nevadas do estado norte-americano de Utah para trocar ideias sobre o que estavam fazendo. Todo o mundo da Engenharia de Software voltou sua atenção para a reunião, e muito foi especulado a respeito de seus resultados. Quando todos esperavam que o encontro resultasse numa nova “UML” (Booch, Rambaut e Jacobson), o resultado da reunião foi o esse manifesto. O único inglês da turma, Martin Fowler, foi quem sugeriu o termo &quot;agile&quot; para descrever aquilo que estavam, afinal, discutindo, mesmo preocupado com o fato de que os americanos tinham dificuldade em pronunciar tal termo. Depois de muitas conversas, esquiadas, comida e diversão, Martin apresentou a redação do Manifesto Ágil, assinado por todos os presentes e por muito mais pessoas a partir de então. Resumo: Decisão assertiva, baseada em algo real, materializado. Adotar uma postura mais flexível, onde todos estão comprometidos com o resultado.
- #6 Adaptworks – Alexandre Magno – He was the first Certified Scrum Trainer of Brazil and have accumulated extensive experience in implement Scrum and other Agile methods for different areas of businesses such as: start-ups, financial institutions, marketing agencies, software factories, airlines companies and ISVs. Magno is also a Licensed Trainer for the Jurgen Appelo&apos;s Management 3.0 course. SCRUM não é um processo ou uma técnica para o desenvolvimento de produtos. O Scrum é usado para reiniciar o jogo após uma paralisação, falta ou impedimento. O Scrum-half (tipo um meio de campo) do time que não cometeu a infração coloca a bola no meio do &quot;túnel&quot; formado pelas duas primeiras linhas de cada equipe com a finalidade de que os jogadores da sua equipe consigam ganhar (talonar) a bola. É como se fosse a “bola ao alto” do futebol. Não são todos os 15 jogadores que podem formar um scrum. Só oito jogadores de cada time podem participar. Os jogadores fazem força para empurrar o outro time e assim ganhar território e por consequência a posse da bola Scrum é um meio e não um fim em si mesmo: Objetivo é ganhar a bola e não fazer o scrum. No scrum todos os atacantes aprendem a atuar em conjunto ao serviço da equipe.
- #7 Entrega constantes = valor para o cliente e oportunidade de validar e ajustar se necessário Entrega mensais &lt;&gt; aguardar semestres para o resultado final, que pode estar defasado Processos Ágeis são fortemente baseados numa abordagem iterativa e incremental. Dessa forma, ao invés de um processo faseado que só realiza a entrega total ao final de um projeto, o Ágil acontece através de ciclos menores de entrega durante um projeto. Dessa forma, cada ciclo entrega um pequeno incremento, onde os envolvidos no projetos podem ter um feedback antecipado sobre entendimento, a assertividade e o valor gerado por aquela pequena parte do trabalho. Essa abordagem é importante para ajudar a mitigar os riscos e as incertezas inerentes ao desenvolvimento de software. Através dos ciclos curtos, é possível validar se determinado requisitos está ou não aderente à necessidade de um cliente ou se, aquela solução proposta está ou não resolvendo o problema negócio para qual ela foi desenhada.
- #8 A decisão fica distribuída entre os integrantes do projeto. Perguntar aos participantes: Por que os clientes acham que Scrum é mais rápido? Resposta: é uma falsa sensação devido ao fato do cliente “enxergar” os primeiros resultados mais rápido (tempo do primeiro Sprint), não tendo que esperar até o final do projeto para homologar o produto como um todo (waterfall).
- #9 Tempo e Custo = fixo Escopo = variável (pode mudar sem problemas, podemos não entregar tudo, mas COM CERTEZA entregamos primeiro o que é mais importante e agrega mais valor – importância do PO Qualidade = objetivo constante para todos os projetos Podemos não entregar tudo do Product Backlog devido as restrições de recursos de Tempo e de Custo, mas entregaremos o que tem mais valor para o cliente primeiro!
- #10 Gestor funcional ficar atendo a estrutura SCRUM, respeitando limites: - Acompanhamento atividades - Atribuição tarefas - Construção time = pessoas com perfil - Avaliação performance = mesmas metas X, diferenciando pelo Y -&gt; autogerenciamento e comprometimentos Ser Auto-organizados Ser multifuncionais Ter entre 5 e 9 integrantes Ter espaço físico apropriado Ter metas e avaliação comum = Todos ganham ou todos perdem. = Energizar pessoas: pessoas são a parte mais importante de uma empresa, certo? Gerentes devem portanto fazer o que for possível para mantê-las ativas, criativas e motivadas. Empoderar times: times devem auto-organizar, mas para isso precisam empoderação, autorização e confiança da gestão. Alinhar restrições: auto-organização pode não funcionar, para diminuir esta possibilidade dê às pessoas um propósito claro e metas compartilhadas. Desenvolver competências: times não conseguirão atingir as metas caso alguns de seus membros não forem suficientemente capazes. Gerentes devem contribuir para o desenvolvimento de competências. Crescer a estrutura: muitos times trabalham dentro de um contexto organizacional complexo, portanto é importante considerar estruturas que promovam a comunicação. Melhorar tudo: pessoas, times, e organizações precisamos melhorar continuamente para evitar falhas sempre que possível.
- #11 PMI... Renomado... e considerando Agile !! GAPCON – João Gama – 1º certificado no Brasil, final de 2011 é um entusiasta da abordagem Agile há pelo menos 15 anos quando conheceu o DSDM, uma metodologia criada no Reino Unido no começo dos anos 90 e considerada a precursora das metodologias Ágeis PMI-ACP em 2011, durante o programa piloto. É o primeiro PMI-ACP do Brasil e um dos primeiros do mundo.
- #12 SCRUM não é um processo ou uma técnica para o desenvolvimento de produtos. O Scrum é usado para reiniciar o jogo após uma paralisação, falta ou impedimento. O Scrum-half (tipo um meio de campo) do time que não cometeu a infração coloca a bola no meio do &quot;túnel&quot; formado pelas duas primeiras linhas de cada equipe com a finalidade de que os jogadores da sua equipe consigam ganhar (talonar) a bola. É como se fosse a “bola ao alto” do futebol. Não são todos os 15 jogadores que podem formar um scrum. Só oito jogadores de cada time podem participar. Os jogadores fazem força para empurrar o outro time e assim ganhar território e por consequência a posse da bola Scrum é um meio e não um fim em si mesmo: Objetivo é ganhar a bola e não fazer o scrum. No scrum todos os atacantes aprendem a atuar em conjunto ao serviço da equipe.
- #13 MOSTRAR: Tarefas, Resultados, Dificuldades, Erros VERIFICAR: Processos, Execução de tarefas, Aderência a padrões MELHORAR: Processos, Execução de tarefas, Qualidade do produto
- #14 O Product Owner O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. Expressar claramente os itens do Backlog do Produto; Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões; Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário. O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner. Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem.
- #15 O Scrum Master O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.
- #16 O Time de Desenvolvimento O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos. Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo. Os Times de Desenvolvimento tem as seguintes características: Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis; Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto. O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra. Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo; e, Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios.
- #17 É um framework dentro do qual você pode empregar diversos processos e técnicas. Na figura são representados todos os aspectos do Scrum: Papéis, Cerimônias e Artefatos. é perfeitamente possível encaixar a MDS no framework do Scrum. O tamanho ótimo para um Time é de 7 pessoas, mais ou menos duas pessoas. Quando há menos do que cinco membros em um Time, há menor interação e, como resultado, há menor ganho de produtividade. Se há mais do que 9 membros, há simplesmente a necessidade de muita coordenação. Times grandes geram muita complexidade para que um processo empírico consiga gerenciar. - O Scrum Master tem o papel de facilitador para a equipe e não atua como gerente. Ele observa a equipe e orienta onde for necessário. O Team é auto-gerido, auto-organizado. Não existe hierarquia dentro do team. - O Scrum Master é o juiz, ele não joga e não faz parte do time. Ele não determina o que cada um deve fazer durante o jogo. Ele apenas direciona e retira impedimentos. Garante a execução do Scrum / Remove Impedimentos / Revela a realidade - O espírito do Scrum é: Todos ganham ou todos perdem. Para atuar em time Scrum é necessário um perfil adequado de pessoas que são auto-gerenciáveis, colaborativas e multi-disciplinar. Problemas de gerenciamento das atividades devem ser resolvidos pelo time, o Scrum Master irá apenas retirar impedimentos. D I S C I P L I N A !! A resposta está nas pessoas e como elas compartilham seus conhecimentos e trabalham juntas... É necessário método SEMPRE...e ter disciplina para executá-lo !!
- #20 Explicação da imagem: É bem conhecido o fato de que na evolução biológica, mudanças ocorrem bruscamente após intervalos separados por grandes períodos de aparente estagnação. Simulações de computador mostram que, na verdade, as mudanças ocorrem na verdade após períodos de mudanças contínuas num organismo, mas as mudanças não são visíveis até que as mudanças em subsistemas (respiratório, circulatório, digestivo etc), se combinem e produzam uma mudança externa dramática. As mudanças contínuas seriam os Sprints. As mudanças dramáticas, perceptíveis ao usuário seriam as Releases. A visão é o objetivo final, onde as as evoluções pretendem chegar
- #21 Desenvolvimento Iterativo e incremental é uma estratégia de planejamento, onde o projeto é construído em partes, ou seja, em ciclos (iterações), a cada iteração é feito um novo incremento (parte do software funcional) até completar o software. Iteração=repetição Incremento = pequena porção de evolução. Processo Iterativo é aquele que se repete. Processo incremental é aquele que entrega pequenas evoluções a cada repetição.
- #22 Backlog do Produto O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir. O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo em que o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são analisados e revisados. O Time de Desenvolvimento decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner. Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, menos detalhes. Os itens do Backlog do Produto que irão ocupar o desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro da Sprint são considerados como “Preparados” para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparência através das atividades de refinamento descritas acima. A palavra Grooming em inglês significa cuidar da aparência, manter limpo e arrumado. Para facilitar a semântica do artigo, traduzirei “Backlog Grooming” como “Organização do Backlog“, considerando que organizado é por consequentemente limpo e arrumado. Alguns autores preferem chamar de Refinamento de Backlog [4]. Organizar o backlog é uma processo contínuo que envolve: A descoberta de novos itens, assim como alteração e remoção de itens antigos [2]. Quebrar Estórias muito grandes (épicos) [1]. A priorização dos itens do backlog (trazendo os mais importantes para o topo) [2]. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento [2]. Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas) [2]. Incluir Critérios de Aceitação [1].
- #23 User Stories Podemos definir e organizar os requisitos de um sistema utilizando User Stories (histórias de usuário). User Stories são artefatos de desenvolvimento utilizados em sistemas geridos segundo metodologias ágeis. Frente: Como &lt;usuário&gt; eu quero &lt;meta&gt; para que eu possa &lt;motivo&gt; Ex. como um cliente quero pesquisar valores de passagens aéreas para que eu possa fazer o meu orçamento de viagem Verso: Considero a história atendida se &lt;condição&gt; Ex.considero a história atendida se tiver uma tela onde eu possa consultar voos e seus respectivos valores Ator – O proprietário da User Story. De forma simplista é o usuário, o interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto da história dentro do sistema. Ação – É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do sistema. Funcionalidade – É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também pode ser visto como justificativa. Alguns aspectos importantes podem ser notados no uso de User Stories: Validar se a funcionalidade é realmente necessária antes de incluí-la Análise das necessidades reais do usuário Ajuda a priorizar o que deve ser feito É mais fácil estimar o esforço que será necessário para implementar a funcionalidade O interessante no uso de User Stories é o foco nas necessidades reais e práticas do usuário.
- #24 O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalham fazem a estimativa final. O Planning Poker é uma prática de estimativa de tarefas bem simples e inclusive divertida, mas muito eficiente. Muito utilizada no SCRUM, esta prática funciona da seguinte forma: – Ao invés de estimar horas exatas estima-se em pontos; – Os pontos utilizados no ‘jogo’ são parecidos com a sequencia do Fibonacci, ou seja, o próximo número é a soma dos dois números anteriores: 0, 1, 2, 3, 5, … Para simplificar é muito utilizada esta sequencia: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Mas vai de cada um; eu por exemplo não chegaria até o 100 porque prefiro trabalhar com tarefas menores; – Porque números tão distante entre si? Porque quanto maior uma tarefa, mais difícil de prever com precisão quantos pontos a mesma terá (e muito menos horas). Isso significa que uma estimativa de 13 pode estar entre 8 e 21… Por isso que quanto menor as tarefas, melhor para serem estimadas e a variação de pontos é melhor administrada. Sempre procure chegar no menor nível de granularidade, evitando tarefas muito grandes; – O time do projeto se reúne com o responsável pelas regras de negócio (Analista, PO, Gerente, Cliente…) e cada um recebe as cartas do Planning Poker. Mas que isso não seja um impedimento! Se não tem cartas, improvise com os dedos (foi o que fiz, rsrs); – As funcionalidades/tarefas são apresentadas, uma a uma e as dúvidas do time são sanadas; – Atribui-se o peso 2 para a menor tarefa, para que esta sirva de comparativo para as demais (ex: uma laranja é maior que um morango? E que uma manga? E assim as tarefas são comparadas tendo essa de peso 2 como parâmetro); – Inicia-se com uma atividade (pode ser por ordem de prioridade), e todos jogam a carta ao mesmo tempo; – A ideia é discutir a variação de estimativa; porque Fulano estimou X e Ciclano estimou Y… e aí… só fazendo para ver o que acontece; – No final a equipe chega a um consenso e define o peso da tarefa, partindo para a estimativa das demais, até que todas estejam estimadas;
- #25 Definition of Ready Having a Definition of Ready means that stories must be immediately actionable. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story or PBI. The Team must understand the &quot;done&quot; criteria and what tests will be performed to demonstrate that the story is complete. &quot;Ready&quot; stories should be clear, concise, and most importantly, actionable. Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done. Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.
- #26 KANBAN Importante ferramenta de gestão visual para controle. Permite o aumento da eficiência, redução de desperdícios e custos Criado pela Toyota . facilidade de controlar . Todos conseguem visualizar . Atualização real time . Melhora comunicação com equipe . Aumenta a qualidade e eficiência da gestão
- #27 O Burndownchart ou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum para representar diariamente o progresso do trabalho em desenvolvimento. Ou seja, após cada dia de trabalho o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total planejado. É comum a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para medir os pontos das histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do seu ritmo de trabalho, verificando se o ritmo está adequado para atingir a meta da sprint, cumprindo com o que foi planejado. O Burndown é o gráfico mais simples que há no Scrum e que muitas equipes nem sempre dão o devido valor as informações referente ao processo de trabalho que ele apresenta, indiretamente. Simplesmente traçar o gráfico pelo simples fato de traça-lo é desperdício, o importante é identificar nele o que há de errado com a estratégia, o processo de trabalho, adotado pela Equipe Scrum.
- #28 A entradas para esta cerimônia é: Product Backlog detalhado e priorizado pelo P.O. O Scrum Master realiza o papel de mestre de cerimônias.
- #29 A reunião é realizada em duas partes Na primeira parte, o time cuida da questão “o quê?” O Product Owner apresenta os itens de maior prioridade do Product Backlog e propõe uma Meta. A decisão referente à quantidade de itens que o time seleciona cabe somente ao Time. Somente o time pode saber o que ele é capaz de fazer no sprint. A meta não é um subconjunto de itens do Backlog, é um objetivo de negócio atingido através desses itens. Pode ser que o time não complete todo o sprint backlog mas mesmo assim atinja a meta de negócio. Meta é uma descrição que orienta o time sobre o motivo pelo qual ele está produzindo esse incremento. A razão para definição dessa meta é dar ao time a flexibilidade necessária para desenvolver as funcionalidades que julgar necessária, mas sem perder o objetivo principal de vista. Metas devem estar relacionadas ao negócio e não devem ser numéricas nem de performance.
- #30 Explicar o passo-a-passo para definição da META da Sprint, como selecionar os itens do Backlog para atender a meta definida e detalhar para cada item selecionado as Tarefas que deverão ser realizadas.
- #31 Não se discute outro assunto durante a reunião de trabalho.
- #32 Objetivo: atualizar o quadro e definir quem fará as outras atividades. Duração: 15 minutos. Tomar cuidado para essa reunião não se transformar em discussão do trabalho. O Scrum Master começa a reunião pela pessoa imediatamente à sua esquerda e prossegue em sentido horário. Apenas essas questões devem ser respondidas. Apenas uma pessoa fala por vez; Enquanto alguém fala, todos ouvem. Dúvidas e discussões sobre os temas comentados devem ser resolvidas após a reunião diária. Galinhas não tem permissão de falar. Galinhas ficam na periferia, fora do círculo formado pelo time. Galinhas não podem falar com membros do time após a reunião. Porcos ou galinhas que não concordem com essas regras podem ser excluídos do time ou das reuniões.
- #33 É realizado para mostrar o resultado da Sprint. O time apresenta os resultados. O resultado final é sempre do time. Nesse momento pode-se solicitar o TRHI. Ocorre sempre ao final do Sprint.
- #34 Para a dinâmica final do treinamento: neste momento pode-se definir quem será o Scrum Master de cada time utilizar o método Russo (cada um levanta a mão e ao mesmo tempo aponta para um do grupo, aquele que for mais “apontado” será o S.M.) entregar o crachá personalizado para cada S.M. escolhido pelo time.
- #35 Reunião para definir melhoria contínua. Reunião de feedback, direcionada pelo Scrum Master. * Nesse caso é muito importante que o Scrum Master seja uma pessoa imparcial ao time, pois as melhorias podem afetar até mesmo a exclusão de pessoas do time.
- #36 O Scrum Master começa a reunião com as respostas compiladas. O Time prioriza em que ordem serão discutidas as melhorias em potencial. Relembrar sobre os Pilares do Scrum: transparência, inspeção e adaptação.
- #37 CSM = Certified Scrum Master / CSPO = Certified Product Owner / CSD = Certified Scrum Developer. São certificações concedidas pela Scrum Alliance, após treinamentos de 2 dias com um “CST – Certified Scrum Trainer”. O que chega mais perto do PMP do PMI, é o CSP, Certified Scrum Professional, na qual é necessária comprovação de experiência de pelo menos 1 ano atuando como Scrum Master. = Tradicional = Escopo, Custo e Prazo – Fixo -&gt; Foco Processo Ágil = Custo e Prazo – Fixo / Escopo – Variável -&gt; Foco nas Pessoas (times autogerenciáveis) = Gestão tradicional =&gt; Abordagem Scrum Escopo =&gt; O escopo é definido pelo Product Backlog e Sprint Backlog Custos =&gt;O custo é dado por Sprint, não por projeto. A priorização do Backlog é voltada ao ROI, equipes fixas, tempos fixos. Tempo =&gt;Definição de time-boxes Comunicação =&gt; Fortemente baseada nas cerimônias. Não exige planejamento, exige disciplinado Scrum. Integração =&gt; O próprio framework SCRUM força a integração das disciplinas, pois aborda indiretamente todas elas. Recursos Humanos =&gt; Times autogerenciados. Papéis claros (scrum master, product owner e time) Qualidade =&gt; Inspeção constante. Cerimônias de revisão e retrospectiva Riscos =&gt; Estratégia de aceitação. A abordagem é que, se tudo der errado , o prejuízo máximo é de 1 mês de trabalho. Aquisições =&gt; Por não definir o escopo com rigidez, o tipo de contrato firmado geralmente é “Time and Material”.
- #38 Só o escopo é flexível Cliente recebendo valor para negócio Mudanças são bem vindas Entrega produto = valor agregado
- #39 SCRUM - É um framework dentro do qual você pode empregar diversos processos e técnicas The Scrum Guide – guia projeto CSM = Certified Scrum Master / CSPO = Certified Product Owner / CSD = Certified Scrum Developer. PMI – Project Management Insntitute PMBOK – guia projeto PMP = Project Management Professional
- #40 http://blog.andrefaria.com/sessoes-de-backlog-grooming-organizacao-do-backlog http://www.desenvolvimentoagil.com.br/scrum/product_backlog https://tipratica.wordpress.com/2012/01/04/planning-poker/ https://www.scruminc.com/definition-of-ready/ https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod) http://pt.slideshare.net/isoflex/gesto-visualkanban http://blog.myscrumhalf.com/2012/01/burndown-chart-medindo-o-progresso-de-sua-sprint-e-trazendo-indicativos-do-processo-de-trabalho-da-equipe/
- #41 https://support.office.com/pt-br/article/Atalhos-de-teclado-para-uso-durante-uma-apresenta%C3%A7%C3%A3o-no-PowerPoint-2010-12f0ef03-d3f4-4901-8392-e6185d1ef8d6 Exibir um slide preto vazio ou voltar para a apresentação a partir de um slide preto vazio. E ou PONTO Exibir um slide branco vazio ou voltar para a apresentação a partir de um slide branco vazio. C ou VÍRGULA
- #42 Pensar fora da caixa Atitude ATEC (Evoluir Inovar Construir) Apresentação diferente, fora dos padrões do banco (cor, logo, agenda)... Vocês perceberam? pode causar estranheza, mas atingiu o objetivo = auxílio na passagem da informação. Encontro ATEC 2012 = Industrialização SCRUM – MDS Ágil Eugênio Mussak – Encontro DSPF 2012 - síntese e estímulo para reflexão - pardadigma PARA ENCERRAR A APRESENAÇÃO... No início deste ano... apresentação Fabio Armani da Banco PF.. Bonomi (missão de construir o maior banco do planeta)... Albert Einstein... Fazer a mesma coisa e esperar resultado diferente... FAZER DIFERENTE !!