Arquivo da categoria: pingos

11.22.11
por

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

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!

11.15.11
por

O poder de mudança e as pessoas

5362273271_7499632c24

No dia 19 de outubro de 2011, eu escrevi no Twitter: “Cuidado, as vezes mesmo em estrutura flat de empresa você pode criar um mundo dilbert. Evite, dê poder de verdade as pessoas! #empowerment”

Gostaria de evitar ver nas empresas qualquer coisa que se relacione com um post que fiz no primeiro de abril, onde trago a tona uma expectativa sobre como não viver no ambiente de trabalho. Enfim, parece que alguns não dão risada e ainda ficam imitando.

O principal é manter as coisas simples.

É poder trabalhar e criar um ambiente onde as pessoas se sintam responsáveis e com vontade de funcionar não apenas como profissionais que executam tarefas, mas também como profissionais que criam e puxam iniciativas, que estão presentes quando o time precisa de ajuda.

Que encontram na equipe um ambiente que se identificam e que querem ajudar a ficar melhor sempre.

Ao centralizar o poder no ambiente de trabalho, você dá a chance das pessoas criarem uma zona de conforto, e isto não deve ser alimentado, nunca. Steve Jobs falou uma vez, “Stay hungry, stay foolish“.

A moral de tudo isto é que você precisa se perguntar o quanto você é capaz de mudar algo onde está trabalhando. Será que a cultura de aprendizado existe mesmo ou você só pode e deve fazer o que está na descrição do seu cargo? E de quem é a responsabilidade sobre isto? #pense

11.01.11
por

Precisamos de prática!

8182308742_11e245507e

Henry Mintzberg disse “You cannot create a manager or leader in a classroom“. O contexto vem de uma discussão sobre o mercado precisar de gerentes e não de MBAs. Que os cursos são muito bons para ensinar as práticas que gerentes vão precisar no mercado, pensando em “o que” aplicar… mas isto é diferente das situações de como aplicar, que se ganha com a prática do dia a dia.

Mintzberg também trabalha a questão que todos deveriam conhecer gerenciamento, para então buscar um cargo onde a necessidade de gestão seja um requisito.

O ponto é que a prática é o que nos leva a experiência e a realmente conhecer algum assunto.
Não é a teoria. É a prática. É a experimentação. É o trabalho em campo.

Então, da próxima vez que você entrar em uma sala de aula, lembre-se disto: um treinamento, o trabalho em sala de aula, serve para consciência e reflexão!

Para ganhar experiência, seja em projetos, em técnicas de apresentação e escrita, você precisa enfrentar situações no seu dia a dia. Existem formas de criar estas situações de realidade, exemplo:

  • Realizar melhorias na sua vída e no seu trabalho
  • Participar de projetos open source
  • Escrever artigos para blogs, revistas, portais
  • Criar produtos novos, sejam eles produtos de software ou não
  • Organizar eventos
  • Realizar trabalho voluntário para ONGs

O simples fato de participar de ações como estas, vão resultar em experiência. Prática. Esta prática vai ajudar a criar cultura. A criar um ambiente, de puro aprendizado, mas lembre, prático!

03.09.11
por

Os Pequenos Notáveis!

5100243292_5a908a8383

Times pequenos (até 5 ou 6 pessoas) podem fazer mais do que times grandes (mais de 10 pessoas) simplesmente porque são menores.

Em times pequenos, a execução de tarefas do tipo “cereja do bolo” ficam sempre em último lugar, pois como o time é pequeno (e a lista de tarefas importantes é maior do que a lista de tarefas menos importantes) todos do time se mantêm trabalhando no que realmente precisa ser feito. Isso reduz significativamente o desperdício de esforço em tarefas que não precisam ser trabalhadas (pelo menos não agora).

Complementando o que já foi comentado pelo Daniel aqui no pingos de agilidade, as restrições de um time pequeno obrigam as pessoas do time a irem além do ponto em que geralmente iriam se trabalhassem em um time grande, pois geralmente (para não dizer sempre) os times grandes possuem especialistas: O Joãozinho só testa, o Pedrinho é o cara do HTML e CSS e o Huguinho conhece todos os segredos do deploy. Já em times pequenos é rotina que todos trabalhem escrevendo estórias, desenvolvendo software, fazendo tunning de banco de dados, testando, fazendo deploy, etc. E, naturalmente, este trabalho multi-disciplinar vai proporcionar ao time uma maior visão “do todo” do projeto.

Em times pequenos é fácil todos saberem o que todos estão fazendo. Isso porque as reuniões diárias são muito rápidas e, é mais fácil uma pessoa processar a informação sobre o que outras 4 ou 5 estão fazendo do que escutar e processar o que uma dúzia de pessoas falaram.

Outro ponto importante é que em times pequenos não faz muito sentido eleger uma pessoa para exercer o papel de gerente/coordenador/supervisor/seja lá o que for, já que todos fazem tudo e dominam o projeto inteiro. E, como neste caso “todos” não é sinônimo de um número grande de pessoas, o cliente (seja interno ou externo), se sente a vontade para participar das reuniões de planejamento juntamente com o time. Quem já trabalha com o hábito de realizar reuniões de planejamento sabe o quanto a presença do cliente é positiva nestas reuniões.

Sendo assim, eu acredito que treinar o time buscando continuamente melhorar as habilidades e, principalmente, a multi-disciplina de todos é melhor solução do que contratar mais pessoas.

É claro que existem casos em que a contratação é inevitável, mas lembre-se “Contrate apenas quando doer!” (e muito). 😉

01.19.11
por

Contrate apenas quando doer!

4129400323_03d17b79b0

Para quem conhece o pessoal da 37Signals, e já leu o livro Rework, deve se lembrar do tópico: “Hire when it hurts“.

Eu particularmente gosto deste tópico, por gostar de trabalhar com equipes pequenas e por entender que as restrições são excelentes para mostrar como somos capazes de ir além e de nos superar.

Demonstra como podemos realmente ser multidisciplinares e como conseguimos crescer como equipe.

Então a dica é sempre esperar o máximo possível antes de partir para uma nova contratação. Trabalhe com o time as restrições, garanta qualidade e excelência técnica do seu time. Garanta o aprendizado e gestão de conhecimento. Garanta a colaboração e práticas que fazem o time crescer.

09.28.10
por

A Importância do Aceite

404150851_cd5bcb1ac2

Ao final de cada ciclo de trabalho (no scrum chamado de sprint), é indicado que o time realize uma demonstração das novas funcionalidades desenvolvidas. Esta demonstração é realizada pelo time para o próprio time. Importante lembrar que o cliente pode fazer parte do time (cliente presente).

Para uso efetivo do tempo do time, é aconselhável que o solicitante de uma funcionalidade, seja cliente interno ou externo, já tenha tido a oportunidade de validar a funcionalidade antes da revisão da sprint. Ou seja, sempre que o time entender que terminou uma funcionalidade o cliente é chamado para aceitar a mesma.

Geralmente neste processo o cliente vai passar alguns feedbacks, sejam eles positivos ou negativos, ou até mesmo indicar que a funcionalidade ficou completamente fora do que ele esperava.

No caso do feedback ser positivo, nós teremos segurança que vamos entregar software funcionando de verdade. Comemore!

No caso do feedback ser “tá quase lá”, você terá oportunidade de ajustar e evoluir a funcionalidade antes de colocá-la em produção.

E no caso do feedback ser negativo, do tipo “não é nada disto, vocês não entenderam o que eu pedi”, comemore também, pois como o Daniel Wildt sempre fala: 

“A única certeza que temos é que vamos falhar, então precisamos falhar rápido.“

Imagine se você só descobrisse que construiu uma funcionalidade totalmente diferente do que o cliente esperava no dia em que o software entrou em produção, ou em um treinamento com toda equipe do seu cliente. Seria terrível!

Por isto, criar a cultura de Aceite dentro de seu time pode ser uma prática muito saudável, e sem contraindicações, pois todo mundo ganha, a empresa, o time e o cliente.

 

Importante: Pedir para o cliente validar uma tarefa não substitui de forma alguma o processo de testes. A ideia aqui não é propor que o cliente faça testes buscando quebrar a funcionalidade, afinal de contas nosso time deve ser composto por desenvolvedores profissionais, que sabem testar software. O objetivo de buscar o aceite do cliente é verificar se ficou tudo de acordo com o esperado. Normalmente este processo não leva mais do que alguns minutos.

 

Uma alternativa interessante para criar a cultura do aceite no time pode ser criar no kanban uma fila chamada “Aguardando Aceite”, onde os cartões prontos na visão do time serão posicionados, e somente após aceite do cliente estes serão movidos para a fila “Pronto”.

Um fator importante para este processo funcionar é o cliente ou solicitante das demandas estar disponível para realizar aceites das tarefas prontas periodicamente, caso contrário estaremos apenas criando um gargalo.

Este processo trará uma maior segurança ao time, uma vez que os cartões considerados prontos pelo time realmente estarão prontos de verdade já que o cliente os aceitou durante a sprint.

Se no seu cenário for impossível aproximar o cliente, mesmo que por skype, considere então buscar o aceite pelo menos da pessoa que realizou a análise da funcionalidade. Isto já vai trazer um ganho significativo de qualidade, o que vai elevar a moral e a coragem do time.

07.19.10
por

Definition of Ready

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.

07.07.10
por

Ainda sobre a Retrospectiva…

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.

07.06.10
por

Retrospectiva Sim, Choradeira Não

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