Participe do Appsilon e do RStudio para um webinar conjunto – Habilitando equipes remotas de ciência de dados – em 28 de julho @ 11h EST. Abordaremos o controle de versão, o dimensionamento do R Shiny, o crescimento de uma equipe remota de ciência de dados e muito mais. voce pode registrar aqui.
Contents
- 1 Como configurar uma equipe de ciência de dados distribuídos
- 2 Gerenciamento de Projetos e Comunicação
- 3 Dicas para colaboração e comunicação eficazes
- 4 Controle de versão e revisão de código
- 5 Fluxo de trabalho de desenvolvimento reproduzível com Docker e renv
- 6 Conclusão: Remoto ou Não, Mantenha-se Organizado
- 7 Saber mais
- 8 Relacionado
Como configurar uma equipe de ciência de dados distribuídos
A configuração de um ambiente colaborativo para sua equipe de ciência de dados é um desafio, mesmo quando você trabalha lado a lado no mesmo escritório. A tarefa pode ser ainda mais onerosa quando todos estão trabalhando remotamente. Talvez você já tenha que lidar com um espaço de trabalho apertado e uma criança chorando na porta do seu escritório em casa – também não precisa se preocupar com falhas de aplicativos e conflitos constantes de versão.
“Funciona na minha máquina. Por que isso não funciona no seu?
Se você implementar as práticas recomendadas neste artigo, nunca precisará ouvir isso novamente.
At Appsilon, passamos anos desenvolvendo sistemas eficientes para colaboração remota. Neste artigo, abordarei as práticas recomendadas para organizar uma equipe de ciência de dados distribuída e iniciar um novo projeto de ciência de dados ou R Shiny. Explicarei como usamos o Scrum para distribuir o trabalho de forma transparente para a equipe e para os nossos clientes. Eu também vou mostrar como usamos Github colaborar com o controle de versão e garantir a qualidade. Finalmente, eu vou cobrir um Dockerfluxo de trabalho para facilitar o desenvolvimento. Aqui está um guia para o que abordaremos:
Gerenciamento de Projetos e Comunicação
Usamos uma versão modificada de Metodologia Scrum para gerenciamento de projetos na maioria de nossos projetos. Antes do início do projeto, o líder do projeto do lado do Appsilon coleta os requisitos do cliente e os divide em tarefas de alto nível. É assim que o backlog inicial do projeto é criado. Também fornecemos estimativas aproximadas de quanto tempo precisamos para concluir o trabalho.
Por exemplo, podemos planejar o trabalho por 8 semanas e depois dividimos em 8 sprints. Cada sprint começa com uma sessão de planejamento em que nós (a equipe do projeto) sentamos juntos com o cliente e planejamos o que será feito na próxima semana. Pegamos as tarefas da lista de pendências do projeto e as dividimos em tarefas menores e as distribuímos entre a equipe do projeto. Por fim, mas não menos importante, estabelecemos uma meta de sprint, que é a coisa mais importante que queremos alcançar no final da semana. Terminamos a semana com uma revisão de sprint, onde apresentamos o treino de incremento durante a semana.
Internamente, nos reunimos diariamente para uma reunião de status muito curta (que chamamos de ‘diária’) para atualizar um ao outro e garantir que todos estejam claros sobre as tarefas que precisam concluir. Também é uma boa oportunidade para acompanhar as pequenas coisas que estão acontecendo na equipe, pois não temos a comunicação contínua que um ambiente de escritório fornece.
Existem várias ferramentas que nos ajudam a gerenciar o backlog e os sprints. Por exemplo, usamos placas de projeto em Asana ou Github. O quadro do projeto reflete o estado atual do nosso trabalho. Nossos clientes têm acesso ao quadro relacionado ao seu projeto, para que possam verificar as prioridades atuais da equipe sempre que quiserem.
Organizamos nosso quadro de projetos nas seguintes colunas:
- Backlog
- A Fazer (em uma determinada semana)
- Plano de implementação
- Em progresso
- Em revisão
- Feito
Nosso processo scrum está intimamente relacionado a controle de versão e revisão de código. Se você quiser saber mais sobre controle de versão e tópicos relacionados, assista à apresentação de Marcin Dubel em Como escrever código R pronto para produção.
Dicas para colaboração e comunicação eficazes
- Escreva um plano de implementação. “Plano de Implementação” é uma coluna fora do padrão no quadro do projeto. Nós o apresentamos como resposta a vários problemas que encontramos. Por exemplo, algumas vezes, durante a revisão do código, o revisor esperava uma implementação diferente, a tarefa foi mal compreendida ou a tarefa poderia ter sido concluída de uma maneira mais simples. Portanto, antes do início da codificação, o proprietário da tarefa escreve um pequeno plano de implementação, recebe uma luz verde do revisor e começa a codificar. Isso evita muitas horas desperdiçadas devido a falhas de comunicação e implementação ineficiente.
- Uma tarefa para tudo. Todo o trabalho do projeto precisa ter uma tarefa correspondente. Se não houver tarefa para um trabalho que precise ser realizado, um membro da equipe deve criar uma tarefa e adicioná-la ao quadro. Cada tarefa precisa ser bem definida e bem descrita, para que fique claro para outros membros da equipe (e para o nosso cliente) o que está sendo feito. Mais tarde, quando a tarefa estiver concluída, cada solicitação de recebimento (PR) precisará vincular a uma tarefa no quadro de projetos.
- Documente toda a comunicação. Certificamo-nos de documentar toda a comunicação e de ter descrições escritas de nosso trabalho. É importante para nós que a diretoria do projeto e o repositório de códigos contenham todas as informações necessárias para concluir o trabalho. É ainda mais essencial agora quando não compartilhamos um escritório com outras pessoas. A barreira de perguntar “ei, o que você quis dizer aqui?” é maior em uma configuração remota.
- Mantenha a comunicação centralizada. Quase todas as comunicações diárias relacionadas ao projeto que estão fora das reuniões acontecem no Slack, de preferência em um canal de projeto dedicado. Dessa forma, não precisamos procurar em vários canais (e-mails, textos, etc.) para encontrar as informações de projeto que precisamos. Além disso, usamos para informar um ao outro que começamos e terminamos o trabalho, quando estamos no modo “Não perturbe”, ou simplesmente precisamos de uma pausa. Usamos a integração com o Google Agenda que atualiza automaticamente o status e informa aos outros que estamos em uma reunião.
Controle de versão e revisão de código
Normalmente, usamos o Github para nos ajudar a gerenciar o controle de versão e executar revisões de código. Eu recomendo fazer o GitHub parte do seu fluxo de trabalho, independentemente da configuração da sua equipe.
Práticas recomendadas que seguimos:
- Todo o código deve ser revisado por pares antes de mesclar em qualquer ramificação principal. Por padrão, desativamos a opção de mesclar sem uma revisão no Github.
- Todas as alterações aprovadas devem ser mescladas no ramo principal que usamos para o desenvolvimento.
- As verificações de integração contínua (linter, testes de unidade, testes de integração) devem ser configuradas e aprovadas. Usamos Ações do Github para configurá-lo no início do projeto.
- Qualquer código adicionado ou modificado deve seguir o nosso guia de estilo. Isso nos ajuda a garantir a qualidade, escrever código que seja mais fácil de ler e entender e detectar rapidamente erros.
- Use modelos de projeto. Inicializamos a estrutura de repo para tipos de projeto típicos a partir de nossos modelos internos. Usamos um modelo de solicitação de recebimento com uma lista de verificação para o revisor.
Antes de enviar um PR, verifique se:
- A alteração foi testada (manualmente ou com testes automatizados).
- Tudo funciona corretamente e funciona como esperado. Nenhuma funcionalidade existente está quebrada.
- Não são introduzidas novas mensagens de erro ou aviso.
- O README, outra documentação e comentários de código foram atualizados com todas as informações necessárias relacionadas à alteração.
- O revisor é responsável por verificar cada aspecto da tarefa.
Fluxo de trabalho de desenvolvimento reproduzível com Docker e renv
Na Appsilon, nossa equipe sempre foi distribuída entre dois escritórios separados, com colaboradores espalhados por todo o mundo. Portanto, mesmo antes da pandemia, tínhamos membros do projeto espalhados por diferentes locais. Além disso, atendemos um grande número de clientes globais com base em diversos fusos horários.
Para alguns projetos, trabalhamos na infraestrutura do cliente e nada pode deixar seu ambiente. Para outros, temos mais “liberdade” e podemos trabalhar localmente em nossas próprias máquinas. É essencial não perdermos tempo configurando um ambiente de desenvolvimento, independentemente da maneira como trabalhamos. Às vezes, trocamos membros da equipe com base na especialização necessária para um estágio específico do projeto (front-end, infraestrutura etc.), por isso é importante facilitar muito o início do desenvolvimento de novos membros do projeto em qualquer estágio do projeto.
Para atender a diferentes sistemas operacionais, dependências do sistema, versões R e versões de pacotes R, desenvolvemos uma instância do RStudio executada em um ambiente isolado (um contêiner do Docker). Quando iniciamos um novo projeto, sempre criamos uma imagem dedicada do Docker para garantir consistência entre as estações de trabalho dos membros da equipe.
Usando o Docker e o `renv` juntos, garantimos a reprodutibilidade. O sistema subjacente, suas dependências e pacotes R necessários, são fixos e constantes para um aplicativo específico. Para saber mais sobre por que isso é importante, leia a postagem do blog de Pawel Przytula em pesquisa reproduzível. Usamos um arquivo de bloqueio `renv.lock` para instalar pacotes R quando a imagem do Docker é criada. UMA tutorial sobre como configurar o Docker e o `renv` está prontamente disponível no RStudio. Armazenamos a versão mais recente do arquivo de bloqueio no repositório do projeto. Todas as alterações relacionadas à imagem do Docker devem ser enviadas ao registro. Nosso fluxo de trabalho de desenvolvimento pode ser configurado a partir de um repositório git como um modelo de projeto.
Conclusão: Remoto ou Não, Mantenha-se Organizado
Não há receita secreta para fazer sua equipe de ciência de dados funcionar eficientemente em uma configuração remota. De fato, descobrimos que usar o scrum com uma diretoria de projeto bem organizada, revisar códigos e cuidar do ambiente de desenvolvimento é essencial para o sucesso do projeto, independentemente da estrutura da sua equipe. Esperamos que essas práticas recomendadas ajudem a manter sua equipe de ciência de dados organizada e produtiva, mesmo depois que for seguro retornar ao escritório.
Saber mais
Artigo Práticas recomendadas da equipe remota de ciência de dados: Scrum, GitHub, Docker e muito mais vem do Appsilon Data Science | Soluções completas de ciência de dados.
Relacionado
