The post (Português) A Confiança do PO no Time tem que ser Criada appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post (Português) Na Sprint zero, entenda seu projeto com 6W2H appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Esse artigo é baseado em uma discussão em uma reunião de projeto e propõe para discussão mais ampla uma pequena adição opcional ao SCRUM.

A questão discutida foi:

Quanto vocês estimam de esforço para fazer o que vou pedir.

O motivo foi que o PO necessitava de uma função porém, como não era essencial, só estava disposto a pagar uma certa quantidade de pontos de esforço por ela. Caso ela ultrapassasse o limite estabelecido por ele, outras funcionalidades eram mais importantes.

A proposta que fica é que o PO sempre tenha ideia de qual o valor, em pontos de esforço, ele estaria disposto a pagar para ter certa funcionalidade e ficar satisfeito. Representaria, de certa forma, o "preço justo" do PO para aquela funcionalidade.

Isso lembra um pouco a prática original de definir o valor de negócio da história de usuário, porém a unidade daquele valor nunca foi estabelecida como a mesma unidade de esforço, e o conceito de preço justo também nunca foi citado.

Por que isso seria útil?

Primeiro, podemos ao longo do tempo acertar o conceito do "preço justo" com o "preço técnico", aquela previsão de esforço feita pelo Time. Isso faria com que o PO tentasse compreender melhor a dificuldade de implementação das funcionalidades e também que a equipe tentasse entender melhor se sua velocidade está atendendo as expectativas do usuário.

O estabelecimento da razão preço justo/preço técnico, que chamaremos de razão de produção, também serviria como padrão de produtividade que ajudaria a balizar uma equipe SCRUM em relação às outras, principalmente quando o PO fosse o mesmo. Assim, uma equipe que produzisse duas vezes mais pontos de esforço que outra equipe só teria essa diferença confirmada caso sua razão de produção fosse a mesma.

Também ajudaria a definir prioridades, pois implementar histórias com maior razão de produção é mais eficiente e provavelmente agregaria maior valor ao PO.

Como desvantagens, podemos analisar que seu uso no início do projeto é bastante complicado para o PO. Porém, podemos estabelecer uma técnica semelhante à usada para estabelecer o padrão de medida de pontos de esforço, i.e., escolher a menor tarefa do primeiro Backlog de Produto e dar o valor 2 para ela.

A ideia é que após a equipe estimar pela primeira vez suas histórias o PO daria o preço justo para elas de forma que a história que adicionasse a menor quantidade de valor na primeira Sprint tivesse o preço justo de 2.  

Fica agora para o leitor a pergunta: você já fez algo parecido? Qual a sua opinião? Qual a sua experiência?

The post (Português) Quanto quer pagar? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Esse é o segundo artigo inspirado na leitura do livro "Conversations For Action and Collected Essays: Instilling a Culture of Commitment in Working Relationships", Fernando Flores e Maria Letelier.

No primeira artigo (O Scrum Coordena Ações de Forma Completa) discutimos como os quatro ato de fala essenciais para o sucesso de uma conversação para ação aparecem no SCRUM.

Lembramos que esses quatro atos de fala são:

1. o pedido do cliente,
2. a promessa do executor,
3. a entrega pelo cliente e
4. a aceitação pelo executor.

Uma questão importante no livro é sobre como os interesses do cliente devem ser endereçados pelo executor quando tenta completar as condições de satisfação do cliente em relação à ação sendo tomada.

É importante entender que um cliente, quando solicita um objeto ou serviço, não está diretamente interessado naquele objeto ou serviço, o que eu chamo em sala de aula como o "objetivo" do cliente, mas sim em atingir alguma meta de negócio, o que eu normalmente defino como o "interesse do cliente". Assim, quando um cliente solicita um relatório, por exemplo, não está propriamente interessado no objeto relatório, mas sim na forma como vai usar as informações do relatório.

A questão importante é que os pedidos são normalmente feitos de forma objetiva, muitas vezes escondendo deliberadamente as preocupações ou interesses do cliente. Assim, se um cliente deseja poder estudar quais seus melhores clientes ele provavelmente vai pedir para a equipe um "Relatório de Venda por Cliente, ordenado pelo valor comprado". A equipe, desconhecendo o verdadeiro interesse, vai fazer exatamente esse relatório, atendendo as condições de satisfação explícitas, mas não atendendo condições implícitas.

A solução para isso é não só entender O QUE deve ser feito, mas PORQUE deve ser feito.

Uma história do usuário bem definida deve dar essa informação ao desenvolvedor.

Consultando a página de Wikipedia para "user stories" é possível encontrar pelo menos quatro formatos básicos. Não é de se espantar que três desse formatos não se preocupem apenas com o que deve ser feito, mas também o porquê de estar sendo feito.

O formato original de uma User Story é:

Como <papel>, eu quero <objetivo/desejo> de forma a <benefício>

Assim nosso pedido deveria ser inicialmente:

— Como gerente, eu quero o relatório de vendas ordenado por valor, de forma a conhecer meus melhores clientes.

Já podemos ver que a equipe poderia perguntar um pouco mais e propor outros relatórios, ou outras formas de entregar a informação "melhor cliente", ou questionar qual é esse valor (receita total, lucro total, período de tempo, etc…). Porém, como a verdadeira função do desenvolvimento é entregar valor, Criss Matt sugere uma inversão:

Para <receber benefício> como <papel>, eu quero <objetivo/desejo>

No nosso exemplo:

— Para conhecer meus melhores clientes, como gerente, eu quero o relatório de vendas ordenado por valor.

A diferença é pequena, mas podemos entender que o foco da frase muda do relatório para o motivo.

Finalmente, minha preferida usa o conceito do 5W.

Como <quem> <quando> <onde>, eu quero <o que> porque <porque>

No nosso exemplo:

— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores clientes.

E, após uma discussão hoje em uma reunião de projeto poderia ainda adicionar:

Como <quem> <quando> <onde>, eu quero <o que> porque <porque>, por <quanto>

No nosso exemplo:

— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores clientes, por até 8 pontos de esforço.

Dessa forma, conhecendo os verdadeiros interesses do PO, a equipe pode realmente agir para melhorar o projeto ao fazer sua promessa.

The post (Português) O Cliente Não Quer o Que Pede appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Ao analisar o Scrum podemos nos perguntar que conceitos reconhecidos nas técnicas de gerência de projetos estão incluídos, mesmo que de forma implícita, para tentar entender por que um método com tão pouca estrutura funciona tão bem.

Aproveitando a leitura de "Conversations For Action and Collected Essays: Instilling a Culture of Commitment in Working Relationships", uma coleção de artigos não publicados de Fernando Flores editados por sua filha Maria Letelier, podemos entender melhor algumas de nossas práticas. Flores é um pesquisador e empresário na área de coordenação de trabalho. Suas teorias foram aplicadas em vários produtos de diferentes empresas. Entre suas motivações está melhorar os processos de gerência.

Uma de suas teses é que quando estabelecemos uma conversação para que uma pessoa, o cliente, obtenha um serviço de outra, o executor, devemos passar por quatro atos de fala: o pedido do cliente, a promessa do executor, a entrega pelo executor e a aceitação pelo cliente. Apenas quando passamos por todos esses passos um trabalho está completo.  

Os problemas de gerência acontecem quando esses dois atores e quatro atos de fala não são claros ou não são feitos:

• clientes e executores mal definidos,
• pedidos mal feitos,
• promessas não cumpridas,
• entregas não informadas e
• aceitações não executadas ou postergardas (para quando é tarde demais para refazer o serviço não conforme)

são as pragas que assolam a gerência. Esses atos de fala precisam ser explicitados e isso é responsabilidade dos métodos e ferramentas de gerência.

Analisando o Scrum podemos ver que ele atende perfeitamente as condições de Flores, explicitando os atores e cada uma das fases.

Primeiro ele exige que existam esses dois atores, o cliente e o executor. Claramente o cliente no Scrum é o Product Owner, enquanto o Time é o fornecedor. Não há necessidade que essa conversação seja feita por apenas duas pessoas e podemos aceitar o Time claramente como o segundo ator. Porém também devemos entender que o Time entra na conversação como um “todo”. Assim todos são responsáveis por suas promessas.

Uma história de usuário no Product Backlog corresponde a um pedido do cliente. Quando esse pedido é estabelecido inicia-se o que Flores chama de estágio de negociação. O objetivo dessa negociação é que cliente e executor concordem nas Condições de Satisfação, outro termo específico que significa as condições que tem que ser preenchidas pelo executor, muitas delas inicialmente implícitas. É importante que o executor entenda os interesses reais do cliente em relação à tarefa. Um bom exemplo usado no livro é o cliente solicitar ao executor que passe o grampeador. Caso o executor passe um grampeador sem grampos ele provavelmente cumpriu exatamente o que o cliente pediu, mas como não atendeu as verdadeiras expectativas do cliente, i.e. grampear folhas, seu trabalho foi inútil.

Quando o Time aceita uma história do usuário no Sprint Backlog ele está fazendo uma promessa. Nessa promessa ele se compromete a atender todas as condições de satisfação dentro do prazo combinado com o cliente (no caso, o fim da Sprint). A promessa termina o estágio de negociação e muda o universo. Agora o cliente espera que a promessa seja cumprida e vai agir no futuro confiante disso.

Com a entrega o executor avisa ao cliente que terminou o seu serviço. Mas isso não encerra o processo, pois o cliente tem que poder verificar se o serviço foi feito e dar o aceite. Esses dois passos são feitos na Reunião de Revisão.

Vemos então que com seus poucos mecanismos o SCRUM garante que todas as ações combinadas entre as partes passem pelos quatro estágios que Flores considera essenciais para uma boa coordenação de ações.

The post (Português) O Scrum Coordena Ações de Forma Completa appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.