Olá amigos,
Dando continuidade a série de artigos sobre Agile Think® Business Framework, uma proposta para auxiliar Product Owners, Business Owners, analistas de negócios, gerentes de produtos e afins no design e gestão de produtos.
Relembrando os artigos anteriores:
- Parte 1 – Apresentação geral e histórico do framework
- Parte 2 – Apresentação dos processos envolvidos no planejamento estratégico dos produtos
- Parte 3 – Apresentação dos processos de descoberta do produto utilizando Design Thinking
- Parte 4 – Apresentação dos processos de definição do produto utilizando Design Thinking
- Parte 5 – Apresentação dos processos de desenvolvimento do produto através de técnicas de Inception
Neste artigo, vamos entender os processos de entendimento de como transformar a ideia desenvolvida nas etapas anteriores em um backlog de produto, identificando o Produto Mínimo Viável (MVP).
A sub etapa de Definir MVP é composta por quatro processos:
- Escrever Histórias: A escrita das Histórias do Usuário é a etapa de organização das informações já levantadas, com a documentação das etapas anteriores do Agile Think® Business Framework. É quando o representante do cliente, junto com o Time de Projeto, cria as histórias que serão utilizadas como scripts do trabalho para a equipe. Os requisitos do produto, bem como os demais artefatos e documentos gerados devem estar aderentes às necessidades do produto, fechando uma versão para iniciar seu planejamento. Com as informações do produto descritas na forma de histórias de usuário é possível realizar o entendimento do trabalho do time, tornando todo processo de planejamentomais crível e compreendido por todos os envolvidos na construção do produto. Isso não apenas reafirma a priorização feita anteriormente, como também estabelece o conjunto de funcionalidades mais importantes, documentando as funcionalidades que precisam ser validadas pelo cliente.
- Critérios de Aceite: A definição dos critérios de aceite representa as regras estabelecidas para que uma funcionalidade seja implementada no formato de história de usuário. Conforme falamos no início deste capitulo, no Agile Think® Business Frameworkas atividades de escrita das histórias do usuário e a definição dos critérios de aceitação ocorrem praticamente juntas. No entanto, a grande dúvida que paira é: Como surgem os critérios de aceite da história do usuário? Os critérios de aceite surgem durante a conversação da equipe junto ao cliente, durante o workshop de escrita das histórias do usuário. Geralmente, as perguntas feitas pelo time ao representante do cliente, no momento em que a história está sendo descrita, já permitem estabelecer os cenários que devem ser testados e entregues ao final da construção.
- Critério de Preparado: O critério de preparado(ou Ready, em Inglês) é um acordo feito entre o representante do cliente e o time do projeto para estabelecer um conjunto mínimo de informações para os itens de maior prioridade do Backlog do Produto, definindo como este deve ser preparado para o trabalho da equipe. O conceito de “preparado” está diretamente ligado aos trabalhos da equipe durante as sessões de refinamento, quando são definidos quais itens devem ser separados para o desenvolvimento nas próximas iterações de trabalho. Um requisito ou história do usuário é considerada preparada para o desenvolvimento quando está escrita de forma clara e entendível por todos do time. Cada história deve estar num nível de granularidade adequada, possibilitando que uma história possa ser entregue numa única iteração. Embora esse tipo de critério possa variar de equipe para equipe, quase sempre é necessário que além das histórias escritas, esse contenha protótipos e critérios de aceite bem definidos.
- Critério de Pronto: A definição do critério de pronto (ou Definition of Done) é um acordo feito pelo representante do cliente com o time do projeto onde se estabelece os artefatos e necessidades que devem ser atendidas e fazer parte da entrega do produto, para que este seja considerado finalizado ao final da etapa de validação. Esse acordo é definido junto com o cliente, quem estabelece quais os padrões que a equipe deverá seguir e aplicar durante a execução do seu trabalho. Costumamos dizer que é quando definimos “O combinado que não sai caro!”. Trata-se então de uma norma a ser seguida desde o início do projeto, evitando que surjam problemas e conflitos relacionados ao não entendimento do que é necessário; tanto do ponto de vista do cliente, como para que uma entrega o produto finalizado.
No próximo e último artigo desta série, vamos entender como transformar todas as etapas anteriores em um planejamento de entregas na linha do tempo, devidamente priorizadas e estimadas.
Abraços e até o próximo artigo! 😉
