Princípios ágeis revisitados: comunicação

Em um post passado, começamos a rever e exemplificar situações em que os princípios ágeis são facilmente demonstráveis. Os quatro primeiros princípios que destrinchamos eram mais relacionados à entrega de valor, mas ainda há mais oito a vermos!

Dessa vez, agrupamos mais quatro princípios que focam nas pessoas e na interação entre elas e passaremos por cada um deles apresentando exemplos de situações cotidianas em que vemos sua utilização. Vamos lá?

Pessoas de negócios e desenvolvedores devem trabalhar juntos diariamente durante o projeto.

Ainda é comum demais encontrarmos times de desenvolvimento de software e pessoas que entendem do negócio que não se falam. A ausência dessa conversa acontece por uma infinidade de razões e o custo para o projeto é bem alto. A falta de comunicação frequentemente aparece na forma de pedidos do usuário que chegam por escrito sem todas as informações necessárias. Então, o time chuta a forma de traduzir aquilo no projeto. Essa prática traz consequências graves: aumenta o retrabalho e promove a desconfiança dos usuários no time de desenvolvimento e no projeto.

Outro formato que tenta substituir a comunicação entre usuários e o time é a produção de extensos documentos com todos os detalhes necessários para que o desenvolvedor não tenha dúvidas do que precisa ser entregue. Embora essa teoria pareça bonita, na prática sabemos que o custo de produzir tal documentação é alto, causa gargalos e, não raro, ainda não resolve o problema, já que interpretação de texto é um problema sério. Além disso, quanto mais documentação existe, mais rapidamente ela se torna desatualizada e não confiável.

Aproximar as pessoas que entendem do negócio e o time de desenvolvimento é a melhor opção. Ela evita trabalho desnecessário e a perda de motivação que isso causa, corta custos e, ao envolver usuários por todo o processo, aumenta as chances de sucesso do software. Ter uma linha de comunicação sempre aberta certamente vai ajudar o projeto -- e é melhor ainda se essa comunicação for o mais direta possível. Finalmente, a convivência diária também tende a aumentar bastante a qualidade da informação entre os envolvidos no projeto.

O método mais eficiente e efetivo de agregar informações para e de um time de desenvolvimento é conversa cara-a-cara.

Uma das ferramentas mais arraigadas no dia-a-dia de empresas é o e-mail. E, incrivelmente, mesmo que estejam no mesmo prédio, ou na mesma sala, vemos com frequência pessoas escrevendo e-mails umas para as outras, em vez de simplesmente levantar e conversar.

Essa substituição da conversa cara-a-cara por e-mails é custosa de diversas formas: há o tempo para estruturar a mensagem e escrevê-la, mais tempo para a outra pessoa perceber que recebeu um e-mail, lê-lo e redigir uma resposta. Por ser uma mídia bem menos rica que uma conversa, provavelmente haverá dúvidas e mal-entendimentos que precisarão ser resolvidos... em novos e-mails!

Em uma situação cara-a-cara, não apenas as interações são mais rápidas, mas todo o suporte de comunicação das caras, bocas, gestos, entonações e, se possível, de um quadro branco de apoio para ajudar na conversa. Todas essas formas de comunicação secundárias são excelentes tanto para reduzir mal-entendidos, quanto para encurtar o tempo necessário para chegar a um bom entendimento.

Reduzir problemas causados pela falta de comunicação é uma boa forma de evitar desmotivar sua equipe. Isso nos leva ao próximo princípio:

Construa projetos com pessoas motivadas. Dê a eles o ambiente e o suporte que precisarem e confie que eles farão o trabalho.

Motivação é um assunto interessante. Comecemos citando o criador do Dilbert, Scott Adams, que disse: "Estou tendendo a acreditar no princípio de que não se pode motivar pessoas, apenas desmotivá-las." Concordamos muito com isso. E expor os problemas que a desmotivação em um ambiente de trabalho causa poderia ser assunto de um post inteiro, mas creio que estamos todos mais do que familiarizados com esse problema.

Em um bom trabalho em time, as pessoas prestam atenção nas outras e tentam manter todas felizes. Contudo, não é raro que fatores externos também interfiram na motivação do time. De itens básicos como cadeiras desconfortáveis e café ruim até os mais graves como a falta de autonomia, opiniões ignoradas e prazos impossíveis. Tirar problemas do caminho ajuda as pessoas a focarem no que realmente importa.

Outra parte polêmica dessa frase é a palavra "confie". E aqui vale um pequeno problema circular para refletir: trabalhar com quem confia em você é muito mais motivante do que trabalhar com quem sempre está atrás da sua cadeira, verificando que você está trabalhando e fazendo suas tarefas direito. E, convenhamos, se "não dá pra confiar no Fulano de jeito nenhum" passou da hora de repensar se essa pessoa deveria mesmo estar no seu time.

Processos ágeis promovem desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários deveriam ser capazes de manter um ritmo constante indefinidamente.

Esse princípio fala de sustentabilidade, assunto bastante importante e frequentemente deixado de lado em busca da tal da produtividade. E vale relembrar um conceito importante: produzir muito não é ser ágil! Mesmo porque há mais do que só desenvolvedores na construção de um projeto, especialmente se praticarmos o desenvolvimento incremental. Produzir demais também causa desperdícios.

Não vale a pena focar em produzir mais software se o levantamento do que é mais necessário não acompanhar o ritmo. Na outra ponta, é arriscado produzir muito código sem que as mudanças sejam entregues aos usuários ou sequer aprovadas. Hora-extra não é sinal de comprometimento do time, mas uma indicação de planejamento falho. Largar mão de qualidade técnica pode fazer um time produzir mais em curto prazo, mas o impacto a longo prazo é potencialmente terrível.

E, claro, ainda há aqueles problemas de fluxo fáceis de enxergar em times que usam um quadro branco (kanban) de acompanhamento do projeto. Até mesmo times que não são de desenvolvimento de software conseguem tirar proveito dessa ferramenta.

Quanto mais sub-times, quanto mais especialistas não-generalistas um time tem, mais frequente é o problema de fluxo e ele também está relacionado a esse princípio.

Práticas relacionadas

Agora que já conhecemos esses princípios e vimos exemplos de suas aplicações, vejamos uma sopa de letrinhas de artefatos, práticas e papéis para você saber o que procurar para se aprofundar nesses assuntos:

Retrospectiva

principal ferramenta de construção e manutenção de times, retrospectivas ajudam a evidenciar as dores de cada membro do time e a promover melhorias -- e melhorias motivam! Além disso, retrospectivas frequentemente ajudam a remover problemas de comunicação;

Daily Meeting ou Stand Up Meeting

o poder de um encontro diário de 15 minutos onde todos se comunicam é impressionante. Muito além de reportar o status do projeto, o daily é uma oportunidade diária de aprender e ouvir os outros membros do time;

Metáfora do sistema

uma das grandes dificuldades de colocar usuários, clientes e desenvolvedores para conversar é que seus vocabulários e formas de expressão podem ser extremamente diferentes. Quando esse é o caso, construir uma metáfora que ambos os lados saibam traduzir para sua visão do sistema é algo tão poderoso quanto simples;

Sem hora-extra

trabalhar mais do que aguentamos é uma má ideia sob diversos prismas: aumenta custos do projeto para quem paga, provoca queda na qualidade de vida dos que fazem, o que usualmente provoca queda na qualidade do código e inserção de bugs. A menos que por um breve período e por decisão do time, horas extra são monstrinhos para seu projeto;

Product Owner / Cliente próximo

novamente, reiteramos a importância da participação próxima do cliente, que aumenta as chances de o projeto caminhar na melhor direção possível;

Workspace informativa

comunicação passiva é uma excelente forma de nos assegurarmos que todos estão na mesma página, com relação ao projeto. Trazer o acompanhamento do projeto para o local onde ele é desenvolvido não só melhora a comunicação do time, mas também incentiva clientes a conhecer o ambiente e os desenvolvedores;

Gráficos

Parte da sua workspace informativa, gráfico de Burn Up ou Burn Down, velocidade média, fluxo acumulado, ou qualquer outro que mostre informações de acompanhamento sobre seu projeto ajudam muito na comunicação e, assim, são ferramentas poderosas. Cuidado, apenas, para não deixar informações se desatualizarem. Se gráficos forem tão pouco importantes a ponto de ficarem desatualizados, remova-os!

Trabalhar com pessoas é sempre complexo e é exatamente por isso que agilistas dão tanta atenção para essa faceta dos projetos. Uma boa comunicação pode não ser perceptível, mas uma má interação entre as pessoas pode ser incrivelmente destrutiva. Exatamente por isso, gostamos de falar muito sobre isso em eventos, conversas de corredor e também no PM-83.

Nos seus projetos, como você trabalhou comunicação e feedback? Além disso, o que fez para aproximar clientes e usuários do time do projeto?