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

Anúncios

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

Agilidade? (por Luiz Claudio Parzianello)

12260_10151163819223263_2111268303_n

É engraçado, mas não sei mais como definir agilidade … Se eu tentar fazê-lo, acho que vou destruir o conceito! Para mim, agilidade é um caminho de descobertas que conduz à ética e ao aperfeiçoamento contínuo, tanto do indivíduo quanto da organização de software.

Na primeira edição do Community Journal da Visao Ágil, pude escrever o seguinte sobre uma pergunta muito semelhante:

Muitos acreditam que o Manifesto Ágil não passa de uma piada, enquanto outros acreditam que ele marca o início de uma mudança na história do desenvolvimento de software. Alguns acreditam que tudo isso é um mero modismo, enquanto outros conquistam continuamente melhorias substanciais na qualidade e produtividade de suas equipes de desenvolvimento. Muitos acreditam que agilidade é assunto para pequenos, enquanto poucos já demonstraram que milhares de pessoas trabalhando de forma colaborativa e distribuída é coisa de gente grande. Pois bem, pude perceber ao longo dos últimos 10 anos, assessorando empresas e capacitando profissionais em projetos de implantação de Metodologias Ágeis, que a agilidade não está associada somente a uma nova cultura de crenças e valores, mas principalmente a uma nova busca de descobertas e iluminação. Iluminação no sentido de enxergar de vez que o desenvolvimento de software é um problema de logística que deve ser sustentado por uma forte cultura de comunicação e colaboração entre todas as partes interessadas num produto ou projeto de software. Logística no sentido de desenvolver competências para a entrega rápida de pequenos incrementos de software de alta qualidade, mantendo sempre um ritmo constante sustentável. Comunicação e colaboração no sentido de compreender como a menor quantidade de software irá aumentar a vantagem competitiva de nossos clientes (fazer cada vez mais com cada vez menos). Se você promover de forma honesta a melhoria contínua de pessoas, ferramentas e métodos, você com certeza encontrará o pensamento Ágil e descobrirá que esse é o único caminho para o sucesso e a satisfação de sua equipe de desenvolvimento.

Luiz Claudio Parzianello é Coach especialista em temas como Engenharia de Requisitos, Lean Software Development, Scrum e Extreme Programming. É sócio-fundador da empresa Surya Gestão Digital e vice-Coordenador do GUMA.