Ultimamente temos falado muito sobre mecanismos ágeis para gerenciar projetos, direcionando-os em Scrum. Este novo mecanismo de conduzir projetos tem-se mostrado a muito tempo extremamente eficiente não somente na condução de projeto de T.I. também em vários outros segmentos, especialmente quando falamos sobre a geração da Release do Produto e sobre a Visão do Produto Scrum.
Mas para que tal eficiência seja atingida é necessário, como também nas demais metodologias, a definição das Metas a serem atingidas.
Hoje falaremos então sobre as Metas do Scrum, o que são, como defini-las e porque as mesmas são tão importantes.
Tanto para Sprints quanto Releases de um projeto, o Time de Desenvolvimento sempre trabalhará nos itens de maior importância para os itens de menor importância com o objetivo de alcançar um objetivo ou meta de negócio clara e atingível.
A meta ou objetivo no Scrum não pode ser comparado a um valor financeiro, data ou mesmo uma determinada quantidade de trabalho.
Trata-se de uma real necessidade da organização ou do negócio a ser atingida como resultado de todo o trabalho a ser realizado.
Das metas definidas pelo Scrum, identificamos:
Visão do produto scrum
- A visão do produto scrum é o objetivo maior a ser alcançado por meio do desenvolvimento do produto. Ela é estabelecida antes de se iniciarem os Sprints e existe ao longo de todo o desenvolvimento.
Meta da Sprint
- Definida durante a reunião de Sprint Planning do projeto corresponde a um passo em direção à Meta da Release ou de Roadmap;
Meta da release ou de roadmap
- Presente em cada Release do projeto, é estabelecida antes do início da Release. Caso o Time de Scrum realize Releases com alta frequência — a cada Sprint ou em entregas contínuas, podem ser substituídas por metas de mais alto nível, conhecidas como Metas de Roadmap;
Esta, no entanto, não é parte do Framework Scrum mas quando utilizada fornece um contexto para o trabalho do Time de Scrum e alinhamento entre os membros do Time de Desenvolvimento, os clientes do projeto e as demais partes interessadas.
Visão do Produto Scrum
Para Pichler (2010):
A Visão do Produto scrum provê um alinhamento entre todos os envolvidos no projeto, desde os clientes e demais partes interessadas até o Time de Scrum, sobre o que deve ser alcançado.
Para que esse entendimento comum seja possível, é necessária uma Visão do Produto Scrum de fácil compreensão e, assim, é desejável que seja concisa e clara, contendo apenas o necessário e suficiente.
A Visão do Produto Scrum é estabelecida antes que o desenvolvimento do produto se inicie e, de forma geral, permanece estável durante todo o projeto.
Ela é criada, gerenciada e compartilhada pelo Product Owner, que garante que o Product Backlog esteja sempre alinhado com ela.
No entanto, o Time de Desenvolvimento, os clientes e quaisquer outras pessoas relevantes interessadas podem estar diretamente envolvidos no refinamento dessa Visão.
Como é
GeoffreyMoore, no seu livro Crossing the Chasm (Moore, 2001), apresenta um modelo interessante para a Visão do Produto Scrum, o chamado “Teste do Elevador”.
A ideia é que seja possível explicar o que é o produto durante a subida de um elevador, ou seja, em um tempo bastante curto.
Adaptado por Jim Highsmith, esse modelo tem o seguinte formato:
Modelo
- Para (cliente-alvo),
- que (problema ou oportunidade),
- o (nome do produto) é um (categoria do produto)
- que (benefício-chave, razão convincente para utilizar).
- Ao contrário de (alternativa primária competidora),
- nosso produto (diferenciação primária).
Exemplo 1:
Para usuários de Internet solteiros em busca de um relacionamento sério, que estão insatisfeitos com encontros mal sucedidos, o LoveFinder é um site de relacionamentos amorosos que os ajuda a encontrar sua alma gêmea. Ao contrário de sites de encontros populares, nosso produto oferece pretendentes compatíveis comas preferências do usuário, apresentando detalhes suficientes que incluem fotos. |
Exemplo 2:
Para turistas usuários de smartphone, que desejam aproveitar melhor seus locais de destino, o MyTrip é um aplicativo móvel de viagens que sugere roteiros diários flexíveis de acordo com seu perfil. Ao contrário de guias de viagens com roteiros predefinidos, nosso produto elabora trajetos personalizados e adaptáveis. |
O “Teste do Elevador” é um enunciado de Visão do Produto Scrum que mostra-se efetivo ao apresentar quem são os clientes-alvo do produto, qual o problema desses clientes ou oportunidade de mercado que será suprida.
Trata-se de um nome e categorização que fornecem um posicionamento do produto no mercado, uma razão convincente para utilizar o produto e a diferenciação do produto diante das alternativas existentes.
Roadmap do Produto
O Roadmap do Produto é um plano em alto nível que pode ser utilizado para se ter uma visão de como se dará a evolução do produto no futuro.
Esse plano é expresso em uma linha do tempo com datas e objetivos a serem alcançados. Cada um desses objetivos pode ser expresso como uma Meta de Release ou de Roadmap.
Detalharemos a partir de agora cada um dos itens acima citados, apresentando seu significado e exemplos de como implementá-los.
Meta da Sprint
O que é
Já sabemos que em cada Sprint o Time de Desenvolvimento cria um valor visível para os clientes do projeto através de incrementos do produto. A Meta da Sprint então é responsável por traduzir o valor produzido.
Definida e formalizada entre o Product Owner e o Time de Desenvolvimento, com mediação do Scrum Master durante a reunião de Sprint Planning de cada Sprint a ser realizada.
Ao Product Owner cabe a responsabilidade de apresentar durante a Sprint Planning as necessidades do negócio fundamentais para o momento.
Esta meta guiará e fornecerá um propósito ao Time de Desenvolvimento, determinando qual objetivo do negócio é fundamental que seja atendido pelo Incremento do Produto.
Espera-se, desta forma um reforço na auto-organização do Time de Desenvolvimento uma vez que, ao definir a Meta, o Time passa a ser responsável por atingi-la.
Uma vez definida na reunião de Sprint Planning, a Meta da Sprint não poderá mais ser alterada, cabendo ao Scrum Master a responsabilidade de garantir tal integridade.
Por outro lado, e se por algum motivo a Meta perder o sentido, a mesma poderá ser imediatamente cancelada.
Como é
Corresponde a uma e somente uma necessidade necessidade de negócio a ser atingida a partir dos itens selecionados para o Sprint Backlog.
Um formato sugerido pode ser:
- [Por meio deste Sprint,] possibilitaremos <QUEM> a <O QUÊ>
Onde:
Quem | Categoria de usuários, clientes ou partes interessadas |
O quê | Objetivo ou necessidade de negócio a ser alcançado |
Ex:
- Possibilitaremos o comprador a pagar com cartões de crédito;
- Possibilitaremos ao usuário realizar login seguro.
Meta da Release
O que é
Objetivo ou meta de negócio em alto nível a ser atingido através do trabalho do Time de Desenvolvimento para uma entrega ( Release ), correspondendo um passo em direção à Visão do Produto.
Também pode representar um marco no Roadmap do Produto onde cada um deles corresponde a uma entrega do produto.
Como é
O formato das Metas da Release podem ser definidos de acordo com as necessidades do cliente, uma vez que não existe um formato prescrito pelo Scrum.
Ex:
- Por meio da Release/Até <QUANDO>, possibilitaremos <QUEM> a <O QUÊ>.
Quando | Identificador da Release ou Data da Release |
O quê | Objetivo ou necessidade de negócio a ser alcançado |
Ex:
- Por meio da Release #6, possibilitaremos ao cliente realizar seu cadastro completo e integrado com as Redes Sociais.
- Até o final do segundo trimestre, possibilitaremos o cliente oferecer a entrega de produtos com frete grátis.
Roadmap do Produto
O que é
O Roadmap do Produto corresponde a um plano de alto nível indicando como o produto evoluirá ao longo de cada Sprint até o momento futuro determinado.
A responsabilidade de criação, alterações e comunicações do Roadmap é do Product Owner normalmente sendo criado junto ao Time de Desenvolvimento e quaisquer outras Partes Interessadas.
Como é
É representado por uma linha no tempo que contém marcos, ou seja, datas exatas ou aproximadas no futuro e objetivo do produto a serem alcançados em cada uma delas.
Este apresenta o caminho em direção à Visão do Produto. Desta forma é sugerido que se apresente claramente os marcos a meta de negócios que se quer alcançar.
Podem-se também adicionar a cada marco objetivos parciais, sejam técnicos ou de negócios.
Embora não seja recomendável, é também aceitável haver mais de uma Meta de Release ou de Roadmap por marco, em geral direcionadas a diferentes classes de usuários, clientes ou demais partes interessadas.
Conclusão
Conforme apresentado, gerenciar projetos, além de exigir muita criatividade por parte do Gerente de Projetos necessita de definições claras e objetivas do que se pretende atingir.
Desta forma, as definição das Metas apresentadas anteriormente torna-se um mecanismo extremamente útil na vida de qualquer Gerente de Projetos.
Planejar é preciso, mas definir o que se quer deve ser o início de qualquer planejamento.