Aula 05 Vídeo 2 - Os épicos do exemplo não ficariam melhor sendo outros projetos?

Oi Rafael, tudo bem?

A decisão é do Dono do Produto com feedback do time de dev.

Se o Dono do Produto determinar que não vai priorizar os Épicos em um mesmo projeto, então ele vai acabar direcionando o time de desenvolvimento para um dos Épicos e focar o esforço no que julgar mais importante.

Se, colaborando com o time, ficar claro que é melhor para o projeto juntar tudo no mesmo esforço, então com apoio da equipe de Dev o Dono do Produto - representando a voz do cliente - vai buscar uma priorização que reflita o feedback da equipe e os interesses desse cliente.

No fim das contas, apesar de ser incumbência do Dono do Produto priorizar, é o time de desenvolvimento que vai dar os insumos necessários para a decisão sobre "manter estes épicos em um projeto ou separar".

É minha opinião sobre o caso.

Outro ponto importante é que programas são um conceito da gestão clássica de projetos, que talvez possam gerar conflito ou confusão no meio ágil.

É preciso saber qual o modelo de gestão da empresa antes de determinar a técnica de gestão a ser empregada - seja híbrida ou Scrum puro, por exemplo.

Abraços,

Frederico

Tudo bem,

Obrigado pela resposta Frederico, de fato entendo que o backlog seja de responsabilidade do dono do produto, contudo me perguntava se existiam dicas (como code smells) que apontassem que talvez um determinado épico seja grande demais para ser um épico e talvez tenha que ser um projeto ou que determinado épico seja muito pequeno para ser um épico e talvez estivesse mais para uma história.

Como você disse em seus vídeos é quase que automático para quem vê o levantamento de épicos no inicio de um projeto pensar em atividades preditivas, fiquei pensando se há algum método para evitar superestimar determinados épicos.

Digo isso pegando o exemplo do avião por exemplo, meu entendimento é que embora não seja possível entregar um avião em uma sprint poderiamos entender que o projeto do avião não está entregue na primeira entrega.

Neste exemplo poderiamos ter a entrega do avião apenas com a classe economica e com o mínimo de controles e sensores que pudesse voar entre 1000 e 5000m dentro das primeiras entregas e com o tempo implementar novos recursos como primeira classe, melhor fuselagem para aguentar maiores altitudes, melhores ssitemas de combustível para aguentar maiores distâncias e afins.

Digo isso pensando neste exemplo em entrega de valor, por exemplo, após as primeiras entregas a empresa já poderia começar a oferecer voos comerciais econômicos ex. SP->RJ (1h +-), após a próxima entrega eles já podem cobrar mais de passageiros por causa da primeira classe, na próxima entrega podem viajar maiores distâncias e mais alto permitindo expandir seu negócio a outros estados.

Desta forma agregando valor de forma iterativa.

Digo isso porque assusta um pouco a visão onde todos os épicos listados parecem ser parte vital de um sistema para seu funcionamento, por exemplo trazendo para software alguém me levanta para um sistema de loja virtual os seguintes épicos:

1. Contas para clientes. (formas dos clientes se cadastrarem, se identificarem e serem associados a compras).
2. Carrinhos de compras. (forma de coletar produtos para pagamento)
3. Gateways de pagamento. (forma de pagamento)
4. Vitrine de produtos (páginas do site)

E não listarem mais épicos, entendo que seja possível ter outros épicos neste exemplo, não sei se fui claro em minhas dúvidas e apreensões.

Tenho gostado do que vi e estou em uma equipe que está adotando scrum, gostei de várias coisas que não sabia sobre scrum, como as técnicas para priorização e planejamento, mas ainda gostaria de me sentir mais seguro sobre a geração de épicos.