Anotações do segundo dia do treinamento CSM feito na AdaptWorks. As anotações do dia 1 está aqui.

Product Owner

  • O PO tem contato forte com o cliente e usuários
  • O PO não precisa ser o cliente, mas dependendo do cliente, pode ter o papel do PO.
  • talvez numa empresa que esteja no estado da arte do relacionamento com o cliente, se torna interessante que eles sejam o Product Owner. Eles conhecem o projeto, eles entendem que é o dinheiro deles que está em jogo, mas eles teriam que conhecer Agile e Scrum ou pelo estarem dispostos
  • O Product Owner garante se o produto está certo e que vai satisfazer o cliente/usuário
  • O PO é responsável pela visão do produto
  • Dessa visão combinada entre PO e Cliente, surge o coração do Scrum, que se chama Product Backlog
  • se o Backlog está muito tempo parado, quer dizer que o PO parou de pensar em novas funcionalidades, ele parou de pensar nos próximos passos para o produto
  • SM precisa perguntar: qual problema essa funcionalidade vai solucionar? Tem outro produto no mercado que resolve esse problema? Como eles resolvem? Por que eles resolvem diferente de você?
  • gerencia os stakeholders. Os stakeholders veem o PO como o responsável pelo projeto, é quem eles procuram pra pedir contas
  • PO conversa com os stakeholders sobre budget, report de projeto
  • do relacionamento entre DevTeam e PO, surge o Sprint Backlog
  • O Sprint Backlog válida as tarefas. O Dev Team pergunta pra o PO se a tarefa pode ser aceita
  • ele dá e recebe feedback sobre as tarefas. Por isso que há mudança de escopo.
  • Em vez de esperar pra ter o contato no final da sprint, tenha o contato no inicio, pra poder modificar rápido
  • Através dessa comunicação, o PO aceita ou rejeita entregas. Critérios de aceite devem estar bem claras para que o time cumpra os requisitos
  • O PO é extamente o que o Founder faz em uma startup.
  • A estrutura do Scrum é uma estrutura enxuta de startup
  • O ScrumMaster faz apenas o gerenciamento do processo e pessoas. Onde nessas conversas do PO o Scrum Master está? Em todas, por tem pessoas em todos os lugares
  • scrum master entende sobre discussão e mediação de consenso.

Dev Team

  • Quando você tem uma estrutura organizacional onde os times são funcionais, você ganha:
    • em produtividade, porque o time é especializada em sua responsabilidade
    • aprendizado especializado.
    • mas você precisa que a cadeia inteira funcione pra gerar valor, por que times assim não entregam valor sozinhas, elas dependem de outros
  • se você tem um time multifuncional ou equipes de valor, você tem todas as skills para gerar valor diretamente para o cliente
    • ganha na geração de valor
    • potencializa aprendizado generalista
    • Em compensação, os integrantes desse time precisam entender um pouco mais sobre as skills de outros integrantes
  • desenvolvimento web teams em scrum, funcionam em times funcionais
  • quanto mais tradicional for sua empresa, mais difícil de implementar o modelo de equipes de valor/multidisciplinar
  • Foco do Scrum não é produtividade, é entrega de valor. Você deve buscar produtividade, dentro da geração de valor
  • McDonalds entre muito hambúrguer, com sabor razoável, prefere produtividade, repetição
  • Hamburgueria Gourmet entrega hambúrguer esplêndido, único, prefere entrega de valor
  • Se uma hamburgueria gourmet demora 2 minutos pra entregar o lanche, você vai achar estranho.
  • Se o McDonalds demorar mais do que 15 minutos pra entregar o sanduíche, você vai achar estranho
  • No Scrum você procura entregar, de forma produtiva, num âmbito de time, não individualmente. Você mede a entrega do time, não do indivíduo.
  • Isso não quer dizer que todos do time devem ser generalistas e devem saber tudo. O time é multidisciplinar e não os integrantes
  • Quando o integrante é compartilhado, ele não tem comprometimento em nenhum dos projetos.
  • o time precisa ser auto-organizado
  • Auto-organizacao não tem nenhuma relação com maturidade.
  • Auto-organizacao é da natureza do ser humano. Todo mundo, de alguma forma, se auto-organiza em algum nível
  • A auto-organizacao precisa de um esforço, ela só acontece quando tem um desassociais fatores: desejo ou necessidade
  • O time tem o desejo de se auto-organizar?
  • O time tem a necessidade se se auto-organizar?
  • Quando o sucesso do projeto depende do resultado de todos os times, o time precisa se cobrar por auto-organizacao
  • O scrum master precisa criar desejo é identificar a necessidade
  • Mais metas compartilhadas e menos metas individuais ajuda a auto-organizacao
  • é para criar desejo? Momentos de integração fora do trabalho, criar empatia entre os integrantes do time

fluxo

  • Backlog é uma lista de pedaços do produto, em níveis de granuladidaxes diferentes em diferentes posições no Backlog, sem muitos detalhes
  • O Backlog é priorizado, onde está mais pro topo, são as tarefas que entregam muito valor pro negocio / cliente
  • De acordo com que você vai pegando itens do topo, as tarefas vão subindo e você precisa ir quebrando as histórias que estão mais pra baixo, dando mais detalhes sobre o objetivo da tarefa
  • ele precisa estar em constante mudança, refletindo as mudanças das descobertas do time e do PO junto ao cliente
  • O Backlog alimenta o Sprint, onde colocamos as tarefas para a linha de desenvolvimento
  • Uma sprint é uma timebox, que tem uma estrutura pré-definida
  • Toda sprint tem:
    • uma reunião de planejamento, sprint planning
    • um período de desenvolvimento, pra desenvolver o incremento
    • Sprint Daily
    • Sprint review
    • Sprint retrospective
  • O scrum propoe que o sprint seja de 1 a 4 semana. Não menores que uma semana nem maiores do que um mês.
  • Em cada final da sprint, precisa haver o incremento, entregando valor para p usuário
  • No Sprint Planning, decide-se as tarefas que vão para o sprint Backlog
  • Retrospectiva fazemos a inspeção e a mudança no processo.
  • O sprint é feito pra ter feedback rápido do cliente e PO
  • Quando entregamos pedaços pequenos via sprints, conseguimos saber se o projeto está indo pra um caminho certo
  • Não quer dizer que temos que entregar valor em produção pronto pra o cliente usar

Product Backlog

  • a visão do produto, se materializa no Product Backlog
  • A visão não faz parte do core do Scrum, por que você só tem uma visão de onde você quer chegar, isso quer dizer que há um final.
  • Se você trabalha com produto, é necessário ter uma visão, pra sabermos onde estamos indo, mas podemos começar a fazer direto o Product Backlog sem depender de uma visão
  • Você não fala de esforço, você fala de tamanho
  • O Backlog é composto de itens. Para escolher os itens, você escolhe uma técnica pra escrever esses itens
  • Quanto mais próximo do topo do Backlog estiver o item, mais clara e menor ele deve estar
  • O nível de incerteza em volta dos itens que estão na parte de baixo do Backlog, é enorme
  • Se o Card está lá Pra baixo, quer dizer que ele não está claro, não está detalhado, está nebuloso ainda
  • Você sobe as tarefas conforme a tarefa vai ficando mais madura, com mais detalhes, com mais valor
  • a maioria dos itens do Backlog, devem representar uma parte real do produto. Isso se chama item de negócio. São itens funcionais, que vão entregar um comportamento novo no produto
  • Nunca vai ter no Backlog algo como: criar tabela no banco de dados. Subir máquinas para produção
  • Cada item tem que entregar algo material, real, palpável sobre o produto.
  • Ou seja, ele não pode ser baseado em trabalho. Eu como PO, preciso que os devs criem um banco de dados é um péssimo item.
  • no Backlog podem haver também bugs, que não entrega um comportamento novo, mas corrige algo que foi feito no passado
  • é podem haver os itens técnicos, como POC, Spikes, Provas de Conceitos, que vão gerar uma entrega de decisão e não algo funcional.
  • Nos itens técnicos, também podem ter dívidas técnicas.
  • Um bug só é bug se a tarefa foi aceita e foi pra produção ou pra alguma área de teste e foi encontrado um problema
  • retrospective e review, consomem 5% da sprint
  • Planning meeting, também 5%
  • Na Planning meeting:
    • Participa os três papéis, SM, PO e Dev Team
    • dividido em duas partes: um planejamento mais estratégico: O Que. Outra parte mais mão na massa: Como
    • parte 1: O Sprint precisa ter um Goal. Tem que ser uma meta de negócio. Tem que dar um benefício pra o usuário. O time precisa ver um propósito.
    • A meta determina se o sprint foi bem sucedido ou não
    • me diga como você mede, que eu digo como entrego.
    • Uma sprint é bem sucedida ou não se ela entregou o esperado e não se ela entregou o estimado
  • Na parte 2, o Dev Team deve identificar tecnicamente qual trabalho deve ser executado para ter aquela tarefa feita
    • é aqui que eles criam as famosas tasks, que são todos as tarefas técnicas para entregar as histórias da meta
    • o que nós precisamos fazer para que essa tarefa esteja pronta no final da sprint?
    • PO tem que participar da segunda parte? Não, ele precisa estar acessível para o time nesse tempo!
  • definition of done é quando a tarefa está pronta pra ser entregue para o PO
  • a Daily é uma reunião de Dev Team para Dev Team.
    • O que fiz?
    • O que farei
    • Impedimento?
    • Tanto o PO quanto o SM são opcionais na Daily, porque a discussão da Daily é para discutir coisas micro.
    • So existem duas dailies, a que correta e a que o PO estava.
  • review e retrospective são duas reunião com o mesmo propósito. A review foca no produto, retrospective foca no processo
Compartilhe este post