Automatizando a comunicação interna em projetos de desenvolvimento de software – um estudo de caso

O artigo sobre o Capítulo 6 do livro The Mythical Man-Month – Passing the Word – fala sobre algumas técnicas de como melhorar a comunicação durante o projeto de desenvolvimento de software.

Embora os princípios sobre comunicação e documentação permaneçam os mesmos até o dia de hoje, as técnicas citadas no livro não se aplicam à nossa atual realidade.

Neste artigo vou apresentar, resumidamente, como utilizamos dentro da Atlassian as suas próprias ferramentas para realizar comunicação e documentação com alto grau de automação.

Comunicação e documentação usando ferramentas modernas

Registrar chamadas telefônicas e distribuir cópias impressas de um manual, conforme sugerido por Brooks no capítulo 6, são práticas que, se ainda são feitas, precisam ser abandonadas. Elas foram deixadas para trás após a ascensão de meios de comunicação tecnológicos mais rápidos, eficientes e econômicos.

Lembre-se, nos anos 70 não havia disponível sistemas de comunicação interna e troca de mensagens instantâneas. Hoje isso fica muito mais fácil usando aplicações na intranet ou, ainda melhor, na nuvem.

Até agora este é um dos poucos pontos do livro que se tornaram desconexos da realidade diária do desenvolvimento de software. Entretanto, note que os mesmos princípios relacionados à complexidade e efetividade da comunicação ainda valem, somente os meios mudaram.

Nos tópicos a seguir, irei exemplificar práticas modernas e mais eficientes de comunicação usando como modelo o ambiente onde trabalho atualmente, na Atlassian.

Reuniões

Reuniões são mais produtivas munindo os participantes com laptops e usando um projetor ou TV grande nas salas de reunião.

Claro que, na maioria das vezes, o conteúdo precisa estar previamente preparado, mas fica muito mais fácil alternar entre páginas web, documentos, gráficos, código-fonte, demonstrações do produto e outros conteúdos do que se você tivesse que gastar tempo juntando tudo isso num documento formal ou numa apresentação de slides.

Como eu já defendi anteriormente em Boas empresas, boas condições de trabalho, laptops são essenciais para produtividade em equipe. Não basta ter uma CPU genérica plugada num projetor, pois na prática isto impossibilita que as equipes façam mais do que mostrar um documento de texto ou planilha na tela.

Laptops pode ser uma distração se usados de forma incorreta, mas são muito eficientes para desenvolvedores discutindo código ou gerentes planejando com a equipe em tempo real.

A Atlassian possui um sistema de teleconferências nas salas de reuniões para facilitar encontros entre equipes de diferentes localidades. Por exemplo, minha equipe tinha alguns projetos em comum com outra equipe localizada na Polônia, então fazíamos um scrum of scrums duas vezes por semana para alinhar os pontos. Cada equipe numa sala de reunião e vendo a outra no vídeo.

Mas isso pode ser tão simples quanto fazer chamadas gratuitas de videoconferência no Skype ou no HipChat. No meu tempo como Desenvolvedor no Suporte, nós fazíamos standup dessa forma com as equipes de suporte de outros países.

Troca de mensagens instantâneas e conferências individuais

Para comunicação rápida entre os desenvolvedores, usamos salas de bate-papo do HipChat.

As salas são segregadas por projeto, onde todos os participantes podem acompanhar as discussões para ajudar ou aprender sobre o produto em que trabalham.

Cada equipe possui uma sala, então também fica mais fácil quando você precisa interagir com outras equipes ou fazer um comunicado à sua própria equipe. Basta acessar a sala correta e conversar. Não precisa abordar pessoas aleatoriamente na empresa e ficar dependendo delas estarem presentes fisicamente.

Tal meio é mais eficiente do que ligações telefônicas porque as conversas ficam automaticamente registradas e são independentes do horário em que cada um costuma trabalhar, facilitando também projetos internacionais.

O HipChat também permite vídeo-conferências, tal como o Skype, o que é bem útil para quem trabalha remotamente. Conversas por vídeo são boas quando se tem algum assunto mais urgente ou para conversas particulares entre gerente/líder e membros da equipe. Elas não são ideias para todas as ocasiões porque você não tem um registro textual da conversa, além do que se a conversa for curta, o tempo de organizar a chamada pode ultrapassar o tempo de simplesmente escrever algo.

Comunicação interna permanente

A comunicação interna é realizada mais facilmente usando uma ferramenta feita especificamente para isto. Aqui, no caso, temos o Confluence.

Usamos o Confluence para gerar documentação interna, propor novas ideias, postar atualizações em blogs internos, registrar incidentes, investigações e tudo o mais.
Tudo segregado por projeto ou área, de forma que qualquer um pode acompanhar projetos específicos.

Se você não conhece o Confluence, ele é basicamente um gerenciador de conteúdos que permite criar páginas organizadas hierarquicamente e blogs, divididas por projetos ou "espaços". Ele também conta com alguns plugins para estender suas funcionalidades, o que permite criar páginas muito mais dinâmicas do que um documento Word, por exemplo.

Alguns exemplos de como o Confluence é superior a documentos estáticos ou mesmo alguns sistemas simples de conteúdo são:

• Lista de tarefas do JIRA baseada em um filtro qualquer.
• Você pode mencionar usuários usando o caractere arroba, tal como @nome. Assim fica fácil relacionar pessoas a documentos, além de que o usuário é notificado sobre essa menção, então não é preciso nem ficar enviando o link para os contatos de interesse.
• Incluir comentários inline ou anotações em qualquer texto da página, sendo possível sugerir correções, melhorias ou expressar sua opinião selecionando exatamente o trecho em questão.
• Criar calendários, por exemplo para detalhar as folgas e férias de cada membro da equipe.
• Você pode se registrar para receber notificações de conteúdos criados, edições, comentários, etc.
• O sistema registra todo o histórico de edições no conteúdo.
• Novas versões do Confluence incluem um modo de edição colaborativa, como o Google Docs, onde várias pessoas podem editar o documento ao mesmo tempo e cada uma vê o que a outra está fazendo.

Enfim, uma ferramenta como o Confluence tem um valor inestimável para a comunicação interna da empresa:

• Ela ajuda a manter a documentação interna “viva” ao permitir edições de qualquer lugar e a qualquer momento.
• Evita a perda de informações ao versionar o documento automaticamente.
• Permite integrações com diversas outras ferramentas para manter o conteúdo atualizado automaticamente, evitando gerar conteúdo duplicado, ainda que se possa visualizar os dados em mais de um lugar.
• Ela automatiza a interação das pessoas com o documento através de menções e anotações.

Existe ainda um plugin chamado Questions for Confluence, de perguntas e respostas, que funciona como um Stack Overflow interno da empresa. Isso lembra bastante o histórico de perguntas via telefone citado pelo autor. A diferença é que as pessoas podem rapidamente pesquisar na intranet e encontrar respostas para as dúvidas mais comuns ou fazer uma nova pergunta se não encontrar a solução.

Isso é particularmente importante porque sempre há aquelas dúvidas frequentes que todo novo desenvolvedor faz e que toda vez alguém precisa lembrar e copiar a solução de algum lugar, o que não é produtivo para ninguém. Sabe aqueles pequenos documentos texto de como configurar a ferramenta X ou Y ou como testar o sistema Z que você acaba fazendo por si mesmo e colocando em algum diretório compartilhado da empresa? É excelente não precisar fazer mais isso!

Caso você use ou venha a usar tal ferramenta, uma dica: é possível ver quem são as pessoas que mais ajudam. Qual tal convencer sua empresa a dar algum prêmio de para quem se destaca em ajudar os colegas?

Acompanhamento das tarefas

O acompanhamento de tarefas individuais é obviamente feito mapeando cada tarefa a um issue no JIRA Software – versão específica para equipes de software.

Tarefas não são apenas pequenas partes da implementação, mas podem incluir:

• Testes
• Investigações
• Melhorias de desempenho
• Escrita de documentação
• Resolução de Bugs
• Procedimento a ser realizado

Enfim, qualquer coisa que seja necessário para completar o projeto.

Componentes grandes dos projetos podem ser acompanhados em épicos, que são issues contendo todos os issues necessários para concluir este componente.

Boards do Kanban e do Scrum também são muito úteis para rapidamente visualizar e atualizar o status de cada tarefa, além de permitir separar o backlog em sprints.

Código-fonte

Outra ferramenta importante é o Bitbucket, o produto da Atlassian que concorre com o GitHub. Nele você pode criar repositórios Git ou Mercurial para colocar seus projetos.

Assim como o GitHub, você pode usá-lo gratuitamente para armazenar projetos pessoais e com uma vantagem: nele você pode ter repositórios privados de graça!

Na empresa, ao invés de manter um repositório num servidor físico dentro da empresa, ter um repositório distribuído na web permite que o pessoal de qualquer localidade trabalhe no projeto sem nenhuma infraestrutura adicional.

Adotamos um processo largamente recomendado onde cada implementação é feita numa branch específica do projeto, vinculada a um issue do JIRA.

Para fazer o merge com a brach principal (master), é necessário passar pelo processo de revisão de código ou peer review. O Bitbucket, assim como o Github, permite criar um Pull Request, que é uma solicitação de merge.

Os demais envolvidos tem então a chance de analisar suas mudanças e sugerir melhorias, correções, etc. Eles podem adicionar comentários nas linhas alteradas do código, por exemplo. Finalmente, quando as partes estiverem satisfeitas, elas aprovam o Pull Request e você pode aplicar suas alterações na branch principal.

Tudo isso pode parecer burocrático, mas depois que se acostuma é bem simples e direto. Já perdi a conta de quantas vezes esse processo de revisão evitou a introdução de bugs ocultos, erros de digitação e, o melhor de tudo, ajudou a produzir soluções muito superiores se cada um fizesse o commit diretamente no código principal.

Integração contínua

Na Atlassian, usamos o Bamboo para realizar a integração contínua. Ele é um servidor de CI – Continuous Integration – do mesmo modo que o Jenkins/Hudson, mas integra melhor com as demais ferramentas da Atlassian, então você já pode ver que por aqui o espeto não é de pau. 🙂

Basicamente você pode criar projetos no Bamboo, cada um com diferentes planos de construção (builds), cada plano com estágios diferentes, cada estágio sendo composto por um conjunto de tarefas.

Um exemplo:

• Projeto: JIRA
• Plano: Teste Funcional
• Estágios:
  • Compilação:
    • Clona o código do repositório Git
    • Executa os comandos para compilar e empacotar, tal como mvn package
  • Deploy do JIRA numa VM
    • Cria VM
    • Deploy do pacote gerado
    • Aguarda sistema iniciar
  • Execução dos testes
    • Cria várias VMs para rodar diferentes conjuntos de testes
    • Inicia a execução dos testes usando um browser em cada instância
    • Coleta os resultados dos testes

Juntando tudo

O mais interessante de tudo é que todas essas ferramentas que citei acima trabalham em conjunto muito bem, automatizando boa parte do trabalho, inclusive de registro e documentação.

Por exemplo, imagine que eu estou querendo fazer uma melhoria aqui no JIRA. Primeiro eu poderia criar uma página no Confluence com a minha proposta, uma espécie de RFC (Request For Comments). Os arquitetos e desenvolvedores podem então adicionar comentários e críticas.

Uma vez que se chegue a um consenso sobre a viabilidade, eu poderia criar um épico no JIRA contendo as tarefas que considero necessárias para a conclusão do projeto ou pelo menos da primeira fase. Cada issue recebe o link da documentação necessário no Confluence.

A configuração do projeto pode incluir também um repositório no GitHub e um projeto no Bamboo, com planos de execução que empacotam, testam, analisam (findbugs, por exemplo) e publicam versões do projeto.

No dia-a-dia, o estado do projeto pode ser acompanhado usando um board que mostra o que tem para ser feito, o que está sendo feito e o que já foi feito.

Para fins gerenciais, eu poderia criar uma página que funcione como um status report no Confluence, montando uma query para exibir todos os issues ainda pendentes, issues que já ultrapassaram o tempo estimado e assim por diante.

A saúde do código pode ser verificada verificando se os builds no bamboo estão verdes. Se alguém criar algum código que faça os builds ficarem vermelhos, basta reverter aquelas mudanças para normalizar a pipeline e solicitar que o autor do commit reveja as mudanças.

Estando JIRA, Bitbucket, Confluence, HipChat e Bamboo devidamente integrados, várias outras funcionalidades são possíveis.

Por exemplo:

• Quando eu começar a trabalhar numa issue do JIRA, há um link que cria uma branch automaticamente e a vincula com aquele issue. As branches criadas via comandos Git também funcionam de forma integrada, mas é preciso respeitar uma regra de nomenclatura.
• A cada push para o Bitbucket o Bamboo executa automaticamente os builds pré-configurados na sua branch, de forma a verificar se suas alterações não causaram regressão no sistema. Essas informações são exibidas se você acessar o issue no JIRA e você é notificado via e-mail se o build falhar.
• Eu posso criar uma sala no HipChat para o meu projeto e configurá-la para receber notificações automáticas do JIRA, avisando se alguém criar, alterar ou comentar em qualquer issue.
• A sala no HipChat também pode receber notificações dos builds do Bamboo, de edições das páginas do Confluence e de comentários e aprovações nos pull requests. A sala basicamente se torna um histórico vivo do que é feito no projeto.
• Ao criar o Pull Request no BitBucket, os resultados dos builds do Bamboo são automaticamente exibidos, assim como um link para o issue no JIRA. Então todos podem facilmente se contextualizar sobre o propósito daquelas alterações e se os testes estão sendo executados com sucesso.
• Eu posso decidir que somente seja possível fazer o merge no master se houver um número mínimo de builds concluídos com sucesso no Bamboo, o que demonstraria que as alterações feitas foram efetivamente testadas.
• Um vez aprovado o Pull Request, você clica no botão para fazer o merge e o Bitbucket automaticamente integra seu código na branch principal.
• A página de visualização do issue no JIRA mostra informações sobre branches, builds, pull requests e menções daquele Issue em salas do HipChat.

Tudo isso que mencionei acima (e, acredite, ainda tem muito mais), funciona como uma documentação viva e automatizada do projeto.

Isso ficou muito evidente para mim especificamente nos últimos dias, quando uma equipe recentemente congelou um projeto inacabado devido a outras prioridade e decidimos continuar o trabalho deles.

Escute o que aconteceu:

• Eu fui até o épico no JIRA o olhei as tarefas que estavam incompletas.
• Li uma página do Confluence contendo um resumo do projeto, cujo link estava no épico.
• Acessei o Pull Request com as últimas mudanças e vi os comentários, o que me permitiu entender o que foi feito e as decisões que foram tomadas me concentrando somente no que foi realmente alterado, sem ter que ler todo o código. Aliás, um Pull Request bem feito evita que eu caia nos mesmos erros e armadilhas que os outros desenvolvedores já superaram.

Enfim, em poucas horas eu já estava com conhecimento suficiente para continuar o projeto sem ter conversado com ninguém e sem ter marcado reuniões.

Comunicação verbal e informal não são um problema

Embora tenha enfatizado muito a comunicação eletrônica e a automação da comunicação, não quero passar a ideia de que é errado ou ruim falar com as pessoas. Conversar quando possível é bom em vários sentidos e há algumas barreiras que só conseguimos quebrar olhando nos olhos uns dos outros.

Meu argumento nos tópicos anteriores é que depender exclusivamente do boca-a-boca para comunicação torna o acesso à informação mais difícil e demorado e a informação menos confiável.

Documentos “mortos” como planilhas e Word também são um problema por serem de difícil manutenção e atualização. Por "difícil", entenda como aquele trabalho a mais que dá para manter o documento atualizado e avisar todos os que usam o documento, que geralmente faz você pensar duas ou três vezes antes de mexer.

A verdade é que a maioria das pessoas racionaliza que tem coisas melhores pra fazer, esquivando-se da burocracia por uma razão ou outra. Esta é a vantagem de usar ferramentas especializadas que automatiza a parte chata e permite a você se concentrar no trabalho de verdade.

Outras Considerações

Alguns dizem que a diferença entre um bom e um mau profissional pode ser visto pelas ferramentas que ele usa. Se a comunicação é um dos fatores mais importantes num projeto de software, as ferramentas que uma equipe usa dizem muito sobre a qualidade resultante do trabalho deles.

Por outro lado, não faz sentido comprar ferramentas caras mas continuar a criar documentos inúteis ou não utilizar as ferramentas de forma adequada.

O processo de desenvolvimento de software de uma equipe ou empresa é algo complexo e que deve estar sempre em evolução, adaptando-se às mudanças nos negócios e liquidando passos repetitivos e burocráticos que atrapalham.

No meio de tudo isso, quaisquer ferramentas adotadas para facilitar a comunicação e o processo como um tudo somente devem continuar a ser utilizadas se cumprirem seu papel, como acabei de descrever. Se uma ferramenta não melhora o desenvolvimento de alguma forma, ela deve ser eliminada, por melhor que ela seja.

Também, a partir do momento em que ferramentas são adotadas por questões políticas, financeiras ou por alguma "modinha", elas acabam sendo mais um problema do que uma ajuda e também deveriam ser excluídas.

Um último ponto importante é que nem todo projeto e nem toda empresa pode se dar ao luxo de der um arsenal completo e automatizado de ferramentas. Assim como qualquer esforço em prol da qualidade, isso custa caro e muitas vezes exige pessoas especializadas. Se você trabalha em equipes pequenas ou em projetos de curta duração, você vai precisar ter um pouco de paciência e aceitar que vale mais a pena executar certas tarefas manualmente do que gastar metade do tempo do projeto automatizando todo o processo.