Dia 2 - CSM - ScrumAlliance - AdaptWorks

15 de Ago de 2016 — Diego Eis

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