Scrum

verso 2 | Jan 2011
SCRUM, O Tutorial Definitivo
O Tutorial Definitivo
www.etcnologia.com.br
Rildo F Santos
(11) 9123-5358 (11) 9962-4260
rildo.santos@etecnologia.com.br twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/
Verso 2 Jan 2011 | RFS
rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos 2006 e 2010
Contedo:
1 Desafios do desenvolvimento de Software 2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Verso 2 Jan 2011 | RFS rildo.santos@etecnologia.com.br
Objetivo:
Objetivo: O Scrum um Mtodo gil para execuo de qualquer projeto ou trabalho.

O Objetivo deste Tutorial prover conhecimento, apresentar e discutir o SCRUM e suas prticas aplicadas a projetos de desenvolvimento de software.
Pr-requisito: No h.
Programa: Menos Papel, Mais rvores
Qual o mundo que queremos ? O primeiro passo para criar um mundo melhor, saber qual tipo de mundo que queremos ter e qual tipo que deixaremos de herana para as prximas geraes. Nossa misso: buscar pelo equilbrio do homem, da tecnologia e do meio ambiente. Para cumprir esta misso necessrio: conscientizar, comprometer e AGIR.
O programa Menos Papel, Mais rvores, uma ao, com objetivo de estimular o consumo sustentvel de papel dentro das organizaes.
Quer participar ? - Reduza o uso de papel (e de madeira) o mximo possvel. - S imprima se for extremamente necessrio. - Evite comprar produtos com excesso de embalagem. - Ao imprimir ou escrever, utilize os dois lados do papel. - Use papel reciclado.
Este material no deve ser impresso..
Facilitador: Rildo F. Santos (@rildosan)

Coach , Instrutor, Consultor e Palestrante de Mtodos geis, Gesto de Negcios, Inovao , Processos e Tecnologia . Minha Experincia: Tenho mais de 10.000 horas de experincia em Gesto de Negcios, Gesto de Inovao, Governana e Engenharia de Software. Sou formado em Administrao de Empresas, Ps-Graduado em Didtica do Ensino Superior e Mestre em Engenharia de Software pela Universidade Mackenzie.
Fui instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).
Conheo Mtodos geis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a Servio), Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de ps-graduao da Fasp e IBTA. Tenho conhecimento de Gesto de Negcio (Inteligncia de Negcio, Gesto por Processo, Inovao, Gesto de Projetos e GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI; Experincia na implementao de Governana de TI e Gerenciamento de Servios de TI. Fluncia nos principais frameworks e padres: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999; Participei de diversos projetos nos segmentos: Financeiro, Telecomunicaes, Seguro, Sade, Comunicao, Segurana Pblica, Fazenda, Tecnologia, Varejo, Distribuio, Energia e Petrleo e Gs. Possuo as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International Institute of Business Analysis (Canada) Onde estou: Twitter: @rildosan Blog: http://rildosan.blogspot.com/ Comunidade: http://etecnologia.ning.com
Contedo:
3 Entendendo SCRUM
4 Estudo de Caso
Objetivo:
Parte 1 - Desafios do desenvolvimento de Software Objetivo: Apresentar e discutir os principais desafios dos projetos de desenvolvimento de software. Pr-requisito: No h.
Desafios do Desenvolvimento de Software

1. Desafio: Responder ao cliente Quanto tempo vai levar ? O tempo outro grande desafio, raro (posso at afirmar que no existe) um cliente que diga: Demore o tempo que for necessrio, pois, no temos pressa nenhuma. Geralmente o cliente quer o software funcionando Para ontem... Quanto custar ? Todo cliente quer saber quanto custar o software...
O primeiro desafio conseguir responder qual o custo do software e em quanto tempo o cliente vai ter o software funcionando.
2. Desafio: Falha na Comunicao das equipes de TI
10
3. Desafio: Entender as necessidades dos clientes

Quando no se entende as necessidades dos clientes, no se pode entregar valor ao cliente.
11
4. Desafio: Compreender por que os projetos falham:
Informao errada 13%
Requisitos incompletos 12%
Outros 50%
Mudana de Requisitos 12% Falta de conhecimento tcnico 7%
37% das falhas esto relacionadas com requisitos
Falta de competncia 6%
Craig Larman, Agile and Iterative Development: A Managers Guide, Addison Wesley Professional (2004)
12
12
5. Desafio: Identificar o que necessidade e o que desejo Uso de funcionalidades do Software

Contudo, a maioria das funcionalidades nunca so usadas pelos usurios
Sempre 7% Nunca 45%
Freqentemente 13%
As vezes 16% Raramente 19%
Craig Larman, Agile and Iterative Development: A Managers Guide, Addison Wesley Professional (2004)
13
13
6. Desafio: Aumentar produtividade da equipe de desenvolvimento: Satisfao dos Clientes
Como aumentar a produtividade da equipe de desenvolvimento de software ?
14
A falta de produtividade pode afetar o negcio

Qual a soluo ? Contratar mais desenvolvedores... Mas, ser que a contratao de novas pessoas garante o aumento de produtividade ?
The Mythical Man Month by Frederick Brooks, 1975*. Quando um projeto est atrasado, contratar novas pessoas para ajudar no projeto pode servir apenas para atras-lo ainda mais. Pois, as novas pessoas precisam primeiro entender o que projeto, objetivos, escopo, funcionalidades e etc, para depois comear a produzir, ou seja, temos que considerar o tempo que ser gasto com explicaes, orientaes, comunicao e treinamento das novas pessoas, devemos considerar o esforo da gesto de projetos que aumentar Ao calcular o tempo que ser necessrio para desenvolver um software, temos que adicionar um tempo extra, pois os desenvolvedores precisam de "tempo para pensar, tempo para pesquisar alm do "tempo para desenvolver" "Adicionar novas pessoas a um projeto de software atrasado s adiar a sua entrega." A Lei de Brooks
15
7. Desafio: Escolher framework certo para desenvolver software ?
UP SCRUM, O Tutorial Definitivo
SCRUM, Lean, ASD, XP, FDD...
RUP
16
8. Desafio: Como reter os bons profissionais ?

Quantas vezes j montamos boas equipe, mas de repente as pessoas comeam a sair...a trocar de emprego. A reteno de bons profissionais grande desafio da atualidade, pessoas trocam muito mais de emprego do que a 10 anos atrs. Insegurana, chefes tiranos, a falta de respeito, falta de reconhecimento e de e ambiente estressante so as algumas das causas que fazem os profissionais de trocarem de emprego. A maioria das pessoas mudam de emprego por problema com o seu chefe e no por motivo de salrio.
17
Por que precisamos dos Mtodos geis ?

Problemas clssicos (ou tradicionais): Stakeholders (Clientes): - Tm dificuldades em externar suas necessidades - Geralmente fazem mudanas de requisitos - Precisam do software funcionando para ontem Desenvolvedores: - No sabem ou no querem elicitar requisitos - Dificilmente conseguem atender todas as demandas de negcio - Tem dificuldade em comunicar e entender os clientes
Para enfrentar estes desafios:
Utilizao de mtodos geis, como SCRUM, pode amenizar estes problemas.
18
Cliente x Desenvolvedores:
Clientes: - Alguns clientes tm dificuldades em externar suas necessidades ou desejos de forma clara e objetiva (No sabem o que querem) - Geralmente fazem mudanas de requisitos durante o desenvolvimento ou quando o software entregue.
- Sempre precisam do software funcionando para ontem

- No tm tempo e nem pacincia para falar com os desenvolvedores.
Desenvolvedores: - No sabem ou no querem conversar com o cliente

- Dificilmente conseguem atender o negcio e todas suas demandas
- Tm dificuldade em se comunicar e entender os clientes
19
Como enfrentar estes desafios: O SCRUM sua sogra

O SCRUm pode ser uma forma para enfrentar estes desafios, O SCRUM no vai aumentar a produtividade da equipe, no vai fazer voc entregar software mais cedo, nem melhorar a qualidade do software e nem otimizar os custos do projeto de desenvolvimento. O SCRUM como sua SOGRA ele vai apontar os principais problemas, falhas e pontos crticos (riscos) do projeto de desenvolvimento, aquilo que realmente precisa ser melhorado, mas se as pessoas envolvidas com o projeto no tomarem nenhuma ao (ou melhor: tomarem atitudes) os problemas continuaram a existir e levaram a maioria dos projetos para a marcha da morte. O Scrum vai deixar todos os problemas aparentes.
20
Se trabalhamos com desenvolvimento gil:

Logo temos: Colaborao com cliente: A estria do Usurio escrita em colaborao entre os desenvolvedores e o cliente (PO). A prioridade satisfazer o cliente, entregando o mais rpido possvel e de forma contnua software que tenha valor: Para satisfazer o cliente preciso entend-lo. A estria ajuda a melhorar o entendimento da necessidade do cliente para que ocorra a entrega de valor. - Conversa face-a-face SEMPRE a melhor forma de comunicao: A estria do usurio geralmente feita na Reunio de Planejamento (Planning Meeting).
Aqui entra a Estria do Usurio:

Titulo: Pagamento com Carto de Crdito Prioridade: Alta
Como cliente de negcio eu gostaria de fazer pagamento com Carto de Crdito para minha comodidade.
Pontos: 5
A Estria de Usurio uma ferramenta simples que pode ajudar. Uma Estria de Usurio nada mais que um carto com algumas frases, escrita pelo cliente e desenvolveres em linguagem comum, sobre algo que o software deve fazer.
21
Exerccios:
1- possvel entregar valor ao cliente (software funcionado, segundo o Manifesto gil), sem entender a necessidade dele ?
2 Por que a especificao de requisitos de software no soluo para os problemas de comunicao ?
22
Contedo:
3 Entendendo SCRUM
4 Estudo de Caso
23
Objetivo:
Parte 2 Sobre SCRUM: Objetivo: Apresentar Manifesto gil e o SCRUM, as principais caractersticas e prticas. Pr-requisito: No h.
24
Parte 2
Sobre o SCRUM
25
As Razes do Scrum:
TimeBoxes Artigo: The New, New Product Development Game de Nonaka e Takeushi na Hardvard Bussines Review Desenvolvimento iterativo e incremental
SmallTalk Engineering Tools
Reunio diria 24 horas
Produto Backlog
Sprint Backlog Produto 2-4 Semanas
26
O que TimeBox ?
durao fixa (imutvel). um conceito diz que a quantidade de tempo imutvel, ou seja, tem durao fixa - a quantidade de dias no poder aumentar. Assim, evita-se atrasos no prazo de entrega e facilita o planejamento. No Scrum as cerimnias e/ou eventos com durao fixa (Time-Boxes) so: - Reunio de Planejamento da Release, - Sprint (iterao), - Reunio de Planejamento da Sprint, - Reviso da Sprint. - Retrospectiva da Sprint. - Reunio Diria. Exemplos de Timebox: A Sprint (que uma iterao) que deve ser realizada de 2 a 4 semanas, no qual a equipe de desenvolvedores dever produzir um entregvel de valor para o cliente (mais frente discutiremos melhor isto). A entrega de valor a meta da Sprint, a durao da Sprint dever ser combinada com o cliente, antes do comeo da execuo da Sprint. Se foi acertado que a Sprint tem a durao de 4 semanas, logo esta durao ser fixa (no mudar). Durante a Sprint so realizadas as Reunies Dirias, uma reunio diria tem a durao fixa de 15 minutos. Ao final da Sprint, feita a reunio de Reviso da Sprint. Para Sprints de um ms, essa uma reunio com durao fixa de quatro horas. Aps a Reviso da Sprint e antes da prxima Reunio de Planejamento da Sprint, a Equipe Scrum tem a Reunio de Retrospectiva da Sprint. essa reunio, te durao fixa de trs horas.
27
Abordagem Iterativo e Incremental:

Entrega 1 Entrega 2 Entrega 3
Incremental
Iterativo
Devido a complexidade, tamanho, mudanas de requisitos, urgncia e necessidade de demonstrar valor mais rpido, fica quase inconcebvel desenvolver software utilizando o modelo cascata, ou seja, desenvolver todo o software em uma nica vez. Desenvolvimento Iterativo e incremental uma estratgia de planejamento (que segue a linha dividir para conquistar) , onde o software construdo em partes, ou seja, em ciclos (iteraes), a cada iterao feito um novo incremento (uma parte do software funcional) at completar o software.
28
O qual propsito do SCRUM ?

Scrum vem sendo utilizado para o desenvolvimento de produtos complexos desde o incio dos anos 90.
Scrum no um processo ou uma tcnica para o desenvolvimento de produtos.

Ao invs disso, um framework dentro do qual voc pode empregar diversos processos e tcnicas. O papel do Scrum fazer transparecer a eficcia relativa das suas prticas de desenvolvimento para que voc possa melhor-las, enquanto prov um framework dentro do qual produtos complexos podem ser desenvolvidos.
Por ser um framework, o SCRUM no uma ferramenta, nem metodologia, nem processo e nem uma soluo completa para o desenvolvimento de software, ele um framework (uma estrutura), ou seja um guia de referncia , isto significa que o Scrum no vai lhe dizer como fazer as coisas! Por ser um framework, ele pode ser utilizado com as prticas de engenharia de software e/ou metodologia de desenvolvimento que j existem dentro da organizao. O SCRUM pode ser utilizado para desenvolver qualquer produto e no s software.
29
Qual a teoria do SCRUM ?

A TEORIA DO SCRUM: Scrum, que fundamentado na teoria de controle de processos empricos*, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos O que so processos empricos ? Antes de responder a pergunta, precisamos saber que existem dois tipos de processos:
Processo Definido: So processos que se conhece todas as variveis, tm poucas ou nenhuma mudana ao logo do processo, so repetitivos e so previsveis. Geralmente existe uma documentao aplicada a execuo do processo. Exemplo: Linha de produo
*Processos Empricos: So aqueles processos que no se conhece todas as variveis, tm mudanas ao logo do processo, no so repetitivos e so imprevisveis. Geralmente baseado na experincia e no conhecimento de quem executa o processo. Exemplo: Desenvolvimento de Software. Quando desenvolvemos um software as vezes no conhecemos todos os requisitos, e os requisitos que so conhecidos mudam com certa frequncia e geralmente todas as estimavas so feitas baseada no conhecimento das pessoas, isto quer dizer, que o mesmo trabalho feito por equipes diferentes a durao pode variar, pois, a equipe mais experiente deve realizar o trabalho mais rpido do que a equipe menos experiente. Isso porque o desenvolvimento de software um problema complexo, que se comporta de forma imprevisvel.
30
Os pilares do SCRUM:
Trs pilares sustentam qualquer implementao de controle de processos empricos.
31
Trs pilares sustentam qualquer implementao de controle de processos empricos.
O primeiro pilar:
A transparncia garante que aspectos do processo que afetam o resultado devem ser visveis para aqueles que gerenciam os resultados. Esses aspectos no apenas devem ser transparentes, mas tambm o que est sendo visto deve ser conhecido. Isto , quando algum que inspeciona um processo acredita que algo est pronto, isso deve ser equivalente definio de pronto utilizada. O segundo pilar:
Os diversos aspectos do processo devem ser inspecionados com uma frequncia suficiente para que variaes inaceitveis no processo possam ser detectadas. A frequncia da inspeo deve levar em considerao que qualquer processo modificado pelo prprio ato da inspeo. O problema acontece quando a frequncia de inspeo necessria excede a tolerncia do processo inspeo. Os outros fatores so a habilidade e a aplicao das pessoas em inspecionar os resultados do trabalho.
32
Trs pilares sustentam qualquer implementao de controle de processos empricos. O terceiro pilar: Se o inspetor determinar, a partir da inspeo, que um ou mais aspectos do processo esto fora dos limites aceitveis e que o produto resultante ser inaceitvel, ele dever ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rpido possvel para minimizar desvios posteriores.
Existem trs pontos para inspeo e adaptao em Scrum. A Reunio Diria (2) utilizada para inspecionar o progresso em direo Meta da Sprint e para realizar adaptaes que otimizem o valor do prximo dia de trabalho. Alm disso, as reunies de Reviso da Sprint (3) e de Planejamento da Sprint (1) so utilizadas para inspecionar o progresso em direo Meta da Release e para fazer as adaptaes que otimizem o valor da prxima Sprint. E a Retrospectiva da Sprint (4) utilizada para revisar a Sprint passada e estabelecer que adaptaes tornaro a prxima Sprint mais eficiente, produtiva, recompensadora e gratificante.
33
O Manifesto gil:
O SCRUM um Metodo gil

Fonte: http://agilemanifesto.org/iso/ptbr/
34
Princpios por trs do Manifesto gil:

Ns seguimos estes princpios:
Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face. Software funcionando a medida primria de progresso. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. Contnua ateno excelncia tcnica e bom design aumenta a agilidade. Simplicidade -- a arte de maximizar a quantidade de trabalho no realizado -- essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo.
35
Como Ser gil ?

Como ser gil ? 1 - Para ser gil preciso colocar em prtica os valores e os princpios do Manifesto gil.
Exemplo:
Se uma organizao implementou o SCRUM e aparentemente tudo ocorre bem...mas, se equipe no est conseguindo entregar software funcionando ao cliente a quatro meses, podemos afirmar que existe uma equipe gil ? Vejamos o que diz o Manifesto gil: Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo. Podemos concluir que a equipe no gil, pois alm da implementao do SCRUM, que um mtodo gil, ela tambm dever levar em conta os valores e princpios do Manifesto gil, ou seja, entregar software funcionando com certa regularidade.
36
Como Ser gil ?

Como ser gil ? 2 Alm de implementar o SCRUM para Gesto de Projetos de desenvolvimento de software tambm adote prticas de Engenharia de Software gil, tais como XP e FDD.
37
Como Ser gil ?
Engenharia de Software 100% gil: O SCRUM utilizado para Gesto de Projetos. J para as prticas de Engenharia de Software podemos utilizar o FDD para os requisitos de software e arquitetura e as Prticas do XP para o desenvolvimento de software (codificao, testes e refactoring).
38
Equipe: Tradicional x Colaborativa

Como ser gil ? 3 Para trabalhar como o SCRUM preciso trabalhar em equipe: Existem alguns tipos de equipe, vamos comparar o formato Tradicional e de auto Gesto: Tradicional auto Gesto
Mtodo de Gesto de Projetos Tradicionais. - No tem auto gesto. - No so auto-organizadas. - So fortemente hierarquizada. Com liderana baseada no comando-controle. - Equipe formada por especialistas.
Mtodo gil - ter auto gesto, - ser Auto organizada; - ser Interdisciplinar - no ter Hierarquia formal, - ter responsabilidade.
O Comando-controle: Pode levar ao baixo A auto gesto: Requer alto comprometimento da comprometimento e desmotivao sinnimo de equipe, que a chave para a produtividade. Equipe baixa produtividade e produtos de baixa qualidade. motivada produz mais e melhor.
39
As Caractersticas da Equipe:
Como ser gil ? 3 Para trabalhar como o SCRUM preciso trabalhar em equipe: Auto Gesto e Auto-organizao: A equipe possui a auto gesto e auto-organizada. No deve haver interferncia externa, nem o ScrumMaster ou Product Owner - pode dizer como a equipe deve se organizar ou fazer inferncia na forma de trabalho da equipe. A equipe deve ser capaz de se auto-organizar para dividir e fazer trabalho. Equipe de desenvolvedores muito parecida com um equipe de Volley Ball, onde todos tem um nico objetivo e so interdisciplinares no jogo. Interdisciplinares e Sem hierarquia formal: Equipes tambm so interdisciplinares: os membros da equipe devem ter todo o conhecimento e habilidades necessrias para entregar a meta da Sprint. Membros da equipe geralmente possuem conhecimentos especializados, tais como: programao, testes, controle de qualidade, anlise de negcios, arquitetura, desenho de interface de usurio e modelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto , a habilidade de trabalhar um item do Product Backlog (ou um requisito) e transform-lo em um produto (software funcionando) tendem a ser mais significativas do que aqueles que eles no dividem. As pessoas que se recusam a programar porque so arquitetas ou designers no se adaptam bem a equipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. Na equipe no h hierarquia nem ttulos, todos so iguais e no h excees a essa regra. As equipes tambm no devem ter sub-equipe dedicados a reas particulares como testes, banco de dados ou anlise de negcios. Responsabilidade: A equipe de desenvolvedores responsvel transformar os itens do Product Backlog em funcionalidades potencialmente entregveis a cada Sprint.
40
Reforando: No existe a Bala de Prata

SCRUM no a Bala de Prata:
O SCRUM no a soluo completa para os problemas de produtividade, complexidade, custo, prazo e qualidade do processo de desenvolvimento de software.
Veja Lei F. Brooks, No existe bala de prata
No existe soluo mgica para problemas complexos

Contudo, voc pode utilizar o SCRUM para: - SCRUM ideal para desenvolvimento de software complexos onde os requisitos mudam rapidamente; - SCRUM mtodo gil para gerenciar e controlar desenvolvimento de trabalho; - SCRUM possibilita que voc utilize as praticas de engenharia existentes e que j so conhecidas; - SCRUM baseado na abordagem interativa e incremental; - Equipe de desenvolvedores (ou time) deve ter auto gesto; - SCRUM o caminho para detectar e causa raiz e a remoo de qualquer coisa que esteja impedindo o desenvolvimento e/ou entrega de software/produtos; - SCRUM o caminho para maximizar a produtividade; - SCRUM vai d transparncia ao processo de desenvolvimento de software.
41
Algumas empresas que esto usando SCRUM:
Quais empresas esto utilizando o SCRUM?
Algumas empresas brasileiras
42
Exerccio
Leia o texto e complete a lacuna (no ltimo paragrafo): O processo de captao de talentos no futebol:
Baseado no texto do Fabrcio Moreira*
Um dos aspectos mais importantes dos grandes clubes de futebol est relacionado captao de talentos para compor suas categorias de base, e posteriormente formar esses atletas para ingressarem no profissional. Para entendermos melhor os caminhos atualmente traados por esses candidatos a futuros atletas de futebol precisamos analisar as formas que costumam chegar esses garotos at os clubes brasileiros e iniciar os seus treinamentos junto s equipes de base. Considerando que hoje esse processo de deteco difere em muito daqueles praticados anteriormente, e que cada vez mais, tem se tornado precoce e competitivo, em que a concorrncia chega a ser absurda. Se pudssemos ter acesso aos nmeros de garotos avaliados anualmente nos grandes clubes em relao aos selecionados, chegaramos certamente a esta concluso. O objetivo deste texto relatar os diversos mecanismos de captao de talentos em prtica nos grandes clubes do futebol profissional brasileiro. Dentre os mecanismos, destacamos cinco principais e dois secundrios. Podemos destacar alguns dos principais: as avaliaes peneiras; campeonatos e jogos amistosos; indicaes; escolas licenciadas franquias e os observadores tcnicos. Entre as secundrias, destacamos: as clnicas de futebol e o intercmbio internacional. As chamadas peneiras so um dos mecanismos mais conhecidos e utilizados no meio do futebol. Porm, um processo ___________________, baseado na observao dos treinadores em uma nica situao (muitas vezes apenas de jogo e de curta durao). Neste caso, muitos clubes pr-selecionam alguns garotos para continuarem os testes por pelo menos uma semana no clube, ou mais um dia, no mnimo.
http://www.universidadedofutebol.com.br/2010/07/1,14757,UM+RELATO+SOBRE+O+PROCESSO+DE+CAPTACAO+DE+TALENTOS+NO+FUTEBOL.aspx?p=1
43
Contedo:
3 Entendendo SCRUM
4 Estudo de Caso
44
Objetivo:
Parte 3 Entendendo SCRUM Objetivo: Apresentar de forma detalhada o framework SCRUM segundo o Guia do Scrum. Pr-requisito: No h.
45
Parte 3
Entendendo o SCRUM
46
Framework Scrum:
O framework Scrum formado por um conjunto pela Equipe (Time) Scrum e seus papis: Product Owner (PO), Scrum Master (SM) e equipe de desenvolvedores, eventos com durao Fixa (TimeBoxes), artefatos e regras.
Reunio diria Reviso da Sprint
Planejamento da Sprint
Retrospectiva da Sprint
24 horas Viso Produto Backlog Sprint Backlog Produto 2-4 Semanas
Legenda: Reunies Artefatos
Eventos (Reunies)
Papis Artefatos Planejamento da Release Planejamento da Sprint Diria Reviso da Sprint Retrospectiva da Sprint Product Backlog Sprint Backlog Sprint Burndown Release Burndown
Product Owner (PO) ScrumMaster (SM) Equipe Scrum
Sprint Burndown Release Burndown
47
Framework Scrum: Eventos de Durao Fixa:
Regras
48
Framework Scrum: Regras

As Regras fazem o elo entre os eventos com durao fixa (time-boxes), os papis e os artefatos do Scrum. As regras so descritas ao longo desta apresentao. Alguns exemplos de Regras: - Somente os membros da equipe de desenvolvimento podem falar durante uma Reunio Diria. - Equipe deve possuir auto-gesto.; - Somente o PO (Product Owner) definir e alterar a prioridade dos itens do Product Backlog. - Uma pessoa no pode desempenhar o papel de PO e de Scrum Master no mesmo projeto. - Somente o PO pode cancelar uma Sprint.
49
Framework Scrum: Papis e Equipe
Papis e Equipe
50
Papis SCRUM: Papis

Equipe Scrum so projetados para otimizar flexibilidade e produtividade. Para esse fim, eles so auto-organizveis, interdisciplinares e trabalham em iteraes. Cada equipe possui trs papis: Product Owner (PO), que responsvel por maximizar o valor do trabalho que a equipe faz, PO tambm responsvel por: - Definir a Viso do Produto - Elaborar , Priorizar e manter o Product Backlog - Definir ROI; - Representar o cliente - Aceitar ou rejeitar os entregveis O ScrumMaster, que responsvel por garantir que o processo (as prticas do SCRUM) seja compreendido e seguido. responsvel ainda por: - Remover impedimentos; - Proteger a equipe; - Ajudar o PO (quando necessrio); - Ser o facilitador da equipe. A equipe (ou time), responsvel pelo desenvolvimento do produto, formada por desenvolvedores que devem ter as habilidades necessrias para transformar os itens do Product Backlog em Produto. A Equipe ainda responsvel por: -Fazer estimativa; - Definir as tarefas; - Garantir a qualidade do produto; - Apresentar o produto ao cliente
51
A Equipe SCRUM: ScrumMaster (SM) e Product Owner (PO):

O ScrumMaster responsvel por garantir que o Equipe Scrum esteja aderindo aos valores do Scrum, s prticas e s regras. O ScrumMaster ajuda a Equipe Scrum e a organizao a adotarem o Scrum. O ScrumMaster educa a Equipe Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda a Equipe Scrum a entender e usar auto-gerenciamento e interdisciplinaridade. O ScrumMaster tambm auxiliar a equipe a fazer o seu melhor em um ambiente organizacional que pode ainda no ser otimizado para o desenvolvimento de produtos complexos. Quando o ScrumMaster ajuda a realizar essas mudanas, isso chamado de remoo de impedimentos. No entanto, o ScrumMaster no gerencia a Equipe Scrum; a Equipe Scrum auto-organizvel. O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pela Equipe. O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos. Todos sabem quais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar. O Product Owner deve ser uma pessoa, e no um comit. Podem existir comits que aconselhem ou influenciem , mas somente o PO poder mudar a prioridade de um item do PB. Empresas que adotam Scrum podem perceber que isso influencia seus mtodos para definir prioridades e requisitos ao longo do tempo. Para que o PO obtenha sucesso, todos na organizao precisam respeitar suas decises. Somente o PO pode definir a prioridade dos itens que a equipe ir trabalhar. As decises do Product Owner so visveis no contedo e na priorizao do Product Backlog. Essa visibilidade requer que o Product Owner faa seu melhor, o que faz o papel de Product Owner exigente e recompensador ao mesmo tempo.
52
A Equipe SCRUM: A Equipe

A Equipe (time) de desenvolvedores transformam o Product Backlog em incrementos de funcionalidades potencialmente entregveis em cada Sprint. A equipe deve ser formada por pessoas comprometidas em atingir as metas das Sprints .
A equipe deve ser interdisciplinar: os membros da equipe devem ter todo o conhecimento e habilidades necessrias para entregar a meta da Sprint. Membros da equipe geralmente possuem conhecimentos especializados, tais como: programao, testes, controle de qualidade, anlise de negcios, arquitetura, desenho de interface de usurio e modelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto , a habilidade de trabalhar um item do Product Backlog (ou um requisito) e transform-lo em um produto (software funcionando) tendem a ser mais significativas do que aqueles que eles no dividem. As pessoas que se recusam a programar porque so arquitetas ou designers no se adaptam bem a equipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. Na equipe no h hierarquia nem ttulos, todos so iguais e no h excees a essa regra. As equipes tambm no devem ter sub-equipe dedicados a reas particulares como testes, banco de dados ou anlise de negcios. A equipe possui a auto gesto e auto-organizada. No deve haver interferncia externa, nem o ScrumMaster ou Product Owner ningum pode dizer como a equipe deve se organizar ou fazer inferncia na forma de trabalho da equipe. A equipe deve ser capaz de se auto-organizar para dividir e fazer trabalho. A equipe deve ser autosuficiente, cada membro da equipe aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficincia e eficcia geral da equipe como um todo.
53
Equipe: Comprometimento e Tamanho:
Envolvidos
Comprometidos
Stakeholders (clientes e usurios finais)
Product Onwer
Equipe
SCRUM Master
O tamanho timo para uma equipe de 7 pessoas, mais ou menos duas pessoas. Quando h menos do que cinco membros em uma equipe, h menor interao e, como resultado, h menor ganho de produtividade. Mais do que isso, a equipe poder encontrar limitaes de conhecimento durante partes da Sprint e no ser capaz de entregar uma parte pronta do produto. Se h mais do que 9 membros, h simplesmente a necessidade de muita coordenao. Equipe grandes geram muita complexidade para que um processo emprico consiga gerenciar. Contudo, temos encontrado algumas equipes bem-sucedidas que excederam os limites superior e inferior dessa faixa de tamanhos. O PO e o ScrumMaster no esto includos nessa conta, a menos que tambm sejam porcos. A composio da equipe pode mudar ao final da Sprint. Toda vez que a equipe muda, a produtividade ganha atravs da auto-organizao reduzida. Deve-se tomar cuidado ao mudar a composio da equipe.
54
Eventos
55
Eventos:Viso Geral
Eventos com durao fixa (time-boxes) : Os eventos com durao fixa so utilizados para criar para criar regularidade, os seguintes eventos tm a durao fixa: - Reunio de Planejamento da Release - Reunio de Planejamento da Sprint, - Sprint, - Reunio Diria, - Reviso da Sprint - Retrospectiva da Sprint. A Sprint: Parte central, ou o corao do Scrum, a Sprint, que uma iterao de um ms ou menos, de durao consistente com o esforo de desenvolvimento. Todas as Sprints utilizam o mesmo modelo de Scrum e todas as Sprints tm como resultado um incremento do produto final que potencialmente entregvel. Cada Sprint comea imediatamente aps a anterior.
Reunio Diria
Sprint
Produto
Product Backlog Verso 2 Jan 2011 | RFS
Sprint Backlog rildo.santos@etecnologia.com.br

56

REUNIO DE PLANEJAMENTO DA RELEASE O propsito do planejamento da release o de estabelecer um plano e metas que a equipe Scrum e o resto da organizao possam entender e comunicar. O planejamento da release responde s questes: - Como podemos transformar a viso em um produto vencedor da melhor maneira possvel? - Como podemos alcanar ou exceder a satisfao do cliente e o Retorno sobre Investimento (ROI) desejados? O Plano da Release, que o artefato resultante dessa reunio, estabelece a meta da release, as maiores prioridades do Product Backlog, os principais riscos e as caractersticas gerais e funcionalidades que estaro contidas na release. Ele estabelece tambm uma data de entrega e custo provveis que devem se manter se nada mudar. A organizao pode ento inspecionar o progresso e fazer mudanas nesse plano da release a cada Sprint. O planejamento da release opcional. Contudo, se a equipe Scrum iniciar o trabalho sem essa reunio, a ausncia de seu artefato aparecer como um impedimento que dever ser resolvido. O trabalho para resolver o impedimento se tornar um item do Product Backlog. Ao se utilizar Scrum, os produtos so construdos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vo adicionando incrementos ao produto. Cada incremento um pedao potencialmente entregvel do produto completo. Quando j tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto entregue. Muitas organizaes j possuem um processo de planejamento de release, e na maior parte desses processos o planejamento feito no incio do trabalho da release e no modificado com o passar do tempo.
57

REUNIO DE PLANEJAMENTO DA RELEASE (continuao)
No planejamento de release do Scrum, so definidos uma meta geral e resultados provveis. Esse planejamento geralmente no requer mais do que 15-20% do tempo que uma organizao costumava utilizar para produzir um plano de release tradicional. No entanto, uma release com Scrum realiza planejamento no momento da execuo de cada reunio de Reviso de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento dirio no momento da execuo de cada Reunio Diria. De forma geral, os esforos para uma release com Scrum provavelmente consomem ligeiramente mais esforo do que os esforos para um planejamento de release tradicional. O planejamento da release requer estimar e priorizar o Product Backlog para a release. H diversas tcnicas para faz-lo que esto fora do alcance do Scrum, mas que apesar disso so teis quando usadas com ele. Artefato resultante dessa reunio: Plano de Release
Plano de Release do Produto

Release #
Viso do Produto
Release #1
Release #2
Release #3
Viso do Planejamento
Product Backlog
Release BurnDown
Sprint #
1
6
58
Reunio diria
Reviso da Sprint
24 horas Viso Produto Backlog Sprint Backlog Sprint 2-4 Semanas Produto
59

REUNIO DE PLANEJAMENTO DA SPRINT A Reunio de Planejamento da Sprint o momento no qual a iterao planejada. fixada em oito horas de durao para uma Sprint de um ms. Para Sprints mais curtas, aloca-se para essa reunio aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeira parte, um evento com durao fixa de 4 horas, o momento no qual decidido o qu ser feito na Sprint. A segunda parte, tambm um evento com durao fixa de 4 horas, o momento no qual a equipe entende como desenvolver essa funcionalidade em um incremento do produto durante a Sprint. Na 1 a equipe Scrum trata da questo: o qu?. O Product Owner apresenta a equipe o que mais prioritrio no Product Backlog. Eles trabalham em conjunto para definir qual funcionalidade dever ser desenvolvida durante a prxima Sprint. As entradas para essa reunio so o Product Back, o incremento mais recente ao produto, a capacidade da equipe e o histrico de desempenho da equipe. Cabe somente a equipe a deciso de quanto itens do Product Backlog ela deve selecionar. Somente a Equipe pode avaliar o que ele capaz de realizar na prxima Sprint.
Meta da Sprint: Uma vez selecionado o Product Backlog , a Meta da Sprint delineada. A Meta da Sprint o objetivo que ser atingido atravs da implementao do Product Backlog. Ela uma descrio que fornece orientao a equipe sobre a razo pela qual ele est desenvolvendo o incremento. A Meta da Sprint um subconjunto da Meta da Release. O motivo para se ter uma Meta da Sprint dar a equipe alguma margem com relao funcionalidade. Por exemplo, a meta para a Sprint acima poderia tambm ser: Automatizar a funcionalidade de modificao de conta de clientes atravs de um middleware seguro capaz de recuperar transaes. Conforme a equipe trabalha, ela mantm a meta em mente. Para satisfazer a meta, elaa implementa a funcionalidade e a tecnologia. Se o trabalho se mostrar mais difcil do que a equipe esperava, a equipe ento ir colaborar com o Product Owner e implementar a funcionalidade apenas parcialmente.
60

REUNIO DE PLANEJAMENTO DA SPRINT (Continuao): Sprint Backlog Na segunda parte da Reunio de Planejamento da Sprint, a equipe trata a questo: como?. Durante as quatro horas seguintes da Reunio de Planejamento da Sprint, a equipe Fazer UI define como transformar o Backlog do Produto selecionado durante a Reunio de Planejamento (o qu) em um incremento pronto. A equipe geralmente comea Fazer as projetando o trabalho. Enquanto projeta, a equipe identifica tarefas. Essas tarefas Tabelas so pedaos detalhados do trabalho necessrio para converter os itens do Product Backlog em software funcional. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas chamada de Sprint Incluir novo cliente Backlog que um artefato do SCRUM. A equipe se auto-organiza para se encarregar e se responsabilizar pelo trabalho contido na Sprint Backlog , tanto durante a Reunio de Planejamento da Sprint quanto no prprio momento da execuo da Sprint. O Product Owner est presente durante a segunda parte da Reunio de Planejamento da Sprint para esclarecer o Product Backlog e para ajudar a efetuar trocas. Se a equipe concluir que ele tem trabalho demais ou de menos, ele pode renegociar os itens do Product Backlog escolhido com o Product Owner. A equipe tambm pode convidar outras pessoas , tais como clientes finais e/ou especialista de negcio, a participarem da reunio para fornecerem conselhos tcnicos ou sobre o domnio em questo. Geralmente, uma equipe nova percebe pela primeira vez se ir ganhar ou perder como uma equipe - no individualmente - nessa reunio. A equipe percebe que deve contar consigo mesmo. Conforme ele percebe isso, ele comea a se autoorganizar para assumir as caractersticas e comportamento de uma verdadeiro equipe. Artefato resultante dessa reunio: Sprint Backlog
consultar cliente
alterar cliente Fazer Testes Unitrios
61
Reunio diria
Reviso da Sprint
24 horas Viso Produto Backlog Sprint Backlog Produto Sprint 2-4 Semanas
62

A SPRINT A Sprint uma iterao. Sprints so eventos com durao fixa. Durante a Sprint, o ScrumMaster garante que no ser feita nenhuma mudana que possa afetar a Meta da Sprint. Tanto a composio da equipe quanto as metas de qualidade devem permanecer constantes durante a Sprint. As Sprints contm e consistem na reunio de Planejamento de Sprint, o trabalho de desenvolvimento, a Reviso da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma aps a outra, sem intervalos entre elas. Um projeto serve para cumprir alguma funo. Em desenvolvimento de software, o projeto utilizado para desenvolver um produto ou sistema. Cada projeto consiste em uma definio do que ser desenvolvido, um plano para desenvolv-lo, o trabalho realizado de acordo com o plano e o produto resultante. Cada projeto possui um horizonte, que o perodo de tempo para o qual o plano vlido. Se o horizonte for longo demais, a definio poder ter mudado, variveis demais podero ter surgido, o risco poder ser grande demais etc. Scrum um framework para projetos cujo horizonte no superior ao perodo de um ms, onde j h complexidade suficiente tal que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser controlada pelo menos a cada ms, e o risco de que o projeto saia de controle ou se torne imprevisvel contido pelo menos a cada ms. As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa faz-lo sob influncia das partes interessadas, da equipeou do ScrumMaster. Sob que tipo de circunstncias pode ser necessrio cancelar uma Sprint? A gerncia pode precisar cancelar uma Sprint se a Meta da Sprint se tornar obsoleta. Isso pode ocorrer se a empresa mudar de direo ou se as condies do mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela no fizer mais sentido dadas as circunstncias atuais, todavia isso deve ser uma exceo. Porm, por causa da curta durao das Sprints, raramente isso faz sentido. Artefato resultante dessa iterao: Parte do produto
63
Reunio diria
Reviso da Sprint
64

REUNIO DIRIA A equipe deve se encontrar diariamente para uma reunio de 15 minutos chamada Reunio Diria. Essa reunio sempre feita no mesmo horrio e no mesmo local durante as Sprints. Durante a reunio, cada membro explica: 1. O que ele realizou desde a ltima reunio diria; 2. O que ele vai fazer antes da prxima reunio diria; e 3. Quais obstculos esto em seu caminho.
As Reunies Dirias melhoram a comunicao, eliminam outras reunies, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rpida de decises e melhoram o nvel de conhecimento de todos acerca do projeto.
O ScrumMaster deve garantir que a equipe realize essa reunio. A equipe responsvel por conduzir a Reunio Diria. O ScrumMaster ensina a equipe a manter a Reunio Diria com curta durao, reforando as regras e assegurando que as pessoas falem brevemente. O ScrumMaster tambm enfatiza a regra de que galinhas no esto autorizadas a falar e nem a interferir de modo algum na Reunio Diria. A Reunio Diria no uma reunio de status. Ela s para as pessoas que esto transformando os itens do Product Backlog um incremento (a equipe), e para mais ningum. A equioe se comprometeu com uma Meta da Sprint, e a esses itens do product Backlog. A Reunio Diria uma inspeo do progresso na direo da Meta da Sprint (as trs perguntas). Geralmente acontecem reunies subsequentes para realizar adaptaes ao trabalho que est por vir na Sprint. A inteno otimizar a probabilidade de que a equipe alcance sua Meta. Essa uma reunio fundamental de inspeo e adaptao no processo emprico do Scrum.
65
Reunio diria
Reviso da Sprint
66

REVISO DA SPRINT Ao final da Sprint, feita a reunio de Reviso da Sprint. Para Sprints de um ms, essa uma reunio com durao fixa de 4 horas. Para Sprints de duraes mais curtas, essa reunio no deve tomar mais do que 5% do total da Sprint. Durante a Reviso da Sprint, a equipe Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanas no Product Backlog feitas durante a Sprint, eles colaboram sobre quais so as prximas coisas que podem ser feitas. Essa uma reunio informal, com a apresentao da funcionalidade, que tem a inteno de promover a colaborao sobre o que fazer em seguida. A reunio inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o que no foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, alm de como esses problemas foram resolvidos. A equipe ento demonstra o trabalho que est pronta e responde a questionamentos. O Product Owner ento discute o Product Backlog da maneira como esse se encontra. Ele faz projees de datas de concluso provveis a partir de vrias hipteses de velocidade. Em seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relao ao que fazer em seguida. A Reviso da Sprint fornece entradas valiosas para as reunies de Planejamento de Sprints seguintes.
67
Reunio diria
Reviso da Sprint
68

RETROSPECTIVA DA SPRINT Aps a Reviso da Sprint e antes da prxima reunio de Planejamento da Sprint, a equipe Scrum tem a reunio de Retrospectiva da Sprint. Nessa reunio, com durao fixa de trs horas, o ScrumMaster encoraja a equipe a revisar, dentro do modelo de trabalho e das prticas do processo do Scrum, seu processo de desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima Sprint. Existem diversas tcnica que so teis em uma Retrospectiva. A finalidade da Retrospectiva inspecionar como foi a ltima Sprint em se tratando de pessoas, das relaes entre elas, dos processos e das ferramentas. A inspeo deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composio da equipe, os preparativos para reunies, ferramentas, definio de pronto, mtodos de comunicao e processos para transformar itens do Product Backlog em alguma coisa pronta. No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as aes de melhoria factveis que ser implementada na prxima Sprint. Essas mudanas se tornam a adaptao para a inspeo emprica.
69
Framework Scrum: Artefatos
Artefatos
70
Scrum tem quatro artefatos principais: - Product Backlog: uma lista priorizada de tudo que pode ser necessrio no produto. - Sprint Backlog: uma lista de tarefas para transformar o Product Backlog , por uma Sprint, em um incremento do produto potencialmente entregvel. Um burndown uma medida do backlog restante pelo tempo. - Release Burndown: Mede o Product Backlog restante ao longo do tempo de um Plano de Release do Produto. - Sprint Burndown: Mede os itens da Sprint Backlog restantes ao longo do tempo de uma Sprint.
71

PRODUCT BACKLOG e RELEASE BURNDOWN Os requisitos para o produto que a equipe est desenvolvendo esto listados no Product Backlog O Product Owner (PO) o responsvel pelo Product Backlog , por sua criao, por seu contedo, por sua disponibilidade e por sua priorizao. O Product Backlog nunca est completo. A seleo inicial para o seu desenvolvimento somente mostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui medida que o produto e o ambiente em que ele ser usado evoluem. O Backlog dinmico, no sentido de que ele est constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e til. Enquanto existir um produto, o Product Backlog tambm existir. O Product Backlog representa tudo que necessrio para desenvolver e lanar um produto de sucesso. uma lista de todas as caractersticas, funes, tecnologias, melhorias e correes de defeitos que constituem as mudanas que sero efetuadas no produto para releases futuras. Os itens do Product Backlog possuem os atributos de descrio, prioridade e estimativa. A prioridade determinada por risco, valor e necessidade. H diversas tcnicas para dar valor a esses atributos. O Product Backlog ordenado por prioridade, os itens com as maiores prioridades devem ter o desenvolvimento imediato. Quanto mais alta sua prioridade, mais urgente ele , mais se pensou sobre ele e h mais consenso no que diz respeito ao seu valor. Os itens do Backlog de maior prioridade, possuem mais informaes e detalhes do que os itens do Backlog de menor prioridade. mais fcil de fazer a estimativa quando existem mais informaes e mais detalhes.
72

PRODUCT BACKLOG e RELEASE BURNDOWN (continuao): Quando um produto utilizado, que seu valor aumenta e que o cliente fornece feedback, o Product Backlog poder se tornar uma lista maior e mais aprofundada. Os requisitos nunca param de mudar. O Product Backlog um documento vivo. Mudanas nos requisitos de negcios, condies do mercado, tecnologia e equipe causam mudanas no Product Backlog. Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. Os itens do Product Backlog que ocuparo a Equipe Scrum pelas vrias Sprints seguintes devero ter granularidade mais fina (mais detalhados), tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da durao da Sprint. Frequentemente, mltiplas equipes trabalham juntas no mesmo produto. Um nico Product Backlog usado para descrever o trabalho a ser realizado no produto. Ento, um atributo que agrupe os itens aplicado no Backlog do Produto. O agrupamento pode ocorrer por conjuntos de caractersticas, por tecnologia ou por arquitetura, e ele frequentemente utilizado como uma forma de se organizar o trabalho por equipe. O grfico de Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints. As estimativas dos itens do Product Backlog so inicialmente calculadas durante o Planejamento da Release, e posteriormente medida que itens forem sendo criados. Durante a preparao do Product Backlog , os itens so revistos e revisados. Entretanto, eles podem ser atualizados em qualquer momento. A equipe responsvel por todas as estimativas. O Product Owner (PO) pode influenciar a equipe, ajudando-o a entender e a escolher as mudanas, mas a estimativa final feita pelo equipe. O Product Owner mantm o Product Backlog e o Release Burndown do Backlog atualizados e publicados todo o tempo. Uma linha de tendncia pode ser traada baseada na mudana do trabalho restante.
73

PRODUCT BACKLOG: Exemplo
Product Backlog
Tema* Venda de Passagem Venda de Passagem Check-in Check-in Programa de Fidelidade Programa de Fidelidade Atendimento ao cliente Atendimento ao cliente Item Vender passagens reas Consulta de disponibilidade de passagens reas Fazer check-in Cancelar Check-in Adeso ao programa de fidelidade Consultar os pontos do programa de fidelidade Fazer registro de comentrios, sugestes e reclamaes dos clientes Responder ao cliente (por email) Prioridade Alta Alta Alta Alta Mdia Mdia Baixa Pontos (estimados) 40 13 40 8 20 5 8
Baixa
Nota: O que Tema ? Tema utilizado para agrupar Estrias do Usurios relacionadas, as estrias so representam o detalhamento dos itens do Backlog, ao usar o conceito de tema, ele poder facilitar as atividades de priorizao e de estimativa. Verso 2 Jan 2011 | RFS rildo.santos@etecnologia.com.br
74

RELEASE BURNDOWN: Exemplo
Release Burndown
150
139
100
Pontos (estimados)
90
Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.
50
52
20 0
Sprint #1
Sprint #2 Sprints
Sprint #13
Sprint #4
75

SPRINT BACKLOG E SPRINT BURNDOWN: A Sprint Backlog consiste nas tarefas que a equipe executa para transformar os itens do Product Backlog em um incremento pronto. Muitas deles so elaboradas durante a Reunio de Planejamento da Sprint. A Sprint Backlog todo trabalho que a equipe identifica como necessrio para alcanar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos. A decomposio deve ser suficiente para que mudanas no progresso possam ser entendidas na Reunio Diria. A equipe modifica a Sprint Backlog no decorrer da Sprint. Quando chega s tarefas individuais, a equipe pode descobrir que mais ou menos tarefas sero necessrias, ou que uma determinada tarefa levar mais ou menos tempo do que era esperado. medida que novo trabalho surge, a equipe o adiciona a Sprint Backlog. medida que se trabalha nas tarefas ou que elas so completadas, as horas estimadas de trabalho restantes para cada tarefa so atualizadas. Quando se verifica que determinadas tarefas so desnecessrias, elas so removidas. Somente a equipe pode modificar a Sprint Backlog durante uma Sprint, pode mudar o seu contedo ou as suas estimativas. A Sprint Backlog um retrato em tempo real altamente visvel do trabalho que a equipe planeja efetuar durante a Sprint, e ela pertence unicamente a equipe.
76

SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo
Na reunio de Planejamento da Sprint, PO dever apresentar a viso do produto, Product Backlog e seus Itens, comentando o nvel de prioridade de cada item. Os membros da equipe devem selecionar os itens com os maiores nveis de prioridades para fazer parte da Sprint.
Estria do Usurio
Titulo: Fazer Check-in
Como cliente de negcio, eu quero fazer check-in pela web para que fique menos tempo em filas. Pontos: ? Prioridade: Alta
A estria do usurio auxilia no entendimento do que deve ser feito, ela permite fazer a estimativa de velocidade da equipe e tambm , utilizada como lembrete e para as atividades de planejamento. Geralmente a estimativa feita em pontos (pontos de estria)
77

SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo Estria do Usurio
Como cliente de negcio, eu quero fazer check-in pela web para que fique menos tempo em filas. Pontos: ?
Prioridade: Alta
Quebrar a estria do Usurio em tarefas: - Para facilitar a estimativa de velocidade da equipe, considere quebrar a estria em tarefas, isto pode fazer que todos os membros da equipe visualizem todas as tarefas que devem ser feitas para implementar o item do backlog. Mas, ainda precisamos estimar os pontos...
Fazer interface do usurio
Impresso do Ticket
Sprint Backlog
Fazer Check-in
Criar Componentes de validao Integrar com Sistema de Reserva
Executar testes unitrios Executar testes de aceitao
A Sprint Backlog um artefato resultante da reunio de Planejamento da Sprint

78
Estimando os pontos da Estria do Usurio:

Uma breve introduo sobre estimativa: Estimar Difcil ? - Estimativa (mundo real) representa um valor aproximado. - Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato.
Contudo, devemos estimar as Estrias do Usurio para saber se elas cabem dentro de uma Sprint. Uma vez que os pontos so estimados eles ajudam a definir a velocidade da equipe, a partir deste parmetro, podemos chegar a concluso se estria cabe ou no dentro da Sprint. Se ela no couber a opo quebrar esta estria em estrias menores.
Exemplo de Estrias do Usurio:

Titulo: Pagamento com Carto de Crdito Quem ? Prioridade: ?
como um cliente
O que ?
Pessoal, qual estimativa para essa estria...
preciso de uma interface de pagamento por carto de crdito que seja intuitiva e fcil de usar. Por que ? Com objetivo de facilitar os pagamentos. Pontos: ?
Product Owner Verso 2 Jan 2011 | RFS rildo.santos@etecnologia.com.br

79

Quando trabalhamos com mtodos geis temos pelo menos duas formas para estimar a velocidade da equipe: Ideal Days e Pontos de Estria. Recomendamos utilizar os Pontos de Estria. Ideal Days: Mais fcil para iniciantes Fcil de explicar
Dias Ideais (Ideal Days)

Baseado na durao de tarefas. - Dias ou horas unidade bem definida, contudo o tempo ideal quase nunca igual ao tempo real... - mais fcil de estimar, mas pode ser tornar difcil de estimar se consideramos todas as interrupes e variaes
Pontos de Estria: Valores relativos Mais abstrato
Pontos de Estria (Story Points) Baseia-se no tamanho da estria influenciado pela: - Nvel de dificuldade, complexidade e experincia ( emprico); Foco nas funcionalidades; O importante so os valores relativos; Pontos so medidas sem unidade; Equipe diferentes podem ter pontos diferentes para a mesma estrias. Principais tcnicas: Opinio de especialista; Analogia; Decomposio (Dividir para conquistar).
80

Estimativa* e o Planning Poker: Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes preciso o escrever as estrias do usurio. O Planning Poker uma prtica que ajuda na estimativa de uma estria ou de uma tarefa e baseada no consenso de toda a equipe. Geralmente o Planning Poker usa um conjunto de cartas com valores especficos que podem representar pontos relativos e praticado como se fosse um jogo de cartas. Os pontos devem estar em uma escala no linear, por e exemplo a Fibonacci: (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala
Jogando o Planning Poker: Antes de comear o jogo necessrio definir um valor de referncia. Por exemplo: Identificar a estria que pode ser atribudo a menor quantidade pontos, esta estria ser utilizada como referncia para pontuao das demais estrias. O PO apresenta uma estria e pede para os membros da equipe fazer a estimativa de velocidade...
1. Rodada
40
100
40
40
Quando todas as cartas estiverem lanadas, elas so viradas e caso no haja consenso nos pontos, as diferenas so discutidas de forma breve, e uma nova rodada acontece at que haja concesso.
N. Rodada
40
40
40
40
Product Owner Verso 2 Jan 2011 | RFS
Equipe rildo.santos@etecnologia.com.br
Equipe
81

SPRINT BACKLOG: Exemplo Estria do Usurio
Como cliente de negcio, eu quero fazer check-in pela web para que fique menos tempo em filas. Pontos: 40
Prioridade: Alta
Planning Poker, estria do usurio e pontos de estria, nada disso faz parte do framework Scrum, contudo so tcnicas e ferramentas complementares ao framework. Elas so altamente utilizadas para fazer a estimativa de velocidade da equipe. E finalmente temos a Sprint Backlog e podemos criar o Sprint Burndonw.
Fazer interface do usurio
Impresso do Ticket
Sprint Backlog
Fazer Check-in
Criar Componentes de validao Integrar com Sistema de Reserva
A Sprint Backlog todo trabalho que a equipe identifica como necessrio para alcanar a Meta da Sprint.
82

SPRINT BACKLOG E SPRINT BURNDOWN:
A Sprint Burndown (ou Burndown ) um grfico da quantidade restante de trabalho do Sprint Backlog em uma determinada Sprint ao longo do tempo da Sprint. Para criar esse grfico, determine quanto trabalho resta somando as estimativas do Backlog a cada dia da Sprint. A quantidade de trabalho restante para uma Sprint a soma do trabalho restante para tudo da Sprint Backlog. Acompanhe essas somas diariamente e utilize-as para criar um grfico que mostre o trabalho restante ao longo do tempo. Traando uma linha atravs dos pontos no grfico, a equipe pode gerenciar seu progresso em completar o trabalho de uma Sprint. A durao no considerada em Scrum. O trabalho restante e a data so as nicas variveis de interesse. Uma das regras do Scrum est ligada ao objetivo de cada Sprint, que ter como resultado incrementos de funcionalidade potencialmente entregveis que estejam de acordo com uma definio de pronto.
Dica: Sempre que possvel, desenhe a Sprint Burndown em um quadro que esteja na rea de trabalho da equipe. mais provvel que a equipe veja um grfico grande e visvel do que um grfico de feito em uma planilha de calculo.
A Sprint Burndown um artefato que deve ser utilizado exclusivamente pela equipe. Se PO tentar fazer a gesto do projeto com base na Sprint Burndown considerado como micro-gerenciamento e que pode levar ao comando-controle... O PO deve fazer a gesto do projeto olhando a Release Burndown.
83

SPRINT BURNDOWN : Exemplo A transparncia, que dos pilares do Scrum, garante que aspectos do processo que afetam o resultado devem ser visveis para aqueles que gerenciam os resultados. O Quadro de Tarefas deixam a Sprint com visibilidade e transparncia.
O Quadro de Tarefas tambm no parte do framework Scrum, ele parte de uma tcnica chamada Gesto Vista, que tem como objetivo facilitar a comunicao e dar visibilidade (transparncia).
84
Framework Scrum: Definio de Pronto
Pronto
85
Definio de Pronto (*DoD):

Uma conversa comum entre o cliente e o desenvolvedor: [Cliente] E a como anda o desenvolvimento da aplicao ? [Desenvolvedor] Est pronta... [Cliente] Isso quer dizer que eu posso implementa-la ? [Desenvolvedor] Bem...ainda no, preciso fazer mais alguns testes... [Cliente] Mas, aplicao no estava pronta..
Definir claramente quando o produto estar pronto, pois: Pronto, para desenvolvedor significa: - Encerrou a codificao... Pronto, para PO significa: - Quando foi entregue... Pronto, para os usurios finais e/ou clientes significa: - Quando o software comeou a funcionar em ambiente de produo...
Evite: A sndrome dos 90% feito (pronto).

86

A Definio de PRONTO
Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregvel, pois o Product Owner (PO) pode optar por implantar a funcionalidade imediatamente. Para isso ser possvel, o incremento deve ser um pedao completo do produto. Ele deve estar pronto. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.
No desenvolvimento de produtos, afirmar que a funcionalidade est pronta pode levar algum a presumir que ela est pelo menos bem codificada, refatorada, que tenha passado por testes unitrios, que tenha sido feito o build e que tenha passado por testes de aceitao. Outros podem presumir que apenas o cdigo tenha sido desenvolvido. Se no houve definio de pronto, os outros dois pilares do controle de processos empricos no funcionam. Quando algum descreve algo como pronto, todos devem entender o que pronto significa. Pronto define o que a equipe quer dizer quando se compromete a aprontar um item de Product Backlog em uma Sprint. Alguns produtos no contm documentao, de forma que sua definio de pronto no inclui documentao. Um incremento completamente pronto inclui toda a anlise, projeto, refatoramento, programao, documentao e testes para o incremento e todos os itens do Product Backlog no incremento. Os testes incluem testes de unidade, de sistema, de usurio e de regresso, bem como testes no-funcionais como de performance, de estabilidade, de segurana e de integrao. Pronto inclui tambm qualquer internacionalizao necessria. Algumas equipes ainda no so capazes de incluir em sua definio de pronto tudo o que necessrio para a implantao. Isto deve estar claro para o Product Owner. Esse trabalho restante dever ser feito antes que o produto possa ser implantado e utilizado.
87

A Definio de PRONTO e NO PRONTO
Algumas organizaes so incapazes de desenvolver um incremento completo dentro de uma Sprint. Elas podem ainda no ter infraestrutura automatizada de testes para completar todos os testes. Nesse caso, duas categorias so criadas para cada incremento: o trabalho pronto e o trabalho no pronto. O trabalho no pronto a poro de cada incremento que ter que ser completada mais tarde. O Product Owner sabe exatamente o que ele est inspecionando ao final da Sprint, porque o incremento atende definio de pronto e o Product Owner entende essa definio. O trabalho no pronto adicionado a um item do Product Backlog o chamado trabalho no pronto, de forma que ele se acumula e isso refletido corretamente no grfico de Release Burndown Release. Essa tcnica cria transparncia no progresso em direo entrega. A inspeo e a adaptao na Reviso da Sprint sero to precisas quanto essa transparncia for. Exemplo: Se uma equipe no capaz de realizar os testes de performance, regresso, estabilidade, segurana e integrao para cada item do Product Backlog, a proporo desse trabalho em relao ao trabalho que pode ser pronto (anlise, projeto, refatoramento, programao, documentao, testes unitrio e testes de usurio) calculada. Vamos supor que essa proporo de seis peas de pronto e quatro peas de no pronto. Se a equipe terminar um item de Product Backlog de seis unidades de trabalho (a equipe est estimando baseado no que ele sabe como aprontar), quatro unidades sero acrescidas ao item do Product Backlog denominado trabalho no pronto quando eles tiverem terminado. Sprint a Sprint, o trabalho no pronto de cada incremento vai se acumulando e deve ser tratado antes da entrega do produto. Esse trabalho acumulado linearmente, embora haja algum tipo de acmulo exponencial que dependente das caractersticas de cada organizao. Sprints so adicionados ao final de cada release para completar o trabalho no pronto. O nmero de Sprints imprevisvel, visto que o acmulo de trabalho no pronto no linear.
88
Exerccios:
Responda Verdadeiro ou Falso para as declaraes: 1 - Quando as regras no so declaradas, espera-se que os usurios de Scrum descubram o que devem fazer. No tente descobrir uma soluo perfeita, porque geralmente o problema muda rapidamente. Ao invs disso, tente algo e veja como se sai. Os mecanismos de inspeo-e-adaptao inerentes natureza emprica do Scrum iro lhe guiar.
] Verdadeiro
] Falso
2 - O ScrumMaster trabalha com os clientes e a gerncia para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor atravs do Scrum. Se eles no souberem, consideramos o ScrumMaster responsvel.
] Verdadeiro
] Falso
3 - O ScrumMaster pode ser um membro da equipe; por exemplo, um desenvolvedor realizando tarefas da Sprint. No entanto, isso frequentemente leva a conflitos quando o ScrumMaster deve escolher entre remover impedimentos ou realizar tarefas.
] Verdadeiro
] Falso
4 - O ScrumMaster nunca deve ser o Product Owner. [ ] Verdadeiro [ ] Falso

89
Exerccios:
Responda Verdadeiro ou Falso para as questes:
5 - O Product Owner pode ser um membro da equipe, trabalhando tambm na realizao das tarefas. Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes interessadas.
[ ] Verdadeiro [ ] Falso
6 Se a equipe sentir que se comprometeu com mais do que podia, ele se encontra com o Product Owner para remover ou reduzir o escopo da Sprint Backlog (itens do Product Backlog selecionado para a Sprint). Se a equipe sentir que sobrar tempo ele pode trabalhar junto ao Product Owner para selecionar mais do itens do Product Backlog. [ ] Verdadeiro [ ] Falso
7- Geralmente, somente 60-70% do total da Sprint Backlog ser definido na Reunio de Planejamento da Sprint. O restante deixado para ser detalhado mais tarde ou so dadas estimativas grandes que sero decompostas mais tarde na Sprint. [ ] Verdadeiro [ ] Falso
8 - Os itens do Product Backlog so comumente representados como Estrias do Usurio. Casos de Uso tambm so apropriados. [ ] Verdadeiro [ ] Falso
90
Exerccios:
Responda Verdadeiro ou Falso para as questes:
9 - Testes de aceitao fazem parte da Estria de Usurio, so utilizados parar substituir descries textuais mais detalhadas com uma descrio testvel.
[ ] Verdadeiro [ ] Falso
10 - O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe Scrum e a organizao tenham decidido usar. As unidades de tempo geralmente so Estrias do Usurio. [ ] Verdadeiro [ ] Falso
91
Contedo:
3 Entendendo SCRUM
4 Estudo de Caso
92
Objetivo:
Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as prticas do SCRUM em projeto de desenvolvimento de Software. Pr-requisito: Conhecimento das prticas Scrum.
93
Estudo de Caso
Estudo de Caso
94
Framework SCRUM
Planejamento da Release
Reunio diria
Reviso da Sprint
24 horas Product Backlog Sprint Backlog Produto Sprint (2-4 Semanas) Viso Legenda: Reunies Artefatos
Reunies
Papis Artefatos Planejamento da Release Planejamento da Sprint Diria Reviso da Sprint Retrospectiva da Sprint Product Backlog Sprint Backlog Sprint Burndown Release Burndown
Product Owner (PO) ScrumMaster (SM) Equipe (time)
Sprint Burndown Release Burndown

95
Estudo de Caso: Viso

Primeiro passo: definir a Viso do Produto.
Reunio diria
Reviso da Sprint
24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Viso Produto
1
96
Estudo de Caso: Viso do Produto

Para definir a viso do Produto, primeiro necessrio entender qual a real necessidade do cliente:
A necessidade: Um hotel, quer incrementar um novo canal de consultas e vendas de reservas de apartamentos. A sugesto foi criar um Portal de Reservas para vender os servios.
Aps entender a necessidade do cliente, hora de definir a Viso do Produto: Declarao da Viso do Produto:
Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line um software baseado na web, intuitivo e fcil de usar que fornece a possibilidade fazer a consultas e reservas de apartamentos. Diferente de outros sistemas, o produto oferece um canal direto de acesso ao cliente.
97

Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog:
Funcionalidades do produto O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver e lanar um produto. A lista deve conter todas as caractersticas, funes, tecnologias, melhorias e correes de defeitos que constituem as mudanas que sero efetuadas no produto para futuras releases . O Product Backlog dinmico, no sentido de que ele est constantemente mudando para identificar o que o produto necessita.
98
99

Exerccio: Podemos fazer a declarao da Viso do Produto sem entender a real necessidade do cliente ?
100
Estudo de Caso: Reunio de Planejamento da Release

Segundo passo: Realizar a Reunio de Planejamento da Release, o resultado desta reunio o Plano de Release e o Release Burndown (artefato Scrum).
Reunio diria
Reviso da Sprint
2
101

O propsito da Reunio de Planejamento da Release o de estabelecer o Plano de Release, as Metas e Release Burndown (que um artefato do Scrum) que a Equipe Scrum e o resto da organizao possam entender e comunicar. O planejamento da release responde s questes: - Como podemos transformar a viso em um produto da melhor maneira possvel? - Como podemos alcanar ou exceder a satisfao do cliente ? - Como podemos alcanar o ROI (retorno sobre investimento) ? O Plano de Release estabelece a meta da release, as maiores prioridades do Product Backlog, os principais riscos e as caractersticas gerais e funcionalidades que estaro contidas na release. Ele estabelece tambm uma data de entrega e custos provveis que devem se manter se nada mudar. A organizao pode ento inspecionar o progresso e fazer mudanas nesse Plano de Release a cada Sprint. O planejamento da release requer estimar e priorizar o Product Backlog para a release. H diversas tcnicas para faz-lo que esto fora do alcance do Scrum (lembre-se o SCRUM framework ele no indica nenhuma tcnica), mas que apesar disso so teis quando usadas com ele.
Release Burndown (artefato)
Entradas
Viso do Produto
Product Backlog (viso inicial) Product Backlog (priorizado)
Sadas
Equipe SCRUM Plano de Release
102
Viso inicial do Product Backlog, antes da reunio de Planejamento da Sprint, ele tem somente as funcionalidades do produto, agrupadas por tema (este agrupamento opcional).
O Plano de Release elaborado nessa reunio. Nesse plano define-se o prazo de entrega do produto e nvel de prioridade dos itens do backlog
O Plano de Release base para atualizao do Product Backlog Agora ele apresenta o nvel de prioridade e quantidade de pontos estimados dos itens. O PO responsvel pela priorizao dos itens e a Equipe responsvel pela estimativa.
2
Plano de Release Releases Nvel de Prioridade Prazo (estimado)
Reserva
3
Promoes Relacionamento ao cliente Programa de Fidelidade Tour Virtual
5 Releases
1 Alto, 3 mdio e 1 baixo
Alto
Mdio
Mdio
Mdio
Baixo
30 dias
15 dias
7 dias
15 dias
15 dias
82 dias
103

Com Product Backlog atualizado e o Plano de Release, o PO poder construir o Release Burndown, que um dos artefatos do SCRUM. As estimativas dos itens do Product Backlog so inicialmente calculadas durante a Reunio de Planejamento da Release. O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.
Release Burndown
120
108 80
Pontos (estimados)
O Product Owner responsvel por manter o Product Backlog e o Release Burndown atualizados e publicados todo o tempo. Uma linha de tendncia pode ser traada baseada na mudana do trabalho restante.
68
40
48
40
20 0
Release #1
Release #2
Release #3 Releases
Release #4
Release #5
104
105

Exerccio: O que aconteceria se a equipe SCRUM no fizer a Reunio de Planejamento da Release ?
106
Estudo de Caso: Reunio de Planejamento da Sprint

Terceiro passo: Realizar a Reunio de Planejamento da Sprint, o resultado desta reunio so os artefatos Sprint Backlog e Sprint Burndown.
Reunio diria
Reviso da Sprint
3
107

Product Backlog: Sistema de Reserva On-Line
A Reunio de Planejamento da Sprint o momento no qual a iterao planejada. No nosso exemplo a durao fixada em 8 horas, pois, a Sprint tem a estimativa de um ms. Essa reunio dividida em duas partes: 1. Parte da Reunio (4 horas): A equipe Scrum trata da questo: o qu?. O PO apresenta a equipe o que mais prioritrio no Product Backlog. Todos trabalham em conjunto para definir qual funcionalidade dever ser desenvolvida durante a prxima Sprint. O Product Backlog est ordenado de acordo com nvel de prioridade dos itens. A equipe deve selecionar o item de maior prioridade e definir qual ser a meta da Sprint.
2. Parte da Reunio (4 horas): A equipe trata a questo: como?. Durante as 4 horas seguintes a equipe define como transformar o item selecionado em incremento do produto pronto e potencialmente entregvel. O PO estar presente para esclarecer dvidas e para ajudar a efetuar trocas, se necessrio. Se a equipe concluir que ela tem trabalho demais ou de menos, ela pode renegociar os itens do Product Backlog escolhido com o PO
108

Detalhando os itens do Produto Backlog em estrias do usurio:
Para facilitar o entendimento dos itens do Product Backlog ele so descritos em estrias do usurio elas auxiliam no entendimento do que deve ser feito, permite fazer a estimativa de velocidade da equipe e tambm , utilizada como lembrete e para as atividades de planejamento. Geralmente a estimativa feita em pontos (pontos de estria)
Como escrever uma Estria do Usurio ? Conversaes sobre a estria, entre os usurios e desenvolvedores, de modo a detalhar o item do Product Backlog e esclarecer todas as dvidas sobre do que deve ser feito.
Estria do Usurio
Titulo: Fazer Reserva de Apartamentos Como cliente de negcio, eu quero fazer reserva de apartamentos pela web para facilitar o meu planejamento.
Carto: Estria do Usurio so tradicionalmente escritas em um carto. Carto podem ter notas, estimativas, comentrio observaes e etc Conversas: Detalhes que podem surgir durante as conversas com PO (Product Owner) e/ou cliente. Confirmao: Testes de aceitao confirmam se a Estria do Usurio foi codificada da forma correta. Testes de aceitao so tipo Caixa Preta.
Pontos: ?
Prioridade: Alta
Boa Prtica: A Estria do Usurio deve prover o entendimento do que deve ser feito e deve facilitar a estimativa de velocidade da equipe.
109

Detalhando as Estrias do Usurio em Tarefas: Estria do Usurio
Titulo: Fazer Reserva de Apartamentos Como cliente de negcio, eu quero fazer reserva de apartamentos pela web para facilitar o meu
planejamento. Pontos: ? Prioridade: Alta
Devemos buscar meios para facilitar a estimativa de velocidade da equipe, quebrar a estria do usurio em tarefas pode fazer que todos os membros da equipe visualizem todas as tarefas que devem ser feitas para implementar a Estria do Usurio. Testes de aceitao devem ser escritos para detalhar melhor a estria do usurio, geralmente eles so escritos no verso do carto.
Tarefas de Negcio Consulta de Reserva de Apartamento Cadastro de Fila de Espera
Tarefas Tcnicas Criar Interfaces Do Usurio Criar Tabelas
Fazer Reserva de Apartamentos
Cadastro de Cliente
Executar testes unitrios
Confirmao da Reserva
Executar testes de aceitao
110

Estimativa e o Planning Poker: Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes preciso o escrever as estrias do usurio. O Planning Poker uma prtica que ajuda na estimativa de uma estria ou de uma tarefa e baseada no consenso de toda a equipe. Geralmente o Planning Poker usa um conjunto de cartas com valores especficos que podem representar pontos relativos e praticado como se fosse um jogo de cartas. Os pontos devem estar em uma escala no linear, por e exemplo a Fibonacci: (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala
Jogando o Planning Poker: Antes de comear o jogo necessrio definir um valor de referncia. Por exemplo: Identificar a estria que pode ser atribudo a menor quantidade pontos, esta estria ser utilizada como referncia para pontuao das demais estrias. O PO apresenta uma estria e pede para os membros da equipe fazer a estimativa de velocidade...
1. Rodada
40
100
40
40
Quando todas as cartas estiverem lanadas, elas so viradas e caso no haja consenso nos pontos, as diferenas so discutidas de forma breve, e uma nova rodada acontece at que haja concesso entre os membros da equipe.
Ensima Rodada
40
40
40
40
Product Owner Verso 2 Jan 2011 | RFS
Equipe rildo.santos@etecnologia.com.br
Equipe
111

Planning Poker, Estria do Usurio e Pontos de Estria, nada disto faz parte do framework Scrum, contudo, so tcnicas e ferramentas complementares ao framework. Elas so utilizadas para ajudar na estimativa de velocidade da equipe. E finalmente temos a Sprint Backlog, mas antes de fazermos o Sprint Burndown, devemos fazer a definio de Pronto.
Estria do Usurio
Titulo: Fazer Reserva de Apartamentos Como cliente de negcio, eu quero fazer reserva de
apartamentos pela web para facilitar o meu planejamento. Pontos: 40 Prioridade: Alta
Tarefas de Negcio Consulta de Reserva de Apartamento Cadastro de Fila de Espera
Tarefas Tcnicas Criar Interfaces Do Usurio Criar Tabelas
Sprint Backlog
Fazer Reserva de Apartamentos
Cadastro de Cliente
A Sprint Backlog todo trabalho que a equipe identifica como necessrio para alcanar a Meta da Sprint.
112

Definio de Pronto: Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregvel, pois o Product Owner (PO) pode optar por implantar a funcionalidade imediatamente. Para isso ser possvel, o incremento deve ser um pedao completo do produto. Ele deve estar pronto. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.
Uma conversa comum entre o cliente e o desenvolvedor: [Cliente] E a como anda o desenvolvimento da aplicao ? [Desenvolvedor] Est pronta... [Cliente] Isso quer dizer que eu posso implementa-la ? [Desenvolvedor] Bem...ainda no, preciso fazer mais alguns testes... [Cliente] Mas, aplicao no est pronta..
Definir claramente quando o produto estar pronto, pois: Pronto, para desenvolvedor significa: - Encerrou a codificao... Pronto, para PO significa: - Quando foi entregue... Pronto, para os usurios finais e/ou clientes significa: - Quando o software comeou a funcionar em ambiente de produo...
Equipe SCRUM: Definiu que o pronto software rodando em ambiente de produo.

113

A transparncia, que dos pilares do Scrum, ela garante que aspectos do processo que afetam o resultado sejam visveis para aqueles que gerenciam os resultados. O Quadro de Tarefas deixa a Sprint com visibilidade e transparncia necessria. Entretanto, o Quadro de Tarefas para o uso exclusiva da equipe, que responsvel pela sua atualizao.
Task Board (Quadro de Tarefas)
Para Fazer
Consulta de Reserva de Apartamento Cadastro de Fila de Espera
Fazendo
Pronto
Pontos 40
Sprint Burndown
30
20 Cadastro de Cliente
10
2 Semanas
Meta da Sprint Entregar a funcionalidade de reserva de apartamentos em 30 dias.

114
115

Esclarecendo algumas dvidas: Por que 40 pontos em uma Sprint de 30 dias ? a primeira vez que a equipe utiliza o SCRUM para o desenvolver um software, logo ela no tem experincia e nem histrico de velocidade de desenvolvimento, que possa ser usado para definir a quantidade de tempo que ela levar para fazer 40 pontos. Para no correr riscos, a equipe optou por trabalhar com uma folga. Com o decorrer das Sprints e novos projetos ser possvel calibrar melhor a velocidade da equipe. O Quadro de Tarefas importante ?
O Quadro de Tarefas (Task Board) tambm no parte do Framework Scrum, ele parte de uma tcnica chamada Gesto Vista, que tem como objetivo facilitar a comunicao e dar transparncia (visibilidade). Lembre-se que a transparncia um dos pilares do SCRUM.
Qual a durao em dias recomendvel quando uma equipe comea a trabalhar com Scrum ? Quando uma equipe comea com o Scrum, Sprints de duas semanas o permite aprender sem cair nas armadilhas da incerteza.
116

Exerccio: O que aconteceria se a equipe considerar que o item do Product Baclog: Os clientes podero fazer reserva de apartamentos um pico ?
117
Estudo de Caso: Reunio Diria

Quarto passo: Aps a reunio de Reunio de Planejamento da Sprint, efetivamente a Sprint comea, o prxima passo so as Reunies Dirias.
Reunio diria
Reviso da Sprint
4
118

A equipe deve se encontrar diariamente para uma reunio de 15 minutos chamada Reunio Diria. Essa reunio sempre feita com as pessoas de p, no mesmo horrio e no mesmo local durante as Sprints. Durante a reunio, cada deve membro explicar: 1. O que foi realizado desde a ltima reunio diria; 2. O que vai ser feito antes da prxima reunio diria; 3. Foi encontrado algum obstculo (impedimento). As Reunies Dirias melhoram a comunicao, eliminam outras reunies, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rpida de decises e aperfeioa o nvel de conhecimento de todos acerca do projeto. O ScrumMaster responsvel por garantir que a equipe realize essa reunio. Contudo, a prpria equipe responsvel por conduzir a reunio. O ScrumMaster deve orientar a equipe a manter a Reunio Diria com curta durao (15 minutos), reforando as regras e assegurando que as pessoas falem brevemente. O ScrumMaster tambm enfatiza a regra de que as pessoas que no participam da equipe no podem SCRUM Master atrapalhar e nem a interferir de modo algum a reunio. Ela s para as pessoas que esto transformando os itens do Product Backlog um incremento (produto), e para mais ningum. A Reunio Diria no uma reunio de status. A equipe se comprometeu com a Meta da Sprint, e os itens do Product Backlog. A Reunio Diria uma inspeo do progresso na direo da Meta da Sprint (as trs perguntas). Geralmente acontecem reunies subsequentes para realizar adaptaes ao trabalho que est por vir na Sprint. A inteno otimizar a probabilidade de que a equipe alcance sua Meta. Essa uma reunio fundamental de inspeo e adaptao no processo emprico do Scrum.
119

Na primeira reunio a Equipe decide qual tarefa vai ser feita primeiro. Aps a escolha da tarefa o Task Board (Quadro de Tarefas) atualizado.
Consulta de Reserva de Apartamento
OK
OK
OK
Equipe
SCRUM Master
Questes: 1. O que foi realizado desde a ltima reunio diria; 2. O que vai ser feito antes da prxima reunio diria; 3. Foi encontrado algum obstculo. rildo.santos@etecnologia.com.br
15 Minutos
120

As reunio se repetem ao longo dos dias e a cada reunio a Task Board atualizado (as tarefas e Sprint Burndown).
O que vai ser feito antes da prxima reunio diria? Comear a tarefa Cadastro de Cliente
O que foi feito desde a ltima reunio diria ? Terminamos a tarefa Consulta de Reserva de Apartamentos...
OK
Foi encontrado algum obstculo ? No
Movimentao do post-it para a coluna: Pronto
Atualizao do Sprint Burndown
OK
Equipe
SCRUM Master
15 Minutos
121

Durante as reunies dirias todos os impedimentos (ou obstculos) identificados so registrados no Quadro de Tarefas. Eles representam um risco a Sprint. O Risco de no se atingir a meta, logo eles devem ser removidos. Geralmente os impedimentos so escritos em Post it de cor rosa.
15 Minutos
OK
OK
OK
?
Encontrei um obstculo (impedimento).
Equipe
SCRUM Master
122
Estudo de Caso: Impedimento

Cabe ao SCRUM Master remover todos os impedimentos, identificados e demonstrados no Quadro de Tarefas, para que estes no afetem o desempenho da equipe nem a meta da Sprint. Caso contrrio, o impedimento poder comprometer a meta e a entrega de valor que deve ocorrer no final da Sprint.
O que um impedimento ? Impedimento tudo aquilo que impede a equipe de realizar seu trabalho e atingir a meta da Sprint. Um impedimento pode ser um problema de rede, falhas no servidor, falta de servidor para testes, a lentido do banco de dados do ambiente de teste ou falta de informao para implementao de uma tarefa.
SCRUM Master
SCRUM Master dever remover este impedimento
Aps remoo do impedimento o SCRUM podemos registrar em base de conhecimento a causa raiz do impedimento, esta informao dever ser utilizada para melhorar o processo, logo ser discutida na Retrospectiva da Sprint.
123

Quando todas as tarefas esto prontas, e a Equipe atualiza o Quadro de Tarefas e o Sprint Burndown.
15 Minutos
OK
OK
OK
OK
Equipe
SCRUM Master
124
125
Reunio de Planejamento da Sprint

Exerccio: O que pode acontecer se um impedimento no for removido ?
Quem pode cancelar a Sprint ?
126
Estudo de Caso: Reunio de Reviso da Sprint

Quinto passo: Aps o final da Sprint (quando todas as tarefas esto prontas) comea a Reunio de Reviso da Sprint. Objetivo primrio desta reunio apresentar ao PO que foi feito durante a Sprint.
Reunio diria
Reviso da Sprint
5
127
Reviso da Sprint: Reunio da Reviso da Sprint

Produto pronto
OK
Product Owner OK OK
4 horas
Equipe
SCRUM Master
Equipe apresenta que foi produzido e faz entrega para PO, que avalia o valor da entrega. PO poder aceitar ou rejeitar a entrega do produto.
128
Reunio de Reviso da Sprint

A Reunio de Reviso da Sprint, para Sprints de 1 ms, essa uma reunio com durao fixa de 4 horas. Para Sprints de duraes mais curtas, essa reunio no deve tomar mais do que 5% do total da Sprint. Durante a Reviso da Sprint, a Equipe Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanas no Product Backlog feitas durante a Sprint, eles colaboram sobre quais so as prximas coisas que podem ser feitas. Essa uma reunio informal, com a apresentao da funcionalidade, que tem a inteno de promover a colaborao sobre o que fazer em seguida. O Product Owner identifica o que foi feito e o que no foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, alm de como esses problemas foram resolvidos. A equipe ento demonstra o trabalho que est pronto e responde a questionamentos. O Product Owner ento discute o Product Backlog da maneira como esse se encontra. Ele faz projees de datas de concluso provveis a partir de vrias hipteses de velocidade. Em seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relao ao que fazer em seguida. A Reviso da Sprint fornece entradas valiosas para as reunies de Planejamento de Sprints seguintes.
129

O Release Burndown atualizado. Lembre-se: O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.
130

Product Backlog atualizado. Lembrem: PO responsvel por manter atualizado Release Burndown e Product Backlog.
131
Estudo de Caso: Reunio de Reviso da Sprint
132

Exerccio: O que aconteceria se PO no aceitasse a entrega ?
Podemos considerar que a entrega da Sprint foi feita mesmo que ela no esteja em conformidade com a definio de Pronto ?
133
Reunio de Retrospectiva da Sprint

Sexto passo: Aps a reunio de Reunio de Reviso da Sprint, realizada a Reunio de Retrospectiva da Sprint. O propsito desta reunio inspecionar como correu a ltima Sprint em se tratando de pessoas, das relaes entre elas, dos processos e das ferramentas.
Reunio diria
Reviso da Sprint
6
134
Retrospectiva da Sprint Reunio Retrospectiva da Sprint

As retrospectivas so a essncia do conceito de Inspeo e Adaptao.
impedimentos
Problemas no Servidor de Teste
SCRUM Master
????
Velocidade da equipe... Equipe
3 horas
Equipe discute o qu deu errado e o qu deu certo... O que precisa ser melhorado para a prxima Sprint
135
Reunio de Retrospectiva da Sprint:

A Reunio de Retrospectiva da Sprint a ltima reunio de uma Sprint.
Nessa reunio, com durao fixa de 3 horas, o ScrumMaster deve encorajar a equipe a revisar, dentro do modelo de trabalho e das prticas do processo do Scrum, seu processo de desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima Sprint. Existem diversas tcnicas que so teis em uma Retrospectiva (por ser um framework Scrum no indica diretamente nenhuma tcnica)
A finalidade da Retrospectiva inspecionar como foi a ltima Sprint em se tratando de pessoas, das relaes entre elas, dos processos e das ferramentas. A inspeo deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composio da equipe, os preparativos para reunies, ferramentas, definio de pronto, mtodos de comunicao e processos para transformar itens do Product Backlog em alguma coisa pronta. No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as aes de melhoria factveis que ser implementada na prxima Sprint. Essas mudanas se tornam a adaptao para a inspeo emprica.
136
Lies Aprendidas, o que deve melhorado para a prxima Sprint:
OK
Consulta de Reserva de Apartamento Cadastro de Fila de Espera
Pontos de Ateno
Velocidade da equipe
O Que Deve Ser Melhorado
=
Atitude: Para uma equipe (time) SCRUM funcionar ser necessrio mudana de atitude, caso contrrio isto poder afetar o desempenho da equipe Ser necessrio mais ateno na hora de estimar as estrias do usurio.
Cadastro de Cliente
Impedimentos:
Problemas no Servidor de Teste
Planejamento: Prestar ateno na hora do planejamento da Sprint, para identificar se todos os recursos necessrio esto disponveis
137
Reunio de Retrospectiva da Sprint
138
Comear nova iterao (nova Sprint)

Repetir o ciclo Scrum:
Reunio diria
Reviso da Sprint
139

Exerccio: O PO deve participar da Reunio de Retrospectiva da Sprint ?
Durante este estudo de caso no foi apresentado as prticas e ferramentas de Engenharia de Software, tais como TDD, SCM e etc, explique o motivo:
140
Quer mais ?
Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos. Comunidade: http://etecnologia.ning.com/

Para participar da comunidade basta se cadastrar: http://bit.ly/czZlez A misso da comunidade compartilhar conhecimento, trocar experincias e prover aprendizado.
141
Referncias
Scrum Guide
Agile Collection (SCRUM, FDD e XP) nova verso
1 Scrum Experience [O Tutorial SCRUM] - Tutorial SCRUM, demonstra as prticas SCRUM para o gerenciamento de projetos de software.
2 SCRUM Product Owner: - Este eBook descreve o SCRUM enfatizando a atuao do Product Owner. apresentado responsabilidades, tcnicas e ferramentas que so utilizadas pelo PO para a garantir o ROI na gesto de projetos g... 3 Engenharia de Software 100% Agil (SCRUM, FDD e XP) - Esta apresentao faz uma demonstrao de como combinar os mtodos geis: SCRUM, FDD e XP para tornar o Ciclo de Desenvolvimento de Software gil, ou seja, a Engenharia de Software 100% gil. 4 Engenharia de Software gil: SCRUM e FDD - SCRUM e o FDD so Mtodos geis que so utilizados para desenvolvimento de software. Fizemos uma pequena demonstrao de como utilizar o SCRUM e FDD (Featured Driven Development) 5 Escrevendo Estrias do Usurio Eficazes - Este tutorial demonstra como "escrever as estrias do usurio de forma eficaz." tambm apresentado as principais tcnicas, boas prticas e ferramentas. 6 Workshop Como Criar, Estimar, Priorizar e Manter o Product Backlog - Este tutorial demonstra como usar as melhores prticas e tcnicas para "Como criar, estimar, priorizar e manter o Product Backlog". 7 Workshop SCRUM Product Owner - Delrio de PO em dia de Vero Esta apresentao sobre o SCRUM Product Owner que aborda prticas, ferramentas e responsabilidades do PO. Tambm demonstrado como os "delrios" do PO pode afetar negativamente os membros da equipe e o resultado do projeto.
142
Licena:
143
Notas:
Marcas Registradas: Todos os termos mencionados que so reconhecidos como Marca Registrada e/ou comercial so de responsabilidades de seus proprietrios. O autor informa no estar associada a nenhum produto e/ou fornecedor que apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde j o autor informa que o uso apenas ilustrativo para fins educativo, no visando ao lucro, favorecimento ou desmerecimento da marca ou produto. Melhoria e Reviso: Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problema ou erro envie um e-mail para ns. Criticas e Sugestes: Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favor envie um e-mail para ns. Imagens: Google, Flickr e Banco de Imagem.
Rildo F dos Santos (rildo.santos@etecnologia.com.br)

144
O Tutorial Definitivo
www.etcnologia.com.br
Rildo F Santos
(11) 9123-5358 (11) 9962-4260
rildo.santos@etecnologia.com.br twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/

Scrum

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Scrum

Diunggah oleh

Hak Cipta:

Format Tersedia

verso 2 | Jan 2011

SCRUM, O Tutorial Definitivo

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

SCRUM, O Tutorial Definitivo

1 Desafios do desenvolvimento de Software 2 Sobre o SCRUM

SCRUM, O Tutorial Definitivo

Objetivo: O Scrum um Mtodo gil para execuo de qualquer projeto ou trabalho.

Programa: Menos Papel, Mais rvores

SCRUM, O Tutorial Definitivo

Facilitador: Rildo F. Santos (@rildosan)

SCRUM, O Tutorial Definitivo

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

SCRUM, O Tutorial Definitivo

1 Desafios do desenvolvimento de Software 2 Sobre o SCRUM

SCRUM, O Tutorial Definitivo

SCRUM, O Tutorial Definitivo

Desafios do Desenvolvimento de Software

SCRUM, O Tutorial Definitivo

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

2. Desafio: Falha na Comunicao das equipes de TI

SCRUM, O Tutorial Definitivo

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

3. Desafio: Entender as necessidades dos clientes

SCRUM, O Tutorial Definitivo

4. Desafio: Compreender por que os projetos falham:

Informao errada 13%

SCRUM, O Tutorial Definitivo

Requisitos incompletos 12%

Mudana de Requisitos 12% Falta de conhecimento tcnico 7%

37% das falhas esto relacionadas com requisitos

Verso 2 Jan 2011 | RFS

5. Desafio: Identificar o que necessidade e o que desejo Uso de funcionalidades do Software

SCRUM, O Tutorial Definitivo

As vezes 16% Raramente 19%

Verso 2 Jan 2011 | RFS

6. Desafio: Aumentar produtividade da equipe de desenvolvimento: Satisfao dos Clientes

SCRUM, O Tutorial Definitivo

Como aumentar a produtividade da equipe de desenvolvimento de software ?

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

A falta de produtividade pode afetar o negcio

SCRUM, O Tutorial Definitivo

7. Desafio: Escolher framework certo para desenvolver software ?

UP SCRUM, O Tutorial Definitivo

SCRUM, Lean, ASD, XP, FDD...

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

8. Desafio: Como reter os bons profissionais ?

SCRUM, O Tutorial Definitivo

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Por que precisamos dos Mtodos geis ?

SCRUM, O Tutorial Definitivo

Para enfrentar estes desafios:

Utilizao de mtodos geis, como SCRUM, pode amenizar estes problemas.

Verso 2 Jan 2011 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

SCRUM, O Tutorial Definitivo

- Sempre precisam do software funcionando para ontem

Desenvolvedores: - No sabem ou no querem conversar com o cliente