Workshop Scrum Agenda

Transcrição

1

2 Scrum na sua empresa A verdade sobre projetos Scrum Visão Geral Escalando Scrum Sprints O papel de Time Workshop Scrum Agenda O papel de ScrumMaster Visibilidade O papel de Product Owner Release Planning Product Backlog Sprint Planning Reuniões

3 Exercício O que colaborou para que seus projetos tenham sido bem sucedidos? O que colaborou para que seus projetos tenham sido mal sucedidos?

4 Chaos Report O Standish Group vem, há mais de uma década, realizando estudos em volta dos resultados dos projetos de software ao redor do mundo. O resultado destes estudos é um relatório batizado de Chaos Report;

5 Chaos Report Segundo o Standish Group quais foram os principais fatores para esta melhora?

6 Chaos Report Segundo o Standish Group quais os principais fatores para um número ainda tão alto de projetos que não alcançam seu objetivo? A vasta maioria dos projetos de software falha por falta de clareza sobre responsabilidades e requisitos e também por inabilidade para acompanhar o que ocorre em cada um dos diferentes passos do ciclo de vida da aplicação.

7 Isso parece familiar?

8 Uso de funcionalidades Média de uso de funcionalidades de sistemas 45% 7% 13% 16% 19% Sempre Frequentemente Às vezes Raramente Nunca Standish Group, 2010

9 Resumindo... A comunicação entre as partes envolvidas nos projetos é muito fraca; A visibilidadedo andamento real e dos problemas existentes nos projetos é muito fraca; Clientes pedem sempre mais do que realmente precisam; Os projetos são caros e, ainda em sua maioria, não alcançam sucesso; Os conflitos existentes entre TI e negócios durante os projetos são muitos;

11 O que é Scrum? Nova versão do Scrum? Mais de 100 modelos de relatórios Vídeos How to Sell Scrum por Ken Schwaber Ferramenta Scrum+ Management 2.0 Check-lists para avaliar o seu nível de maturidade com Scrum 50 horas de suporte técnico

12 O que é Scrum? É um processo interativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto; É mais um framework que uma metodologia, mais atitute que um processo;

13 Scrum é... Processo empírico de gerenciamento e controle; Inspeção e adaptação em loops de feedback; Entrega frequente de funcionalidades com valor para o cliente; Escalável a projetos distribuídos e grandes

14 O que não é Scrum? SCRUM,but...

15 Atividade: O melhor Plano Tabela de Valores Passo Curto R$ 20,00 Passo Longo R$ 40,00 Virada R$ 10,00

16 O Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: Indivíduos e interação entre eles mais queprocessos e ferramentas Produto em funcionamento mais quedocumentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais queseguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda."

17 Processos ágeis e Scrum

18 Papéis no Scrum

19 Papéis no Scrum Product Owner Responsável por garantir o ROI (Retorno de Investimento); Responsável por conhecer as necessidades do(s) cliente(s); Proxy emambientescom maisde um cliente; ScrumMaster Responsável por remover os impedimentos do time; Responsável por garantir o uso de Scrum; Protege o time de interferências externas; Time Definir metas das iterações; Auto-gerenciamento; Produzir produto com qualidade e valor para o cliente;

20 Responsabilidades de cada papel Atividade Responsável Responsabilidades Gerenciar a Visão Product Owner O Product Owner estabelece, nutree comunica a visão do produto. Ele consegue o investimento inicial e de andamento para o projeto através da criação de um Plano de Releases e de um Product Backlog inicial Gerenciar o ROI Product Owner O Product Owner monitora o projetoatravés das metas de ROI e da visão de investimento. Ele atualiza e prioriza o Product Backlog para assegurar que a funcionalidade mais valioza seja Gerenciara Sprint de desenvolvimento Time desenvolvida primeiro. Ele prioriza e refina o Product Backlog e mede sucesso vs. despesas. Duranteuma Sprint o time seleciona e desenvolve as funcionalidaes de maior prioridade no Product Backlog. Coletivamente, o time expande os itens do Product Backlog em pequenas tarefas, criando assim o Sprint Backlog., e depois gerencia o seu próprio trabalho. Gerenciar o processo ScrumMaster O ScrumMaster é responsável por direcionar otime para o sucesso assegurando-se que o projeto e a cultura organizacional estão otimizadas para atender os objetos do ROI. Isto envolve a organização de uma reunião de planejamento e de uma reunião de revisão, a proteção do time de influências externas, a otimização das reuniões diárias e a remoção de impedimentos. Gerenciar a entrega Product Owner O Product Owner toma a decisão sobre quando criar uma entrega oficial. Por uma série de razões pode não ser desejável entregaro produto na conclusão de cada incremento.

21 Estrutura do Scrum Product Owner ScrumMaster Time

22 Estrutura do Scrum O Product Owner define a Visão do Produto. Esta Visão é o que representa sua necessidade, é o que deve ser satisfeito ao fim do projeto; Para definir esta Visão o PO colhe informações junto a clientes, usuários final, time, gerentes, stakeholders, executivos, etc.;

23 Estrutura do Scrum O PO cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do projeto seja bem sucedida; Esta lista de necessidades é chamada de Product Backlog.

24 Estrutura do Scrum O PO cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do projeto seja bem sucedida; Esta lista de necessidades é chamada de Product Backlog; O ScrumMaster deve auxiliar o PO na elaboração desta lista.

25 Estrutura do Scrum No início de cada iteração (Sprint) o time deve se reunir para realizar a Planning Meeting; Nesta reunião o time realizará o planejamento do que será entregue ao final do ciclo da Sprint (que deve ser de 2 a 4 semanas).

26 Estrutura do Scrum Na primeira parte da Planning Meetingo PO deverá: definir a meta da Sprint e falar para o time sobre os Itens mais prioritários do Product Backlog; O time deve estimar os Itens em tamanho (caso ainda não estejam estimados) e selecionar o que acredita que possa ser feito durante a Sprint. Essa lista selecionada chama-se Selected Product Backlog; O facilitador desta reunião é o ScrumMaster.

27 Estrutura do Scrum Na segunda parte da Planning Meeting o time deverá colher mais detalhes dos Itens do Selected Product Backlog e decompô-los em tarefas, gerando assim o Sprint Backlog; Para isso pode ser necessária a ajuda de Especilistas de Domínio; Após a decomposição, cada membro do time deve selecionar as tarefas que deseja executar durante a Sprint (sempre negociando com o time) e estimá-las em horas; O facilitador desta reunião é o ScrumMaster.?

28 Estrutura do Scrum Durante a execução da Sprint, valem as práticas de engenharia definidas para o projeto; O ScrumMaster, através da sua capacidade de liderança e colaboração, facilita o trabalho do time removendo os impedimentos encontrados e garantindo a boa aplicação do Scrum; Durante a Sprint o time pode sentir necessidade de consultar Especistas de Domínio, ou mesmo o Product Owner;.

29 Estrutura do Scrum Diariamente o time realiza uma reunião de 15 minutos (Daily Meeting) na qual cada membro deve responder: O que fiz desde a última reunião? O que pretendo fazer até a próxima? Tive (estou tendo) algum impedimento? Através desta reunião o time ganha visibilidade de como está o caminho para a meta e planeja o dia seguinte de trabalho; O ScrumMaster novamente é o facilitador, e deve lembrar-se que a reunião é para o time e não para ele.

30 Estrutura do Scrum Ao final da execução da Sprint deve ser realizada a Review Meeting,reunião que tem como propósito apresentar o que foi feito para o Product Owner e convidados; O time é quem realiza a apresentação, que deve ser feita no formato de demo; Product Owner avalia se a Meta da Sprint foi alcançada; Product Owner faz anotações que poderão se tranformar em novos Itens para o Product Backlog.

31 Estrutura do Scrum A última cerimônia de um Sprint Scrum é a Retrospectiva; Reunião de lições aprendidas, facilitada pelo ScrumMaster, na qual o time deve avaliar: o que foi bom na última Sprint? O que deve ser melhorado? Quem está no controle? Esta reunião representa o espírito de Inspeção- Adaptação dentro do Scrum; É uma reunião do time, mas caso seja de acordo de todos seus membros o PO também pode participar.?

33 Conceito de Sprint A Sprint é um time-box de 2 a 4 semanas no qual o time do projeto irá produzir uma parte do produto definida pelo cliente O conceito de Sprint nos remete à necessidade de estarmos frequentemente entregando algo de valor para o cliente. Uma Sprint deve ser empreendida por um time multi-disciplinar com não mais que 9 membros Cada Sprint deve ter uma meta específica que represente o desejo do cliente para aquele time-box específico

34 Entregas Sushi x Entregas Sashimi

35 Diálogo: Definindo pronto O que significa pronto para você em um projeto? Você concorda com essa definição? Por que? Quais problemas você percebe com essa definição de pronto? Como você pode corrigir isso?

36 Incremento do produto Ao final de cada Sprint, o time deve ter produzido um incremento potencialmente entregável do produto Com alta qualidade, testado, completo e pronto Potencialmente entregável entregável S1 S2 S3 S4 S1, S2, S3 e S4 são produtos potencialmente entregáveis R1 R1 é um entregável!

37 Uma Sprint deve ser SMART Specific Específico Measurable Mensurável Achivable Atingível Realistic Realista Timed Datado

38 Sempre entregar valor! Sempre entregar valor para o cliente ao final de cada Sprint Nunca esquecer: o deadline é sagrado, as funcionalidades é o que podem variar Se houver necessidade de incluir tarefas técnicas, arquiteturais, estudos, ou qualquer tipo de tarefa que não forneça valor visível para o cliente: fazer balanceamento entre estas tarefas e as com alto ROI

39 Itens com ROI visível Sempre entregar valor! Itens técnicos, arquitetura... S1 S2 S3 S4 S5 S6

40 Tamanho de Sprints O tamanho ideal de uma Sprint é o tamanho que seu time e cliente achar ideal. Encontre o seu! Observe: Mudança constante no topo do Product Backlog: ideal trabalhar com Sprints curtos Dificuldade de entregar valor para o cliente ao fim das Sprints: ideal trabalhar com Sprints curtos Time e/ou cliente exaustos com loopstão curtos: ideal trabalhar com Sprints longos

41 Tamanho do Release O Product Owner é quem possui a visão de qual o período ideal para distribuir uma nova versão do produto Observe: Não adianta entrega produto tão rapidamente de forma a tornar impossível o acompanhamento de atualização do cliente Um Release deve ser algo integrado e de grande valor para o cliente

42 Sem mudanças durante a Sprint O que o time se comprometeu a entregar e o que foi acordado com o Product Owner é o que deve ser entregue Quando mudar o conteúdo da Sprint se torna regra: Cliente deixa de sentir necessidade de fazer um planejamento de qualidade, bem como de estar atento a uma boa composição e priorização do Product Backlog; afinal, se pode mudar a qualquer momento, para que se preocupar com isso? Time ignora meta, afinal com certeza ela mudará Time perde foco e motivação Stress impera

43 Parando a Sprint antes da sua finalização Umas Sprint pode ser terminada antes da sua finalização nas seguintes situações: O time sente que não conseguirá atingir a meta O Product Owner percebe que mudanças em fatores externos influenciarão diretamente no valor da meta da Sprint Caso uma Sprint seja cancelada deve se iniciar imediatamente o planejamento da próxima Sprint

45 ScrumMaster revela a realidade A maioria dos projetos entregam software a cada 6 a 18 meses. Scrumreduzisso a muitas entregas mensais que incrementam o controle via inspeção e adaptação. Isto permite ao time e a organização, maior visibilidade, expondo problemas e limitações, ou seja, expondo o que está por trás da janela suja. O trabalho do ScrumMaster é priorizar estes problemas e ajudar a organização a superá-los, gerenciando investimentos e garantindo o seu retorno.

46 Responsabilidades do ScrumMaster Um ScrumMaster deve: Remover a barreira entre desenvolvimento e cliente Ensinar o cliente a maximir o ROI e atingir seus objetivos através do Scrum Melhorar o dia-a-dia dos membros do time facilitando a criatividade e fortalecimento Priorizar os impedimentos e combatê-los Auxiliar o Product Owner com o Product Backlog Garantir o uso do Scrum Facilitar reuniões

47 Diálogo: Como membro do time! Quais seriam alguns dos desafios que um ScrumMaster iria ter caso ele também fosse um membro do time? O que poderia ajudar a superar estes desafios?

48 Um dia na vida de um ScrumMaster Se assegure que todo mundo está fazendo o que se comprometeu a fazer Determine onde Scrum está, comparado com onde poderia estar e atualize seu próprio Product Backlog Trabalhe no Product Backlog com o Product Owner Use todos os seus sentidos, inclusive bom senso

49 E lembre-se! Um ScrumMaster inútil é um ScrumMaster morto...você acha que pode ser feliz morto?

51 Responsabilidades do Product Owner Um Product Owner deve: Definir a visão do produto (product vision); Gerenciar o retorno de investimento (ROI); Apresentar ao time os requisitos necessários para a entrega do produto; Priorizar cada requisito de acordo com seu valor para o negócio/cliente; Gerenciar a entrada de novos requisitos e suas priorizações; Planejar entregas (releases); Atuar como facilitador quando mais de um cliente estiver envolvido no projeto; Garantir que Especialistas de Domínio estejam disponíveis para o time;

52 Recursos utilizados pelo Product Owner Product Vision Box: Materializar a idéia do produto/projeto a ser elaborado

53 Recursos utilizados pelo Product Owner Remember the Future: Mapear passos que serão necessários para chegar ao objetivo

54 Product Owner dentro do Taxi

56 Por que não apenas especificar? Assumimos que há um nível avançado de conhecimento de tudo Alto consumo de tempo para escrever e ler; um tédio para escrever Trata o aprendizado do cliente como mudança de escopo Difíceis de se adequarao desenvolvimento iterativo e incremental

57 Documentação substitui a comunicação? Original by Alistair Cockburn

58 Qual o propósito dos Backlog Itens?...representar os requisitos do cliente mais que documentá-los.

59 Product Backlog O primeiro passo em um projeto Scrum é de responsabilidade do Product Owner, que deve articular a visão do produto; O Product Backlog representa esta visão, ele deve ser apresentado no formato de uma lista com itens priorizados e ordenados de acordo com o valor que representampara o cliente e negócio; O Product Backlog irá existir por todo o ciclo de vida do projeto e é regularmente atualizado pelo Product Owner para refletir as necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias, enfim...mudanças; Um Product Backlog é composto de vários tipos de itens: funcionalidades, requisitos de desenvolvimento, exploração técnica, estudo, documentação, bugs, etc.

60 A engenharia do Product Backlog

61 O nível certo de priorização

62 User Stories

63 Os três C s da User Story Card ( Cartão) Conversation ( Conversas) Confirmation (Confirmação)

64 Uma UserStorydeve ser

65 Alexandre Magno, CST - fevereiro.2009story-writing Workshop

66 Story-Writing Workshop Story-Writing Workshops são reuniõesque incluem desenvolvedores, usuários, cliente e product owner; Durante este workshop os participantes escrevem a quantidade de estórias que conseguirem; Prioridades não são associadas; Bons workshops combinam os melhores elementos de brainstorming e prototipação de desenho;

67 Atividade: Story-writing Workshop Uma empresa de taxi aéreo deseja elaborar um site onde seja possível ao seus clientes realizar a compra de bilhetes, pesquisar vôos, realizar Check-in on-line e pesquisar serviços relacionados como hotéis e shows

68 Story-Writing Workshop Home-page Pesquisa vôos Check-in on-line Pesquisar serviços relacionados Compra bilhetes Paga pela compra Reservar lugares Pesquisar hotéis Pesquisar shows

69 Quem? Como um <PERFIL> eu posso/gostaria/devo <FUNCTION> para <VALOR AO NEGÓCIO> O que? Como um INSTRUTOR eu devo APONTAR A LISTA DE PRESENÇA DOS ALUNOS para MANTER AS INFORMAÇÕES DO TREINAMENTO ATUALIZADAS Por que?

70 Story-Writing Workshop Como um cliente de negócios eu posso realizar check-in on-line para acelerar meu embarque Como um cliente de turismo eu posso reservar hotel para fazer uma compra conjunta Como um cliente eu posso pesquisar vôos para visualizar as informações que necessito Como um agente de viagens eu posso reservar lugares para dar um diferencial no atendimento a meus clientes Como um cliente de turismo eu posso comprar ingressos para shows para fazer uma compra conjunta

71 Observações Em um projeto ideal nós devemos ter uma única pessoa responsável pelo trabalho de priorização das estórias; Uma característica marcante de projetos stories-driven é que clientes e usuários estão comprometidos no projeto em toda sua duração; User stories devem ser compreensíveis por todos: usuários, cliente e time de desenvolvimento; Uses stories evitam interpretações de documentação

72 Teste de aceitação Uma das melhores formas de se expressar em uma estória alguns dos detalhes discutidos entre cliente (Product Owner, Especialista de Domínio,...) é a escrita de Testes de Aceitação; Como um usuário eu posso exportar dados em XML para poder integrar minhas informações com outros sistemas Testar abrir no Microsoft Excel o arquivo exportado;

73 Teste de aceitação Testar com Visa, MasterCard e Aura (passar) Como um cliente cadastrado eu posso pagar meu bilhete com cartão de crédito para agilizar minha compra Testar com cartões expirados (falhar) Testa com valores acima do limite (falhar) Testar com cartão de pessoa física (falhar)

74 Teste de aceitação - Prática Escrever Testes de Aceitação antes da codificação; O cliente é quem deve especificar Testes de Aceitação; Teste DEVEM fazer parte do processo; Automatização de Testes de Aceitação Script de Testes Alguns tipos de testes Teste de Interface; Teste de Usabilidade; Teste de Performance; Teste de Stress;

75 Stories, Temas e Epics EPIC STORY STORY STORY STORY STORY STORY STORY STORY STORY TEMA STORY STORY STORY STORY STORY

76 Diálogo: User Stories( Estórias) As Estórias são apropriadas para o seu ambiente de trabalho? Quais os desafios você visualiza para utilizá-las? Quais as vantagens que você visualiza em utilizálas?

78 Daily Meeting (Reunião Diária) O que fiz desde a última reunião? O que pretendo fazer até a próxima; Estou tendo impedimentos?

79 Diálogo: Daily Meeting Vocêacreditaqueumareuniãodiáriade 15 minutos pode atrapalhar seu time? Por que? Quais os ganhos que seu time pode obter realizando uma reunião diária? Que ações você, como ScrumMaster, poderia tomar para fazer com que seu time tivesse reuniões diárias de qualidade?

80 As armadilhas das reuniões diárias Reunião diária não é coffee-break Reunião diária não é bate-papo Reunião diária não é conversa sobre a relação Reunião diária não é julgamento

81 Review Meeting Apresentação do resultado da iteração para os clientes Todos os envolvidos no projeto participam

82 Consequências da Review Meeting Devolver ao Product Backlog funcionalidades não terminadas e repriorizá-las Remover do Product Backlog funcionalidades que foram finalizadas antecipadamente Repriorização do Product Backlog Solicitaro fechamentode um Release com as funcionalidadesdemonstradas, sozinhasoucom o incremento de Sprints anteriores Escolher não avançar mais com o projeto e não autorizar outra Sprint Solicitar que o progresso do projeto seja acelerado autorizandoa inclusãode times adicionaisparatrabalharno Product Backlog

83 Retrospectivas Melhoria de processos no final de cada Sprint Falicitada pelo ScrumMaster O que foi bom? O que deve ser melhorado? O ScrumMaster prioriza os itens citados de acordo com a direção do time O time propõe soluções para a maioria dos problemas que a atrapalham/irritam Retrospectivas são a essência do conceito de inspeção e adaptação

84 O que foi bom? O que deve melhorar? O que foi bom? O que deve melhorar?

85 Quem está no controle? Time Empresa Time Empresa Impediments Backlog

87 Sprint Planning Meeting A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em duas partes, e entra em cena no início de cada Sprint. Além de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser convidados a participar em determinados momentos da reunião, desde que agreguem valor à mesma e tenham seu convite aprovado pelo Product Owner. Pela prática, percebemos que a duração desta reunião segue a seguinte tabela:

88 Velocidade Velocidade é uma medida da produtividade do Time; Representa a taxa de trabalhoque o Time conseguiu completar durante um Sprint; Serve de guia para o planejamento de Sprints. Serve de guia para o planejamento de Releases e progresso do projeto.

89 Atividade: Velocidade Quantas em 1 minuto?

90 Planejamento por velocidade Parte I Parte II Ajuste de prioridades Identificar a meta da Sprint Selecionar Itens do Backlog Quebra Itens em tarefas Determinar velocidade Estimar tarefas

91 Planejamento por compromisso Se compromete; ainda pode fazer mais Ajuste de prioridades Identificar a meta da Sprint Selecionar um Item do Backlog Quebra Itens em tarefas Estimar tarefas Não se compromete Pergunte se time se compromete Remove o Item Se compromete; mas não consegue incluir mais nada Finaliza Sprint Planning

92 Resultado do planejamento de Sprint Itens Tarefas

94 Planejamento de Release Continua planejando Releases até que a Visão do produto seja alcançada Selecionar um tamanho de Sprint Determinar as condições de satisfação Estimar os Itens do Backlog Estimar velocidade Selecionar Itens e data do Release Priorizar User Stories

95 Estimando o Product Backlog O esforço estimado para os itens do Product Backlog deve ser negociadoentre o time e o Product Owner, sempre praticando o bom senso; Existem diversas técnicas de estimativas que podem ser utilizadas em projetos Scrum. O Planning Poker é uma das mais populares, onde, através de cartas com numeração seguindo a tabela de Fibonacci, os membros do time sugerem um tamanho (size) para os itens do Product Backlog.

96 Estimando o Product Backlog 0 1/

97 Atividade: Planning Poker Baseado na Story-Writing efetuada para a empresa de Taxi aéreo. Realizar a medição de cada Item/Atividade a ser realizada. Utilizar o método do Planning Poker

98 Por que o Planning Poker funciona? Apresenta múltiplas opiniões de especialistas quanto à estimativa de um item; Estimula o dialogo durante as reuniões, e cada membro do time tem a oportunidade de explicar para todos os outros membros o porque estimou o item com aquele tamanho. Todo este processo gera compartilhamento de conhecimento; Estudos mostram que estimas feitas em grupo vem sendo mais bem sucedidas que estimativas individuais;

100 Scrum Board (Kanban)

101 Sprint Burndown

102 Sprint Dashboard

103 Project Burndown

104 Definição de Artefatos Todos os artefatos e documentação requeridos por sua empresa estão totalmente definidose são conhecidospelo time de desenvolvimento?senão, o seguinte trabalho deve ser feito antes de entregar muitos incrementos: Definir TODA a documentação e artefatos que são parte de cada incremento de funcionalidades do produto, sempre respeitando a cultura da empresa

106 Times Scrum Regras de etiqueta de times Scrum: Nunca usam a palavra você porque a outra pessoa pode se sentir no centro do problema e agir na defensiva Nunca se remete a uma história ( Há três meses atrás você disse que... ) Seja pontual nas reuniões; se atrasar peça desculpas e pague uma penalidade Se todo mundo está falando ao mesmo tempo, use algum objeto para determinar quem fala. Aquele que está com o objeto fala, o resto escuta A opinião de todos é importantee precisa ser entendida e levada em consideração Sem palavrões

107 Critérios de sucesso para times Scrum Times pequenos Missão clara Liderança apropriada Todos os papéis necessários: ScrumMaster, Analista de Negócios, Tester, Desenvolvedor, etc. Bom entendimento das necessidades do cliente Garantia de que os recursos e pessoas necessárias estão disponíveis Auto-gerenciamento fluente Práticas de engenharia e de outras disciplinas presentes

108 Um típico time Scrum

109 Times que atingem meta devem celebrar!

111 Escalando Scrum Quando há a necessidade de escalar: Tipos de aplicação e sistemas complexos; Tamanho de time; Localização do trabalho a ser executado; Duração;

112 Como frameworks ágeis escalam?! Múltiplas equipes Backlog do produto inicial Requisitos funcionais Requisitos não-funcionais Requisitos por etapas, e de escalabilidade o resto dos requisitos funcionais e não-funcionais Backlog do produto Requisitos funcionais Requisitos não-funcionais

113 Seis práticas ágeis que escalam Time de componente para: definições, build e testes Dois níveis de planejamento e tracking Releases pequenos e mais freqüentes Testes concorrentes Integração contínua com outros sistemas Regular ajustes e adaptação

115 Diálogo: Scrum na sua empresa Quais forças irão colaborar com a adoção de Scrum na sua empresa? Quais os desafios que você identifica que Scrum encontrará para ser bem sucedido na sua empresa? Quais benefícios você visualiza que sua empresa terá ao utilizar Scrum? E seu time? E você?

116 Nossa estratégia #1 : VISÃO #2 : CULTURA #3 : PLANEJAMENTO #4 : EXECUÇÃO #5 : INSPEÇÃO/ADAPTAÇÃO

117 Lembre-se O pessimista vê dificuldade em cada oportunidade; o otimista vê oportunidade em cada dificuldade." (Winston Churchill)

118 Obrigado! Twitter.com/addtechnologies Facebook.com/addtechnologies Rio de Janeiro Rua da Ajuda, 35 / 16º e 24º andares Centro Rio de Janeiro RJ CEP: Tel.: São Paulo Av. Brigadeiro Luis Antônio, 2482 / 5 andar Jd. Paulista São Paulo SP CEP: Tel.: