Olá nesse vídeo vamos falar sobre desenvolvimento de software na Perspectiva do Product owner o dono do produto essa aqui é a Pat ela é uma product owner ela tem uma visão muito clara do produto ela não sabe ainda os detalhes do que que o produto vai fazer mas sabe o por que estamos construindo que problema ele vai resolver e para quem ela fala sobre isso o tempo todo esses aqui são os stakeholders os interessados no projeto eles são as pessoas que vão de fato usar o sistema dar suporte ou que vão ser de alguma forma
afetadas por ele a visão da Pat é que essas pessoas vão gostar muito do sistema e vão usá-lo o tempo todo as necessidades dos stakeholders são expressas como histórias de usuário por exemplo em um sistema de reserva de voos as pessoas precisam conseguir pesquisar por um voo essa seria uma história de usuário os stakeholders TM um monte de ideias e a Pat é quem ajuda a dividi-las em Stores de usuário agora Alguém precisa construir o sistema esse aqui é o nosso time de desenvolvimento por serem de um time ágil eles não fazem uma única entrega
enorme no final do projeto ao invés disso eles entregam cedo e com frequência geralmente quatro a seis histórias por semana essa é a capacidade desse time é fácil medir é só contar o número de histórias entregues por semana algumas histórias são grandes por isso contam como duas outras são pequenas e contam como meia mas no fim das contas acaba sendo em torno de quatro a seis histórias por semana para conseguir manter esse ritmo e não ficar sufocado com teste de regressão manual o time investe fortemente em testes automatizados e integração contínua toda funcionalidade tem testes
de aceitação automatizados e a maior parte do código tem teste de unidade Só que tem um problema a gente tem vários stakeholders pedindo todo tipo de coisa eles Com certeza não vão se limitar a quatro a seis histórias por semana eles têm um monte de ideias e desejos e sempre que a gente entrega uma versão eles vão ter ainda mais ideias e vão pedir mais coisas mas o que acontece se a gente tentar fazer tudo o que eles pedem a gente vai ficar sobrecarregado Imagine que o time comece a trabalhar por exemplo com 10 histórias
novas por semana se a entrada é 10 e a saída é algo entre quatro e seis o time vai ficar sobrecarregado de trabalho isso atrapalha o foco do time é desmotivante e acaba causando uma saída ainda menor e de pior qualidade é ruim para todo mundo é como tentar enfiar mais papel na impressora para que ela Imprima mais rápido ou mais carros uma Rodovia já congestionada não vai funcionar a maneira pela qual o scrum e o XP evita esse problema é conhecer Como o clima de ontem o time fala bom nas últimas semanas terminamos por
volta de quatro a seis histórias Então quais são as quatro a seis histórias que devemos construir na semana que vem o trabalho do produto owner é descobrir de todas as histórias possíveis Quais são as quatro a seis que devemos fazer agora a maneira que o kamban trata o mesmo problema é limitando o trabalho e andamento Suponha que o time decide que cinco é o número ótimo de histórias simultâneas permite que haja tarefas para todo mundo mas sem sobrecarga então eles decidem que cinco é o limite para o trabalho em andamento ou work in Progress sempre
que eles terminarem uma história eles vão aceitar iniciar uma nova mas garantindo que o limite de cinco não seja ultrapassado essas duas abordagens funcionam muito bem elas vão gerar uma fila na entrada do time que no scrum é chamada de backlog do produto mas essa fila precisa ser gerenciada se os stakeholders continuarem pedindo 10 histórias novas toda semana e o time entrega de quatro a seis essa fila vai ficar cada vez maior Logo logo a gente vai ter uma lista de desejos para mais de 6 meses de trabalho Isso significa que em média Cada história
que o time entrega é de algo que foi pedido por alguém se meses atrás isso não é nada ágil só tem uma forma de impedir que essa fila saia de controle é dizer Não essa é a palavra mais importante para um produto owner e a p pratica todos os dias na frente do espelho dizer sim para uma nova solicitação é fácil o trabalho mais importante do produto owner é decidir o que não desenvolver e assumir as consequências dessa decisão o produto owner decide o que entra e o que sai ele também decide a ordem o
que vamos construir agora e o que fica para mais tarde é um trabalho difícil e precisa ser feito envolvendo o time e os stakeholders para poder priorizar o produ owner precisa ter uma ideia do valor de cada história e também do seu tamanho algumas histórias são extremamente críticas outras são só desejáveis algumas levam horas para desenvolver outras podem levar meses mas qual que é a relação entre o valor de uma história e o seu tamanho nenhuma maior aqui não significa melhor pense em algum sistema que você use Com certeza ele vai ter alguma funcionalidade muito
simples que é também muito importante que você usa todos os dias e tem também aquelas funcionalidades complicadíssimas sem nenhuma importância é só a gente lembrar do famoso clips do Microsoft Office alguns anos atrás o valor e o tamanho são o que ajudam a parte a priorizar de forma inteligente essas duas histórias são mais ou menos do mesmo tamanho Mas tem valores diferentes Então vamos construir esta primeiro e aqui essas duas histórias TM mais ou menos o mesmo valor mas tamanhos diferentes Então vamos construir esta primeiro e por aí vai mas tem uma coisa como que
a parte sabe o valor de uma história e como ela sabe o tamanho aqui vem a notícia ruim ela não sabe é um jogo de adivinhação e é um jogo onde todos são envolvidos a p conversa o tempo todo com os stakeholders para descobrir o que eles valorizam mais e conversam o tempo todo com o time para descobrir o que eles acham que é grande ou pequeno em termos do esforço de implementação são aproximações chutes mesmo não são números absolutos eu não sei quanto pesa essa maçã ou aquele morango mas eu tenho certeza que a
maçã pesa pelo menos cinco vezes o peso do morango e que para mim morango é mais gostoso que maçã isso é tudo o que a pate precisa para priorizar o backlog no início de um projeto os nossos chutes vão est inevitavelmente errados Mas não tem problema o mais importante aqui tá nas discussões e não nos números em si toda vez que o time entrega alguma coisa para usuários reais Nós aprendemos algo e vamos melhorando nossas estimativas de valor e de tamanho é por isso que nós priorizamos e estimamos o tempo todo continuamente tentar acertar tudo
no início não dá certo é justamente quando nós sabemos menos sobre o projeto e sobre o produto esse feedback é o nosso grande aliado mas a priorização ainda não acabou para entregar cedo e frequentemente a gente precisa quebrar as histórias em pedaços pequenos de preferência em algo que leve poucos dias para ficar pronto nós buscamos esse formato de funil com histórias pequenas e Claras na frente e histórias mais vagas atrás fazendo essa quebra só no momento certo nós temos a vantagem de poder aproveitar os últimos insights sobre o produto e as necessidades dos usuários tudo
isso que falamos até agora estimar o tamanho e valor das histórias priorizar dividir é o que é geralmente chamado de backlog grooming a part faz um workshop para isso toda quarta-feira de 11 da manhã ao meio-dia todo time participa e às vezes alguns stakeholders também a pauta varia algumas vezes o foco natim ativa outras na quebra de histórias e outras são para escrever os critérios de aceitação para uma história Provavelmente você já percebeu o tema aqui é comunicação o papel do Product owner tem tudo a ver com comunicação quando perguntamos a product owners o que
é mais importante para ter sucesso eles costumam sempre enfatizar entusiasmo e comunicação não é à toa que o primeiro princípio do Manifesto ágil é que indivíduos e interações entre eles são mais importantes que processos e ferramentas o trabalho do Product owner não é ficar dando histórias muito mastigadas e detalhadas pro time isso é chato e ineficaz a pate ao contrário procura ter certeza de que todos entenderam a visão que o time está em contato direto com os stakeholders e que é um ciclo rápido de feedback com entregas frequentes a usuários reais dessa forma o time
aprende e pode tomar decisões o dia a dia por conta própria enquanto a Pat pode se concentrar em coisas mais abrangentes há vários tradeoffs que a Pat e o time tem que fazer primeiro tem um tradeoff entre diferentes tipos de valor no início de um projeto a A incerteza e o risco são os nossos inimigos tem o risco de negócio a gente tá construindo a coisa certa tem o risco social essas pessoas conseguem desenvolver tem um risco técnico vai funcionar na plataforma em que queremos vai ser possível escalar e tem um risco de custo e
cronograma será que a gente vai conseguir completar o produto em um tempo razoável e a um custo razoável conhecimento é o oposto do Risco quando a incerteza é alta o nosso foco é em ganhar conhecimento focamos em coisas como protótipos de telas e experimentos técnicos não são coisas muito empolgantes PR os clientes mas são valiosas e nos ajudam a reduzir o risco na Perspectiva do cliente a curva no início Parece isso aqui a medida que a incerteza diminui a gente vai focando gradativamente em mais e mais valor pro cliente agora que sabemos o que e
como fazer é só fazer e como começamos com as histórias de maior valor a gente consegue esse crescimento na curva de valor E aí gradualmente essa curva começa a se estabilizar já construímos o que é mais importante agora estamos só adicionando as funcionalidades de bônus a cobertura do bolo é um bom lugar da curva porque a qualquer momento a Pat e o time pode decidir cortar essa cauda e ir para algum projeto mais importante ou mesmo iniciar um novo grupo de funcionalidades pro mesmo produto isso é a agilidade de negócio então quando falamos de valor
estamos falando da soma de valor de conhecimento e valor para o cliente a gente precisa encontrar um bom equilíbrio Entre esses dois outro tradeoff é o pensamento de curto prazo versus o de longo prazo o que devemos desenvolver em seguida corrigir aquele bug urgente Construir aquela personalidade nova que os usuários vão adorar ou fazer aquela mudança de plataforma complicada mas que vai nos dar mais produtividade no futuro a gente precisa sempre equilibrar o trabalho reativo e proativo apagar incêndios e prevenir incêndios isso tá relacionado a um outro tradeoff a gente deve focar em construir a
coisa certa em construir certo ou em construir rápido idealmente a gente quer os três mas é difícil encontrar esse equilíbrio Suponha que a gente esteja aqui tentando construir o produto perfeito com arquitetura perfeita se a gente gastar muito tempo tentando chegar a essa perfeição a gente pode perder a janela de mercado ou então cair em problemas de fluxo de caixa ou Imagine que a gente esteja aqui correndo para tentar fazer algum protótipo virar um produto minimamente usável ótimo pro curto prazo mas lá na frente a gente vai cair em déficit técnico e nossa velocidade vai
cair para próxima de zero ou Imagine que a gente esteja aqui construindo uma catedral linda em tempo recorde Só que tem um detalhe os usuários não precisam de uma catedral o que eles estão precisando aqui na verdade é de uma Kombi há uma tensão saudável nos papis do scrum os product owners vão focar mais em construir a coisa certa os times em construir corretamente e o scrum Master tende a focar mais em curtar O Ciclo de feedback velocidade é algo muito importante um ciclo curto de feedback acelera o aprendizado e com isso é possível aprender
mais rapidamente o que é a coisa certa e como construí-la corretamente mas todas essas três perspectivas são muito importantes por isso a gente deve encontrar um equilíbrio por último a o tradeoff entre o desenvolvimento novo e melhoria de produtos o termo backlog do produto confunde porque passa a ideia de que é somente um produto e o termo projeto também confunde porque implica que o desenvolvimento do produto termina quando o projeto acaba um produto nunca está terminado tem sempre manutenção e melhorias a fazer até que o produto chegue no fim da vida e seja desligado então
quando o time começa a desenvolver um novo produto o que acontece com o que foi desenvolvido antes migrar o produto de um time para outro é caro e arriscado o cenário mais comum é o time continuar mantendo o produto anterior enquanto desenvolve o novo nesse caso a gente não tem de fato um backlog de um produto é mais um backlog do time uma lista de coisas que o produ owner quer que o time construa pode ser uma mistura de coisas de diferentes produtos o produo owner lida com esse tipo de tradeoff o tempo todo de
vez em quando um stakeholder liga para Pat e pergunta quando que as solicitações dele vão estar prontas ou o que que vai estar pronto até o Natal como uma product owner a Pat é responsável por gerenciar essas expectativas ou mais importante gerencias de forma Realista e isso significa não mentir pode ser difícil mas é muito importante não é difícil dar uma previsão desde que ela não tenha que ser exata se você medir a velocidade do time ou a velocidade combinada de todos os seus times você pode fazer um gráfico de burnup das histórias esse gráfico
mostra o número acumulado de histórias entregues ao longo do tempo ou em Story Point se você preferir perceba a diferença essa curva mostra a saída produzida aquela curva mostra resultados obtidos uma é saída a outra é o resultado que esperamos obter com ela a nossa meta aqui não é produzir o máximo de saída possível a meta é produzir o resultado desejado usando o mínimo de saída possível menos é mais Olha esse gráfico de bap e trace uma linha de tendência otimista e outra pessimista você pode fazer isso tanto com ferramentas complicadas de estatística ou pode
simplesmente desenhá-las visualmente a distância entre essas linhas está relacionada com quão inconstante e imprevisível é a nossa velocidade isso tende a se estabilizar com o tempo e com isso o nosso cone da Incerteza deve ficando mais e mais estreito Mas vamos voltar à gestão das expectativas Suponha que o stakholder Pergunte a Pat quando todas essas coisas aqui vão estar prontas quando estaremos aqui essa pergunta tem um escopo fechado e o tempo é variável a Pat usa as duas linhas de tendência para responder provavelmente algo entre abril e meados de Maio imagina agora que os stakholders
perguntem o quanto vamos conseguir fazer até o natal essa é uma pergunta de tempo fixo e escopo variável as linhas estão mostrando provavelmente terminaremos tudo isso um pouco disso e nada disso suponha agora que os stakeholders digam a gente pode ter tudo isso até o natal essa é uma pergunta de tempo e escopo fixos olhando as linhas de tendência a parte diz olha Sinto muito mas não vai ser possível isso aqui é o quanto teremos pronto até o natal ou então esse é o tempo que precisamos para fazer tudo isso geralmente é melhor reduzir o
escopo do que estender o prazo Porque se reduzimos o escopo primeiro Ainda temos a opção de estender o prazo de depois e adicionar o restante das histórias o contrário não funciona porque a gente não consegue fazer o relógio andar para trás a parte torna essa escolha fácil ela diz a gente pode entregar alguma coisa aqui e o resto depois ou então não entregar nada aqui e o resto depois o que vocês preferem os cálculos são todos muito simples de fazer por isso a Pat atualiza essas projeções toda semana o mais importante aqui é que a
Pat tá usando dados empíricos para fazer uma previsão ao invés de se basear no que ela quer que aconteça ela está sendo honesta com tem certeza lembra que antes a gente disz sobre não mentir essa é uma forma muito honesta de comunicar com os stakeholders e eles geralmente gostam disso mas é importante fazer um alerta Se o time estiver acumulando déficit técnico se não tiver escrevendo teste se não estiver melhorando continuamente a arquitetura ele vai ficar cada vez mais lento e a curva de banear de história vai parar de crescer isso torna praticamente impossível prever
o futuro por isso o time é responsável por manter um ritmo sustentável e a Pat Evita ficar fazendo pressão para que eles tomem algum tipo de atalho outro recuperem esses cuidados E se tivermos um projeto maior com vários times ao invés desse time com cinco pessoas podemos ter três times e podemos ter vários produt owners cada um com seu backlog para uma parte diferente do produto em linhas Gerais o modelo é o mesmo a gente continua precisando gerenciar nossa capacidade comunicar com os stakeholders precisamos de product owners que digam não e de fazer o backlog
grooming velocidade nesse caso é a soma de todas as saídas e pode ser usada da mesma forma para fazer projeções ou então faça projeções paradas Para cada time se isso fizer mais sentido só que no cenário de múltiplos times os product owners T uma responsabilidade a mais eles têm que conversar uns com os outros a gente precisa organizar os backlogs de cada time para minimizar essas dependências isso depende de um sincronismo entre os produ owners para que as coisas sejam feitas na ordem certa em projetos grandes é comum ter alguém no papel de líder dos
product owners para mantê-los sempre sincronizados Ok é isso o papel do produ honer em 15 minutos n
