Agile Planning Board - Transparência para estimativas e planejamento de projetos.

538 visualizações

Publicada em

Planejar não é uma atividade fácil.
A falta de alinhamento entre os envolvidos sobre valor de negócio, itens arquiteturais e a real complexidade de construção, por muitas vezes nos leva ao fracasso.

O Agile Planning Board foi criado com a ideia de auxiliar times iniciantes a realizar boas reuniões de planejamento de releases e de sprints, mas com o tempo se mostrou mais do que isso.

Uma nova forma de realizar planejamento de maneira visual, acompanhar as métricas e estimar com base em métricas realizadas.

Publicada em: Software
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
538
No SlideShare
0
A partir de incorporações
0
Número de incorporações
49
Ações
Compartilhamentos
0
Downloads
6
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Diversas empresas em diversos segmentos
    Atuando com práticas ágeis em diversas equipes
    Elaborando uma ferramenta de facilitação
  • A ideia aqui é apresentar o agile planning board, uma ferramenta que foi criada para auxiliar times iniciantes a realizar boas reuniões de planejamento, mas que com o passar do tempo, se mostrou muito mais do que isso.
    Eu utilizava sempre com os meus times e este resolvi expor o conteúdo para devolver um pouco do que a comunidade ágil tem me ensinado ao longo dos últimos anos.
  • Planejamos para termos “previsibilidade aproximada” quanto às entregas e diminuirmos os riscos para se atingir determinados objetivos.
    Previsibilidade:
    Posso ter uma campanha de marketing envolvida
    Posso precisar de uma estimativa aproximada de custos
    Posso precisar definir uma estratégia de concorrência
    Diminuir os Riscos:
    É necessário acompanhar os riscos que podem impactar no objetivo do projeto.
  • Para o desenvolvimento de software, devemos considerar a Metodologia que será utilizada
    Pois está ligado ao Quando eu tenho que planejar
  • Por que que a metodologia influencia?
    Justamente devido ao Tamanho do Lote, que é a quantidade de requisitos envolvidos no planejamento.
  • O Esforço do planejamento é totalmente proporcional à quantidade de itens da entrega
    Planejamento tem custo.
    Quanto tempo eu quero ficar planejando?
  • Vamos pensar por quê isso acontece.
    Quando somo chamados para estimar o esforço de uma necessidade, nem que seja de forma rápida, pensamos no COMO FAZER, mas muitas vezes não temos o entendimento sobre O QUE FAZER.
    Desta forma, para chegarmos ao esforço, maior deve ser o nosso CONHECIMENTO minimizando os Riscos.
    Ao passo que quanto menos CONHECIMENTO, maiores serão os RISCOS envolvidos
    Todos estes fatores, envolvem a COMPLEXIDADE sobre o que iremos trabalhar.

    Não adianta planejar tudo no início, que estas incertezas não vão desaparecer.

    Pedreiro – pensando em como fazer:
    vou levar 2 dias
    Mas tem que entender o que fazer>
    Eu tenho a impressão que eles nunca entendem o que é para fazer.
  • Ajudar a determinar o contexto operacional predominante para poderem tomar decisões adequadas. Ele foi desenvolvido em 1999 no contexto da gestão do conhecimento e estratégia organizacional por Dave Snowden.
    Este modelo que teve base na teoria da complexidade classifica os problemas enfrentados por líderes em cinco contextos definidos pela natureza da relação entre causa e efeito. Cada contexto requer ações diferentes

    Simples: Entendo, Categorizo e Respondo
    (Manual da tv)
    Complicado: Entendo, Analiso, respondo
    Complexo: Experimenta, Sente, e responde..
    Trânsito (pelo menos o de São Paulo é bastante) Incertezas
    Desordenado: Quando o segundo sol chegar, para realinhar a ordem dos planetas (não precisa cantar)

    Onde vocês acham que o desenvolvimento de software se encaixa?
    Acredito até que cada um pode estar em um momento, mas em sua grande maioria no complexo, principalmente se estiver no início.
  • Diante de toda esta complexidade, talvez a forma mais simples de planejar seja por tamanho.
    Pense na seguinte situação, eu sou um especialista técnico que está sendo contratado para resolver um problema complicado na sua empresa.
    Como sou novo na empresa, eu posso ter muitas dúvidas de negócio, enquanto você tem poucas.
    Você pode ter dúvidas técnicas que eu não tenho.
    Se diminuirmos nossas dúvidas, conseguiremos chegar a um esforço mais assertivo.
    O esforço é algo mais tangível, enquanto as dúvidas são muito subjetivas.
  • Com estes conceitos, chegamos a este fluxograma para determinar o esforço:
    Você tem dúvidas de negócio?
    - Sim. Ela é Grande, Média ou Pequena?
    Não tenho Dúvidas
    Você tem dúvidas técnicas?
    - Sim. Ela é Grande, Média ou Pequena?
    Não tenho Dúvidas técnicas
    Qual o Esforço? Grande, Médio ou Pequeno?
    Quanto mais para a direita, maior meu conhecimento e menor o risco
    Quanto mais para a esquerda, menor o meu conhecimento e maior o risco

    É garantido que teremos incertezas, pois sempre teremos itens emergentes.
  • Mas ainda temos 1 problema: A COMUNICAÇÃO
    Eixo vertical: efetividade da comunicação
    Eixo Horizontal: Riqueza do canal de comunicação
    Face a Face com quadro branco – Modelagem ágil, visual thinking
    Por esse motivo foi criado o agile planning board como ferramenta de comunicação e transparência.
  • Nesta área você identifica o nome e o objetivo do Projeto, release, Sprint (depende do que você está planejando)
    Damos um Propósito:
    Pois quando não há um propósito claro, o resultado pode não ser o esperado.
    É muito importante quando você quer criar o conceito de time auto organizável.
  • Identificamos o Product Owner e o Time responsável pelo planejamento
    Mas eu não tenho Product Owner?
  • Trazemos o backlog priorizado.
    Nesta palestra, não vou entrar no mérito como foi montado o backlog ou se você usa user stories, features, casos de uso
  • Acordamos a Definição de Pronto das funcionalidades, que é importante para nortear o planejamento.
    Alinhar as Restrições
    As restrições sempre são importantes para guiar e alinhar o interesse de todos os envolvidos.
  • O Item D ele tem um pouco mais de esforço que o A, mas é menor que o B
    Visualmente fica fácil fazer a triangulação.
  • O Item E é semelhante ao C.
    Dá pra fazer analogia colocando na mesma coluna.
  • Posso ter um item com muitas dúvidas técnicas. Podemos criar um item novo para fazer uma prova de conceito, diminuído as dúvidas do item atual.
  • Pode ter itens ainda com muitas dúvidas onde você demonstra claramente pro seu P.O que vai precisar da participação dele.
  • Nos ajuda a definir restrições
    Posso dizer que só vou avaliar a parte técnica, depois de ter os critérios de aceitação definidos
    Identificar quais são os comportamentos esperados para o item
  • Toda vez que eu tiver muita dúvida técnica, precisarei acionar o Líder técnico para fazer uma prova de conceito
  • Ou ainda que toda vez que o esforço for grande, o time deverá quebrar em estórias menores
    Por exemplo o tamanho do código de identificação do usuário vai estourar o tamanho eu precisarei aumentar o tamanho em todas as interfaces do sistema
    Muitas vezes uma pessoa só ser a responsável por este item pode se tornar cansativo e tomar mais tempo do que havia previsto.
    Pode-se quebrar em: Alterar campos dos cadastros, alterar campos das consultas e alterar campos dos relatórios e dividir em 3 itens menores.
  • Se vocês repararam, estes são conceitos utilizados no Planning Poker
    Eu uso o Planning Poker pq eu gosto da comunicação que a dinâmica possui.
    Trazendo o conceito para o Agile Planning Board, fica fácil você visualizar o pq eu joguei 3, ou pq eu joguei 8.
    Fica mais tangível

    Todos conhecem o planning poker?
  • Um conceito interessante é com relação ao cone da incerteza.
    Ele nos diz que quando ainda estamos na ideia do produto, temos 4x a chance de errar na estimativa para mais ou para menos.
    E assim sucessivamente.
  • Esta é a forma como planning Board se encaixa nele.
    A ideia é sempre trabalhar com os itens com menos dúvidas.
  • Podemos então alimentar as colunas com estas métricas
    Então fica mais fácil realizarmos o planejamento das sprints
    Posso entregar ABC em 15 dias
    DEF2 em 15
    E F em mais 15
    Montei o plano da release

    Mas se eu entrego 8 pontos em uma Sprint vou precisar de 5 sprints pra entregar o de 40.
    Pois é, vamos entender juntos melhor o que deve ser feito, que teremos melhor visibilidade dela.
  • É MELHOR ESTAR APROXIMADAMENTE CERTO DO QUE PRECISAMENTE ERRADO.
  • Petrobras
  • BrasilPrev
  • Porto Seguro
    1 Time novo.
    A ideia de adotar métodos ágeis na Porto Seguro era entregar mais.
    Tínhamos janelas fixas de implantação.
    Então só pegávamos os itens que cabiam na próxima Sprint.
    Caminhávamos com os demais itens conforme o andamento do projeto.
  • Serasa
    Terminei antes do planejado, estou sem trabalho e é por isso que eu tô aqui numa terça-feira.
    Se alguém tiver precisando... Segue o meu contato
  • Agile Planning Board - Transparência para estimativas e planejamento de projetos.

    1. 1. Massimus C&T Edson de Sousa @EdsonSousaTi AGILE PLANNING BOARD TRANSPARÊNCIA PARA ESTIMATIVAS E PLANEJAMENTO DE PROJETOS
    2. 2. Breve histórico 1997 2000 2004 2006 20072007 2014 2014 2015 2015 - 2016 Edson de Sousa, CSM, CSPO, CSP @EdsonSousaTI
    3. 3. Conceitos
    4. 4. Por que planejamos? • Dar Previsibilidade • Diminuir Riscos
    5. 5. Influência da Metodologia A B C D E F G H I Análise Desenvolvimento Testes ... A B C Sprint 1 D E F Sprint 2 G H I Sprint n A B C D E F G H
    6. 6. Tamanho do Lote A B C D E F G H I plan X Y Z Sprintplan A plan
    7. 7. Esforço Proporcional à Entrega plan plan plan
    8. 8. O quê fazer? Como fazer? Esforço Níveis do Conhecimento Complexidade
    9. 9. Cynefin framework
    10. 10. Planejamento por Tamanho G M P Dúvidas Técnicas Esforço Dúvidas de Negócio
    11. 11. Fluxo do Conhecimento - Conhecimento + + Riscos -
    12. 12. Comunicação Efetiva
    13. 13. Agile Planning Board
    14. 14. Sapatos On-Line Permitir e-commerce de sapatos
    15. 15. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João
    16. 16. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C D E F G H
    17. 17. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C D E F G H C1 C2 C3
    18. 18. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João B C D E F G H C1 C2 C3 A
    19. 19. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C C1 C2 C3 E F G H D
    20. 20. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João D C1 C2 C3 F G H E A B C
    21. 21. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João E C1 C2 C3 F G H D A B C
    22. 22. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João C1 C2 C3 F2 G H F E D A B C
    23. 23. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João C1 C2 C3 G H F F2 E D A B C
    24. 24. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C D E C1 C2 C3 G H F Critérios de Aceite Definidos Definition Of Ready F2
    25. 25. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C D E C1 C2 C3 G H F Spikes Definition Of Ready F2
    26. 26. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C D E C1 C2 C3 G H F Desagregação Definition Of Ready F2
    27. 27. Planning Poker  Comunicação  Transferência de Conhecimento  Analogia  Desagregação  Triangulação
    28. 28. Concepção Inicial Definição do Projeto (Aprovada) Requisitos Concluídos Design do Produto Software Concluído 0,25x 2x 4x 0,5x 1,5x 0,67x 1,25x 0,8x Cone da Incerteza
    29. 29. 0,25x 2x 4x 0,5x 1,5x 0,67x 1,25x 0,8x Cone da Incerteza
    30. 30. Métricas [Velocidade] Lead Time 1pt 3pt 5pt 2 dias 9 dias 4 dias
    31. 31. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C D E C1 C2 C3 F2 G H F Planejamento 2 dias3 dias4 dias9 dias15 dias Meta: xxx 9 pts 15 dias __/__/__ Meta: yyy 8 pts 15 dias __/__/__ Meta: zzz 8 pts 15 dias __/__/__
    32. 32. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João A B C D E C1 C2 C3 F2 G H F 2 dias3 dias4 dias9 dias15 dias Meta: xxx 9 pts 15 dias __/__/__ Meta: yyy 8 pts 15 dias __/__/__ Meta: zzz 8 pts 15 dias __/__/__ Acurácia
    33. 33. Cases
    34. 34. A B C D E F G H I J
    35. 35. A B C D E F G H I J
    36. 36. A B C D E F G H I J
    37. 37. A B C D E F G H I J
    38. 38. https://agileplanningboard.wordpress.com/
    39. 39. +55 (11) 2246 - 2826 www.massimus.com Av. Paulista, 37, 4o Andar, São Paulo, SP, 01311-902, Brasil Edson de Sousa, CSM, CSPO, CSP @EdsonSousaTi IN EdsonSousaTi edson@massimus.com

    ×