Maturidade 3 em Métodos Ágeis – Práticas Consistentes em Projetos e Demandas

Dando continuidade à nossa série de postagens sobre aumento de maturidade em métodos ágeis, desta vez iremos falar sobre a consolidação de práticas em projetos.

A consolidação de práticas ágeis vem através da sistematização destas práticas pelos membros dos times. E para isso devemos falar de dois aspectos fundamentais para essa sistematização, que são os hábitos e os padrões (patterns).

Hábitos em Métodos Ágeis

Um hábito é uma prática humana que é realizada com baixa energia cerebral e portanto não gera resistência ou cansaço excessivo ao ser realizada. Pense por exemplo em alguns hábitos diários que você realiza como a direção de um carro, que envolve controlar a marcha, pedais e volantes do seu carro e observar os transeuntes e outros carros ao seu redor. Tudo isso ao mesmo tempo. Este hábito é realizado naturalmente pelos motoristas, depois de alguma prática. Não existe desconforto ou resistência cerebral nas ações e a repetição leva à excelência na realização deste hábito. Pessoas experientes em uma área de trabalho realizam tarefas complicadas de forma simples, o que pode ser observado ao ver uma partida de futebol do Lionel Messi. Isso faz parte da prática do hábito.

Em métodos ágeis, hábitos são fundamentais. São eles que fazem com que times não gerem resistência ao buscar uma reunião diária, uma revisão, retrospectiva, refatorar código, modelar de forma colaborativa ou jogar um planning poker para estimar o trabalho em uma sprint. Times ágeis em formação ainda podem ter resistências a uma prática ágil, mas isso acontece porque o hábito não se formou.

E a pergunta que surge então é: Como formar hábitos em times ágeis?

A formação de hábitos já foi bastante estudada na psicologia e existem bons livros a respeito. [Recomendo alguns no final deste post]. Mas em linhas gerais, uma abordagem para formação de hábito inclui o seguinte:

  1. Começar leve. Por exemplo, mesmo que a reunião diária não seja realizada com sucesso em um certo dia, é importante persistir e realizá-la todo dia. A repetição é chave para formar um hábito.
  2. Estabelecer um gatilho. Por exemplo, alguns times ágeis colocam um alarme divertido, como uma música do Star Wars,  ou fazem a reunião diária logo após o momento do café ou quando a última pessoa do time chega ao escritório pela manhã. Estabelecer gatilhos facilita a formação de hábitos.
  3. Tratar o evento como um ritual. Seja um facilitador e mostre que vocês estão ali por um motivo e que isso irá gerar um benefício para todos. Abra a reunião, estabeleça o passo a passo e feche a reunião. Ritualize cada encontro.
  4. Estabelecer uma recompensa. Todo hábito (bom ou ruim) se torna forte pelos sistemas de recompensas. Fumantes conhecem isso em profundidade. Enquanto líder facilitador, você deve buscar pequenas recompensas para ajudar o seu time a formar bons hábitos. Elogios públicos são formas simples de recompensas. Em momentos críticos do projeto, após horas extras para entregar um parte do produto, dar folga ao time no dia seguinte também pode ser um exemplo de uma recompensa.
    As recompensas reversas também funcionam. Por exemplo, se uma pessoal quebrou o código do build, ele deve  depositar 1  real na caixinha da cerveja do time ou trazer chocolates para o restante do time no dia seguinte.
  5. Conhecer o mecanismo cerebral humano chamado de willpower, que diz que a força de vontade é um recurso perecível ao longo de um dia. Ou seja, a manhã é um momento mais propício para pedir que pessoas façam coisas que elas ainda não estão acostumadas. Um exemplo reverso deste conceito é observado em pessoas que esgotaram o seu tanque de boa vontade à noite ao tentar o hábito de um regime e atacam impiedosamente a geladeira.

Alguns estudos mostram que hábitos demoram entre 30 a 70 dias para se formarem e portanto é importante perseverar. Talvez a diferença mais fundamental entre métodos ágeis e métodos tradicionais é que os primeiros requerem disciplina. E sabemos que ter disciplina requer formar bons hábitos.

Patterns em Métodos Ágeis

Padrões são amplamente disseminados em TI. Eles representam melhores práticas da indústria e se dominados pelo praticante, podem tornar o trabalho mais simples e ao mesmo tempo mais efetivo. Patterns tem nomes divertidos, resolvem problemas concretos e apresentam soluções guiadas para estes problemas. Os padrões mais populares são os Design Patterns, embora existam também Analysis Patterns, Implementation Patterns ou mesmo SCM Patterns. Existem também Agile Patterns ou SCRUM Patterns, que representam melhores práticas compiladas por praticantes que operam este método há mais de 20 anos.

Compilo aqui uma lista de 7 SCRUM Patterns que podem servir para o leitor levar o sua prática ágil para um nível acima.

  1. Product Backlog
    • Problema: O seu time e os interessados no seu produto tem dificuldade de definir a ordem de entrega das funcionalidades de um produto. Conflitos e insatisfações surgem por toda parte.
    • Forças: Quando tudo é importante, nada é importante. Ou seja, uma lista de prioridade é fundamental para determinar o quem vem primeiro lugar, o que vem em segundo lugar e assim sucessivamente.
    • Solução: Crie uma lista de itens com incrementos de produto chamada de backlog do produto. Cada item deve representar uma micro-funcionalidade do produto (e não tarefas). A lista deve ser ordenada, ou seja, cada item deve ter uma ordem específica, representando a prioridade do item. Esta lista deve ser priorizada coletivamente, ser publicada em um repositório público e deve ser mantida do início ao final do projeto.
  2. Pigs Estimates
    • Problema: O time tem dificuldades para cumprir os prazos estipulados pela gerência de projeto.
    • Forças: Estimativas devem ser realizadas baseadas em racionais estruturados, ao invés de desejos e fantasias gerenciais.
    • Solução: Deixe a pessoa que for realizar o trabalho realizar a estimativa do número de horas do seu trabalho. Estabeleça tempo para que ele realize a estimativa e forneça os insumos necessários para esta estimativa. Se possível, use todo o time para realizar as estimativas em conjunto com o padrão Planning Poker.
  3. Planning Poker
    • Problema: Um desenvolvedor se sente inseguro em fornecer uma estimativa para o seu gerente. Ele se coloca na defensiva e bastante incomodado com a pressão em ter prazo.
    • Forças: Pessoas com pouco conhecimento de um assunto ou de uma tecnologia temem ser julgados por uma estimativa ruim. Isso gera desconforto e uma situação de pânico quando gerentes pedem por estimativas.
    • Solução: Faça uma estimativa em grupos através de uma dinâmica com um baralho de cartas, em uma reunião com aproximadamente 2 horas. Cada pessoa tem um baralho com cartas com valor 1, 2, 3, 5, 8, 13 ou 21. Um facilitador seleciona um item do backlog (ou uma tarefa). Cada pessoa seleciona em silêncio uma carta. Todos jogam as suas cartas. Se existe um consenso coletivo, então a rodada de estimativa do item é terminada. Se não existe um consenso, os jogadores com estimativa mais alta e mais baixa debatem e após isso uma nova estimativa é buscada para aquele item, até que haja um consenso. Depois, o processo é repetido para todos os itens do backlog.
  4. Daily Clean Code.
    • Problema: A qualidade do código do seu time degrada ao longo do projeto ou longo das manutenções evolutivas.
    • Forças: Você toma banho em base diária. E provavelmente o seu cachorro toma banho em base semanal. Até o seu carro toma banho eventualmente. Pessoas e coisas que não tomam banho começam a cheirar mal e degradar. Software inclusive. Ou seja, dê banho no seu código em base diária para que ele mantenha boa manutenibilidade.
    • Solução: Reserve dez a quinze minutos por dia para refatorar o seu código. Refatore o seu código, rode os seus testes de unidade e publique o código limpo em base diária. Para saber mais a respeito de banhos e software, veja o livro Código Limpo – Habilidades Práticas do Agile Software.
  5. Definition of Ready
    • Problema: O seu time tem dificuldade de trabalhar os requisitos, o que gera mal-entendidos, atrasos na implementação e testes e consequente estresse.
    • Forças: Requisitos mal elicitados e mal compreendidos são um das fontes primárias de problemas na construção de produtos. Mas, estabelecer requisitos claros não é trivial.
    • Solução: Estabeleça com o seu time um critério chamado de “Preparado/Ready”. Este critério é usado pelo seu time para aceitar (ou não) um requisito para construção. Se um requisito trazido pelo PO não atender ao critério de “preparado” do time, ele é adiado para um novo ciclo (sprint). Exemplos desses critérios podem incluir, para produtos de software, protótipos de tela ou regras de negócio formalizadas. Para implantações de redes sem fio em um time de infraestrutura, esse critérios poderiam incluir a topologia da rede a ser implantada e um estudo que demonstre a cobertura dos pontos de acesso a ser instalados.
  6. Definition of Acceptance Criteria
    • Problema: As demonstrações dos seus incrementos de produto não atendem as expectativas dos seus usuários. As expectativas desalinhadas geram mal entendidos e frustrações nos seus clientes e também nos membros do time. Os julgamentos sobre a atuação dos analistas de requisitos surgem e são negativos.
    • Forças: Requisitos mal elicitados e mal compreendidos são um das fontes primárias de problemas na construção de produtos. Mas, capturar e comunicar requisitos não é trivial.
    • Solução: Formalize com os seus clientes internos e externos os critérios de aceite dos incrementos de produto. Exemplos de critéros de aceite podem incluir evidências de testes, usos de dados reais ou atendimento a normas e padrões de qualidade como segurança ou interoperabilidade. O PO é o papel responsável por verificar se os critérios de aceite de cada incremento de produto foram atendidos ou não ao final de cada sprint.
  7.  Definition of Done
    • Problema: O seu time técnico reclama que não tem “tempo” para implementar boas práticas. Ao longo do projeto, começam a surgir várias pontas soltas e o débito técnico se acumula. No final do projeto, o seu produto entra em produção com um déficit técnico interno e gera problemas diversos carregados para a manutenção.
    • Forças: A urgência sempre irá ganhar das coisas importantes. Portanto, é importante estabelecer na largada condições mínimas de saúde do projeto e criar o conceito de qualidade contínua desde o começo do projeto. Fazer um item pela metade e depois voltar a ele para melhorar um atributo técnico é um exemplo da má prática chama de “Trabalho Parcialmente Feito”, bastante discutida e combatida no pensamento Lean.
    • Solução: Estabeleça, com o seu time técnico, “cláusulas pétreas” que não podem ser violadas e que devem ser implementadas para qualquer item do backlog. Exemplos incluem: regras de negócio financeiras devem ter testes automatizados; códigos devem passar em um teste de regressão no repositório em base diária; liberações em produção devem ter um documento com as notas da liberação (release notes), implantações de infraestrutura devem ter a planta da topologia física da empresa redesenhada (modelo as-built).
      As estimativas dos itens do trabalho já devem considerar o esforço necessário para entregar o item com a sua definição de “Done”. O SM é responsável por garantir o cumprimento desta constituição técnica, que deve fornecer conforto ao time e que possa ser absorvida no custo do projeto.

Em uma postagem futura em uma série própria dedicada à temática de patterns, iremos este conceito de padrões para métodos ágeis e compilar aqui 50 Agile Patterns.

Em resumo, a sistematização envolve a repetição de boas práticas. Ao repetir através de bons hábitos as melhores experiências do mercado, você provavelmente irá levar o trabalho do seu time para um nível acima. Isso irá gerar resultados temporais e financeiros expressivos, ao mesmo tempo que irá promover maior transparência e colaboração.

No próximo post desta série, iremos falar no quarto nível de maturidade em métodos ágeis, que leva os princípios ágeis muito além dos times dos produtos de inovação ou da tecnologia da informação, mas para toda a estrutura de uma empresa.

Uma lista breve de livros sobre a formação de hábitos – Conforme prometido 🙂

  • O Poder do Hábito – Simples, direto e divertido.
  • Essential Zen Habits – Minimalista, inspirador e acionável .
  • A Guinada – Tratamento técnico e ao mesmo tempo divertido sobre porque criar hábitos é difícil e como acionar mecanismos que simplificam a formação de hábitos.

 

2 comentários sobre “Maturidade 3 em Métodos Ágeis – Práticas Consistentes em Projetos e Demandas

  1. A engenharia de sistemas é por si só complexa. Acrescentam-se as camadas de software, a tecnologia e as regras de negócio nem sempre triviais. O time técnico possui o enorme desafio de conciliar todas estas disciplinas e o líder de equipe ou gerente de projetos pode ajudar com os métodos ágeis e/ou tradicionais que removam os impedimentos para o desenvolvimento do trabalho.

    Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s