planning meetings - agilepills.comagilepills.com/pills/agilepills_v20.pdf · dentro de cada...

AGILE MASTERINGVALUE STREAMS

Plataformasde Negócio

VALUE STREAM

VALUE STREAM

VS (AUTOMÓVEL)

VALUE STREAM

VALUE STREAM

O QUE SÃO “VALUE STREAMS”?

A primeira quebra de uma operação dentro do “pensamento enxuto” é a Plataforma de Negócio.

Dentro de cada Plataforma de Negócio, temos vários fluxos contínuos de entrega, conhecidos como Value Streams (fluxos de valor). Um exemplo simples de fluxo de valor é a modalidade dentro de uma seguradora:

● Automóvel● Vida● Massificado

Os fluxos de valor são “autônomos” o máximo possível e representam o ciclo de vida de um agrupamento de produtos ou serviços.

Não se deve nunca confundir “Value Stream” com “Plataformas de Negócio”. Por exemplo, numa empresa de retail como o Magazine Luiza, existem basicamente três plataformas ”core” de negócio:

● Compras● Vendas● Logística de Distribuição e Entrega

TemasSoftwareRodando

As plataformas de negócio englobam diversos “Value Streams”. Por exemplo dentro da plataforma de Vendas nesse exemplo de retail, podemos ter o Value Stream de venda em loja física ou venda pelo e-commerce.

Um ponto chave dos Value Streams é que eles permitem a conexão de processos com maior efetividade, evitando desperdício e reduzindo o lead time.

Um nome bem comum para “Value Streams” no mercado é “esteira”.

QUAL A IMPORTÂNCIA DOS “VALUE STREAMS”?

Na indústria em geral o emprego de Value Streams proporciona o balanceamento da produção e a coleta e monitoramento de métricas de uma forma profissional e eficiente.

Este modelo de trabalho permite a adição ou retirada de esteiras, adequando a capacidade de produção de acordo com a demandas de um sistema puxado. Não “emprestamos” recursos para outro time sobrecarregado, adicionamos mais um Value Stream, como se fosse uma nova esteira de produção.

CONCEITOS LEAN

Épicos

versão: 19/02/2018 agilepills.com[pill-0001]

HANDS-ONPLANNING MEETINGS

O QUE É PLANNING MEETING?

Planning Meeting, ou simplemente “Planning” é o nome que se dá a um dos ritos oficiais do SCRUM, sendo a primeira interação do DEV TEAM que ocorre a cada sprint.

Ela ocorre no primeiro dia da sprint, sendo preparada pelo SCRUM MASTER.

QUEM PARTICIPA DA PLANNING?

A participação de todos os integrantes do time de entrega é obrigatória. O SM é o facilitador, organizando o evento antecipadamente. Em times distribuídos pode-se eventualmente eleger um “proxy” para o time de desenvolvimento.

A dinâmica da planning é simples, porém fundamental para o sucesso da sprint. Todos os integrantes devem chegar com folga para o início, se possível preparados com questionamentos.

É durante a planning que Product Backlog previamente revisto e priorizado (durante o processo de refinamento) é atacado, destacando-se as estórias candidatas para compor o novo sprint backlog.

COMO É A CONDUÇÃO DA PLANNING?

Cada estória e principalmente seus critérios de aceitação são lidas para o time.

A cada leitura de cada uma das estórias, o time emprega uma técnica de estimativa de tamanho, que NÃO é dada por horas e sim por “pontos”, o Planning Poker.

Os membros do time jogam as cartas com o valor da Escala de Fibonacci que acreditam representar em pontos a melhor estimativa de tamanho do esforço de entrega. É o famoso Planning Poker. Às vezes utiliza-se a técnica de T-shirt Size (P, M, G, GG), ou a mais indicada na atualidade: os CPs (Complexity Points).

Somente passa-se para a próxima estória após haver unanimidade da escolha do valor do esforço, pois assim há certeza que todos entenderam da mesma forma o comportamento da estória.

O ideal é que cada estória saia da planning com todas suas tarefas definidas na ferramenta de ALM.

QUAL A DURAÇÃO DE UMA PLANNING?

Geralmente um dia de trabalho colaborativo é necessário e suficiente de entendimento do DEV TEAM para se realizar a planning.

QUAL O RESULTADO FINAL DA PLANNING?

Ao final da Planning, teremos as estórias estimadas e quebradas em tarefas (ideal) prontas para o início do desenvolvimento.

Product Backlog

1

3

2

4

Sprint Backlog

Estórias que serão desenvolvidas na

sprint corrente

? 0.5 0 1

2 3 5 8

13 21 ...

P M GTodos os Épicos e estórias

Planning Poker Cards

T-Shirt Size

RITOS SCRUM

EstóriasÉpicos

versão: 20/02/2018

GG

agilepills.com[pill-0002]

AGILE MASTERINGONE-PIECE-FLOW

O QUE É ONE-PIECE-FLOW?

ONE-PIECE-FLOW é a abordagem na qual as estórias de usuário são produzidas do começo ao fim, uma à uma de cada vez. Apesar de ser tentador iniciar o desenvolvimento de várias estórias simultaneamente, as medições de produtividade sempre entregam que é muito melhor começar e terminar uma estória de cabo à rabo, sem interrupções que iniciar várias e criar “estoques” nas colunas do ciclo de desenvolvimento.

De um modo simples de compreender, one-piece-flow representa um flow contínuo, onde os processos estão conectados e otimizados. Um bom exemplo é a montagem de lanches no McDonalds. Todos os pedidos são iniciados e finalizados sequencialmente em esteiras distintas (lanches, batatas, bebidas, sobremesas). Isso garante rapidez e identificação imediata e gargalos.

PORQUE É TÃO DIFÍCIL PRATICAR O ONE-PIECE-FLOW?

Para a maioria de nós, o bom-senso nos diz que se um block foi introduzido, de qualquer tipo, é melhor abandonarmos o assunto bloqueado e tentar “puxar” outro assunto. Isso cria efeitos colaterais no balanceamento da esteira, introduzindo débito técnico. Para que o fluxo contínuo funcione bem, é necessário ajustar o timing de necessidade de recursos (just-in-time).

Por exemplo, se o DEV TEAM aguarda uma definição de regra de negócio, existe um buffer máximo para que a entrega final não seja comprometida.

COMO FAZER PARA PARALELIZAR AS ESTÓRIAS?

O ideal é que para o mesmo time SCRUM (Squad, Pod, Célula, etc) não se tenha o desenvolvimento concorrente de estórias. Para paralelizar, a segunda estória deverá ser puxada por um segundo Value Stream.

COMO FAZER PARA “QUEBRAR” UMA ESTÓRIA DE MODO QUE TODOS DO TIME TRABALHEM NELA BALANCEADAMENTE?

Durante a planning, no momento da criação das tarefas, o time deve se preocupar em obter a granularidade que melhor se distribua entre os membros do time. É importante nesse momento levar em consideração a senioridade dos desenvolvedores e é claro o conhecimento das tecnologias.

COMO FAZER CASO O BLOCK SEJA COMPLETAMENTE IMPEDITIVO?

Cabe ao PO decidir se a estória cairá do caminhão e será retomada no próximo ciclo ou não

Product Backlog

1

3

2

4

Sprint Backlog

Estórias que serão desenvolvidas na

sprint corrente

Todos os Épicos e estórias

CONCEITOS LEAN

EstóriasÉpicos

versão: 21/02/2018

Discovery Desenv Homolog Prod

1 1 1 1

ONE-PIECE-FLOW=

Uma estória por vez!


HANDS-ONQUEBRA DE ÉPICOS

O QUE SÃO ÉPICOS?

Épicos são comportamentos sugeridos para a solução que foram descobertos mas ainda estão em um nível “raso” de profundidade (entendimento de como deverão funcionar). À medida que forem atacados pelos key positions, estórias menores serão derivadas. É costume mantê-los ao longo do desenvolvimento para agrupar funcionalidades ou assuntos conectados.

COMO SE FAZ A QUEBRA DE ÉPICOS?

A prática mais comum para quebra de épicos em estórias é considerar como estória, um comportamento da solução atômica e testável, através do atingimento total de seus critérios de aceitação.

O QUE É A FASE DE DISCOVERY?

Discovery é a 1ª fase do ciclo de desenvolvimento ágil. É onde a mágica da transformação de desirements em requirements, através da quebra de estórias num product backlog consistente.

Se na abordagem waterfall havia a necessidade da escrita de um documento de requisitos evoluindo para uma especificação funcional, na abordagem ágil tem-se o Discovery de estórias.

Muitos consideram os Épicos como “demandas” e aplicam técnicas de quebra em partes menores “testáveis”, representadas por cards (estórias de usuário).

QUEM PARTICIPA DA FASE DE DISCOVERY?

Obviamente a presença da área de negócio responsável pela oferta/produto é mandatória, assim como o PO (Product Owner). Com frequência outros key positions são chamados para participar, como o SM (Scrum Master), o arquiteto e outros SMEs (Subject-matter Experts). A aterrissagem de requisitos em estórias é de corresponsabilidade do PO e do também do SM, já que ele é um proxy do Dev Team e tem a capacidade para realizar a transferência dos critérios de aceitação das estórias para os desenvolvedores .

COMO PODEMOS PRIORIZAR OS REQUISITOS DURANTE A FASE DE DISCOVERY?

Uma boa opção é a técnica conhecida como Análise MoSCoW:

Must Have Should Have (Deve Ter) (Deveria Ter)

Could Have Won’t Have for Now (Poderia Ter) (Não Terá por Enquanto)

Product Backlog

PRÁTICA ÁGIL

versão: 22/02/2018

DISCOVERY DEVELOPMENT VALUE ACTIVATION

SPRINT N-1 SPRINT N SPRINT N+1

Demandas = Épicos

Meeting dos Key Positions:PO Team + SM + Negócio/Produto

Regras de Negócio

Critérios de Aceitação

Quebra deÉpicos em Estórias

Fase deDISCOVERY

Estórias

Épicos


EDUCATIONMETA DA SPRINT

O QUE É A META DA SPRINT?

Meta da sprint é o acordo estabelecido entre os participantes da Planning Meeting, o qual define e deixa claro o compromisso de entrega dos Value Streams, mais precisamente de cada time / célula / squad / pod. Como uma sprint por definição é um timebox, a DUE DATE da meta já está fixada, resta ao time chegar a um consenso sobre quais estórias serão desenvolvidas dentro do período fixado.

COMO DIMINUIR A INCERTEZA DE QUE AS ESTÓRIAS DESTACADAS SERÃO MESMO ENTREGUES?

Como a Planning Meeting utiliza estimativas em pontos para o esforço, a meta da sprint já nasce com um risco de prazo intrínseco. Nas sprints iniciais a incerteza é mais proeminente, e à medida que os membros dos times aprendem a trabalhar colaborativamente, a meta da sprint ganha maior assertividade. Um truque simples para atenuar esse efeito é separar as estórias em duas classes: estórias GOAL e estórias NON-GOAL.

O QUE TORNA AS ESTÓRIAS “GOAL”?

Quando uma estória está clara para todos, isto é, foi discutida e passou pelos critérios da DoR (Definition of Ready), com critérios de aceitação maduros e abrangentes, e principalmente, nenhum block restou, o time chega um consenso de que

efetivamente conseguirá desenvolvê-la no prazo, e que será demonstrada e entregue ao P.O., esta estória torna-se GOAL.

O QUE TORNA AS ESTÓRIAS “NON-GOAL”?

Para as estórias NON-GOAL, não significa que não serão entregues pelo time ao final da sprint corrente, pelo contrário, como o time determinou sua capacidade de queima com base na DoR, em sua produtividade, e nos blocks (impedimentos) anteriores, estas estórias classificadas como NON-GOAL possuem riscos a serem tratados, sem desprezar a DoR. Cada time irá queimá-las na sequência do planejamento do roadmap do projeto, estando empenhados em ativar valor para o negócio. E dessa forma estará claro para todos que o acordo não foi quebrado, pois a meta da sprint foi alcançada, entretanto sem as estórias da classe NON-GOAL.

PORQUE É TÃO IMPORTANTE COMUNICAR A META DA SPRINT PARA TODOS?

A meta da sprint é o compromisso mais sagrado para uma célula de entrega, ao ponto que tornou-se uma boa prática relembrá-la diariamente na daily meeting. Do ponto de vista da gestão de projetos, a meta definida e perseguida é um fator crítico de sucesso autêntico. Dessa forma, os stakeholders mais impactados devem sempre tomar conhecimento da meta. Essa comunicação deve ser abrangente e se possível realizada pelo PMO (escritório de projetos).

COMUNICAÇÃO ÁGIL

versão: 23/02/2018 agilepills.com

1 2

6

3 4

5

7

Sprint Backlog 1

32

4

5

6

7

EstóriasGOAL

EstóriasNON-GOAL

META DASPRINT

[pill-0005]

EDUCATIONFASES OU SPRINTS ?

NOS MÉTODOS ÁGEIS COMO O SCRUM EXISTEM FASES?

Sim, podemos pensar em fases sem problemas. São consideradas no mínimo 3 fases distintas num ciclo contínuo de entrega:

● Descoberta● Desenvolvimento (o SCRUM de fato)● Ativação de Valor

Estas fases serão sempre sequenciais, mandatoriamente uma após a outra, por definição. Isto significa que não é possível executá-las simultaneamente. Entretanto para “demandas” (sic) distintas, é perfeitamente normal que ocorram em paralelo, por exemplo quando utilizamos mais de um parceiro de negócio (fornecedor).

COMO SE SABE QUE UMA FASE TERMINOU E OUTRA INICIOU?

A fase 1 (Descoberta) engloba desde o nascimento de uma demanda, agora conhecida como Épico (\o/) até o ponto em que todas as estórias de usuário estejam “prontas” para o início do desenvolvimento (segundo a DoR – Definition of Ready). O time que atua na fase de desenvolvimento elabora o DoR com a definição completa de “pronto”.

A fase 2 (Desenvolvimento) inicia-se com a Planning Meeting, onde o sequenciamento de estórias e tarefas é combinado pelo time de

desenvolvimento. Encerra-se quando os critérios de feito (segundo a DoD – Definition of Done) são plenamente atingidos. O time que atua na fase de desenvolvimento elabora e mantém vivo o DoD.

A fase 3 (Ativação de Valor) se preocupa com implantação em produção das estórias desenvolvidas, demonstradas e aceitas pelo PO, combinadas para trazer mais valor para o negócio.

QUAL O TAMANHO IDEAL DE UMA SPRINT?

“Sprint” é o nome dado para o período de tempo de cada bloco de desenvolvimento. Não existe um tamanho ideal. Geralmente pode variar entre 1 e 3 semanas. Como parâmetro inicial, adota-se o período de 2 semanas. Existem empresas que calibraram em 8 dias, como agências digitais e startups e outras com um maior período, 21 dias por exemplo, como em Softhouses de produtos para Mercado Financeiro. É uma questão de calibragem.

A CONTAGEM DE SPRINTS COMEÇA NO SPRINT “0” OU SPRINT “1”?

No início da adoção dos métodos ágeis, algumas iniciativas chamavam a primeira sprint de sprint “0”. Atualmente chamamos esta sprint de Setup, o qual pode ocorrer ou não ao longo dos anos. Geralmente o Setup prepara o time com capacitação em novas tecnologias e deixa os equipamentos e ambientes prontos para o início.

TERMINOLOGIA ÁGIL

versão: 26/02/2018 agilepills.com

1 2

6

3 4

5

7

Sprint Backlog 1

32

4

5

6

7

EstóriasGOAL

EstóriasNON-GOAL

META DASPRINT

[pill-0006]

DISCOVERY DEVELOPMENT VALUE ACTIVATION

SPRINT N-1 SPRINT N SPRINT N+1

DoR

1

3

2

4

Sprint Backlog

1

3

2

4Build

Incremental

DoD

HANDS-ONCRITÉRIOS DE ACEITAÇÃO

O QUE É MESMO UMA ESTÓRIA DE USUÁRIO?

Estória de usuário nada mais é que um comportamento útil e esperado de um processo de negócio, viabilizado pela ação coordenada de uma boa interface de usuário, um bom algoritmo de aplicação de regras de negócio e a persistência de informações relevantes, se necessário. Trocando em miúdos, uma estória é algo “testável”, “atômico”, “delimitado”, “otimizado”, “incremental”, “performático” que faz um problema ser resolvido.

Exemplos muito simples:● Busca por clientes● Modificar agendas● Executar testes● Iniciar aplicação com última edição● Fechar aplicação● Solicitar cartão de crédito

O QUE NÃO É UMA ESTÓRIA DE USUÁRIO?

Salvo raras exceções, não é uma estória um procedimento técnico, um passo muito granular e que o P.O. não reconhece como enabler de valor.

Por exemplo:● Criar uma Stored Procedure● Criar classes de teste unitário● Limpar o arquivo de log todo início do mês● Aumentar o tamanho do campo para 25

caracteres

Lembre-se: estórias são comportamentos testáveis e não tarefas do time de desenvolvimento.

PORQUE O P.O. PRECISA TANTO DEFINIR E APROVAR OS CRITÉRIOS DE ACEITAÇÃO?

Ao longo dos anos, a comunidade ágil testou vários formatos de estória. No início, a proposta era descrever comportamentos apenas, no modelo:

"Como um <papel>, eu quero/posso <ação com o sistema> para que <benefício externo>".

Ao longo dos anos, incorporou-se um além do comportamento, um título (mais sucinto) e todos os critérios que, ao receber a demonstração da estória, o P.O. comprovasse que a estória estava feita por completa. Um “checklist” de critérios era suficiente essa comprovação. Até chegar nos CAs.

CRITÉRIOS DE ACEITAÇÃO SÃO OU NÃO SÃO REGRAS DE NEGÓCIO?

Não! Nunca foram! Regras de negócio são enquadramentos, pontos de decisão, cálculos, fluxos, aproximações, aplicações de políticas, ajustes em dados, enfim aquilo que suporta o produto ou serviço ofertado. Critérios de Aceitação, por outro lado são o conjunto de resultados obtidos com o comportamento da estória. Exemplo de Critério de Aceitação: mandei pintar o quarto do meu filho de azul. Quando cheguei em casa e abri a porta, o quarto estava pintado de azul. Coloquei mais um critério de aceitação para o pintor: comprar a tinta mais barata, porém uma tinta sem cheiro. Ele fez isso, então passou pelos critérios de aceitação. Outro CA: passar 2 demãos de tinta e o pintor passou 3, aproveitando a tinta.Exemplo de Regra de Negócio: - 100 ml de corante / litro de acrílico branco.

PRÁTICA ÁGIL


Estória deUsuário

Comportamento“Como cliente, eu quero solicitar um cartão de crédito adicional para alguém com grau de parentesco próximo, para distribuir compras pequenas em duas datas no mês, equilibrando o fluxo de caixa da família”.

“Solicitar Cartão Adicional”

Título

Critérios deAceitação

Pontos

No Canal Digital, utilizando-se um celular e a App de cartões instalada, existe agora uma opção para se pedir um cartão adicional;

A Interface de Usuário resume-se a um botão com o label: “EU QUERO UM CARTÃO ADICIONAL”, e o cliente deverá marcar um check que concorda com as condições contratuais;

O limite do cartão deve ser de 50% do cartão titular, sem no entanto diminuir o limite do títular;

O cartão adicional deve ser da mesma bandeira que o titular.

Épico

Regras de Negócio

Critérios de Aceitação

Quando o P.O. mostra seu

valor!

AGILE MASTERINGDESPERDÍCIO

O QUE É DESPERDÍCIO?

O que não gera valor para o negócio do cliente é desperdício que consome orçamento.

COMO PODEMOS IDENTIFICAR DESPERDÍCIOS?

A melhor maneira de se identificar desperdícios é através do mapeamento de Value Streams para trazer problemas à tona. A técnica de Value Stream Mapping foi criada pela Toyota e continua muito empregada para a descoberta de desperdícios.

EXISTEM INDICADORES QUE AJUDAM NA IDENTIFICAÇÃO DE GARGALOS E DESPERDÍCIOS?

Sim, praticamente todos os indicadores do ágil se bem coletados e analisados certamente ajudarão na identificação e tratamento dos desperdícios.

Faça as perguntas:

- Qual minha previsibilidade?

- Como está minha qualidade?

- Qual minha produtividade?

- Como está meu CFD (Cumulative Flow Diagram)?

- Como está o Flow Efficiency?

- Qual meu Lead Time?

COMO PODEMOS CLASSIFICAR/AGRUPAR OS DESPERDÍCIOS?

MUDA

Muda é o termo em japonês para qualquer atividade que consuma recursos sem criar valor para o cliente. Dentro dessa categoria geral, é útil distinguir entre Muda tipo 1, que consiste das atividades que não podem ser eliminadas imediatamente, e Muda tipo 2, as atividades que podem ser rapidamente eliminadas por kaizen.

MURI

Muri é a sobrecarga de equipamentos ou pessoas, exigindo que trabalhem em ritmo mais intenso ou acelerado, empregando mais força ou esforço, por um período maior de tempo do que podem suportar.

MURA

Mura é falta de regularidade em uma operação, como altos e baixos na programação, causados não pela demanda do cliente final, mas pelo sistema de produção, ou ritmo de trabalho irregular em uma operação, fazendo com que os operadores tenham picos de trabalho intensos e depois momentos de espera.

O QUE É EFICIÊNCIA PARA O LEAN?

Atender com precisão às exigências do cliente com a quantidade mínima de recursos.

CONCEITOS LEAN


MUDA MURI MURA

Tudo que não é valor é desperdício.

AGILE MASTERINGLEAD TIME X PROCESS TIME

O QUE É LEAD TIME?

No momento exato que um Épico é descoberto, isto é, acabou de nascer um card na primeira coluna do quadro Kanban (coluna muitas vezes chamada de “Em Descoberta”), até o exato momento que o valor é gerado (coluna “Implantada em Produção”) define o tempo total ou Lead Time.

Em termos gerais, quando um novo trabalho é recebido, o relógio começa a contar e só pára quando este trabalho é encaminhado para o próximo processo ou departamento. Esse é o Lead Time. Outros nomes comuns para Lead Time são: Elapsed Time, Throughput Time ou Turnaround Time.

PORQUE É IMPORTANTE CONHECER O LEAD TIME?

Como o Lead Time representa o tempo total transcorrido, desde o surgimento até a ativação de valor real, dentro dele coexiste outra medição, conhecida como PT = Process Time. O Process Time é o delimitador do tempo de início e término real da construção ou montagem do item. Como na maioria esmagadora das situações existem tempos de espera ou ociosidade, onde o trabalho sobre o item está congelado, ou aguardando uma fila de processamento, é possível diminuir o Lead Time de um processo ou cadeia de processos, simplesmente calibrando o ritmo da esteira para zerar o idle-time, para em seguida reduzir o Process Time. Você também encontrará os termos “Touch Time”, “Work Time” e “Cycle Time” como sinônimos de Process Time.

O Mapeamento da Cadeia de Valor fará a indicação dos gargalos. Assim, além de se conhecer bem o Lead Time, o principal objetivo será reduzi-lo.

QUAL A RELAÇÃO ENTRE OS DESPERDÍCIOS E O LEAD TIME?

Considerando os três tipos de desperdícios:

● Muda (Wastefulness) -> atividades que não tem valor para o cliente,

● Muri (Overload) -> sobrecarga em recursos, ● Mura (Imbalance) - ritmo irregular na linha

os desperdícios do tipo Muda são ofensores diretos do Lead Time. Identifique e extermine!

Já os desperdícios do tipo Muri, um ponto (recurso) da linha sobrecarregado, certamente influenciará o Process Time (e o Lead Time por tabela). Um efeito quase certo é o aumento de estoque no ponto anterior ao ponto com sobrecarga.

Para desperdícios do tipo Mura, a linha desbalanceada com altos e baixos de produção também afetará o Lead Time médio.

EXISTE ALGUMA FERRAMENTA NO KAIZEN PARA AJUDAR NA REDUÇÃO DO LT?

A melhoria contínua é fundamental para a redução do Lead Time e uma maneira muito prática de se enxergar ofensores de Lead Time é o CFD (Cumulative Flow Diagram). O rito de retrospective é o momento ideal para apresentar o CFD para o time e combinar o jogo da redução.

CONCEITOS LEAN


LT - Lead Time

PT - Process Timeidle idle

Novo Épico,Nova Estória

Estória ativadaem produção

Desperdícios

DESCOBRINDO PORQUE A ENTREGA ESTÁ DEMORANDO

HANDS-ONRETROSPECTIVE MEETING

O QUE SÃO REUNIÕES DE RETROSPECTIVA?

No último dia de cada sprint, realiza-se um rito importantíssimo, conhecido como RETRO. É o momento no qual um time revisita sua jornada (suas fortalezas e fraquezas). Diversos fatores podem cooperar para o desempenho global do time, como por exemplo a determinação de metas calibradas e tangíveis para a sprint, a redução de blocks impeditivos ou mesmo aspectos de engajamento. Essa reunião é a oportunidade do time se auto-avaliar, de propor melhorias nos pontos deficientes e incorporar na cultura os pontos de destaque. A Retro não é delegável, e para ser legítma, precisa da participação de todos.

QUEM CONDUZ A RETRO?

Nas primeiras sprints, é normal que a condução seja realizada pelo SM (Scrum Master). Desde a reserva de uma sala, até a conclusão da reunião. À medida que o time evolui mais e mais, a condução poderá ser auto-administrada. Existem Retros extremamente formais e também extremamente informais. Uma vez um SM sugeriu uma “COOL RETRO” para o time, que havia mandado muito bem na sprint corrente., e pediu ao GP para realizá-la no Starbucks. Cada membro do time ganharia um Frappuccino! Idéia genial do SM! Isso dá sinais claros de seu engajamento e a preocupação com o time.

COMO SE RODA BEM UMA RETRO?

A retro deve ser uma atividade “leve” e natural, e uma boa opção é utilizar Post-Its para que cada

membro participe apontando pra valer os assuntos positivos e negativos do período.

O SM pode começar solicitando ao time que escreva nos Post-Its os assuntos que considerem positivos, bem executados, ou seja, coisas boas que devam ser fomentadas e mantidas.

Em seguida, o SM solicita ao time que anote nos Post-Its os assuntos deficientes, que atrapalharam a entrega ou causaram desgastes. São assuntos que não contribuíram para a geração de valor ou consumiram recursos desnecessariamente, Por isso devem ser melhorados via Kaizen.

O importante é valorizar os pontos positivos e para os pontos negativos, traçar um plano de ação sério, que resolva-os durante a próxima sprint. Este plano de ação pode ser implementado como um mini-Kanban e exposto na Situation Wall do time. É responsabilidade do time e não só do SM resolver todos os cards o mais rápido possível.

TODOS OS ASSUNTOS NEGATIVOS PRECISAM SER RESOLVIDOS?

Certamente uma boa RETRO produzirá muitos cards de melhoria, todos importantes, no entanto é muito mais razoável atacá-los pelo Princípio de Pareto: aqueles assuntos que, se resolvidos, trarão a maioria dos benefícios ganham prioridade de implementação. É uma ótima prática pedir ao time que escolha entre todos os assuntos negativos, 5 deles que considerem mais importantes. Então a média das escolhas representará o melhor plano de ação.

RITOS SCRUM


Vamos Manter!

Nonono nono non no noo.




Nonono nono non no noo. Nonono

nono non no noo.



Vamos Melhorar... AçõesTODO WIP IMPLEMENTED



Nonono nono non no noo. Nonono

nono non no noo.

SITUATION WALL

Divulgue eIncorpore na cultura!

Escolha 5 maisvotadas e implemente!


Estou melhor que a sprint anterior?

EDUCATIONROADMAP INTEGRADO

O QUE É UM ROADMAP INTEGRADO?

Ao elaborarmos um roadmap, quase sempre o pensamos como se fosse um roteiro de versões para o produto que está sendo desenvolvido. Iniciamos com o MVP (Minimum Viable Product) e montamos o roadmap de features que serão adicionadas ao longo das próximas sprints.

Por exemplo, se estivermos planejando lançar uma app para contratação de seguros pelo smartphone, com a menor burocracia possível, montaremos um “roadmap” que estará aderente ao modelo de negócios e, ao longo de 12 meses, incorpore um conjunto de features que torne essa app suficientemente robusta para o uso em larga escala. Um “roadmap integrado” estende esse conceito, trazendo na mesma visão os compromissos de entrega de todas as áreas envolvidas, dos fornecedores de tecnologia ou mesmo das plataformas de negócio afetadas.

QUAIS AS VANTAGENS DE SE APLICAR O ROADMAP INTEGRADO?

Na nova economia, é muito comum o envolvimento de vários parceiros de negócio e áreas internas para viabilizar e lançar um novo produto ou plataforma de negócio com potencial de mexer com a concorrência. O roadmap integrado tornou-se essencial para trazer a visão única compartilhada para stakeholders acima. Tem-se várias vantagens na sua utilização, sendo as mais destacadas e imediatas, a simplicidade de atualização e a efetividade de comunicação, tornando-se um excelente orquestrador de times.

O ROADMAP INTEGRADO SUBSTITUI O CRONOGRAMA TRADICIONAL/CLÁSSICO?

Existe um enorme equívoco ao virar-se a chave para os métodos ágeis, abandonar-se as ferramentas tradicionais de gestão de projeto. O objetivo de um cronograma tradicional é apresentar as tarefas predecessoras e sucessoras, garantindo que o roteiro não esqueça de nenhum pacote de trabalho. Um roadmap integrado não tem a pretensão de ser o roteiro de atividades, com paralelismos, buffers e principalmente apontar o caminho crítico. Um roadmap integrado utiliza as barras de um Gantt Chart, entretanto seu intuito é orquestrar o trabalho de times colaborativos.

SE EU JÁ TENHO UM QUADRO TIPO KANBAN, COM COLUNAS MAPEANDO O FLUXO DE VALOR, FAZ SENTIDO PROPOR O USO DE UM ROADMAP INTEGRADO?

A resposta para essa questão é testar. Tudo depende de quanto o trabalho está segregado em áreas distintas ou plataformas de negócio, ou mesmo os parceiros de negócio (fornecedores). Para facilitar e viabilizar o trabalho em equipe, certamente estampar a participação dos times, quer sejam Value Streams, times de outsourcing, Integradoras, ou parceiras estratégicas, torna-se essencial e natural uma ferramenta desse tipo.

EXISTE UM PADRÃO DE ELABORAÇÃO DE ROADMAPS INTEGRADOS?Como tudo em uma jornada de transformação ágil, o empirismo é o caminho. Proponha um formato e teste-o, checando e adaptando até estabilizar.

COMUNICAÇÃO ÁGIL


TEMA ÉPICO ESTÓRIAPARCEIRO

PARCEIRO 1

PARCEIRO 2

PARCEIRO 3

TEMA A

TEMA A

TEMA A

Épico A

Épico B

Épico A

Épico C

Épico B

Épico C

Estória 1

Estória 2

Estória 3

Estória 4

Estória 5

Estória 6

Estória 7

Estória 8

Setup Homolog Homolog N-1

Setup Desenv Sprint N-1 Sprint N

Setup MTP MTP N-1

Discovery N-1 Discovery N Discovery N+1 Discovery N+2

Sprint N+1

Homolog N

SPRINT 12 SPRINT 13 SPRINT 14

HEIJUNKA

AGILE MASTERINGVALUE STREAM MAPPING

O QUE É O “VALUE STREAM MAPPING”?

Grande parte da eficácia do pensamento enxuto está na prática da observação da movimentação de materiais e fluxos de informação na cadeia produtiva. Quando mapeamos o fluxo de valor, trazemos à tona as ineficiências do processo. Assim, o VSM (Value Stream Mapping) é uma ferramenta estratégica poderosa, que permite enxergar o macro da produção. Foi criada pela Toyota e leva consigo muito da Teoria das Restrições (TOC - Theory of Constraints).

MAS COMO FUNCIONA NA PRÁTICA O MAPEAMENTO DOS FLUXOS DE VALOR?

Aprender a enxergar requer treino e muitos quilômetros rodados. No entanto, podemos começar o mapeamento considerando poucos passos. Um bom ponto de partida é quebrar a fase de Descoberta em algumas colunas:

Solicitado: o PO acabou de solicitar o épico.Priorizado: o PO acabou de priorizar o épico para entrar em status de refinamento.Em Refinamento: o épico será refinado funcionalmente, considerando o apoio dos experts.Pronto p/ Desenvolver: o épico foi quebrado em estórias, e possui todos os CAs aprovados pelo PO.

Para a fase de Desenvolvimento (a sprint propriamente dita), um bom ponto de partida é quebrar em mais algumas colunas:

Planejado: as estórias passaram pela Planning Meeting e foram discutidas e pontuadas por todo o Dev Team, e estão ready para serem construídas.Em Construção: as estórias estão em desenvolvimento dentro da sprint corrente.Demonstrado: as estórias ficaram prontas e foram demonstradas para o PO, durante a reunião de sprint review (demo).Em Homologação: as estórias demonstradas e com os feedbacks ajustados, estão em teste pelo PO. Por último, mapeamos colunas para o momento de ativação de valor:

Homologado: os Critérios de Aceitação estão OK.Em Prep Implantação: a estória está sendo preparada para ser ativada em produção.Implantada em Produção: a estória está no ar.Em Análise Pós-Implantação: o time de implantação está certificando o bom funcionamento da estória que subiu.

CONCEITOS LEAN


Setup Homolog Homolog N-1

Setup Desenv Sprint N-1

Sprint N

Setup MTP MTP N-1

Discovery N-1

Discovery NDiscovery N+1 Discovery N+2

Sprint N+1

Homolog N

MTP N

Discovery N+3

Sprint N+2

Homolog N+1

MTP N+1

Discovery N+4

Sprint N+3

Homolog N+2

DESCOBERTA DESENVOLVIMENTO ATIVAÇÃO DE VALOR

Solicitado

Priorizado

Em refinamento

Pronto para Desenvolver

Planejado

Em Construção

Em Homologação

Homologado

Em Preparação para Implantação

Implantada em Produção

Em Análise Pós-Implantação

DESCOBERTA

Solicitado Prioriza-do

Em Refina-mento

Pronto p/ Desen-volver

DESENVOLVIMENTO

PlanejadoEm

Constru-ção

Demons-trado

Em Homolo-

gação

ATIVAÇÃO DE VALOR

Homolo-gado

Em Prep. Implanta-

ção

Implanta-do em

Produção

Em Análise Pós-Implan

tação

Demonstrado/Pronto p/ Homologar

AGILE MASTERINGPRODUCT OWNER

A ATRIBUIÇÃO DE UM “DONO DO PRODUTO” É REALMENTE NECESSÁRIA?

Certamente associar um “dono”, que integralmente seja responsável pelas decisões em tempo de projeto sobre usabilidade, comportamentos, capacidades e sobretudo sobre segurança, atuando desde o momento da concepção, nos requisitos até o uso intensivo do produto quando chegar ao mercado, traz benefícios muito mais tangíveis do que não fazê-lo. Um dos benefícios mais esperados é a coerência de visão ao longo das sprints, pois, além de ter participado da elaboração do business case, o Product Owner é 100% accountable no roadmap de produto.

A QUEM DEVE SER ATRIBUÍDO O PAPEL DE “PRODUCT OWNER”?

Um bom candidato ao papel de Product Owner, com certeza será uma pessoa menos técnica, com profundo conhecimento funcional e principalmente com a visão abrangente dos workflows e constraints de negócio. Isto servirá de pano de fundo para o desenvolvimento do produto, suprindo sem surpresas as necessidades do público para o qual foi desenhado.

O PRODUCT OWNER É UMA PESSOA OU UM TIME?

O PO é sempre uma pessoa. Ponto final.

Entretanto poderá contar com a contribuição de outros, para formar um grupo de trabalho conhecido como “PO Team”.

QUAL O PAPEL DE “PO TEAM”?

Pode-se lançar mão de um “PO Team” para expandir a capacidade de análise, levantamento e, refinamento do PO, no entanto, a última palavra sobre o comportamento, atributos e características do produto mandatoriamente sempre é do PO.

QUAIS RITOS O PO DEVE PARTICIPAR?

DESCOBERTA

DESENVOLVIMENTO

MTP (Move to Production)

PAPÉIS DO SCRUM


PO

POTEAM

POTEAM

POTEAM

SM

DEVTEAM

DEVTEAM

DEVTEAM

DEVTEAM

SME

STAKEHOLDER

SME

STAKEHOLDERSME: Subject-Matter Expert

Elaboração, discussão e aprovação dos Critérios de Aceitação (estórias)Priorização do Roadmap (linha do tempo com principais marcos)Plano de Releases (planejamento de ativação de valor, em produção)

Refinamento (antes da próxima planning meeting)Planejamento de SETUP ( sprint n-1 )Planning Meeting (no primeiro dia de um novo sprint)Sprint Review (demonstração para o PO no último dia da sprint)Sprint Retrospective (Check and Adapt do Dev Team após a Demo)

Preparação de GMUDsImplantação em ProduçãoTestes pós-implantaçãoAcompanhamento pós-implantação

EDUCATIONIMPEDIMENTOS

O QUE SÃO IMPEDIMENTOS (BLOCKS)?

O framework SCRUM introduziu e popularizou o termo “impedimento”, para enquadrar qualquer evento, qualquer escassez de recurso ou mesmo qualquer política ou regra de negócio que não tenha sido esgotada a discussão prévia durante o refinamento. Também os problemas técnicos ou de tecnologia não solucionados em tempo de setup podem ser enquadrados como “impedimentos”.

COMO “NASCEM” OS IMPEDIMENTOS ?

Uma boa maneira de se pensar em impedimentos é estabelecer uma relação direta com os desperdícios. Como “tudo o que não gera valor é desperdício”, é bem provável que um ou mais impedimentos estejam criando condições ideais para o surgimento de desperdícios durante a sprint corrente. Por exemplo: o Dev Team está a todo vapor queimando as estórias, meticulosamente dentro da meta da sprint. De repente, um componente que estava previsto para chegar hoje não foi entregue por outro Value Stream. A estória está bloqueada! Para atenuar o efeito do block, o Dev Team decide criar um “mock” (um componente fake), para simular o comportamento real. Apesar do trabalho avançar, haverá retrabalho para conectar o componente definitivo quando estiver pronto. Esse “contorno” paliativo consumiu orçamento e tempo, portanto teremos um impedimento cujo efeito colateral foi desperdício.

Quase 90% dos impedimentos tem origem no débito técnico, isto é, “improvisos aceitos” que, em algum momento, cobram sua solução. Karma?

É VERDADE QUE O SM (SCRUM MASTER) É RESPONSÁVEL POR REMOVER OS IMPEDIMENTOS?

Sim, o SM é o responsável, por seu papel ser o dono. Entre todas as atribuições do SM, aquela que mais demonstra sua postura e respeito pelo Dev Team é remover os blocks para que a meta do sprint seja atingida da maneira mais otimizada possível. O SM empregará tanto os hard skills como soft skills para identificar a causa-raiz, comunicar os envolvidos e traçar as ações para sanar o impedimento ASAP. É claro que obterá todo o apoia do Dev Team, do PO, dos Stakeholders e SMEs, para colaborativamente deixar o caminho livre para a resolução. Teamwork na veia!

COMO OS IMPEDIMENTOS PODEM SER CATEGORIZADOS?

O mais comum é iniciar com as categorias INTERNO e EXTERNO. Blocks internos residem dentro da cozinha do time e blocks externos estão no perímetro que envolve o PO ou outros parceiros. Dentro dessa primeira categorização, podemos pensar em blocks técnicos, comportamentais, estruturais, etc. É bem comum categorizar em termos da severidade, como por exemplo: impeditivos, momentâneos, perfumaria, etc.

EXISTE ALGUMA FERRAMENTA OU TÉCNICA PARA ANTEVER/ PREVENIR IMPEDIMENTOS?

Sim, uma boa DoR (Definition of Ready), revista e melhorada a cada iteração tem o potencial para não deixar escapar blocks de grande impacto.

TERMINOLOGIA ÁGIL


DESENVOLVIMENTO

Planejado Em Construção Demonstrado

DESCOBERTAPronto p/

Desenvolver

estóriabloqueada

SM

DoR

filtro

AGILE MASTERINGPENSAMENTO ENXUTO

O QUE É PENSAMENTO ENXUTO?

Lean Thinking, ou pensamento enxuto, é o termo de mercado cunhado para o conjunto de técnicas e práticas desenvolvidas pela Toyota, conhecidas como TPS - Sistema de Produção Toyota. Este novo mindset considera a escassez de recursos como ponto de partida e agrupa princípios claros para nortear a gestão dessa escassez. São eles:

COMO ESSES PRINCÍPIOS CONTRIBUEM MUTUAMENTE PARA UMA MELHOR ENTREGA?

Nada é mais importante que o valor percebido pelo cliente. Afinal de contas, o investimento provém dele e nada mais justo que para uma boa entrega, é necessário que se entenda onde o valor real é percebido por ele.

Uma vez entendido onde reside o valor para nosso cliente, a batalha diária estará em direcionar esforços para a geração desse valor, mesmo que o bom senso diga o contrário. Tudo que não é valor percebido pelo cliente é desperdício e consome orçamento. Cortem a cabeça!

O que a Toyota descobriu e aprimorou, deixando um legado extraordinário para as demais indústrias é que conectar processos sucessivos, com a menor movimentação de materiais possível e também o menor caminho para o fluxo de informação, traz economias enormes em termos da redução do lead time. Assim, quanto mais contínuo o fluxo, maior e mais rápido será o throughput. Redução real de desperdício e geração real de valor para o cliente.

Através de técnicas C&A (checar e adaptar), criam-se ciclos de melhoria contínua, onde os gargalos são identificados (Value Stream Mapping) e assim assegura-se o menor estoque possível.

Por fim, repetindo-se e padronizando-se o trabalho, naturalmente chega-se à perfeição; um patamar de qualidade altíssimo é atingido.

Percebe como os princípios coexistem e cooperam uns com os outros?

QUAL O SEGREDO POR DETRÁS DESSE MODELO DE TRABALHO?

O pensamento enxuto estabelece uma forma diferenciada de trabalho em equipe e a mágica da sua eficácia está na simplicidade em se parar de começar e terminar o que se começou. Isso se deve à um “sistema puxado”, onde o comando para se produzir algo origina-se na ponta do cliente. Substituímos o paradigma de um sistema empurrado (keep the metal moving), onde o importante é produzir mais e mais para um sistema balanceado e puxado. Pare de empurrar e comece a puxar!

CONCEITOS LEAN


#262b2c 46.0 %Blue Charcoal (Blue)#29766d 17.6 %Genoa (Green)#207d38 12.8 %Japanese Laurel (Green)#835132 8.8 %Korma (Brown)#df6118 8.1 %Chocolate (Brown)#cb1f68 2.9 %Cerise (Red)#e7dd1f 2.4 %Golden Fizz (Green)#c5fefd 0.8 %Light Cyan (Blue)#d9ca57 0.6 %Confetti (Yellow)

PRINCÍPIOSLEAN

VALORPERCEBIDO

DESPERDÍCIOZERO

FLUXO CONTÍNUO

ESTOQUEMÍNIMO

QUALIDADE EXTREMA

ESCASSEZ

Entender o que é de fato valor para

o cliente

VALOR PERCEBIDO

DESPERDÍCIO ZERO

FLUXO CONTÍNUO

ESTOQUE MÍNIMO

QUALIDADE EXTREMA

Aprender a identificar e

eliminar o que não é valor para o

cliente, buscando o desperdício

zero

Planejar, implementar, testar,

com foco no fluxo contínuo, otimizando

fronteiras entre processos na

cadeia

Identificar gargalos onde se concentram

formação de estoques, eliminando-os

sistematicamente

Fazer certo da primeira vez, sem retrabalho e com

qualidade suprema para

a perfeição

HANDS-ONTESTE ESCALADO

O QUE É “TESTE ESCALADO”?

Quando a jornada ágil de uma empresa e seus parceiros/fornecedores de tecnologia atinge a adoção ampla, diversos temas que antes se mantinham em “silos”, controlados e protegidos por ilhas de gestão, começam a exigir atenção dos executivos, e o teste do produto não poderia ser diferente. Teste escalado é o nome dado ao teste de produto considerando a integração de plataformas de negócio, sistemas, workflows, operações de ponta a ponta, com diversos Value Streams de diferentes parceiros. Apesar de tais parceiros serem concorrentes, esse novo ecossistema ágil força-os a ter alianças para o atingimento das entregas. Não é raro a atuação de quatro ou mais parceiros/fornecedores na mesma empreitada. O teste escalado é o nome dado então às práticas multi-parceiros para entregar as engrenagens funcionando ao longo das sprints.

QUAL A PRINCIPAL MUDANÇA EM RELAÇÃO AO TESTE TRADICIONAL?

Tradicionalmente, os projetos consideram um planejamento waterfall ou rolling-wave planning, que represam as partes prontas de cada parceiro e preveem boa parte do release para um período de teste exaustivo e com cobertura de testes extrema abrangência. Muitas das vezes, este período é quebrado em dois momentos em sequência: aceitação e homologação, onde geralmente uma central de testes executa primeiro casos de teste, para depois “homologar” com o solicitante. Essa prática tornou-se muito comum, mesmo sendo considerada um enorme desperdício.

Do outro lado, frameworks ágeis recomendam rodarmos ciclos bem mais curtos de descoberta / desenvolvimento / ativação de valor, trazendo ou enfocando muito mais em teste unitário que testes minuciosos com dezenas de casos de teste. Este benefício gera um trade-off no teste, pois exige uma orquestração muito mais bem executada, daí teremos que tornar o teste escalado.

DE QUEM É A RESPONSABILIDADE PELA ORQUESTRAÇÃO DO TESTE ESCALADO?

Os SMs (Scrum Masters) de cada Value Stream. Durante as reuniões de SoS (Scrum of Scrums) ocorre a sincronização e preparação para o teste no momento correto de cada time.

COMO SE FAZ NA PRÁTICA PARA CONSEGUIR OS TESTES ENCADEADOS E ESCALADOS PARA O MOMENTO DE CADA FORNECEDOR?

Além da SoS (Scrum of Scrums), pode-se lançar mão de um “roadmap integrado” e um “mapa de dependências”, deixando exposto todas as due dates para antever pedidos de ambiente, componentes, massa de dados para teste, processos síncronos e não síncronos, etc.

QUAIS OS BENEFÍCIOS DO TESTE ESCALADO?

O teste escalado inicialmente traz um benefício x custo não tão bom, por conta do aprendizado dos envolvidos, entretanto à médio prazo, combinado com ciclos de entrega ágil, o teste escalado permitirá aumentar a qualidade com recursos entrosados e funcionando com múltiplos parceiros.

QUALIDADE ÁGIL


Estórias do parceiro A

Estórias do parceiro B

Estórias do parceiro C

TesteEscalado

A

B

C

A+B A+B+C B+C Estórias que testem aspectos

conjugados

EDUCATIONBEHAVIOR-DRIVEN DEVELOPMENT

O QUE É “BEHAVIOR-DRIVEN DEVELOPMENT” (BDD)?

Desde os primórdios da computação, inúmeras abordagens para guiar o desenvolvimento foram testadas e incorporadas pelo comunidade de TI. Nos anos 70 para 80, havia muita dúvida de como seria a melhor maneira para se descrever requisitos e transformá-los em funcionalidades. Esse período ficou conhecido como “A Crise do Software”. Um marco importante foi a introdução da UML com a contribuição dos famosos casos de uso. Tornou-se muito popular a escrita de um “caminho feliz” e seus “caminhos alternativos” para cada uso. Então ocorreu que esta técnica se tornou extremamente prescritiva e de péssima manutenabilidade. Qualquer ajuste nos paths (happy path e alternative paths) logo tornava os artefatos defasados e incorretos.

Após a declaração do Manifesto Ágil em fevereiro de 2001, novas propostas foram surgindo, e o “desenvolvimento guiado pelo comportamento” se mostrou muito adequado para uma grande gama de cenários. Sua maior contribuição foi e ainda é a simplicidade e poder de comunicação, além da possibilidade de utilizá-lo em ferramentas de teste.

ONDE CABE A UTILIZAÇÃO DE BDD?

O BDD tem se mostrado uma excelente alternativa para se escrever os Critérios de Aceitação de uma estória. Sua estrutura básica, naturalmente direciona para a verificação de feito de um comportamento narrado na estória de usuário.

QUEM É RESPONSÁVEL PELA ESCRITA EM BDD DOS CRITÉRIOS DE ACEITAÇÃO ?

O dono é o PO Team, apoiado nas dúvidas pelos SMs. Os SMEs (especialistas) também são importantes para a completeza dos CAs (Critérios de Aceitação). Em grandes corporações, as torres ou unidades de negócio, que muitas vezes não são a casa do PO, com certeza são fundamentais para a eficácia do emprego do BDD.

O BDD É UM FORMATO DE ESCRITA LIVRE OU PADRONIZADO?

Á priori, o BDD é uma padronização, por tratar-se de um facilitador na comunicação entre times, e ficou convencionado num formato muito simples:

QUAL A RELAÇÃO ENTRE O BDD E AS REGRAS DE NEGÓCIO?

BDD é um formato estruturado de escrita de comportamentos, chamados cenários. As regras de negócio estão “embutidas” nesta escrita. Não há problema em se utilizar fórmulas, tabelas de enquadramento, procedimentos e políticas. O importante é dissipar o vapor e fazer-se entender.

TÉCNICAS ÁGEIS


DADO:

QUANDO:

ENTÃO:

Conjunto de pré-requisitos

Quando o evento ocorre

O seguinte resultado é atingido

Título: no nnno nono nno

Comportamento:Nono nono nooon onn onNo n onononon noo noo n

Critério de Aceitação

DADO: o nono no nnnnQUANDO: no nono no noENTÃO: nono no nono

ESTÓ

RIA

Dado que estou na tela de

extrato e sou um cliente

universitário

Quando o aciono o link

de exibição de comprovantes de pagamento

Uma lista com todos os comprovantes é exibida para

baixá-los

GIVEN WHEN THEN

D

HANDS-ONDUAL TRACK AGILE

O QUE É “DUAL TRACK AGILE”?

Dual Track Agile é a quebra do product backlog em dois momentos distintos:

Isso mesmo, não há nada que impeça dividirmos o backlog considerando um primeiro momento onde os épicos são adicionados para serem pensados e testados e um outro onde já ocorreu o refinamento do épico, algumas estórias foram identificadas e passaram pela peneira de valor.

Grande parte do sucesso dos métodos ágeis está na antiga abordagem do “dividir para conquistar”. Ao separar e coordenar duas trilhas, não concorrentes, defasadas de um ou dois sprints, garantiremos que as squads dos value streams rodando SCRUM por exemplo não morram de fome (entrem em estado de “starvation”) .

QUAL A VANTAGEM DE SE UTILIZAR UM DUAL TRACK AGILE?

Na nova economia, digital e disruptiva, os testes de MVP (Minimum Viable Product) são essenciais para se testar idéias de produtos e serviços, gastando-se pouco porém obtendo-se um ótimo feedback dos usuários finais. A vantagem então está em aumentar as chances de lançar um produto que tenha valor de fato para o cliente, e apostar as fichas naqueles com maior potencial de vendas ou adesão.

QUEM COMPÕE O TIME QUE ATUARÁ EM CADA TRILHA?

Na trilha de descoberta, os participantes serão o PO e seu time de apoio (PO Team), além do SM e algum recurso técnico com maior senioridade, tipicamente um arquiteto. Além destes, poderão compor o time estrategistas (digitais ou não), especialistas em UX (User eXperience) e gerentes de produto.

Para a trilha de entrega, serão os papéis técnicos (Dev Team, QA, Infraestrutura e Arquitetura) e também os papéis de gestão (SM, PM, Operações). É NECESSÁRIO SER UMA STARTUP PARA ADOTAR O DUAL TRACK AGILE?

Claro que não! O modelo nasceu na onda Lean Startup, porém nada impede sua adoção em outros contextos. Por exemplo, uma companhia de seguros poderia utilizar o Dual Track Agile para impulsionar seus canais digitais, propondo novas maneiras de contratação de seguros, novas formas de estreitar o relacionamento, melhorando o CRM, incorporando aspectos de CLM (Marketing de Circuito Fechado), enfim criando inovações, onde os feedbacks de testes MVP alimentariam a trilha de delivery com muito mais assertividade.

A QUEBRA EM 2 BACKLOGS NÃO PODE INTRODUZIR UM GARGALO ENTRE OS ENDPOINTS DOS PROCESSOS?

A secção pode sim trazer algum ruído, entretanto os resultados compensariam a independência.

PRÁTICAS ÁGEIS


DISCOVERYTRACK

OPPORTUNITYBACKLOG

DELIVERYTRACK

DEVELOPMENTBACKLOG

IDEIAS

A B

C

MVP

Y X C B A

BACKLOG DE OPORTUNIDADE

BACKLOG DE DESENVOLVIMENTO

SPRINT SPRINT SPRINT SPRINT

AGILE MASTERINGSCRUM MASTERPAPÉIS DO SCRUM


A ATUAÇÃO DE UM “MESTRE” DO SCRUM É REALMENTE NECESSÁRIA?

Em quase todas as atividades realizadas em grupo, existe a figura de um “mestre”, uma referência,, principalmente quando tal grupo acabou de se reunir e ainda está se conhecendo. Naturalmente surge a liderança, alguém com postura de condução, para combinar as regras básicas para o trabalho em grupo. No framework SCRUM não poderia ser diferente. Acrescenta-se um mestre para ensinar o jogo e aconselhar até que o grupo dispense seus serviços. Muito se escreveu sobre o papel, suas atribuições e responsabilidades. Uma das mais completas descrições está no paper “The 8 stances of a Scrum Master”:

A QUEM DEVE SER ATRIBUÍDO O PAPEL DE “SCRUM MASTER”?

Considerando essas 8 “posições” que dão a completude do papel, um bom candidato a SM é alguém com uma boa dose de hard skills, para liderar tecnicamente, porém com uma superdose de soft skills. Em última instância é alguém imbuído do espírito de blindar o Dev Team de qualquer issue que afeta a queima de estórias.

MAS UM “SM” É UM “AGILE COACH JÚNIOR”?

Pode ter certeza que a trilha está correta, no entanto este é um mito que se propagou, na verdade tem-se apenas os Km rodados a mais que distanciam os dois papéis e o fato de que o Coach atua com diversos times, enquanto que o SM atua somente em um squad.

QUAIS RITOS O SM DEVE PARTICIPAR?

DESCOBERTA

DESENVOLVIMENTO

MTP (Move to Production)

Elaboração, discussão e aprovação dos Critérios de Aceitação (estórias)Priorização do Roadmap (linha do tempo com principais marcos)Plano de Releases (planejamento de ativação de valor, em produção)

Refinamento (antes da próxima planning meeting)Planejamento de SETUP ( sprint n-1 )Planning Meeting (no primeiro dia de um novo sprint)Sprint Review (demonstração para o PO no último dia da sprint)Sprint Retrospective (Check and Adapt do Dev Team após a Demo)

Preparação de GMUDsImplantação em ProduçãoTestes pós-implantaçãoAcompanhamento pós-implantação

Paper: https://www.scrum.org/resources/8-stances-scrum-master

PO

POTEAM

POTEAM

POTEAM

SM

DEVTEAM

DEVTEAM

DEVTEAM

DEVTEAM

SME

STAKEHOLDER

SME

STAKEHOLDERSME: Subject-Matter Expert

Removedor deImpedimentos

Facilitador

Treinador

Professor

Líder Servidor

Gerente

Agente de Mudança

Mentor

HANDS-ONSPRINT REVIEW MEETING

O QUE VEM A SER A REUNIÃO DE “SPRINT REVIEW”?

SCRUM é um framework com regras simples, porém muito claras, incluído desde seu início nos chamados “métodos ágeis”. Surgiu com o objetivo de estruturar um motor de entrega minimalista, avesso aos preciosismos do Processo Unificado. Para garantir um mecanismo auto-contido e abrangente para a maioria dos problemas, ele inclui atividades em grupo, muito simples mas fundamentais. A Revisão do Sprint é uma dessas atividades previstas no framework, igualmente importante das outras (Planning, Execution, Daily, Retrospective, Refinement). Nenhuma traz tanto engajamento como a “demo”. Esse é o apelido da Sprint Review Meeting, já que na maioria das vezes é uma demonstração do time para o PO.

A SPRINT REVIEW É OBRIGATORIA?

Sim, como todas as outras atividades. Pode parecer purismo de agilista, no entanto “pular” uma atividade traz consequências desastrosas para o time. Somente algo muito sério tem o poder de cancelar uma demo! Lembre-se disto. #ficadica

QUAL O OBJETIVO DE UMA SPRINT REVIEW?

A Sprint Review possui o objetivo claro de verificar e adaptar o produto que está sendo construído. É o momento de revisitar os Critérios de Aceitação escritos no refinamento e confirmar que estão contemplados na solução dada pelo time. Verificar e adaptar vem dos ciclos PDCA (Plan Do Check Act). Kaizen na veia!

COMO É A DINÂMICA DE UMA SPRINT REVIEW?

Idealmente, a sprint review deve ocorrer no último dia da sprint. Existem muitas forças ocultas que tracionam para empurrar a demo para outra sprint e até pulá-la, esquecê-la. Isto demonstra falta de maturidade do time. Não deixe isso acontecer! Os preparativos de uma demo iniciam no logo primeiro dia da sprint e ao longo dos dias serão providenciados e disponibilizados para o dia da demo. Assuntos potencialmente geradores de blocks, como por exemplo massa de dados faltante, ambientes não estabilizados, troca de prioridades das estórias, se tratados o quanto antes para serem sanados não impedirão a demonstração. No dia da demonstração, o ambiente estará operacional e um dos membros do Dev Team se encarregará em mostrar para o PO as partes construídas ou ajustadas que atendem plenamente os Critérios de Aceitação. Geralmente, por se tratar de uma reunião com menos formalismo, não se impõe uma agenda muito rígida. É um momento de comemoração!

O PO decide se aceita a entrega ou não, baseado nos critérios de aceitação, nos quais foram escritos por ele (ou seu time = PO Team). É opcional “formalizar ou não” este aceite.

QUEM PARTICIPA DA SPRINT REVIEW?

A presença do PO é obrigatória e também do SM. É encorajada a participação do Dev Team por completo, no entanto a escolha de um membro do time para representá-lo pode ser uma alternativa.

RITOS SCRUM


STAKEHOLDEREXTERNO

STAKEHOLDERINTERNO

PO POTEAM

DEVTEAM

SM SME

Overview

Demo

Discussão Adaptação

Estórias“Demonstráveis”

Estórias“Empacotadas”

planning meetings - agilepills.comagilepills.com/pills/agilepills_v20.pdf · dentro de cada...

Documents