XP Rio

As informações que podem ser compartilhadas em um stand up meeting também poderiam ser transmitidas através de ferramentas. O que ocorre no XP, é que há uma preferência por canais de comunicação mais ricos, o que não significa que os outros canais sejam errados ou não funcionem. Quem trabalha com XP apenas acredita que pode avançar melhor e mais rapidamente dando preferência aos diálogos. Aliás, essa é uma palavra chave na compreensão do stand up meeting.

Trata-se de um diálogo entre todos os membros da equipe, se possível envolvendo também a presença do cliente. Em qualquer diálogo, existem pelo menos duas coisas que são compartilhadas de maneira bastante rica: informações e emoções.

Informações

Em projetos XP, cada membro da equipe tem acesso a toda e qualquer parte do código e, acima de tudo, tem o direito de alterar qualquer parte do sistema, a qualquer momento, sem ter que pedir permissão a ninguém. Essa é uma prática conhecida como Código Coletivo. A parte boa dessa prática é que o desenvolvedor consegue avançar muito rapidamente, pois nunca fica dependendo de outra pessoa, ou da autorização de alguém, para editar uma parte do código. Por outro lado, isso exige muita troca de informações, visto que tudo o que está acontecendo, em qualquer parte do sistema, interessa a todos os membros da equipe.

O diálogo diário permite que cada desenvolvedor descreva brevemente o que fez no dia anterior, eventuais problemas que detectou, soluções interessantes que foram criadas etc. Não é necessário entrar em detalhes. A idéia é que as pessoas saibam o que está acontecendo e quem fez o que. Se um desenvolvedor se interessar bastante por um assunto a respeito do qual outra pessoa trabalhou no dia anterior, ele pode, após o stand up meeting, se reunir com essa pessoa e discutir a solução com maior nível de detalhe. Pode até resolver fazer par com aquela pessoa durante o dia de trabalho que se está iniciando.

À primeira vista, o stand up meeting parece ser demorado. Afinal, se cada desenvolvedor tiver que explicar tudo o que fez no dia anterior, certamente isso pode consumir muito tempo. Entretanto, note que a idéia é fazê-lo diariamente e há várias razões importantes para ser assim. A primeira é que um dia de trabalho é um período relativamente curto. Descrever o que aconteceu em um dia é diferente de descrever os acontecimentos de uma semana, um mês ou um ano. Um dia é muito pouco tempo e normalmente não se produz uma quantidade enorme de coisas interessantes em um único dia. Sendo assim, existe a tendência de que cada desenvolvedor tenha pouco o que dizer se o stand up meeting realmente for conduzido com frequência diária. Apesar de pouco, o que ele tiver a dizer interessa a todos, porque o código é coletivo. De tempos em tempos, haverá alguma coisa realmente muito significativa que tenha sido feita por um par no dia anterior. Nestes casos, o stand up meeting pode acabar tomando mais tempo, porém o valor deste tempo é mais alto devido à utilidade da informação que se está transmitindo.

O stand up meeting é uma prática regida pelo valor da comunicação. Entretanto, é importante notar como também incorpora bem o valor do feedback. A cada dia de trabalho, podemos acertar em diversos pontos do projeto, mas também podemos errar. Equipes XP não esperam ser perfeitas e sabem que erram com frequência. Entretanto, isso não é temido, pois trata-se de um aspecto básico do ser humano: errar. O que realmente tememos é descobrir que erramos tarde demais, porque normalmente o custo de corrigir um erro cresce bastante quanto mais tempo levamos para detectá-lo e corrigi-lo. O stand up meeting é uma oportunidade para que os membros da equipe detectem e discutam problemas que tenha surgido no dia anterior, de modo que se possa priorizar ou não a correção dos mesmos e, de modo que se possam compartilhar sugestões sobre como tratá-los. Quando os problemas são apresentados a todos os desenvolvedores, é comum que surjam várias sugestões e, dessa variedade, surge frequentemente uma forma rápida e simples de solucionar a questão.

Se alguma coisa muito grave é detectada no stand up meeting, o gerente do projeto e o próprio cliente ficam sabendo com bastante rapidez. Pois qualquer problema terá sido detectado há no máximo um dia de trabalho. Assim, o gerente, o cliente e os desenvolvedores podem criar soluções enquanto esse problema ainda não deu origem a outros.

Essa reunião matinal também é uma demonstração da aplicação do valor da simplicidade. Existem muitas formas de se transmitir informações, mas convenhamos, quando as pessoas estão próximas umas das outras, nada é mais simples do que conversar. Usar ferramentas é um caminho, mas isso normalmente envolve aprender a usá-las e a conviver com seus problemas. Além disso, não é necessário passar muito tempo ligado a computadores para saber que eles falham, os sistemas operacionais falham, travam, um dia funcionam e o no outro não e assim perde-se tempo, quando existem soluções mais simples e menos propensas a erros.

O stand up meeting também é um mecanismo para expressar e treinar a coragem dos membros da equipe. Em muitas empresas, os desenvolvedores escondem problemas potenciais com medo de sofrerem uma punição do chefe, do cliente ou de qualquer pessoa com poder na organização. De fato, muitas organizações são regidas pela cultura do medo. O stand up meeting é um espaço aberto onde as pessoas são incentivadas a falar tudo o que está acontecendo e são valorizadas por fazer isso. Trata-se de um aspecto importante porque com a prática, os membros da equipe perdem o medo de revelar os problemas à medida em que percebem que são valorizados por fazer isso. Além disso, os desenvolvedores passam a se expressar mais e com frequência, o que normalmente é ótimo para treinar a habilidade de comunicação. A mesma de que ele irá necessitar, por exemplo, para se comunicar bem com o cliente. Da mesma forma que é necessário coragem para dizer o que realmente está acontecendo, o stand up meeting acaba servindo como uma forma de treinar e desenvolver essa coragem diariamente.

Finalmente, equipes XP costumam utilizar Radiadores de Informações como o Quadro de Acompanhamento Diário. Trata-se de uma tabela, desenhada em um quadro branco, contendo informações sobre todas as histórias da iteração. Nela, colocam-se as estimativas de cada história, quanto tempo foi gasto em cada uma por dia da iteração, que tarefas extras foram executadas etc. É um quadro importante porque gera muita visibilidade para todos os membros da equipe, incluindo o cliente. Com esse quadro, não há necessidade de perguntar nada para o gerente para saber o estado do projeto em um iteração. Basta
olhar para a parede. As informações estão lá. Projetos XP atualizam esse quadro diariamente, sempre nos stand up meetings. Assim, nenhum desenvolvedor precisa preencher uma folhinha dizendo quantas horas trabalhou por dia, por exemplo. Ao invés disso, ele faz algumas marcações simples em um quadro, uma vez por dia, durante o stand up meeting. Todos os desenvolvedores fazem isso durante essa reunião e leva apenas alguns segundos para cada pessoas marcar a sua informação. Quando todos o fazem em conjunto, essa prática tende a se manter de forma mais consistente do que quando realizamos uma atividade dessas sozinhos. Além disso, é um momento de socilização do qual todos participam.

Emoções

É possível transmitir informações através de ferramentas. Porém, emoções também informam e estas são muito difíceis de serem compartilhadas através de ferramentas. Durante um stand up meeting, os membros da equipe conseguem avaliar e sentir como está o clima da equipe. Olhando para cada pessoa, é possível observar se estão satisfeitas com o trabalho que está em andamento, dá para ver se estão cansadas ou energizadas, se estão entediadas ou empolgadas, se estão de acordo com os rumos do projeto etc. Muitas informações importantes jamais são verbalizadas, mas frequentemente basta você olhar para a expressão facial de uma pessoa para saber que ela discorda plenamente de alguma coisa ou para notar que ela está cansada, ou aborrecida. Nestes momentos, um bom coach (bem como qualquer membro da equipe) deve atuar pedindo à pessoa que expresse seus sentimentos. Muitas vezes vivenciei grandes viradas em projetos, viradas extremamente positivas, porque alguém notou um problema na expressão de um dos desenvolvedores.

Há pouco tempo, por exemplo, tínhamos iniciado um projeto em um dos nossos clientes e, em uma reunião dessas, um membro da equipe demonstrava pela expressão facial que não estava muito satisfeito com o rumo das coisas. Ele não disse isso, apenas pareceu insatisfeito pela expressão que fazia. Então perguntei o que o estava incomodando. Ele me explicou que tinha a sensação de que aquele projeto não deveria produzir um software para web, como estava sendo feito. Na opinião dele, pelas características do projeto, faria mais sentido que fosse uma aplicação desktop. Discutimos isso com todos e ficou bastante claro que ele estava coberto de razão. Então, decidimos reverter o que estávamos fazendo e refazer algumas coisas para direcionar o software para desktop. Hoje, passados alguns meses, percebe-se que tomamos a decisão certo. Felizmente descobrimos isso bastante cedo devido à oportunidade de fazer um stand up meeting e interpretar as emoções que estavam no ar e não apenas as palavras verbalizadas. Se tivéssemos continuado no caminho original, talvez tivéssemos chegado à mesma conclusão em algum outro momento. Mas, certamente demoraria mais e o custo de reverter o projeto para desktop acabaria sendo maior. Portanto, emoções também representam um feedback importante que precisa ser levado em conta a todo o momento.

Para finalizar, precisamos compreender que o stand up meeting é uma forma de priorizar o que será feito em cada dia de trabalho. Nós priorizamos para assegurar que estamos fazendo o que é mais importante a cada momento do projeto e isso é feito porque o maior objetivo do XP é entregar um fluxo constante de valor para o cliente. Isso só é possível quando planejamos cuidadosamente o que será feito, isto é, quando escolhemos a cada dia fazer o que mais tenha potencial de gerar valor naquele momento. Sem essa priorização diária, é fácil um desenvolvedor acabar gastando tempo com algo que pode até ser útil, mas não era a coisa mais importante naquele ponto do projeto.

Em princípio, é fácil decidir o que deve ser feito a cada dia de trabalho. Basta olhar para o mural, onde a equipe coloca os cartões contendo as histórias da iteração, e verificar que histórias ainda precisam ser finalizadas. Entretanto, às vezes surgem problemas inesperados no dia anterior. Nesses casos, a equipe usa o stand up meeting para decidir se esses problemas devem ser tratados já no dia que está sendo iniciado, se devem ser deixados para uma iteração futura etc.

A priorização em equipe só pode ser feita de forma adequada quando temos a noção do todo, isto é, quando sabemos o que está acontecendo em cada parte do projeto, com cada pessoa da equipe e não apenas conosco. Pois, algo que eu possa considerar muito sério e prioritário no momento, pode ser absolutamente irrelevante quando somos informados de um problema bem mais significativo que está acontecendo em outra parte do projeto. Nos dias em que isso acontece, talvez faça mais sentido deixar o meu problema de lado e ir ajudar outra pessoa a resolver o problema mais sério que está afetando toda a equipe. Sem stand up meeting diário, é mais difícl notar e atuar rapidamente sobre situações como essas.