Arquivo da categoria: pingos

09.18.12
por

Vá e veja com seus próprios olhos!

Quantas vezes durante sua carreira você trabalhou na solução de um problema, que na verdade, não existia?

Ou utilizou uma informação incorreta para criar uma funcionalidade em seu software?

Ou tomou alguma decisão baseada em boatos que escutou pelos corredores?

Eu já passei por isto algumas vezes, e provavelmente você também.

O que precisamos fazer é simples: Genchi Genbutsu!

Vá e veja com seus próprios olhos!

Quando um cliente te pedir uma funcionalidade nova, que por exemplo, resolva um problema em sua linha de produção, vá até o cliente e veja com seus próprios olhos como funciona a linha de produção e qual é o problema do cliente.

O ponto aqui é: Vá na origem, observe pessoalmente, verifique dados, em vez de teorizar com base no que os outros te falam.

Quando você vê algo por si mesmo, você entende completamente a situação, e não é traído pelas falhas de comunicação que ocorrem com frequência.

Isto vai exigir que você saia da famigerada zona de conforto, porém reduzindo significativamente o desperdício de energia (e muitas linhas de código) para resolver problemas que não existem. 😉

02.29.12
por

Qual a melhor estimativa usada em ambientes Ágeis?

03082012TrenaFotoMarcosSantos009

Qual funciona melhor, qual é mais precisa?

E a minha resposta é ao mesmo tempo nenhuma e todas. O ponto não é este.

O que seu time deve buscar em uma reunião de estimativa não é uma certeza, mas sim conseguir entender que o time está alinhado e aprendendo sobre o negócio. Em uma brincadeira com planning poker, onde os números possíveis são 1,2,3,5,8,13… se uma pessoa indica o número 1 e outra pessoa indica o número 13, você tem um momento para discussão, para nivelar conhecimento ou conhecer um risco que estava “escondido” no sistema.

Todas as técnicas funcionam para guiar o time e criar um modelo de pensamento… conforme o time evolui em conhecimento de negócio e tecnologia, a tendência é a estimativa funcionar melhor e ajudar o time a visualizar questões que estejam “fora de padrão”.

O principal benefício dos exercícios de classificação/estimativa é gerar discussão e basear o conhecimento das pessoas sobre as funcionalidades a serem desenvolvidas. Ou seja, se você usa uma técnica de estimativa, deveria ser para crescer conhecimento da equipe. Não para poder culpar alguém depois.

E se você precisa estimar algo que é nebuloso? Você vai precisar seguir no conceito do 3C, para poder conhecer mais sobre a funcionalidade e possivelmente adicionar Spikes no planejamento, assim poderá experimentar e aprender mais sobre algo antes de fazer a definição da funcionalidade por completo.

Você deveria conversar até ter visão de que o que precisa ser feito é algo factível. Eu gosto de quebrar coisas e entender que elas cabem no máximo em três dias (idealmente no máximo 1 dia). No fim, isso é uma “regra de dedão“, ou seja: vamos aprender mais se o que temos para fazer ainda não está sendo percebido por todos da equipe. Vamos nos manter em modo descoberta, até que possamos caminhar para o modo entrega.

Se o seu time chegar nesta regra de que tudo tem um tamanho pequeno para executar, você não precisa mais estimar! Tudo vira “1”. E isso só quer dizer que o seu time tem um objetivo de “até quando vamos nos manter em modo descoberta” antes de iniciar a executar / entregar algo.

02.14.12
por

A reunião da manhã – melhoria contínua

8135229928_de131d8c4d

Seth Godin fala duas coisas que eu acho muito legal. Uma delas é porque perguntar porque? E a outra é sobre a qualidade das nossas perguntas. Nós crescemos e evoluímos e cada vez mais aprendemos a perguntar de forma especializada, sobre como está o tempo hoje.

Melhoria contínua será um processo muito melhor e simples se aprendermos a fazer perguntas diferentes, além de perguntar sobre o tempo durante a manhã.

Além de melhorar a qualidade das perguntas, precisamos estar presentes no local dos problemas, para poder ver de perto e sugerir melhorias, com o devido contexto. Estar presente no Gemba, e poder trabalhar com o conceito de Genchi Genbutsu é o que precisamos.

Mas o objetivo é falar de melhoria contínua e sobre uma prática da Fastcap, sobre a reunião da manhã para puxar melhoria contínua.

Prática simples, que busca criar uma cultura de aprendizado, diário, e que permite as pessoas exercitarem inovação, permite as pessoas trabalharem em equipe, melhorando o sistema e o ambiente de trabalho como um todo.

Na sua empresa, como sua equipe exercita a melhoria contínua?

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). 😉