Agregar valor

Olá, Wagner

O scrum possui pequenas entregas de valores individuais que vão se integrando a cada sprint para atingir o objetivo final. Agregar valor é continuamente entregar novas funcionalidades de acordo com o que foi solicitado.

Agregar valor é um dos 12 princípios do Manifesto Ágil. Para realizar esse principio é produzindo o software o mais breve possível e de forma continua. Quanto mais cedo o cliente receber software, mais cedo ele pode testá-lo, usá-lo e melhorá-lo. Receber software de forma contínua significa que o cliente terá periodicamente novas funcionalidades em suas mãos. Receber o software mais rapidamente e constantemente pode significar vantagens competitivas para o cliente na área em que atua. Isso é agregar valor para o cliente.

Wagner, se posso contribuir ao seu entendimento, pense no cliente como uma torcida de futebol. Agregar valor ao cliente seria, na mesma proporção, fazer gols para a torcida.

O valor agregado satisfaz o cliente através das entregas de requisitos funcionais, como um relatório de clientes inadimplentes, e não funcionais, como o aumento na velocidade do fechamento de pedidos.

Gostei da comparação Marcelo! É desse jeito!

Entregar valor é entregar algo que realmente faça a diferença para os clientes/usuários e principalmente entregar o produto que satisfaça suas necessidades. É, por exemplo, entregar funcionalidades que efetivamente serão utilizadas pelo cliente/usuário. Por exemplo, digamos que eu estou fabricando um carro e uma das características que eu entrego é a possibilidade de ele andar na areia em um país que não existem praias ou terrenos semelhantes. Perceba que as pessoas não irão utilizar e nem enxergam sentido nisso pois não possuem essa necessidade. Em startups é muito comum utilizarmos um MVP (Minimum Viable Product ou Mínimo Produto Viável) para testar junto aos clientes se o produto realmente tem sentido (ou valor) para o cliente, isto é, se realmente ele está utilizando e seu problema está sendo atendido ou resolvido. Se não faz sentido, nem deveria ser desenvolvido/construído.

Complementando, existe uma técnica que é utilizada para atribuirmos valor para cada item de backlog do produto (requisitos do usuário): MoSCoW. O M do MoSCoW quer dizer Must Have (Deve Ter) – Tudo o que é imprescindível para o escopo do projeto. Aquelas funcionalidades CORE da sua aplicação, que sem elas a aplicação perderia totalmente o sentido. O S quer dizer Should Have (Deveria Ter) – Tudo o que é importante ter no escopo do projeto, mas que não são imprescindíveis. Funcionalidades que se por ventura não forem desenvolvidas, não farão com que o produto perca o seu valor de negócio. O C quer dizer Could Have (Poderia Ter) – Tudo o que seria bom ter, mas não são importantes. É mais ou menos como a cerejinha do bolo. Na maioria das vezes, clientes aceitam comer bolo sem cereja, até porque, bolos sem cerejas são mais baratos. O W quer dizer Won’t Have for Now (Não Terá por Enquanto) – Tudo o que não será desenvolvido por enquanto, pois as features classificadas com won’t have for now, não geram valor de negócio no momento. Maiores detalhes podem ser consultados nesse link: (https://cafecomscrum.com/2015/11/07/priorizando-backlog-com-a-tecnica-moscow/)

Essa classificação é de responsabilidade do PO - Product Owner que também define a prioridade de cada item, ou seja, o que deve ser entregue primeiro.

Tem uma coisa que começamos a fazer quando o cliente diz que tudo é prioridade. Simplesmente perguntamos, quando você pensa neste projeto, qual seria a primeira necessidade que vem na sua cabeça. Pronto. Aquilo teoricamente agrega mais valor porque é o que ele está precisando no momento.

Tem funcionado até agora. ;)