Slide 1: SCRUM
Método ágil para gestão de projetos
Erick Herdy
Slide 2: Criação do modelo SCRUM
Janeiro-Fevereiro de 1986; Takeuchi e Nokana lançam “The New Product development Game” Inicialmente, concebido para fábricas de autos e bens de consumo; Equipes cross-fu nct iona l; Scrum no Rugby; Onze anos depois, Ken Schwaber formalizou a definição de Scru m e ajudou a implementá-lo em desenvolvimento de software em todo o mundo.
Slide 3: ntrodução
O que é metodologia?
Slide 4: ntrodução
Meto dolo gia, é o estudo dos m étodo s ou o s passos em um determinado pro cesso . A finalidade de uma metodologia, é captar e analisar as características dos vário s méto do s disponíveis, avaliar suas capacidades, po tencialidades, lim itaçõ es, disto rções e criticar os pressupostos ou limitações das mesmas. Além de ser uma disciplina que estuda métodos, a metodologia é também considerada uma forma de conduzir a pesquisa.(pesquisa acadêmica)
Slide 5: rque estudar métodos?
Pesquisas indicam pouca ou quase nenhuma qualidade em softwares desenvolvidos; Cro no gramas estourados, custos nas alturas....prejuizo...e prejuizo... A necessid ad e dos clientes não são alcançadas; Má, péssim a ou nenhum a comunicação com o cliente; A procura pela “bala de prata” (BROOKS – 1987) Pr ob lemas citado s : C om plex idade, C on fo rmidade, Mutab ilidade e Invisibilidade ; Soluçõ es: L in guagens de alto-nivel, Prototipação , De sen volvim en to in crem en tal, bon s desen volvedo res, bo ns pro jetistas......
Slide 6: Heavyweight vs L igthweight
Heavyweigth (Plan-d riven)
Planejamento extensivo, processos bem definidos, reuso, visando produção eficiente e previsvel; Aos poucos atingir a perfeição.
Ligthweight (Agile Metod s)
Planeje, d ocum en te somente o suficien te ; Individualidade e satisfação momentânea do cliente; Ser bom o suficien te ;
Slide 7: lores e Diferencia is
Nós estamos descobrindo melhores maneiras de desenvolver software, criando-o e ajudando outros a criar. Através desse trabalho, passamos a valorizar:
In dividuo s e inter açõ es vs pro cesso s e f err am entas; Sof tw are operante mais do que d ocum en tações co mpletas; Co lab or ação do clien te vs n egociações con tratuais; Resp on der e estar aptos a mudanças do que seguir um plan ejamento
Slide 8: que são metod ologia s ágeis?
Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.
Slide 9: ra que? Qual a motivaçã o?
Minimizar o risco de desenvolvimento de software em prazos muito curtos; Prover uma melhor comunicação entre os integrantes do projeto; Entregar partes funcionais; Alcançar o “suficiente”
Slide 10: acterísticas de um AM (Agile model)
É um modelo bom o suficiente, nada mais que isso, e que exibe as seguintes características: Atende ao seu propósito; É inteligível; É suficientemente preciso; É suficientemente detalhado; É suficientemente consistente; Provê um valor positivo; É tão simples quando possível.
Slide 11:
Pensem em AM não como ciência, mas sim como arte.
Slide 12: que é uma A M ?
Atitude, não processo prescritivo; Suplemento aos métodos existentes. Ele não é uma metodologia completa; É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades dos st akehold er s do projeto; É efetivo e é sobre ser efetivo; É uma coisa que funciona na prática, não é uma teoria acadêmica; É para desenvolvedores médios, mas não substitui pessoas competentes.
Slide 13: que n ão é uma AM ?
Não é uma bala de prata; Não é um ataque à documentação, pelo contrário, AM aconselha a criação de documentos de valor para o projeto; Não é um ataque as ferramentas CASE; Não é para todo mundo.
Slide 14: jetivos / Funções do SCRU M
A função primária do Scrum é ser utilizado para o ger en ciam ent o de pr o jet os de desenvolvimento de software. Teoricamente pode ser aplicado em qualquer contexto no qual um g r up o de pess o as necessitem tr ab alhar ju nt as para atingir um o bj etiv o com um ; Iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.
Slide 15: racterísticas do SCRUM
Backlog vivo e ativo de todas as tarefas a serem feitas; Sprint é a entrega de um conjunto fixo de itens em um determinado período de tempo. Backlog de produto é mantido pelo “Product Owner” e é uma lista de requisitos que vêm do cliente; Backlog de sprint é uma interpretação do backlog do produto e contém tarefas que serão realizadas durante o próximo sprint para implementar os principais itens no backlog do produto.
Slide 16: omo funciona ?
Slide 17: ntegrantes
O SCRUM possui três figuras:
Product
Owner; Master; TEAM;
SCRUM
SCRUM
Slide 18: roduct Own er
Define as funcionalidades do produto; Decide sobre as entregas e o conteúdo; É responsável pelo ROI (lucratividade); Prioriza as funcionalidades de acordo com o mercado; Ajusta as funcionalidades e prioridades com cada iteração, conforme necessário; Aceita ou rejeita o entregável;
Slide 19: CRUM TEAM
Basicamente, consiste em uma equipe de 5 a 12 pessoas; Durante a discução com o Product Owner, o objetivo do sprint é determinado e priorizado, e explorado minuciosamente, determinando pequenas tarefas; O time se auto-organiza e os membros trabalham juntos para a entrega do delivery, sendo todos responsáveis pelo resultado; É quem decide qual trabalho será feito e quais serão as responsabilidades atribuidas. Não existe uma pré-definição de responsabilidades: Todos devem estar aptos a trocar de papel com outro membro do time;
Slide 20: CRUM MASTER
Coach do scrum team; Remove todos os impedimentos para que uma determinada tarefa seja realizada; Trabalha constantemente procurando maximizar toda a eficiencia do time, e da condições que eles deem o melhor de si; Esta sempre atento para as tarefas que deverão ser entregues no final de cada sprint; Treinador, fixer e gatekeeper. Ele é o responsável por organizar as reuniões diárias; Isola a equipe de interferências externas; Sempre adota o “aqui-agora”; Ele fica responsável por administrar as reuniões de retrospectiva do projeto, onde todas as decisões são revistas;
Slide 21: iando um processo:Sprint Planning
Product owner cria a lista com todas as requisições e especificações do produto; SCRUM TEAM seleciona itens a partir do Product backlog que eles possam se comprometer a entregar; Tarefas são identificadas; É feito por toda equipe, e não apenas pelo SCRUM Master;
Slide 22: eunião diária
Todos os dias, no mesmo horário, o Scrum Master se reúne com todos os membros do time, e faz três perguntas básicas:
O
que eu fiz desde ontem? O que eu irei fazer até amanhã? O que me impede de ir adiante?
Reuniões duram no máximo 15 minutos; Preferencialmente, de pé =)
Slide 23: Sprint review
A equipe apresenta o que atingiu durante o sprint Tipicamente, toma forma de apresentação de um demo do produto funcional; Informal; Sem powerpoint; A equipe inteira participa.
Slide 24: ntrega / Delivery´s
Após a fase do sprint, cada entregável é entregue ao cliente, para ser testado e analisado; Após o cliente validar os entregáveis, é criado um novo sprint backlog; Uma nova fase se inicia, novos entregáveis a caminho.
Slide 25: print Retrospective
Periodicamente olhar o que funciona e o que não funciona; Tipicamente de 15 a 30 minutos; Feito no final de cada Sprint; A equipe inteira participa e discute o que gostariam de: Começar / Parar / Continuar
Slide 26: o nclusões
SCRUM pode ser aplicado em qualquer situação; Metodologias ágeis tendem a se aproximar da realidade dos times de trabalho; Não existe solução mágica, apenas times bem organizados e sincronizado; Um time é diferente de uma equipe. No time, todos tem o mesmo objetivo final, todos são responsáveis
Slide 27: Riscos e Mitos no Desenvolvimento de soluções Web
Riscos
Atraso no cronograma; Cancelamento do projeto; Entropia de sistemas de produção; Taxa de defeitos; Incompreensão dos requisitos de negócios e sistemas; Mudanças Constantes; “Scoope Scrip” (Invasão de requisitos) Alta taxa de evasão de desenvolvedores. Podemos coletar todos os requisitos de uma vez só; Podemos antecipar todas as mudanças; Podemos controlar completamente todo o projeto do software; Custo de mudança é por natureza, maior a medida que o projeto avança;
Mito s:
Slide 28: Exemplo
A ponte mais alta do mundo
Slide 29: Obrigado
Dúvidas? Perguntas ?
erick@hutil.com.br
