Seu backlog está em ordem?

Então você deseja implementar o Scrum? Então preste atenção.

Este é o passo 1 da minha série: "Como implementar Scrum em 10 passos simples".
É muito importante considerar que este não é apenas o primeiro passo, mas sim o passo mais importante.
Se você for capaz de dar esse primeiro passo, posso lhe garantir que você irá longe.
Você vai sentir como com este passo você beneficia sua equipe e sua organização.
Vamos lá?
Em primeiro lugar, por onde você deve começar? 

1) Alinhar com negócios
Antes de fazer qualquer outra coisa, todo Product Owner deve alinhar sua equipe de desenvolvimento com o negócio. 
Se você já faz parte de uma unidade de negócios, isso deve ser natural e simples.
Se por algum acaso você atende várias unidades de negócios, desenvolvendo vários produtos, deve ser mais trabalhoso.
Neste momento eu peço que tenha pelo menos 1 pessoa dedicada ao produto, onde você deverá começar a implementar o Scrum.

2) Criar o Backlog de produtos 

Agora todo P.O deve criar o Backlog de produtos. 
Você provavelmente precisará criar ou facilitar a criação do Backlog do Produto. 
Estritamente falando, o backlog de produtos deve ser de propriedade do Proprietário do Produto. 
O Backlog do produto, na sua forma mais simples, é uma lista de coisas que as pessoas desejam para o produto, em ordem de prioridade. 
Note: Qualquer pessoa pode adicionar ideias ao Backlog do produto. 
No processo Scrum e nos princípios de desenvolvimento ágil geralmente são colaborativos e inclusivos. 
Desta forma mudanças sempre são bem vindas.. 
Mas considere isto, é muito importante que apenas o Proprietário do Produto priorize o Backlog do Produto. 
O Backlog do produto deve conter coisas relacionados ao produto. Melhorias. Projetos inteiros. Problemas. Riscos. Qualquer coisa. 
Dito isto, os itens no Backlog de produtos devem, idealmente, ser expressados ​​em termos comerciais que sejam de algum valor para o usuário (ou cliente ou empresa). Os requisitos funcionais devem ser expressos como recursos. Os requisitos não funcionais também podem ser colocados no Backlog, por exemplo, "o produto precisa ser mais rápido", "precisamos garantir que o produto seja seguro", "precisamos sair da plataforma antiga", há um alto risco Do tempo de inatividade devido a um único ponto de falha ". Estes podem não ser características, como tal, mas são completamente justificadas como itens no Backlog do produto.

 
3) Priorize o Backlog

O Proprietário do Produto prioriza o Backlog do Produto. Eles não categorizam as prioridades 1, 2, 3 ou qualquer coisa assim. A prioridade é determinada simplesmente pela ordem da lista. O Proprietário do Produto coloca o Backlog do Produto em ordem de prioridade.
As coisas na parte inferior da lista podem estar fora e podem ou não ser feitas. As coisas no fundo provavelmente ficarão distorcidas e mal definidas. Não perca tempo definindo coisas que você nunca pode chegar ou não chegar por algum tempo. Se algo é uma má idéia, o Proprietário do Produto deve explicar a quem solicitou o motivo pelo qual eles estão removendo-o do Backlog. No entanto, se algo não é uma má idéia, embora nunca seja feito, basta colocá-lo em seu lugar legítimo baixo no Backlog e explique ao solicitante onde ele se encaixa com as prioridades.
Na verdade, isso é como filas. Ou em uma linha. Estamos todos acostumados a isso. As pessoas geralmente aceitarão isso. Fornecer a autoridade do Proprietário do Produto foi comunicado e tem suporte de gerenciamento, as pessoas irão ocupar seu lugar na fila.
Muitas vezes em equipes de desenvolvimento, não há uma visibilidade clara da fila. As pessoas não sabem quanto tempo é a fila. E eles não sabem quantos estão à sua frente. Isso geralmente leva a impaciência e queixas, porque é a única maneira de avançar e avançar na linha.
A visibilidade do Backlog do produto pode resolver esse problema.

4) Defina Scrum Master 
Então agora você está organizado. 
Você está alinhado com negócios. 
Você tem 1 produto ou gama de produtos. 
Você tem pelo menos 1 pessoa dedicada ao produto (ScrumTeam). 
Você possui 1 Proprietário do Produto. 
Você tem 1 ScrumMaster, que deve ser responsável por apoiar a Equipe Scrum, treinando e 
orientando-os através desse processo e removao quaisquer impedimentos que bloqueiam seu progresso.

E tão mais importante que isto.

Os passos acima podem ter um efeito poderoso ...

A priorização é agora um desafio de negócios. 

A dinâmica, ou trade-off entre adicionar itens e fazer mais, ou esperar pacientemente na fila, é agora uma decisão comercial. 
Uma conversa mais adulta? Qual custo versus benefício. 
Viu só, nosso problema agora não é mais entregas.

E sim de escolhas.

E pense em um problema técnico ou risco que faz com que você perca o sono, mas você nunca recebe o tempo para abordar. 
Coloque-o no Backlog. 
O Proprietário do Produto pode decidir que outras características mais visíveis devem ter prioridade. 
Mas se o risco o morder, foi uma decisão comercial informada para suportar o risco. 
Com toda certeza a propriedade do risco é transferida com sucesso.
As coisas para o topo do Backlog do produto podem ser feitas de maneira previsível. 

Portanto, é provável que sejam melhor compreendidos. 
E eles precisam e devem estar suficientemente bem definidos para que a equipe possa trabalhar com eles. 

Embora esses recursos (ou itens de Backlog) devem ser definidos individualmente, para que eles possam ficar sozinhos como peças de trabalho 
discretas e entregues. 

Então, você tem isso. Agora você tem uma equipe Scrum. 
Um ScrumMaster. 
Um Proprietário do Produto.  
Um Backlog de produtos. 

Você já alinhou sua equipe com o negócio. 
Você criou uma visão clara do produto. 
Você obteve o trabalho de sua equipe priorizado. 
E você possui um sistema, um mecanismo, um sistema de filas, para priorizar de forma contínua.

10 Comments

0

Post A Comment