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 padrão… 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.

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.

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?

Caso você não tenha lido ainda o primeiro princípio, eu sugiro que você acesse o post anterior e realize a leitura antes de prosseguir.

Princípio #3: Proficiência sobre incompetência

Nunca se de por satisfeito com a sua produtividade e rendimento, sempre é possível melhorar.

Busque evoluir sempre! Isto vai te manter motivado para atingir e manter um nível de excelência.

Cuidado: Fazer mais rápido não é sinônimo de fazer melhor.

O próximo post será sobre o princípio #4: Excelência sobre mediocridade

Caso você não tenha lido ainda o primeiro princípio, eu sugiro que você acesse o post anterior e realize a leitura antes de prosseguir.

Princípio #2: Simplicidade sobre complexidade

Mantenha as coisas simples!

Não invente fórmulas mirabolantes.

Mas como saber se está simples? Se você estiver encontrando dificuldades para explicar para alguém como uma nova feature do software vai funcionar, é provável que sua proposta de solução esteja complexa/confusa. Quando isto ocorrer, pare, pense, remodele, e apresente novamente para outra pessoa.

Interessante como o princípio 2 vai de encontro a um dos 12 princípios do manifesto ágil:

“Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.”

Princípio #3: Proficiência sobre incompetência

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!

Stephen Long em seu livro “Level Six Performance: A Gold Medal Formula for Achieving Professional & Personal“, citou 11 princípios que fazem um bom atleta se tornar um atleta campeão. Gostei muito da visão do autor e adaptei estes 11 princípios para o mundo corporativo.

A cada semana, sempre na quinta-feira, será pulicado um dos princípios aqui no pingos de agilidade.

Princípio #1: Aprendizado sobre ignorância

Não chore sobre o leite derramado!

Os problemas sempre vão acontecer, mas cabe a você aprender com eles (todos os dias, para sempre).

Entenda (e aprenda) com a diferença entre o resultado planejado x resultado ocorrido.

Aprenda com erros, mas principalmente, com os acertos.

Reuniões de retrospectiva são um ótimo momento para aprendizado -> Sugestão de leitura 1, Sugestão de leitura 2

Princípio #2: Simplicidade sobre complexidade

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

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!

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

E eu mandei: Atitude, foco em entrega de software, trabalho em equipe e mehoria contínua.

Só que como todo desenvolvedor Clean Code, tudo pode ser refatorado.

E nesta declaração, se eu for refatorar, como já vi o @KlausWuestefeld fazer com os valores do eXtreme Programming, chegando no Learning and Coolness, entendo que atitude e foco em entrega fazem o resto acontecer.

Vejamos:

Trabalho em equipe não é opcional. Você nunca vai ser melhor do que uma equipe em sinergia. Não quer uma equipe? Pense em um par, pense nos benefícios de ter conhecimento navegando e se tornando algo consciente e consistente entre as pessoas que fazem parte da equipe.

Melhoria contínua também não é opcional. Se sua equipe não melhora, ela sempre vai piorar. Simplesmente não se consegue “manter” a qualidade porque conforme o aumento da base de código, prazos, decisões mal feitas no projeto, novos problemas relacionados a modularidade e outros aspectos no desenvolvimento de software vão ficar mais visíveis. Então melhorar continuamente é algo que se faz sempre.

É a continuidade do processo de questionar aquilo que está sendo feito e buscar sempre melhorar, faz parte da atitude.

E é o que sobra e ao mesmo tempo faz a diferença. A atitude da equipe perante os obstáculos e como ela encara as situações de planejar novas funcionalidades para um produto, como ela encara o feedback ao cliente depois de um problema na operação do produto. Ou ainda como cada pessoa que faz parte da equipe vê a resolução de um defeito.

Se eu foco na entrega de software, quero garantir que o trabalho será o melhor possível, pois ninguém quer ter que trabalhar a noite ou final de semana ajustando algum problema de produção, causado na liberação de versão.

Então focar em entrega exige busca por qualidade, exige melhoria contínua. Só que sem atitude e foco em entregar aquilo que o cliente precisa, pensando em simplicidade, nada ocorre.

Exige aprender novos truques, em buscar novos conceitos como DevOps e Continuous Delivery.