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.

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.

Para fins de dinâmica e uso efetivo do tempo do time, normalmente quem solicitou uma funcionalidade já teve a oportunidade de testar e validar a mesma antes desta cerimônia.

E se isto não ocorrer?

Como assim?

Geralmente nesta demonstração o solicitante de uma determinada funcionalidade comenta sobre alguns pontos positivos e pontos que poderiam ser melhorados, que não ficaram exatamente como esperado.

Até aí tudo bem, é fazer alguns ajustes e depois fechar o assunto, certo? Se pode considerar a funcionalidade pronta?

Não. E sabemos que se algo não está pronto na visão do solicitante então não está pronto mesmo!

Em alguns casos pode ser até pior! O solicitante da demanda pode dizer que a funcionalidade ficou completamente diferente do que ele esperava, que está tudo errado, o que leva a moral do time para o chão.

Ou seja, a tarefa que na visão do time estava pronta na verdade não está pronta ainda na visão do solicitante.

Para resolver este problema, nada melhor do que adicionar a definição de pronto do time a necessidade de obter o aceite do solicitante, antes da demonstração.

Importante 1: Pedir para que o solicitante aceite uma tarefa antes de considera-la pronta não substitui de forma alguma o processo de testes. A idéia aqui não é propor para que o solicitante faça testes, mas realizar uma demonstração da nova funcionalidade para que o solicitante tenha oportunidade de verificar se ficou tudo de acordo com o esperado. Normalmente este processo não leva mais do que alguns minutos.

Importante 2: Melhor ainda se os usuários finais puderem testar a funcionalidade, em uma sessão de treinamento guiado ou ainda em testes exploratórios. Lembre que são eles que farão uso de funcionalidades durante algumas horas do dia e merecem uma excelente experiência no uso.

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

Um fator importante para este processo funcionar é o solicitante das demandas estar disponível para realizar aceites dos cartões prontos periodicamente.

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 solicitante os aceitou durante a iteração.

E a equipe não precisa e não deve esperar até o final da iteração para descobrir isto.