Definition of Ready
julho 19, 2010
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.
Ainda sobre a Retrospectiva…
julho 7, 2010
Para que as reuniões de retrospectiva proporcionem o crescimento do time e do processo de trabalho, é interessante que as pessoas se preparem.
Algumas sugestões:
- Preparação: É interessante que durante a iteração, cada membro do time tenha um controle pessoal dos pontos positivos e negativos que foram ocorrendo no dia-a-dia. Desta forma todos chegarão à reunião melhor preparados, e o risco de que se esqueçam de citar algum assunto relevante é menor.
- Tiro ao Alvo: As pessoas devem ser breves e objetivas quando forem falar. As emoções devem ficar do lado de fora da sala de reuniões.
- Tempo definido: É importante que a reunião tenha uma hora limite para acabar, porém as decisões não precisam ser tomadas as pressas. Se necessário o time deve marcar um novo horário para discutir sem pressa algum assunto que mereça maior atenção.
- Ataques pessoais podem ser evitados: Quando algum membro do time não gostou da atitude de outra pessoa, talvez seja mais produtivo e apropriado que o feedback ocorra individualmente (cara-a-cara) do que tratar o assunto na frente de todo o time.
- Ambiente: Se possível as reuniões devem ocorrer em um ambiente diferente daquele que o time passa o tempo todo trabalhando. Ambientes descontraídos colaboram para que as pessoas entrem “desarmadas” na reunião.
Retrospectiva Sim, Choradeira Não
julho 6, 2010
A reunião de retrospectiva é um bom momento para o time levantar pontos positivos e negativos que ocorreram durante a iteração.
Mas cuidado, reunião de retrospectiva não é local de choradeira.
Sempre levante pontos negativos com educação e cordialidade, lembre-se que pessoas não cometem erros propositadamente.
E muito importante, além de levantar um ponto negativo sempre passe ao time uma sugestão de ação para melhoria, ou caso contrário você estará apenas “choramingando”.
