Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Mini-curso Scrum

No description
by

priscila nesello

on 1 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Mini-curso Scrum

1. Estimar Histórias de Usuário ou itens do Backlog do Produto, um tipo por vez:
Tipo de interação
Regras de negócio
Número de entidades manipuladas
Dados a serem lidos, criados, atualizados e excluídos (create, read, update e delete ou CRUD). Como resolver isso? Apresentações Características
Métodos àgeis MINI-CURSO SCRUM:
GESTÃO ÁGIL DE PROJETOS Cerimônias e Artefatos San Francisco Budapest Equipe Multifuncional (cc) photo by Metro Centric on Flickr (cc) photo by Franco Folini on Flickr (cc) photo by jimmyharris on Flickr Stockholm (cc) photo by Metro Centric on Flickr Adaptabilidade:
Habilidade e capacidade de adaptação rápida do processo para atender e reagir a mudanças de última hora nos requisitos e/ou no ambiente, ou a situações ou riscos não previstos inicialmente. Iteratividade:
Envolve vários ciclos curtos, dirigidos por características do produto, nos quais certo conjunto de atividades é completado em poucas semanas; estes ciclos são
repetidos muitas vezes para refinar as entregas. Discussão em grupo: Por que Métodos Ágeis?

Por que os projetos terminam com sucesso? Programa e Planejamento Como o Scrum funciona Dinâmica Aluna do Curso de Mestrado em Administração da Universidade de Caxias do Sul (2012);
Professora da FTEC Faculdades (2011);
Membro do PMI-RS, Gerente de Projetos Profissional (PMP), certificada pelo PMI (2011);
MBA em Administração da Tecnologia da Informação - ATI pela UNISINOS-RS (2010);
Coordenadora da Área de Gestão de Projetos e Sistemas de Informação e Escritório de Projetos da empresa MAIUS Tecnologia Ltda. (2008).
Contato: @pnesello / pri.nesello@gmail.com
Fone: 54-8134-5231 Priscila Nesello
1. Introdução aos Métodos Ágeis
Processos empíricos e definidos, o Manifesto Ágil, conceitos de valor, interação e iteração, o desenvolvimento Enxuto (Lean) e os desperdícios dos projetos;

2. Iniciando um Projeto Ágil e User Stories
Concepção / Iniciação Ágil; Visão do Projeto; escrevendo User Stories;

3. O Framework Scrum
O ciclo de vida; Papéis do Scrum: Product Owner, Scrum Master, Team; Cerimônias: Planning, Daily Scrum, Review, Retrospective; Artefatos: Product Backlog, Sprint Backlog, Gráfico de Burndown;

4. Princípios da Gestão e Auto-Organização (Self-Organizing Teams)
Equipes de Alta Performance como fator de sucesso para o Scrum; a Liderança Participativa do Scrum Master;

5. Simulação de Scrum, o trabalho em equipe
Atingindo resultados por meio das equipes;

6. Estimativas e Métricas Ágeis
Fundamentos; Estimando em Story Points; Pontos, Velocidade e Prazo; Planning Poker; Estimando a velocidade; Inspeção e Adaptação das Estimativas;

7. Simulação de Scrum, projeto real
Vivenciando a experiência do Scrum;

8. Conclusão
Perspectiva do uso do Scrum no Brasil e no mundo, principais dificuldades, resistências, dicas, estratégias para vender projetos com Scrum internamente na sua empresa, alinhamento com o PMBOK. Programa Planejamento - Dia 02 (manhã):
Item 1 - 3 Programa
- Dia 02 (tarde):
Item 4 - 6
Dinâmica (Item 5)
- Dia 09 (manhã):
Dinâmica (Item 7)
Conclusão (Item 8) Horários:
8:00 às 12:00hs e 13:00 às 17:00hs
Intervalo:
10:00 e 15:00hs (15 minutos 15 min
Agrupar sucessos e fracassos em categorias Sucesso Fracasso Compare Grupo 1 Grupo 2 Grupo 3 Clientes Pessoas Processos “Um método para ser caracterizado ágil, deve apresentar, em um grau
adequado ao contexto de desenvolvimento de software em que se insere, as
características de adaptabilidade, incrementalidade, iteratividade, colaboratividade,
cooperação, orientação à pessoas, parcimônia (leanness) e restrição de prazo.” O periódico britânico The Economist (27 de novembro de 2004 p. 71), cita estimativas do Standish Group, que

"... 30% de todos os projetos de software são cancelados, quase metade vem em relação ao orçamento, 60% são considerados fracassos pelas organizações que os iniciaram, e 9 em cada 10 vêm no final." Quantos dos problemas encontrados se enquadram em... • http://agilemanifesto.org/
• http://www.mountaingoatsoftware.com/scrum
• http://www.xprogramming.com/xpmag/whatisxp.htm Colaboratividade:
É uma atitude entre membros da equipe de desenvolvimento, entre os quais se encoraja a comunicação para disseminar informação e apoiar integração rápida de incrementos. Cooperação:
Interação aberta e com proximidade entre os vários stakeholders (especialmente entre cliente e desenvolvedores); o cliente deve tomar parte ativa no processo de
desenvolvimento e prover feedback de forma regular e frequente. Orientação a pessoas:
Favorecimento de pessoas sobre processos e tecnologias; desenvolvedores são
encorajados a aumentar sua produtividade, qualidade e desempenho; a
comunicação e a cooperação dentro das equipes de desenvolvimento são
consideradas fundamentais e necessárias. As reuniões diárias em pé e os workshops de reflexão dão às pessoas a chance de manifestar suas preocupações. Incrementalidade:
Não tentar construir o sistema todo de uma só vez; o sistema é partido em incrementos (pequenas releases com novas funcionalidades) que podem ser desenvolvidos em paralelo em ciclos rápidos; quando o incremento é completado e testado, ele é integrado ao sistema. Parcimônia:
Eliminação de perdas ou habilidade de fazer mais com menos recursos;
característica que o processo ágil tem, de requerer o mínimo necessário de
atividades para mitigar riscos e alcançar metas; deve-se remover todas as atividades desnecessárias no processo de desenvolvimento. Restrição de Prazo:
Estabelecimento de limite de tempo para cada iteração programada. Grandes volumes de desenvolvimento são quebrados em múltiplas entregasque possam
ser desenvolvidas incremental e concorrentemente de modo previsível. Outras:
Transparência ou clareza ;
Auto-organização,
Emergência;
Períodos de reflexão e introspecção;
Incorporação de feedback rápido;
Modularidade;
Convergência;
Equipes pequenas;
Testes constantes;
Equipes locais,
Cortesia. José Fortuna Abrantes, Guilherme Horta Travassos Uma vez que a qualidade global do software também depende do seu processo de desenvolvimento, a necessidade de um processo organizado de produção torna-se importante.
Modelos de processos, tais como CMMI evoluíram ao longo dos anos com este foco - "fornecer às organizações os elementos essenciais de processos efetivos que, finalmente, melhoram o seu desempenho".
Ao longo dos anos, pode-se perceber que as formas iterativas de desenvolvimento e métodos ágeis são mais eficazes para uma melhor entrega.
E nos últimos tempos, tem havido uma mudança considerável para adotar modelos ágeis mais leves, como Scrum e Kanban sobre modelos de processos pesados e prescritiva, como RUP.
Prescritiva significa que há regras a seguir, e os adaptativos têm regras menos a seguir. Os métodos ágeis são leves, uma vez que são menos exigentes do que os métodos tradicionais de processo de software. Mesmo dentro ágil, os modelos mais leves e menos prescritivo estão se tornando mais populares, naturalmente, porque eles são mais adaptáveis às nossas necessidades organizacionais e parecem ser mais eficazes e fáceis de aprender e praticar do que os com mais regras. Processos Prescritivos X Adaptativos Manifesto Ágil:
Em 2001, um grupo de especialistas em software se reuniu no resort Snowbird, em Utah, para rascunhar o que ficou conhecido como Manifesto Ágil (www.agilemanifesto.org):

"Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a fazê-lo. Ao longo deste trabalho começamos a valorizar:
indivíduos e interações em vez de processos e ferramentas;
software funcional em vez de negociação de contrato;
colaboração com o cliente em vez de negociação de um contrato;
respostas à mudança em vez de seguimento de um plano.
Ou seja, mesmo havendo valor nos itens da direita, valorizamos mais os itens da esquerda." Fundamentos Scrum Forma de reiniciar o jogo, seja após um incidente, seja depois que a bola saiu de jogo. A idéia é manter o jogo (desenvolvimento de software) rolando. Por que as equipes às vezes falham com Scrum? 1. Profissionais desacostumados a metodologia;
2. Projetos tão complexos a ponto de precisar de técnicas mais avançadas que reduzam sua complexidade para que seja possível controlá-lo;
3. Empresas despreparadas para o Scrum ou suas equipes não sabem como usar segundo as restrições atuais da empresa. Modelos de processos: os dois extremos da escala não parecem funcionar bem. [©2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.] Declaração de Interdependência:
Enquanto o Manifesto Ágil lida com desenvolvimento de software, a "Declaração de Interdependência" (Declaration of Interdependence, ou DOI) da Gestão de Projeto Ágil, que outro grupo de especialistas elaborou em 2005, focaliza mais o gerenciamento de projetos (http://pmdoi.org):

"Somos uma comunidade de líderes de projeto que tem sido altamente bem-sucedida em entregar resultados. Para alcançar tais resultados:
aumentamos o retorno do investimento, tornando o fluxo contínuo de valor o nosso foco;
entregamos resultados confiáveis, engajando os clientes em interações frequentes e propriedade compartilhada;
esperamos incertezas e gerenciamos levando-as em conta, por meio de iterações, antecipação e adaptação;
promovemos criatividade e inovação reconhecendo que os indivíduos são a fonte última de valor e criamos um ambiente em que eles fazem a diferença;
impulsionamos o desempenho por meio do compromisso do grupo em obter resultados e da responsabilidade compartilhada pela eficácia do grupo;
melhoramos a eficácia e a confiabilidade por meio de estratégias situacionais específicas, processos e práticas." Fundamentos [©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.]
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
3. Entregar software funcionando com frequencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. Além desses quatro valores, o Manifesto Ágil tem doze princípios: Origem do Scrum Historicamente, o termo Scrum surgiu em um artigo publicado por Hirotaka Takeuchi e Ikujiro Nonaka na Harward Business Review de 1986. Nesse artigo entitulado "The new new product development game" ("O novo novo jogo do desenvolvimento de produtos"), Takeuchi e Nonaka descreveram uma abordagem holística, na qual equipes de projeto são compostas de pequenas equipes multifuncionais, trabalhando com sucesso rumo a um objetivo comum, que os autores compararam à formação Scrum do rugby. Origem do Scrum Origem do Scrum Enquanto trabalhava na construção de uma ferramenta de Análise e Projeto Orientados a Objetos (Object-Oriented Analysis and Design, ou OOAD), Jeff Sutherland, então vice-presidente de engenharia da Easel, Inc., percebeu que sua equipe de software precisaria de uma versão aprimorada do Desenvolvimento Rápido de Aplicações (Rapid Application Development, ou RAD).
O que ele queria era um processo semelhante ao Scrum, em que, ao final de iterações curtas, o CEO da Easel pudesse ver a demonstração de código funcional em vez de gráficos Gantt em papel. Hirotaka Takeuchi Ikujiro Nonaka Jeff Sutherland Durante este mesmo período, Ken Schwaber estava pesquisando ativamente sobre como poderia ajudar sua empresa, Advaced Development Methods (ADM), a melhorar seu processo de software com objetivo de aumentar a produtividade das equipes.

Após profunda análise de como outras vendedoras de software independentes (Independent Software Vendors, ou ISV) bem-sucedidas contruíriam softwares, Ken percebeu que o processo de desenvolvimento de todas elas era semelhante, no sentido de que todas usavam processos empíricos e exigiam inspeção e adaptação constantes. Ken Schwaber A pedido da Object Management (OMG) em 1995, Jeff e Ken trabalharam em conjunto para resumir o que haviam aprendido ao longo dos anos; eles criaram uma nova metodologia, que foi chamada de Scrum, descrita em um artigo de Schwaber, "Scrum and the perfet storm" ("Scrum e a tempestade perfeita"), disponível em www.controlchaos.com/my-articles. Conceitos Iteração: 1. Influência recíproca de dois ou mais elementos.
2. Fenômeno que permite a certo número de indivíduos constituir-se em grupo, e que consiste no fato de que o comportamento de cada indivíduo se torna estímulo para outro. Interação: 1. Repetição. 1. Um projeto é considerado bem sucedido se for entregue no prazo, dentro do orçamento e com os atributos e funcionalidades originalmente previstos;

2. Um projeto é considerado fracassado se for cancelado antes de sua finalização ou se nunca for utilizado após à sua conclusão; e

3. Um projeto é considerado contestado se for entregue depois do prazo, acima do orçamento ou com menos atributos e funcionalidades do que originalmente previstos. Sobre
Projetos: User Histories Vantagens do Scrum http://www.dicionariodoaurelio.com/ http://www.dicionariodoaurelio.com/ http://blog.scrumhalf.com.br/2011/02/o-scrum-como-instrumento-de-sucesso-em-cenario-adverso/ Periodicamente o The Standish Group, um instituto de pesquisa americano que atua no mercado de TI, publica o relatório “CHAOS Summary report”. O mais recente, de abril de 2009, mostra números preocupantes.
O relatório apontou em 2009:
apenas 32% dos projetos foram considerados bem sucedidos;
enquanto 24% foram classificados como fracassados; e,
os restantes 44% ganharam o status de contestado.

Em um artigo publicado em 30 de junho de 2009, a Computerworld descreve que de 2006 (ano do penúltimo relatório) para 2009 o número de projetos bem sucedidos diminuiu de 35% para 32%, de projetos fracassados aumentou de 19% para 24% e de contestados diminuiu de 46% para 44%. Jim Johnson, presidente do The Standish Group na época, explica que a recessão econômica contribuiu de três formas para isso:

1. Nesse cenário há redução de orçamentos e as organizações ficam mais propensas a cancelar projetos que evoluem mal.
2. A redução do quadro de funcionários nas empresas, tanto dentro do departamento de TI quanto fora, também contribuiu para os números do relatório do Standish Group, porque sobrecarregou gerentes de projetos e stakeholders de negócio, diminuindo o tempo gasto por essas pessoas em atividades importantes para projetos serem exitosos.
3. A recessão aumenta a aversão das empresas a risco. Por isso elas exageraram no número de check-points e verificações para garantir a aderência às melhores práticas de governança de desenvolvimento em TI. http://blog.scrumhalf.com.br/2011/02/o-scrum-como-instrumento-de-sucesso-em-cenario-adverso/ Desperdício Estudo do The Stadish Group conclui (Chaos Report 2002):
Pesquisa sobre a utilização das funcionalidades do software... Mais de 64% de um sistema de software quase nunca é utilizado. Como ganhar dinheiro resolvendo problemas que você não conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se divertindo)? Um mecanismo de redução de risco: todos nós somos responsáveis pelo planejamento e execução de projetos, sabemos a importância de reduzir o nível de risco ou incerteza a zero, ou para o menor possível;
Um ciclo de vida de desenvolvimento de software mais enxuto;
Um processo de gestçao de projeto mais adaptativo. Diferentemente do processo sequencial usado dentro do ambiente em cascata, que considera a estabilidade do projeto como sua fundação, no Scrum a mudança é considerada a única constante;
Uma estrutura de processo da gestão e desenvolvimento de projeto baseado na motivação e no orgulho das pessoas. Mais do que tudo, talves este seja um dos princípios mais importantes da metodologia Ágil e do Scrum. Cartão de História Segundo Passo:
Coletar requisitos para o Backlog de Produto Perguntas:
Quais são os objetivos ou metas de negócio?
Por que você necessitaria desse novo produto de software? Exemplo: Primeiro Passo:
identificar os stakeholders e seus objetivos Específico: todos terão o mesmo entendimento do que são os objetivos;
Mensurável: podemos determinar objetivamente se os objetivos foram alcançados;
Alcancável: Os stakeholders concordam sobre o que são os objetivos;
Realista: devemos ser capazes de realizar os objetivos do projeto com os recursos que temos;
Baseadas em tempo: daremos tempo suficiente para realizar os objetivos SMART Objetivos e métricas dos stakeholders.
Métricas podem ser critérios como redução dos gastos (30%), número de chamadas de serviço (35%) ou número de usuários registrados (35%). Técnica: Floresta
(Produto) Árvores Galhos Folhas (Histórias) Consistente: um requisito consistente nao entra em conflito com outro requisito;
Inequívoco: os revisores de uma declaração de requisito devem ser capazes de extrair a mesma interpretação deça, independente de seus papéis;
Testável: devemos ser capazes de criar casos de teste para um requisito. Se um requisito não for testável, tentar determinar se ele está implementado de forma correta torna-se uma questão de opinião;
Factível: deve ser possível implementar cada requisito dentro das capacidades e limitações conhecidas do ambiente de sistema;
Independente: nenhuma história de usuário (PBI) deve depender de outra história de usuário . Coleta visual de Requisitos para o Backlog de Produto Durante este passo você se reunirá com os usuários que representam os stakeholders, cada um em seu papel específico para tentar entender as necessidades de alguns dos usuários e transformá-las em requisitos do novo produto de software. CUTFIT Da mesma forma que o Product Owner pode usar as regras SMART para verificar os objetivos dos stakeholders, ele e a equipe podem usar as regras CUTFIT, para identificar se suas histórias ou PIBs (Product Backlog Itens), estão escritas de maneira apropriada, prontas para que a equipe de desenvolvimento possa estimá-las e desenvolvê-las. As árvores e a floresta Você para de escrever a história quando:
1. o usuário não consegue decompor essa história em outras histórias ponta a ponta, ou seja, histórias que abranjam todas as camadas da aplicação;
2. a equipe consegue derivar tarefas dessas histórias, variando de 4 a 8 horas, para começar o trabalho de desenvolvimento;
3. a equipe consegue começar a estimar os pontos dessa história utilizando a técnica baseada em critérios, para estimar o número de pontos da história. Fronteiras do Produto Serviço ao Cliente Desenvolvedores Árvore de Gerenciamento de Sala Árvore de Gerenciamento de Usuário Árvore de Gerenciamento de Reserva Galho Novo de Gerenciamento de Usuário Galho Atual de Gerenciamento de Usuário Incluir uma sala;
Excluir uma sala Editar cobrança;
Cancelar conta;
Cadastro Reservar uma sala;
Cancelar uma sala FLORESTA (PRODUTO)
Produto de Software para Reserva de Sala Privada ÁRVORES
1. Gerenciamento da sala
2. Gerenciamento do usuário
3. Gerenciamento da resera GALHOS
2.1 Gerenciamento de usuário atual
2.2 Gerenciamento de usuário novo FOLHAS
3.1 Incluir uma sala; 1.2 Excluir uma sala;
2.1.1 Editar informações de cobrança;
2.1.2 Cancelar conta; 2.2.1 Cadastro
3.1 Reservar uma sala; 3.2 Cancelar uma sala PRIORIZAÇÃO Os stakeholders vão querer focalizar primeiro as histórias de usuário que trouxerem o maior valor para sua empresa ou unidade de negócio. Depois que essa decisão é tomada, um cartão de história, pode ser usado para descrever algumas das tarefas de alto nível que os usuários gostariam de realizar com todos os casos de teste ("verificar se...") que devem ser realizados para essa história de usuário: Na posição de usuário, devo ser capaz/desejo [...], o que ajuda a [objetivos]
Tarefas: _________________
Verificar: ________________
Verificar: ________________ Conceitos Ciclo de vida do Scrum Escanear figuras:
pg 48 e 49 Escanear pg. 42 Equipe composta de:
um Scrum Master;
um Product Owner (Dono do produto);
Equipe de Desenvolvimento (Equipe). Com todas as habilidades necessárias (como coleta de requisitos, projeto, codificação e teste para construir o produto de software. Scrum Master Product Owner Trabalha com as partes interessadas para definir o Backlog de Produto e para ser responsável pelos resultados do negócio
Coleta requisitos para o Backlog de Produto
Colabora com o ScrumMaster e a equipe para fazer o Planejamento de Releases e o Planejamento das Sprints
Colabora com o ScrumMaster para proteger a equipe de distúrbios externos
Guia e treina a equipe no sentido de alcançar as metas do Planejamento de Realeses e do Planejamento das Sprints
Acompanha de perto o progresso do projeto
Fica responsável para dar feedback à equipe A Equipe de Desenvolvimento Se auto-gerencia e se auto-organiza
Responsável por estimar, por conta própria, os itens do Backlog ou as histórias de usuário
Tem o poder de transformar itens do Backlog de Produto, ou histórias de usuário, em tarefas nas quais possam trabalhar
Fica de olho no progresso do projeto
Responsável por demonstrar os resultados do Sprint para o Product Owner e partes interessadas, ao final de cada sprint Serve como guardião da estrutura de processo do Scrum
Guia e treina a equipe no sentido de alcançar as metas dos lançamentos e dos Sprints
Trabalha com o Product Owner para proteger a equipe de distúrbios externos
Ajuda a ficar de olho no progresso do projeto, conforme necessário, para auxiliar a equipe
Organiza a Retrospectiva da Sprint para ajudar a equipe de Scrum a melhorar seu desempenho nos processos e no projeto Figura pg. 42 1. Product Owner: responsável por obter informações dos stakeholders, ou usuários que os representem para elaborar uma lista de requisitos e criar um Backlog de Produto. Costumam ser coletados como histórias de usuário curtas, durante um workshop de um ou dois dias, anteriormente à reunião de Planejamento das Realeses (Planejamento de Lançamentos) e à reunião de Planejamento de Sprints. O objetivo-chave do Planejamento das Realeses é permitir que a equipe de Scrum identifique todos os lançamentos que o produto de software deve ter, com uma agenda de entregas prováveis. Duração do
Planejamento de Realeses:
quatro horas no caso de uma equipe de Scrum com Sprints de quatro semanas. 2. Além do Planejamento de Realeses a equipe de Scrum também deve passar por alguns Planejamentos de Sprints;

Durante a primeira parte da reunião, o Product Owner percorrerá os requisitos, na forma de histórias de usuário, para decidir, com o feedback da equipe, quais deveriam fazer parte de quais Sprints e quais são seus objetivos. A primeira reunião serve para responder à questão "O quê". Duração do
Planejamento de Sprints:
em torno de oito horas, no caso de Sprints de quatro semanas, e deve ser ajustada para quatro horas no caso de Sprints de duas semanas. 3. Durante a segunda parte da reunião de Planejamento de Sprints, que focaliza o "Como", a equipe de desenvolvimento tentará identificar as tarefas "tasks" a partir das histórias previamente escolhidas e deduzir quanto tempo (em horas) a equipe levará para transformar essas tarefas em incrementos de produto potencialmente entregáveis.

A menos que a equipe utilize algum tipo de software de planejamento, todas as tarefas de desenvolvimento que fazem parte do Sprint normalmente são registradas em um Quadro de Tarefas (Task Board), algum tipo de quadro-branco em uma parede, para fácil alocação e rastreamento por parte da equipe. notes Cerimônias e Artefatos Tão logo as reuniões de Planejamento de Realeses e Planejamento de Sprints tenham terminado, inicia-se o trabalho propriamente dito dos Sprints, como os 15 minutos do Daily Scrum (Scrum Diário) e Daily Standup (algo como Reunião Diária em Pé). 4. Originalmente, a Reunião Diária poderia durar até cerca de 30 minutos, mas, como parte da evolução ou ajuste do Scrum, sua duração poder ser cada vez mais reduzida, podendo chegar aos 15 minutos. Duração de uma Sprint:
de uma a quatro semanas. 5. Antes do final de cada Sprint, a equipe se reunirá com o Product Owner, como parte do Mecanismo de Inspeção e Adaptação do Scrum que é conhecido como Revisão de Sprint, organizada pelo Scrum Master. Duração da Revisão de Sprints:
quatro horas, no caso de um Sprint de quatro semanas, duas horas, no caso de um Sprint de duas semanas. 6. Logo após a Revisão do Sprint, mas antes do Sprint seguinte, a Equipe de Scrum também se reunirá para percorrer uma Retrospectiva do Sprint. Diferentemente dos processos tradicionais, em que o gerente do projeto é responsável por organizar reuniões de status semanais para acompanhar o status do projeto, no Scrum a equipe se reunirá todo dia, não para inspecionar o estado do projeto, e sim, para inspecionar o progresso da equipe rumo ao objetivo do Sprint. Para manter o registro do progresso da equipe rumo ao objetivo do Sprint, um Gráfico de Burndown (Gráfico de Consumo) será criado. Mesmo que a criação desse Gráfico de Burndown seja responsabilidade da equipe, pode ser atualizado pelo Scrum Masters sempre que não tiver tempo para isso. Objetivo:
1. Discutir o que foi e o que não foi feito (Equipe e Product Owner)
2. Demonstrar para o Product Owner aquilo que foi feito e obter o seu feedback.
3. Obter atualizações do Product Owner relativas a quaisquer mudanças na direção do mercado ou do produto. Objetivo:
identificar o que funcionou e o que não funcionou durante o Sprint atual. A intenção é ver como os participantes poderiam tornar sua colaboração ainda mais eficaz ao seguir para o próximo Sprint de duas semanas. RESUMO Princípios da Gestão e Auto-Organização (Self-Organizing Teams) NADA É MAIS IMPORTANTE EM UM PROJETO SCRUM DO QUE FAZER OS MEMBROS DA EQUIPE TRABALHAREM BEM EM CONJUNTO. Mesmo que se tenha o suporte da gerência e consiga reunir o melhor Backlog de Produto possível, ainda assim poderá falhar caso os membros de sua equipe não trabalhem bem em conjunto. Se os membros da equipe de um projeto não se entendem e nada é feito a respeito disso, percebemos que quase sempre o projeto termina em problemas. Isso se aplica a projetos tradicionais, mas principalmente ao projeto Ágil ou Scrum, já que essas duas estruturas de projeto dependem maciçamente do auto- gerenciamento e da prestatividade da equipe. Social: amizade, amor, camaradagem Segurança, Proteção dos perigos Fisiologia ou Necessidades Básicas:
comida, ar, água Hierarquia de necessidades de Maslow Autoestima Autorealização As camadas de autoestima e autorealização, são as camadas nas quais os gurus da metodologia Ágil e os especialistas em Scrum se baseiam para que uma equipe tenha o poder de realizar seu trabalho e de se autogerenciar. O Grupo Um grupo não tem objetivo comum que unirá os indivíduos; nenhum objetivo pelo qual poderão ser responsabilizados. Sempre que um projeto falha, quando não se deve a outras razões, poderá muito bem ser porque a equipe do projeto tem trabalhado no âmbito de grupo, não se sentindo responsável por algo em conjunto. A Equipe Quando um grupo de pessoas se reúne para atingir um objetivo em comum, inicia-se uma equipe. O fato de a equipe ter um desempenho alto ou baixo dependerá de sua capacidade de trabalar em conjunto como uma equipe auto-organizada, além de depender das pessoas que a lideram no ambiente tradicional de comando e controle. O conceito de “curva de performance da equipe” foi desenvolvido por KATZENBACH, Jon R. & SMITH, Douglas K. (1994).
Segundo estes autores, “a equipe real trata-se de um pequeno número de pessoas com conhecimentos complementares, que se encontram igualmente compromissadas com propósito, metas e abordagens de trabalho comuns, pelos quais permanecem mutuamente responsáveis”. Para que uma equipe tenha um bom desempenho é necessário seguir alguns passos: Tenha habilidades de Comunicação:
• Seja breve: nada de prolixidade;
• Evite os “achismos”, podem transmitir insegurança;
“Se está claro para mim, deve estar claro para você também”.
Essa suposição é uma grande barreira ao êxito da comunicação. Tome cuidado com as palavras....
Combinações: não usar as palavras e os termos:
EU ACHO
ALGUMA DUVIDA? ENTENDERAM? Tenha habilidade de Saber ouvir..
Ouça sem interromper, principalmente quanto estiver em desacordo.
Dê ao outro a oportunidade
e se expressar até o fim.
Não antecipe ao que o outro
vai dizer, mesmo que tenha
certeza do fim. Tenha habilidade de dar e receber Feedback:
Feedback é o processo de fornecer dados a uma pessoa ou grupo ajudando-o a melhorar seu desempenho no sentido de atingir seus objetivos. Seja Assertivo!!

Assertividade é a capacidade das pessoas em declarar ou afirmar algo de maneira positiva e franca, é dizer / fazer as coisas que precisam ser ditas e feitas. O não assertivo Tipos de Pessoas O Assertivo Dá respostas adequadas à situação ou pessoa com quem se comunica. Sua meta é atender a si e ao outro, de modo a se sentir bem. Usa a comunicação direta e aberta. É sincero e congruente. Coloca, frequentemente, os outros em primeiro lugar. Faz dessa atitude uma forma de manter a sua infelicidade e inferioridade. Confunde dizer sim ou não com gostar e não gostar. Teme ser rejeitado se disser não e acaba assumindo mais compromissos. Os cinco estágios da equipe Decisão por minoria:
Algumas pessoas envolvidas na situação consideram o problema, tomam a decisão e os demais a acatam. Decisão por maioria
Mais da metade das pessoas envolvidas na situação toma a decisão e esta é aceita por todos do grupo. Decisão individual
Uma pessoa, normalmente o chefe, toma a decisão e os outros envolvidos na situação a acatam. Decisão por consenso
A decisão por consenso é um método de solução de problemas e/ou aproveitamento de oportunidades em equipe.
As pessoas envolvidas debatem as questões inerentes à decisão, agregando o conhecimento e a experiência de todos. USE A TOMADA DE DECISÃO POR CONSENSO Tipos de Tomada de Decisão: Estabelecendo as Regras do Jogo: São expectativas de como os participantes de uma equipe devem se comportar ou não. Elas informam quais comportamentos são importantes e quais são desestimulados. As regras do jogo informam aos membros da equipe “como devemos fazer”. Portanto, a eficácia da equipe depende:
• do grau com que as regras do jogo encontram-se alinhadas com os objetivos e valores da equipe e da Organização;
• do grau com que as regras do jogo aprimoram os processos da tarefa e do relacionamento. Todos os membros devem estar envolvidos diretamente no estabelecimento destas regras Equipes de alto desempenho são... Divertidas Receptivas Solícitas Equipes de Baixo desempenho caracterizam-se por... Silêncio nas reuniões Sorrisos Forçados Atitude de fachada Os membros de uma equipe de desempenho médio apenas seguem o fluxo diariamente, fazendo apenas o que é necessário para permitir que as horas passem e sejam pagos por isso, mas não agregam nenuma tipo de valor à empresa. Diferentemente de um projeto tradicinal que usa o estilo de comando e controle, a equipe é auto-organizada no Scrum.
Isso significa que membros da equipe têm o poder de decidir por conta própria como gostariam de interagir no trabalho. Ninguém, nem mesmo um gerente do projeto, dirá à equipe o que deve ser feito. Montar Grupos de ate 7 pessoas;
Escolher o Product Owner;
Escolher o Scrum Master;
Solicitar o tema do projeto;
Conhecer o cliente e suas necessidades;
Definir o Product Backlog;
Definir as Sprints;
Desenhar o quadro de Ciclo de Vida do Projeto;
Montar o quadro de Gestão à vista;
Apresentar o quadro com os Product Backlog e as Sprints. Vivenciando a experiência do Scrum Atingindo resultados por meio das equipes A responsabilidade pela gerência ou liderança é compartilhada entre os três componentes da equipe de Scrum: o Scrum Master, a equipe de desenvolvimento e o Product Owner. Até onde se estende o conceito de liderança, qualquer pessoa pode ser um líder, contanto que tenha alguma influência sobre a equipe, mas as pessoas que podem exercer uma liderança positiva sobre a equipe são, principalmente, o Product Owner e o Scrum Master, dois dos três tipos principais a que, Mike Cohn se refere como sendo líderes em seu livro Succeeding with Agile Scrum. Estimativas e Métricas Ágeis Planning Poker Trata-se de uma técnica de estimativa usada em equipes de Projeto Ágil para estimar, coletivamente, o tamanho relativo de suas histórias usando uma métrica denominada ponto de história. Para ser efetivo no uso do Planning Poker, supõe-se que a equipe de projeto seja composta de generalistas que tenham experiência com as diferentes tarefas de desenvolvimento de software, como coleta de requisitos, análise, projeto , codificação e teste. Dificuldades com Planning Poker:
Pontos de História não comparáveis entre várias equipes gera um risco de impacto negativo, em uma implementação de escala corporativa;
Problemas culturais: a influência de pessoas mais velhas e pessoas em papéis de liderança geralmente inibe os membros da equipe no momento de fazer uma estimativa diferente. Elementos de uma aplicação:
(1) usuários de negócio tentando interagir com algum código funcional que implementa;
(2) regras de negócio em
(3) um modelo que contém entidades de negócio, cujos valores estão armazenados no
(4) banco de dados físico, que é criado, lido, atualizado ou excluído. Estimativa Baseada em Critérios Objetivos: Escanear pg. 89 2. Calcular a complexidade com base no número de regras de negócio a serem aplicadas:
Regra de negócio = uma afirmação que diz quando você pode ou não fazer algo. Regra de negócio
X
Requisito de negócio:

Exemplo de regra de negócio: um cliente deve ter 18 anos ou mais;
Exemplo de requisito de negócio:
(impõe a regra)
o cliente deve estar com a carteira de motorista válida ou um passaporte válido e com foto, para verificar que ele tem pelo menos 18 anos. 3. Determinar o número de entidades necessárias para executar essa história de usuario: Escanear pg. 91 4. Determinar o fator de manipulação de dados (CRUD) Exemplo História de usuário:
"Incluir uma sala (de conferência)" A. Tipo de interação = 3 pontos
B. Regras de negócio = 1 ponto
C. Número de entidades manipuladas = 1 ponto
D. Criar, Ler, Atualizar, Excluir (CRUD) = 2 pontos PNA = PONTOS NÃO AJUSTADOS
PNA = 7 PONTOS (RELATIVOS AOS PONTOS NÃO AJUSTADOS DA HISTÓRIA OU PIB "INCLUIR UMA SALA" 5. Considerar as dimensões de ambiente (DA), que podem ter um impacto negativo ou positivo sobre a equipe durante seus esforços para entregar a história "inclusão da sala": 1. Dimensão organizacional
2. Dimensão de infraestrutura de desenvolvimento
3. Dimensão de equipe
4. Dimensão de tecnologia
5. Dimensão de processo
6. Dimensão de negócio Capacidade ou habilidade da equipe:
0 = menor valor
2 = maior valor Cenários Possíveis: 1. Se o valor de DA ficar entre 0 e 11, o coeficiente de multiplicação C será 2. Isso implica que as dimensões do ambiente são tais que a equipe não será capaz de entregar tantas histórias, durante o Sprint, quanto se o valor de DA fosse maior. 2. Se o valor de DA ficar entre 12 e 23, o coeficiente de multiplicação C será 1. Isso implica que o ambiente não dificulta nem facilita o trabalho em equipe. 3. Se o valor de DA ficar entre 24 e 36, o coeficiente de multiplicação será 1/2. Isso implica que as dimensões de ambiente são tais que a equipe deverá ser capaz de entregar mais histórias durante o Sprint. PA (PONTOS AJUSTAD0S) =
PNA (PONTOS NÃO AJUSTADOS) x C (COEFICIENTE

PPH (PONTOS POR HISTÓRIA) =
(PA x DA)/36 PNA DA 1. ORGANIZACIONAL = 3
2. INFRAESTRUTURA = 2
3. EQUIPE = 4
4. TECNOLOGIA = 3
5. PROCESSO = 2
6. NEGÓCIO = 4 A soma dos valores é igual a 18.
ENTÃO, coeficiente de multiplicação é 1. "INCLUIR UMA SALA":
PA = PNA x C
PA = 7 x 1 = 7
PPH = (PA x DA) / 36
PPH = (7 x 18) / 36 = 126/36 = 3,5 PONTOS
Full transcript