Scrum

Tom ShinderPrincipal WriterMicrosoft SCD iX Solutions Group

Yuri DiogenesSenior Technical WriterMicrosoft SCD iX Foundations Group

Josh AdamsSenior Program ManagerMicrosoft Enterprise Engineer Center (EEC)

Núcleo de Capacitação Permanente

Agile

Marco BaccaroArquiteto de SistemasUnidade de tecnologia Giespp

Scrum, framework de desenvolvimento para produtos complexos.

Giespp

Ponto de partida

2008 - 2013Pensamento Kaizen: mudança para melhor, melhoria contínua de um fluxo completo de valor ou de um processo individual, a fim de se criar mais valor com menos desperdício. Além de melhorar a produtividade, o contribui para a melhoria das condições de trabalho.

Boas notícias | Remar a favor da maré…



Boas notícias | Remar a favor da maré…Salesforce.comPercebeu que passou a entregar 01 features ao invés de 04 no ano. Após o primeiro ano com Scrum a empresa lançou 94% mais recursos, distribuiu 38% mais recursos aos desenvolvedores e distribuiu 500% a mais de valor a seus clientes.

QSM AssociatesBase de 7,5 mil projetos, que considerou esforço, prazo, dificuldade técnica e outros fatores. Obteve o resultado que projetos ágeis são 16% mais produtivos e 37% mais rápido.

DDJ e Version OneCom um número significante de participantes, 82% acharam que a produtividade com Scrum foi maior, 73% acharam que com conceito ágil tinha melhorado, 50% melhorado expressivamente e 23% profundamente.

Gartner Prevê que 80% dos projetos de software utilizarão métodos ágeis em 2012.

Problema conhecido… qual o real motivo?

Processo Interativo e Incremental

Incremental: Estratégia de planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas.

Interativo: Estrategia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido.

Priorizar Planejar Executar Responder

Processo Interativo e Incremental

1 2 3 4

O Manifesto Ágil

Criado em 2001, ele define os quatros valores e doze princípios.

Colaboração do cliente

-mais que-

Negociação de contrato

Indivíduos einterações

-mais que-

Processos e ferramentas

Responder a mudanças

-mais que-

Seguir planejament

o

Software funcionando

-mais que-

Documentação

abrangente

Embora existam valores nos itens abaixo, nós valorizamos mais os itens acima.

Benefícios

Inspeção Transparência AdaptaçãoIntegração Contínua

Heterarquia Melhoria Contínua Pareamento Flexibilidade

Papéis

Composição do time


Product OwnerO dono do produto, responsável por maximizar o valor do produto e do trabalho da equipe de desenvolvimento. É a única pessoa responsável por gerenciar o product backlog, ele é uma pessoa e não um comitê.

Expressar claramente os itens do Product Backlog.

Ordenar os itens do Product Backlog para alcançar melhor as metas e missões.

Garantir o valor do trabalho realizado pelo Time de desenvolvimento.

Garantir que o Product Baklog seja visível e transparente para todos.

Garantir que a equipe de desenvolvimento entenda os itens do Product Backlog no nível necessário.

Scrum Master

Liderar e treinar a organização na adoção do Scrum.

Responsável por garantir que o Scrum seja entendido e aplicado em suas práticas e regras. O Scrum Master é um servo-líder para o time, ensinando e liderarando a equipe de desenvolvimento na criação de produtos de alto valor.

Ajudar colaboradores e stakeholder a compreender e tornar aplicável o Scrum e o modelo empírico.

Causando mudanças que aumentam a produtividade do time Scrum.

Treinar a equipe de desenvolvimento em auto-gerenciamento e interdisciplinaridade.

Remover impedimentos para o progresso do time de desenvolvimento.

Facilitar os eventos Scrum conforme exigidos ou necessários.

Development Team

Equipes de desenvolvimento são auto-organizadas.

Equipes de desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias.

Tornam o Product Backlog em incrementos de funcionalidades potencialmente utilizáveis.

Integrantes podem ter habilidades especializadas, mas a responsabilidade pertence à equipe.

Equipes de desenvolvimento não contém sub-equipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócios.

Profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. As equipes são estruturadas e autorizadas pela organização para organizar e gerenciar seu próprio trabalho.

Artefatos

Desejos do usuário e problemas existentes


User Story

Como um cliente, quero ser capaz de executar o seu produto em todas as versões do Windows desde o Windows 95.

Como CTO, eu quero que o site esteja disponível 99,99% do tempo para não ter frustação e procurar outro site para usar.

Como alguém que fala uma língua latina, gostaria de utilizar o sistema no meu idioma a qualquer momento.

Como um cliente, quero ver os filmes disponíveis para locação para que possa alugá-lo.

Como um gerente, preciso visualizar pedido de empréstimos acima do limite de crédito do cliente para efetuar a aprovação.

Como um vendedor responsável pelo setor de livros, eu quero procurar por livros filtrando por nome para que seja possível verificar se o livro X está disponível para pronta entrega.

Estórias são requisitos fracionados para que seja possível estimar o esforço para realizar aquele objetivo. São descrições simples que descrevem a funcionalidade no ponto de vista do usuário. Simples, curtas e claras.

http://www.microsoft.com/sqlserverlabs






Critério de Aceitação• Eu posso pesquisar por...• Eu posso pagar com

um...• Eu posso visualizar e

editar…

Itens

Product Backlog

Product Backlog Sprint Backlog

Sprint Backlog

5

8

5

Burndown Charts

Qual é a velocidade da equipe para completar o trabalho restante?

A equipe está adicionando trabalho durante a iteração? Há espaço suficiente?

Quanto trabalho resta para completar no tempo disponível?

Quando é que a equipe terminará a iteração atual?.

Team System | N Visões

Visão de saúde das estórias. As estórias são sempre listados de acordo com a sua classificação, onde a equipe realizou mais trabalho para essas estória que aparecem em primeiro lugar no relatório.

Visão geral das estórias que apresenta uma foto do trabalho que tem sido realizado para o conjunto filtrado de histórias de usuários para a data atual.

Team System | Backlog View

Team System | Taskboard

Eventos

Comunicar para adaptar e inspecionar


SprintPode ser considerado um projeto com horizonte não maior que um mês, no qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

Não são feitas mudanças que podem afetar o seu objetivo.

A composição da equipe permanecem constantes.

As metas de qualidade não diminuem.

O escopo pode ser clarificado e renegociado quanto mais for aprendido.

Sprint PlanningReunião colaborativa de planejamento do trabalho, conteúdo a ser realizado em um Sprint.

Parte 01 Parte 02

• Apresentação e explicação do Product Backlog pelo PO.

• Estimativa de esforço no entendimento do “pronto”.

• Seleção dos itens de acordo com período da Sprint e suas respectivas prioridades.

• Definição da meta da Sprint.

• Definição do time de como irá construir as funcionalidades.

• Entendimento de tarefas no nível menor, compreender ordem necessária, dependências e etc.

• Apresentar ao PO e SM como pretendem trabalhar para completar o objetivo da Sprint.

Planning PokerEstimativa consensual entre a equipe de desenvolvedores, que pontua o esforço entre as estórias, técnica também conhecida como Story Points.

Daily ScrumReunião para inspecionar o trabalho desde a última reunião diária, e prever o trabalho que deverá ser feito antes da próxima reunião diária.

1. O que foi completado desde a última reunião?

2. O que será feito até a próxima reunião?3. Quais os obstáculos que estão no

caminho?

Melhoram as comunicação, eliminam outras reuniões, identificam e removem impedimentos.

Reunião chave para inspeção e adaptação.

Sprint ReviewReunião de Revisão da Sprint, executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto, se necessário.

O Product Owner identifica o que foi “Pronto” e o que não foi “Pronto”

A equipe discute o que foi bem durante a Sprint, quais problemas ocorreram e como foram resolvidos.

A equipe demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento.

O PO projeta as prováveis datas de conclusão baseado no progresso. O grupo todo colabora sobre o que fazer a seguir e fornece entradas valiosas para a próxima reunião de Sprint Planning.

Sprint RetrospectiveReunião de retrospectiva é uma oportunidade para o time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

Inspecionar como a última Sprint foi em relação as pessoas, relações, processos e ferramentas.

Identificar e ordenar os principais itens que foram bem e as potenciais melhorias

Criar um plano para implementar melhorias no modo que o time faz seu trabalho.

Resumo

Considerações Finais

1. Definição clara do feito.

2. Falhar rapidamente.

3. Aprender a velocidade do time.

4. Finalizar o que começou.

5. Bugs são trabalhos reais.

6. Escrever teste unitário - sempre.

7. Automatizar e compartilhar.

8. Fazer as coisas certas no momento certo.

9. Não ignore os eventos, comunique- se.

10. Qualidade não é uma variável.

Obrigado

Giespp

Documents

Scrum