UM plano de liberação é um processo de negociação extremamente importante. Deve ser factual, considerando dependências, antecipando riscos e compartilhando com suas preocupações de proprietário do produto, planeja melhorar o produto em requisitos não funcionais (por exemplo, QA, segurança, desempenho, etc.). Você está gerenciando expectativas, desafiando o quão confiável é a previsibilidade de sua equipe de desenvolvimento. Mas você deve considerar apenas o seu MPP? Como você pode evitar emoções no processo de planejamento de liberação?
Alguns posts atrás eu já expliquei os conceitos de produto mínimo viável (MVP) e produto mínimo possível-Verifique o post: você sabe o seu MPP?
Mas eu gostaria de voltar a esses fundamentos, para compartilhar alguns pensamentos e técnicas para tornar o seu processo de planejamento de liberação mais eficiente. Podemos descrevê-lo em 3 fases principais:
Fase 1-quando seu proprietário do produto expressa sua ambição,
Quando seu proprietário do produto expressa sua ambição, sua lista de desejos para essa liberação. Se é um produto brandnew nós chamamos-lhe normalmente o MVP.
Fase 2-a estimativa de Dev Team
Esta é uma tarefa feita em conjunto com o Scrum Master (se fizermos Scrum) ou com o Delivery Manager (se fizermos Kanban).
Se você não fazê-lo regularmente, sua capacidade não irá refletir este fator e você terá um MPP maior do que o que é o real.
Se você não considerar dependências regularmente em suas estimativas, o que eu recomendo que você é para estimar-los juntamente com os épicos. Assim, você pode estimar Epics e resumi-los com os pontos de história estimado para dependências.
Nesta fase, gostaria ainda de deixar algumas considerações sobre:
Ele faz parte da função Dev Team ou Scrum Master para defender essa capacidade.
-Capacidade de bloqueio para as histórias obrigatórias legais.
Tenho certeza que se você fizer este exercício recomendado, provavelmente você vai perceber que o seu MPP inicial será reduzido e que você precisa para entrar em um processo de negociação com o seu proprietário do produto. Você deve estar pronto e apoiado por fatos nesta capacidade normal dentro do tempo de liberação para implantar o valor mais alto para o produto.
Fase 3-o processo de negociação entre o proprietário do produto e Dev Team
Eu recomendo para iniciar este processo de negociação tentando entender o valor individual de cada Epic para o produto ou para o lançamento.
Perguntas como:
- É este Epic trazendo diferenciação competitiva para o produto?
- Nossos concorrentes já têm esse recurso?
- Nossos processos internos ou produtividade estão sendo afetados?
Explique ao proprietário do produto como você está estimando seu esforço em pontos de história.
Tente completar esta matriz juntamente com o seu proprietário do produto:
No x você terá seu esforço de implementação em pontos de história (saída da fase 2), no y você vai distribuir o valor de épicos para o lançamento ou para o produto.
Dependendo do posicionamento das ideias, devemos decidir:
- Go-baixo esforço de implementação-alto valor para o produto/Release
- Investigue-alto esforço de implementação-alto valor para o produto/Release
- Quick WINS-baixo esforço de implementação-baixo valor para o produto/Release
- e no go! -Alto esforço de implementação-baixo valor para o produto/Release
Tenha em mente que você deve considerar as histórias de implementação para cumprir os deveres legais fora desta avaliação, mas bloqueando a capacidade de fazê-los.
Outro conselho é não começar imediatamente todos os Epics possível. Muitas atividades em paralelo não são eficientes. Multitarefa mata produtividade. Devemos apenas começar o desenvolvimento, uma vez que temos orçamento disponível e recursos.
