Pré Game: Cascata, agilidade ou apenas opção para o mundo real?

Oi pessoal.

Este post tem que ter uma menção honrosa ao Eduardo D’avo, que me pediu pra pensar num método sobre Pré Game.

Vou contextualiza-los:

Trabalho numa grande (e muito legal e feliz) consultoria. Nós atuamos em muitos projetos e nem sempre nossos clientes conhecem Agile. Ou mesmo os que conhecem optam, por vezes, em não trabalhar desta forma e esse é o mundo real. Como todos aqui somos profissionais, e provavelmente não compramos as casas na praia que queremos ou viajamos pra todos lugares que desejamos, nós não negamos fogo a projetos “não ágeis”.

Sem duvida, não deixamos de explicar os benefícios do filosofia Agile (junte Lean aqui, ok) e de trabalhar com essa mentalidade, mas muitas vezes o cliente não abre mão da aceitação formal de fases, mantém o conhecimento em silos, deseja estimativa para saber prazo e custo e as outras maravilhas que todos conhecem. Então, nós aqui na Empresa fazemos um Pré Game.

O Pré Game consiste, no nosso caso, num curto espaço de tempo antes do início do desenvolvimento em si (das iterações) aonde averiguamos o contexto do Negócio (Projeto ou Produto) especulamos sobre seus objetivos, sua forma de gerar Valor e a quem ele gera valor. Também fazemos uma análise sobre as principais necessidades dos clientes e começamos a especular sobre as principais funcionalidades. Quando o caso é projeto, muitas vezes o Cliente já tem uma documentação preparada e tem seus Domain Experts.

Neste caso, literalmente sugamos o conhecimento junto ao Domain Expert, criamos conexões com os usuários e fazemos um reconhecimento da documentação existente. A questão é, Por que fazemos isso a invés de começar logo a desenvolver?

A resposta: Estamos no mundo Real!

Se pegarmos a documentação já existente, toma-la como correta e definitiva e começarmos a desenvolver, alguém aqui arrisca o resultado? Sim, o resultado será MERDA. Não por falta de qualidade ou incompetência. Sabemos o resultado de conhecimento de negócio colocado em papel, como forma de comunicação. Dá merda.

Outro ponto também: muitas vezes o cliente documenta o DESEJO e não o REQUISITO. E o pior: REQUISITO sem conhecimento do domínio do NEGÓCIO é como sexo sem órgão genital. O Pré Game, no nosso caso, serve também para criar a ponte entre o Cliente e o Time, fazer a contextualização sobre o Domínio do Negócio, unir as pessoas e criar o elo indivisível entre aqueles que querem entregar valor.

No nosso Pré Game, começamos a entender o que é desejo, o que é requisito e junto do Cliente buscamos o MPV (minimo produto viável) e criar o Plano de Release. É normal o cliente pedir tudo sem saber do valor sobre o que ele está pedindo. E ele acha que tem que pedir tudo pois provavelmente já teve experiências tristes e frustadas em outras consultorias, aonde coisas de valor pra ele, quando ele não especificou logo no começo do projeto e foi pedir depois, foi tratada como “change request” e foi um transtorno pra ser feito.

O nosso Pré Game serve como meta-game para educar o cliente, sem ele pedir está educação. E sem duvida nosso Pré Game também serve para outra coisa, que gera polêmica: ESTIMATIVAS. No nosso Pré Game, muitas vezes listamos as principais funcionalidades, as entendemos e estudamos sua complexidade técnica e em muitos casos, fazemos POCs.

E geramos uma potencial estimativa para ser feito o MVP. Ao longo do nosso processo de Pré Game, o cliente vai sentido que ele não precisa conhecer ou dominar todo o escopo. Explicamos o que realmente é uma estimativa e como vamos trata-la ao longo do projeto. Porém, por mais bonito que seja o discurso Ágil, e muitos sabem o quanto eu advoco por ele, muitas vezes os clientes não querem isso. Eles querem estimativa e prazo. Nossa artimanha para tentar ir quebrando esse medo e necessidade deles é o Pré Game.

Lá se vão 1 ano e 2 meses que estou aqui. Lá se vão 5 projetos que atuei diretamente e outros N > 10 e < 20 Pré Games feitos em propostas que não vingaram ou estão para vingar e o resultado tem sido muito bom. 2 casos recentes foram muito interessantes:

1 – Um cliente começou um projeto conosco mas por questões políticas internas deles, foram obrigados a parar.

Eles não poderiam fazer o projeto conosco por questões de contrato com outros parceiros e tal. Mas assim que isso se resolveu, eles nos escolheram não só pra terminar o projeto quanto começar um outro grande projeto.

O diferencial: O mote como fizemos o Pré Game e a concepção do MPV deles.

2 – Outro cliente que teve no seu Pré Game grandes descobertas de valor, graças a estudo de mercado e falseamento de hipóteses.

Ao fim do Pré Game, toda uma cadeia de valor foi estudada, grandes e inovadoras funcionalidades foram testadas em POC e hoje o produto ta no ar já dando o ROI esperado. E vem mais Releases dele…

Seria muito fácil para nós, negarmos fazer um projeto por sentir que o cliente não “deseja” Agile. Porém seria, IMHO, muito infantil da atitude de um profissional. Nosso Pré Game é um Meta Game de ensino de Agile. Sim, nós fornecemos estimativas e prazos, mas damos a estes o valor que eles merecem. Nada mais do que chutes ao vento cujo toda iteração iremos avaliar.

O ouro do nosso Pré Game é: O aprendizado junto ao cliente sobre o negócio e seu valor, gerando a integração entre stakeholders e Time, ao mesmo tempo que fornecemos o aprendizado em Agile, criando um elo de confiança.

No nosso Pré Game, sempre buscamos integrar o máximo possível de membros do Time junto aos stakeholders. Abaixo, seguem imagens do método de nosso Pré Game, de um material que gerei graças ao pedido do Edu.

Eu soltei ele pra Comunidade pois quero coletar feedback:

Pré Game

stakeholders

roi

fronteira

macrovisaofuncionalprovaconceito

meta

Anúncios

Domain Game – Uma dinâmica para todos

Desenvolver um produto requer muita comunicação. Os desafios de se transferir conhecimento são grandes. Bem como o desafio de se ter um bom ambiente onde desenvolvedores, testers e outros papéis técnicos consigam se comunicar com eficácia e eficiência com aqueles que dominam o negócio acerca do produto.

Foi tendo este desafio em mente que criei o “Domain Game”.

O Domain Game é um Agile game que visa auxiliar a ardua tarefa de disseminação de conhecimento, de uma forma simples e divertida.

O Domain Game se baseia no Domain Drive Design onde, através do Domain Model e a Ubiquitous Language podem ser geradas perguntas que são apresentadas ao Time de desenvolvimento. Vamos explicar a dinâmica.

O Product Owner junto do Domain Expert, Analista de Negócios e Clientes geram uma série de perguntas em torno de Domain Model do produto, exemplo:

Digamos que estamos tratando do desenvolvimento de um software de Nota Fiscal Eletrônica, podemos formular algumas questões:

  • O que significa NFe?
  • Para que serve uma Nota Fiscal?
  • O que siginifica DANF?
  • O que siginifica ICMS?
  • O que signifca ISS?
  • Qual a diferença entre tributo, imposto e taxa?
  • É correto afimar que existem mais tributos que impostos?
  • Quando é emitida uma Nota Fiscal Eletrônica?

Uma vez geradas estas perguntas, podemos reunir todos envolvidos possíveis numa sala.

Product Owner, Analistas de Negócio, Domain Expert e Cliente irão fazer o papel do “Caixa”. Tanto o Caixa quanto cada membro do Time começam o jogo com uma quantidade de bombons, semelhante ao “stack” do Poker.

O Caixa irá realizar uma pergunta para um membro do Time por vez. Se o membro do Time acertar a pergunta, ele recebe um bombom do Caixa. Se ele errar a resposta, ele dá um bombom para o caixa.

O jogo pode ficar ainda mais interessante. Caso o Caixa realize uma pergunta a um membro do Time, e este dar uma resposta e outro membro do Time achar que aquela não foi a resposta correta e quiser responder a pergunta do Caixa, ele pode desafiar a resposta do membro anterior. Aí, a quantidade de bombons envolvidas na aposta aumenta.

 

 

 

 

 

 

 

 

 

Quem acertar, leva os bombons envolvidos na disputa. Se ambos errarem o Caixa leva tudo.

O jogo não tem uma busca por vencedor. O ideal é que se estipule um Time Box para se jogar. Ao final do tempo, uma boa dica é juntar os bombons e repartir entre todos, com todo mundo que estiver por perto, pelo caminho e etc.

Ao final do jogo, podemos fazer um Retrospectiva para avaliar como o Domain Model  está absorvido pelo Time. Nesta Retrospectiva podemos verificar tais pontos:

  • Entendimento sobre o Domínio: O Time teve muitas duvidas quanto as perguntas realizadas?
  • Entendimento sobre a lingaguem do Domínio: O Time compreende os jargões e metáforas?
  • Ambiente saudável: O jogo foi jogado de forma descontraída e alegre? Houve pressão?

O Domain Game não tem regras especifícas. Ele tem diretriz. Você pode adaptá-lo para jogar em pares, grupos, usar tabuleiros. Busque apenas criar um bom ambiente e através dele, fortalecer o entendimento do Domínio.

O Domain Game é um jogo integrativo. Visa aproximar o Cliente e especialistas do Negócio ao Time de desenvolvimento, gerando uma interação mais amigável e sustentável.

Eu já utilizei o jogo em Domínio muito complexos e com várias pessoas envolvidas e os resultados foram bons. Geralmente o aplico no início do desenvolvimento do produto ou de um novo módulo, para podermos validar nosso entendimento.

Eu apresentei o Domain Game em uma Talk no Agile Brazil 2011.

Aqui estão os slides da apresentação.

Utilize também e compartilhe os resultados.