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.
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
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
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 do 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