Agile Think® Business Framework: Uma proposta para o design e gestão de produtos englobando do estratégico ao operacional – Parte 6

AGRADEÇA AO AUTOR COMPARTILHE!

Olá amigos do PTI,

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:

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).

Produto-Minimo-Viavel-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.

Relembrando os artigos anteriores:

Abraços e até o próximo artigo! ;-)

AGRADEÇA AO AUTOR COMPARTILHE!

Vitor Massari

Mais artigos deste autor »

Profissional com mais de 15 anos de experiência em projetos de software. Sócio-proprietário da Hiflex Consultoria, profissional PMP e agilista, acredita no equilíbrio entre as várias metodologias e frameworks voltados para gerenciamento de projetos.
Lema: "Agilista convicto sempre, agilista obcecado jamais"


Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">