Agile Planning Board - Transparência para estimativas e planejamento de projetos.
•Descargar como PPTX, PDF•
7 recomendaciones•1,122 vistas
O documento discute a importância do planejamento ágil de projetos para fornecer previsibilidade e reduzir riscos. Ele explica como a metodologia influencia o planejamento e apresenta o Agile Planning Board como uma ferramenta para planejar de forma transparente, desagregar tarefas e acompanhar métricas de velocidade e prazos. Um exemplo prático mostra como o quadro é usado para planejar as etapas de um projeto de e-commerce de sapatos.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Similar a Agile Planning Board - Transparência para estimativas e planejamento de projetos.
Similar a Agile Planning Board - Transparência para estimativas e planejamento de projetos. (20)
Agile Planning Board - Transparência para estimativas e planejamento de projetos.
- 1. Massimus C&T Edson de Sousa @EdsonSousaTi AGILE PLANNING BOARD TRANSPARÊNCIA PARA ESTIMATIVAS E PLANEJAMENTO DE PROJETOS
- 2. Breve histórico 1997 2000 2004 2006 20072007 2014 2014 2015 2015 - 2016 Edson de Sousa, CSM, CSPO, CSP @EdsonSousaTI
- 4. Conceitos
- 5. Por que planejamos? • Dar Previsibilidade • Diminuir Riscos
- 6. 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
- 8. Esforço Proporcional à Entrega plan plan plan
- 9. O quê fazer? Como fazer? Esforço Níveis do Conhecimento Complexidade
- 11. Planejamento por Tamanho G M P Dúvidas Técnicas Esforço Dúvidas de Negócio
- 12. Fluxo do Conhecimento - Conhecimento + + Riscos -
- 15. Sapatos On-Line Permitir e-commerce de sapatos
- 16. Sapatos On-Line Permitir e-commerce de sapatos Bruno Jr Roger, Lara, Joyce, Maria, João
- 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
- 18. 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
- 19. 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
- 20. 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
- 21. 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
- 22. 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
- 23. 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
- 24. 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
- 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 Critérios de Aceite Definidos Definition Of Ready F2
- 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 Spikes Definition Of Ready F2
- 27. 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
- 28. Planning Poker Comunicação Transferência de Conhecimento Analogia Desagregação Triangulação
- 29. 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
- 31. Métricas [Velocidade] Lead Time 1pt 3pt 5pt 2 dias 9 dias 4 dias
- 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 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 __/__/__
- 33. 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
- 34. Cases
- 40. +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
Notas del editor
- 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