O desenvolvimento de software, como bastante enfatizado, é um trabalho criativo, e empresas sempre têm um ótimo retorno quando investem em um ambiente que propicie a criatividade da equipe. Como escreveu o desenvolvedor do Github, Zach Holman, em uma sequência de posts, uma decisão que muito contribui para a melhoria do ambiente de trabalho é fazer com que toda a interação da equipe se dê de forma assíncrona.
No caso do Github, a solução é simples: a forma principal de comunicação na empresa é uma ferramenta de chat:
O Github não teve um escritório nos seus dois primeiros anos; toda a interação da equipe era feita via chat. Hoje já estamos no segundo escritório, e o chat continua sendo a maneira que fazemos as coisas funcionarem.
Pode-se notar as vantagens claras da "assincronicidade" em um ambiente de desenvolvimento, em que não raro os desenvolvedores passam grande parte do tempo concentrados, programando, e em que a comunicação com o restante da equipe é feita através de emails ou mensagens instantâneas em momentos de pausa. Encontra-se até equipes inteiras que passam dias fisicamente distantes, porém com o projeto fluindo sem que a distância se torne um empecilho.
A comunicação assíncrona, reforça Holman, permite que cada membro da equipe decida quando é a melhor hora para interagir com os outros membros, sem a necessidade interromper seu fluxo de trabalho a todo momento, para atender ligações ou responder perguntas de colegas. Isso pode soar óbvio, mas é fato recorrente dentro de ambientes comuns de trabalho, e afeta diretamente a produtividade e os resultados do desenvolvedor:
Usar a comunicação assíncrona significa que se pode sair para almoçar e mais tarde acompanhar tudo o que foi discutido; que se pode fazer uma pergunta a alguém da equipe e não se preocupar em atrapalhar sua concentração. E que se pode trabalhar em casa ou em lugares remotos e se sentir como se estivesse no escritório.
Outro ponto citado pelo autor, sobre como a comunicação se dá geralmente de forma assíncrona, é o processo de desenvolvimento adotado pelo Github. Toda implementação, seja ela de uma nova funcionalidade ou correção de bug, é feita em paralelo por cada membro da equipe, através de um modelo chamado Pull Requests.
No lugar de todo desenvolvedor trabalhar diretamente com o código-fonte de produção, é criada uma estrutura em separado deste código para cada membro da equipe, e todo o desenvolvimento é feito neste código auxiliar. Quando finalizado o código, é iniciada uma discussão sobre as mudanças feitas, incluindo revisão do código, comentários sobre as modificações etc., antes que a mudança seja incorporada ao repositório principal. Isso que permite que a colaboração durante o desenvolvimento também aconteça de forma assíncrona:
No modelo de Pull Requests, não preciso arrastar ninguém para uma reunião que seria inconveniente para eles e para mim.
A principal vantagem deste modelo é reduzir reuniões ao mínimo ou mesmo evitá-las totalmente. Holman destaca que outras empresas consideram reuniões "extremamente tóxicas”.
Reuniões tendem a envolver mais pessoas que o necessário, e mesmo que se esteja extremamente interessado no assunto da reunião, impedem que se trabalhe passando em vez disso a discutir sobre o trabalho.
Nota-se que o aumento de reuniões é proporcional ao número de reclamações da equipe pelo tempo perdido e os poucos resultados alcançados.
Detalhes como estes contribuem para que a equipe de desenvolvimento tenha um ambiente saudável e criativo para trabalhar. Maior ainda é o ganho para a empresa, ao manter a equipe comprometida e, principalmente, motivada.
Problemas antigos e Problemas novos
by Victor Tales,
Re: Problemas antigos e Problemas novos
by Rafael Nunes,
Fábricas assincronas?
by André Viturino Barbosa,
Re: Fábricas assincronas?
by Rafael Nunes,
Problemas antigos e Problemas novos
by Victor Tales,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Quando comecei a usar Scrum uma das coisas que eu mais gostei foi a facilidade e transparência que a comunicação fluía. Isso se dá em sua maioria quando ocorre a Daily Meeting, garante que todos estejam cientes do trabalho do time, torna a equipe responsável pelo seu trabalho e dos outros que estão interagindo.
Usar o chat ou e-mail como ferramenta de desenvolvimento, é voltar no tempo, antes era dessa forma que a comunicação era mantida entre os projetos. Quais eram os problemas que isso acarretava?
1) Programador Herói: Aquele que só pede ajuda quando está morrendo pelas mãos do monstro
2) Programador Síndrome do Estudante: Diz que demora uma semana para fazer, mas no fim, acaba só demorando um dia e entrega de última hora
3) Programador Ostra: Só sai da casca para virar "comida"
Precisamos de uma interação maior do que chat e e-mails dentro de um projeto, precisamos que o time esteja coeso e acima de tudo responsável pelo trabalho do TIME e não somente do SEU trabalho. É lógico que temos problemas também com essa abordagem, reuniões de Daily que são praticamente reuniões de status e não agregam valor ao processo de trabalho por exemplo, mas isso deve ser administrado pelo Scrum Master que deve manter a cola entre Comunicação x Time x Backlog x Cliente.
Chat e e-mail são ótimos, mas desde que sejam utilizados com os aspectos que eu citei acima, para manter a responsabilidade da pessoa entre o que ela faz e o que o time faz. Se essa pessoa só se comunica quando ela decide ser o momento certo, desculpe, o momento certo para pode não ser o momento certo para todos e para o projeto.
Re: Problemas antigos e Problemas novos
by Rafael Nunes,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Minha experiência(e mais de uma) com Daily Meetings é exatamente o que você citou, apenas uma reunião de 'status report'. E se dependemos que o scrum master administre toda a comunicação/time/backlog/client, então só trocamos o papel, deixamos de ter um desenvolvedor herói e passamos a ter um scrum master herói.
Para mim a maravilha de se trabalhar assíncrono, é eu por fazer o meu timing, como não precisar estar trabalhando num horário pré-definido para a daily scrum, e poder definir os meus horários de parada para me comunicar com o restante do time(respeitando também o horário de parada deles). Porque eu acho praticamente impossível acontecer como você citou um 'momento certo para todos'.
No mais, parece que tem dado bastante certo pra galera do Github, 37signals, Google, e mais um monte de gente que tenho notícia.
Fábricas assincronas?
by André Viturino Barbosa,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Eu não concordo totalmente com a acepção de que toda a interação deveria ser de forma assincrona. Na verdade, afirmações que vem com "tudo", "todo", "sempre", normalmente são questionáveis.
A impressão que passa é que o isolamento do desenvolvedor sempre é essencial, e isso é dar um passo pra trás, como disse o Victor. Nós lutamos tanto para afirmar que software é feito por pessoas, para pessoas, e queremos nos livrar da comunicação tête-a-tête? Queremos montar fábricas de software assincronas?
Óbvio que a "assincronicidade" é útil, mas para o que for assincrono: eu uso muito email, para distribuir, questionar e receber tarefas. Só que volta e meia eu caio na situação oposta: um backlog gigante de emails e mensagens para organizar e responder, e isso também atrapalha meu trabalho - mesmo tarefas assincronas são esperadas num prazo determinado de tempo.
Também é óbvio que reuniões exaustivas são um porre, mas isso cria um paradoxo: equipes realmente ageis precisam das reuniões exaustivas? Nesse caso, temos uma equipe ágil ou um banco de bur(r)ocratas?
Acho válido que o desenvolvedor deva ficar um pouco mais longe da burocracia do mundo corporativo, para melhor fazer o seu trabalho. Mas não podemos nos isolar como ermitões numa montanha.
Re: Fábricas assincronas?
by Rafael Nunes,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Talvez tenha expressado mal, também não acho que isolamento seja algo bom ou produtivo, nem que 'toda' comunicação deve ser assíncrona. Como Zach disse, o chat é a principal forma de comunicação(mas isto não quer dizer que seja a única). No ost dele mesmo ele fala dos encontros para tomar chopp com a equipe durante o trabalho, ou projetos em paralelo que se faça em tecnologias aleatórias.
É claro que conversar diretamente(seja pessoalmente ou via skype) é necessário em momentos que o chat não resolve, mas a proposta é que este seja o segundo passo, e não uma conversa direta antes de tentar resolver por uma mensagem.