Times ágeis constantemente encontram-se frente a frente com algumas perguntas cruciais na hora de desenvolver um como chegar ao backlog do produto? Como construir algo que tenha valor? Como encontrar a real necessidade do cliente? Como definir o que é prioridade no primeiro momento? Como refinar os itens do backlog? Movido pelo objetivo de clarificar esse caminho muitas vezes complexo, Fábio Aguiar desenvolveu o método Product Backlog Building, o PBB. Junto de Paulo Caroli, criador do método Lean Inception, eles apresentam um guia prático para quem deseja construir um produto de sucesso, criando e refinando o backlog. Ao incorporar o PBB no fluxo de desenvolvimento de produtos, seguindo o passo a passo apresentado nesta obra, você e seu time conseguirão, de maneira • Construir um entendimento compartilhado da necessidade do produto;
Iniciei esta leitura para aprimorar alguns conhecimentos para o trabalho. Este livro complementa o framework Scrum e é centrado na construção do backlog de produtos. Apresenta dicas táticas para projetos de desenvolvimento de software e aborda demais temáticas sobre agilidade. Com certeza irei reler! Vale a pena para quem trabalha em tecnologia ou tem interesse no assunto.
Iniciei esse livro quando trabalhava como Product Owner (PO) e estava enfrentando problemas para a construção do backlog, então entrei em contato com o Paulo Caroli, expliquei minha situação e ele mesmo recomendou esse livro. O livro é muito bacana, mas também precisa de uma boa dedicação prática para ser eficiente, o que não consegui fazer.
Ótimo livro! Eu acabo de encerrar o curso de marketing e o conteúdo desse livro está completamente alinhado com o que estudei em Gestão de Projetos.
As explicações são rápidas, objetivas, com exemplos claros, boas ilustrações e, pelo menos para mim, fica muito claro como as teorias citadas podem ser postas em prática.
Com uma escrita objetiva e repleto de exemplos práticos, a obra do Fabio e do Caroli apresenta o PBB (Product Backlog Building) que representa um guia prático de como construir o escopo de trabalho de um produto digital. A seguir, listo alguns dos aprendizados extraídos a partir da leitura: - A grosso modo o backlog é uma pilha de pedidos em espera. - Um item de trabalho é um requisito e um requisito de software consiste na definição documentada de uma propriedade ou comportamento que um produto particular deve atender. - É importante observar a granularidade do do backlog e o PBB sugere: funcionalidades, histórias de usuário e tarefas. - Identificar os problemas, levantar as expectativas com o produto, descrever as Personas, listar as funcionalidades e mapear os passos que serão oferecidos pelas funcionalidades permitirão a construção de um backlog de produto consistente. - O modelo ARO (ação, resultado e objeto) pode ser uma forma de descrever um item do backlog de produto. Exemplo: Visualizar (ação) o extrato (resultado) da conta corrente (objeto). - A frequência com que a pessoa usuária utiliza um item do backlog de produto pode ser uma variável de priorização (ex: hora a hora; diário; semanal; mensal; trimestral). - Uma demanda para ser entendida como pronta para ser trabalhada ao conter as seguintes características: - A equipe possui a informação necessária para trabalhar no item? - O porquê está explicito? - É possível compreender o que é necessário para que haja o término do trabalho? - O item possui uma relação com uma funcionalidade? - Uma outra técnica que pode ser aplicada para garantir que a demanda de trabalho está devidamente refinada é a técnica criada pelo Manoel Pimentel chamada TAPA: tangível (a história é tátil, concreta e específica), atômica (a história é pequena e independente), preciosa (a história resolve um problema importante para quem é usuária) e acessível (a história é de claro e fácil entendimento).
Bastante objetivo. Acho que entre as técnicas ainda tem alguns sonhos mirabolantes como o vamos juntos aqui ficar 8 horas trabalhando em backlog que nunca vai acontecer. Mas manter os contratos com o time de definição de pronto (ready) e definição de feito (done) é essencial. Algumas vezes quando a pressão aperta e algumas dessas boas práticas são abandonadas, refinamento é deixado de lado, tentam paralelizar tudo ao invés de organizar direito habilitadores/tarefas antes de funcionalidades, fica difícil convencer o time a abandonar o caos depois.
Absurdo de bom! Demonstra passo a passo, detalhadamente, como construir e como refinar o backlog de produto de forma colaborativa com o squad. O livro é bem completo, então aborda proriozação de PBIs, como escrever histórias, como definir critérios de aceite, definição de ready e done entre outros pontos essenciais. É um bom livro pra começar com refinamento de Backlog.
Pra quem é dev chega a emocionar os exemplos de história no Trello kkk Como descrito no livro o método é simples, rápido e enxuto. Leitura prazerosa visto que a edição lembra muito o estilo Head First. Parabéns aos envolvidos.
Livro prático e direto, apresenta abordagem que pode ser aplicada subsequentemente ao workshop Lean Inception. Ele torna a criação de hostórias de usuários uma ação colaborativa e dinâmica, alinhada às expectativas e problemas dos usuários e às definições do MVP.
Uma boa referência para construção de backlogs. Um pouco raso na teoria mas bastante pragmático e prático. Ponto ruim: simplificação extrema dos níveis de backlog. Ponto legal: o canvas é um ótimo suporte pra questões didáticas
Achei bem simples e poderia ser mais curto até mas a metodologia é bem simples e prática. Se vc trabalhar com scrum e lean inception se encaixa mto bem.
O livro atende exatamente à seu propósito: explicar de maneira clara, simples e direta o uso de uma ótima técnica de criação e organização Backlog. Já vou colocá-la em prática!!
Li por recomendação do meu PO e foi muito bom para eu entender mais sobre o trabalho dele. Indico para as pessoas que querem melhorar o backlog do produto, como as histórias de usuários.
Fábio e Paulo apresentam neste livro uma técnica para construção e evolução de backlogs para desenvolvimento de produtos digitais. Ainda precisarei aplicar a técnica na prática, mas já tendo realizado Lean Inceptions (prática autorada pelo Paulo e livro que também recomendo aos interessados), tenho expectativas muito boas quanto aos resultados.
Não atuo diretamente como PO/PM, mas já tendo alguns anos de experiência com Scrum, Kanban e XP, gostei de encontrar um bom referencial de boas práticas e dicas que poderão ajudar no meu dia a dia, independente da aplicação da técnica (por exemplo, não conhecia o acrônimo ARO - Ação-Resultado-Objeto, usado no livro para descrever items de backlog e spikes).
Por fim, da perspectiva de desenvolvedor, recomendo a leitura do livro e a aplicação da técnica PBB como proposta de método para times ágeis colaborarem na construção de backlogs em conjunto com seus POs/PMs, tornando essa etapa colaborativa.
Definitivamente farei uma indicação para meus colegas desenvolvedores e de produto.