Cartão, Conversação e Confirmação! O conceito 3C.

Padrão

3879260297_dfc867d531
Fichas de papel, cartões de papel ou index cards, são uma excelente forma de manter a vista novas ideias para um produto de software. E a melhor característica delas é o espaço limitado. Hein?

Sim.

Você não vai conseguir colocar toda informação necessária na ficha. E isto é bom, pode acreditar.

Em 2003 quando eu estava estudando eXtreme Programming, ouvi uma história do Ron Jeffries sobre 3C. E desde então eu aplico e ensino isto, pelo valor que esta prática agrega no dia a dia de um projeto.

O conceito do 3C é baseado em iniciar com a escrita de uma ideia em um cartão, para que possamos lembrar. O cartão é o primeiro C. E ele leva ao próximo, gerando um “lembrete para a conversação”.

Que é o que precisamos gerar, conversas. O objetivo com isto é validar as ideias, com pessoas que podem ajudar no tópico. O melhor nestas conversas é criar exemplos que ajudem a validar a mesma. Estes exemplos acabam virando depois cenários de aceitação da história. Se é um cálculo, exemplos de cálculos. Através deste processo, criamos um “cartão executável“. E este é o nosso segundo C. Ah, um cartão normalmente possui um documento auxiliar, onde o requisito em questão é documentado seguindo os padrões que a equipe utiliza.

Estas conversas ajudam o time a identificar alguns atributos para os cartões, exemplo?
- senso de valor
- prioridade
- risco associado
- qualquer-atributo-que-o-time-consiga-ver-valor.

O terceiro C é sobre confirmação. Através das conversas com o time e clientes poderemos entender como validar o cartão e confirmar que o que temos definido é o necessário para “fazer acontecer“. E então é isto que precisamos buscar, confirmação! E dos nossos clientes! Eles irão confirmar sua ideia e ajudar a mesma a crescer.

O que mais sobre cartões?


Jessica Hagy do site Indexed, que conheci por indicação da minha irmã. Você encontra o livro da Jessica na Amazon.

O negócio é o seguinte: um cartão pode fazer muito por você. Até mesmo ajudar você a manter uma conversa com seus clientes. Tente e teste!

Definition of Ready

Padrão

4837626192_d4f1c83ff6

Quando um desenvolvedor vai iniciar o trabalho em uma funcionalidade, ele precisa ter informações mínimas para que este trabalho seja bem sucedido. Entender o que o cliente deseja alcançar na funcionalidade, conhecer o contexto de negócio envolvido, entre outras.

Estas informações são chamadas de “definition of ready” ou “definição de pronto para trabalhar”.

Considere que você tem uma demanda do cliente. Qual a quantidade mínima de informação necessária para dizer que ela pode ser colocada no seu “a fazer”, sendo priorizada?

Veja exemplos de perguntas que devem ser respondidas:

- Quem? É importante que esteja identificado a persona que vai utilizar o recurso que está sendo desenvolvido;

- O quê? Uma breve descrição do que deve ser desenvolvido;

- Por quê? Se o desenvolvedor entender porque determinado recurso foi solicitado a sua chance de desenvolver software aderente as necessidades do cliente serão bem maiores;

- Como? Talvez esta seja uma das informações mais importantes. O desenvolvedor precisa saber como será utilizada funcionalidade que está sendo desenvolvida. Ele precisa saber quais são os critérios de aceitação. Este link pode ajudar.

- Estimativa: É interessante que só sejam iniciadas tarefas que já foram estimadas pelo time, isto para evitar que os desenvolvedores trabalhem em épicos.

Estas informações se relacionam a capacidade do time de entender o que o cliente busca, melhorando a escrita das demandas, seja com as perguntas “Quem, O que, Por quê, Como”, seja com protótipos de papel e outras técnicas que ajudem os 3Cs (um Cartão que gera Conversas que vão gerar Confirmações).

Existem outras dicas para se seguir, como o modelo INVEST, mas isto é assunto para outro post.