Posts Tagged ‘lista’

Prática ágil: busque e compartilhe o conhecimento

2 de setembro de 2010

Sintoma: os desenvolvedores de um projeto jamais enfrentaram um tipo de problema e decide resolvê-lo. Uma história começa a ser desenvolvida, mas o mesmo fica parado diversas vezes em pequenos detalhes que impedem completá-la pois ninguém na equipe possui tanta experiência com a ferramenta: existem mais dúvidas do que respostas na equipe.

Ação: participe ativamente em listas e fóruns de discussão de plataformas ou linguagens, como o Tectura, o GUJ ou o guru-sp.

As chances de outras empresas e desenvolvedores terem passado pelos mesmos problemas que nós em algum momento no passado é muito grande. Em toda singularidade de nossos projetos, a similaridade é muito grande.

Em casos pequenos como uma mensagem de erro jamais vista, buscadores são seus amigos, como quando procuramos no google entre as páginas do brasil a mensagem exata de erro “java.lang.IllegalStateException: Response already committed”:

Busca por IllegalStateException

Buscando por uma exception no google entre as páginas do Brasil: ajude a comunidade local a se desenvolver.

Em casos em que não encontrar publicada a resposta para sua pergunta, não deixe de aproveitar para colaborar: compartilhe suas dúvidas e soluções.

Como professores, sabemos que escrever a dúvida ajuda no processo do desenvolvedor entender o seu próprio problema. Ajuda a expressar aos outros um conceito e problema abstrato: algo que requer exercício para dominar.

Quando tentamos explicar o que está ocorrendo conosco para terceiros somos obrigados a pensar nele com mais calma do que o momento de estresse no qual estamos tentando as soluções.

Ao mesmo tempo ajudar outros a resolverem problemas facilita o processo de assentamento do aprendizado uma vez que o processo de explicação exige uma estruturação maior do que foi aprendido. Criar um blog público sobre tópicos do desenvolvimento dentro da empresa e, principalmente no início, incentive a criação de um posts regulares até o momento em que compartilhar as experiências se torne algo natural.

Utilizar os fóruns para compartilhar as idéias, começando novas threads como no caso do Tectura, é um exercício ainda melhor onde não só doamos parte de nosso conhecimento para um mercado de maior qualidade mas também aumentamos nossa capacidade de expressar nossas idéias.

Se o assunto for grande o suficiente, considere escrever para as revistas da área, sites de notícias ou apresentar em grupos de usuários e eventos.

Anúncios

Prática: Evite adivinhar, faça o que é esperado

6 de agosto de 2010

Sintoma: frente a uma duas possibilidades que o cliente não deixou claro, é escolhido um caminho e frequentemente descobre-se ser o errado.

Após a entrega de uma funcionalidade, é o cliente quem testará, aprovará e utilizará a mesma no dia a dia. Uma vez que é difícil nos colocarmos em seus pés e pensarmos como eles, assumir a resposta de uma dúvida como a provável escolha do cliente é um risco muito alto que corremos. Por exemplo:

Para integrar com o sistema de billing, é necessário aceitarmos cartões de crédito, débito ou vale?
Em um caso, a resposta é assíncrona, no outro, síncrona.

O time deve evitar assumir respostas: procure o cliente pessoalmente e faça a pergunta, somente então continue a criação da funcionalidade pelo caminho que o cliente pretende utilizar.

Caso ele esteja indisponível, envie um email para uma lista interna. Durante a espera pela resposta sobre qual caminho seguir em determinada história, evite cruzar a linha da certeza e iniciar a parte da história que envolve um “chute”, principalmente quando mudar entre o escolhido pelo time e as outras opções é custoso para o projeto.

Ao invés da adivinhação, prefira começar uma história nova. Quando terminar essa segunda, analise então se a história parada já possui resposta, se o impedimento foi removido ou se deve continuar com uma terceira história.

Caso costume do cliente demorar pouco tempo para responder, por exemplo vinte minutos, ao invés de começar uma nova história, utilize o tempo para melhorar a qualidade do código, refatorando o mesmo.

A resposta poderá vir na forma de um feedback inicial, somente para permitir o andamento da história, até o momento que o responsável estiver livre para a conversa frente a frente, por exemplo:

Tenho certeza que aceitaremos cartões de débito mas não sei sobre crédito ainda.

Uma resposta final e direta também permite a continuação da história.

Outra possível resposta é o cancelamento temporário da história por diversos motivos, como quando o cliente não possuir a informação necessária e prefere postergá-la, outro sistema não está ainda pronto ou o cliente decidir que a mesma deixou de fazer sentido, por exemplo:

A equipe financeira ainda não fechou o contrato com as representantes dos cartões.
Precisamos esperar a resposta para continuar esse trabalho.

Em qualquer uma das finalizações, evitamos adivinhar e durante todo o tempo a equipe entregou valor ao projeto: nem ficou parada nem foi para o caminho errado.