O que é Agilidade? Revisitando o conceito… (por Daniel Wildt)

daniel-wildt-small

No dia 26 de junho de 2010, o Rafael Helm publicou aqui mesmo no Pingos de Agilidade o que era para mim Agilidade. O Rafael pediu para eu mandar em uma frase.

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.

Anúncios

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.

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.

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.

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.

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