Qual estrutura ou metodologia você recomendaria para uma equipe de Data Science?
Sou Scrum Master para uma equipe composta principalmente por cientistas de dados, alguns engenheiros de software e um proprietário do produto.
Nossa organização decidiu que todas as equipes trabalham em sprints de 2 semanas usando Scrum. Eu pessoalmente não acredito que esteja funcionando. O framework Scrum não está realmente funcionando para nós pelos seguintes motivos:
- É muito difícil estimar porque o nível de incógnitas é enorme. Por exemplo, você teria um item do backlog para executar um experimento, a saída poderia e geralmente é muito variada. O resultado do experimento literalmente direciona seu trabalho para os próximos dias.
- Mesmo que você consiga fazer com que a equipe se divida em histórias, há um grande número de dependências entre as histórias. É mais como um fluxograma ou árvore de decisão do que um mapa da história.
- O PO e o SM não são cientistas de dados, é impossível realmente ajudar com o conteúdo das histórias.
- O compromisso de sprint quase nunca é concluído devido aos motivos acima.
- A equipe não se comunica da mesma forma que os engenheiros. Eles precisam de muito tempo para discutir e formular hipóteses (ou seja, não é para isso que o Scrum foi criado), pelo menos esta é a minha experiência.
- O planejamento de reuniões torna-se difícil devido à natureza desconhecida do trabalho.
Qual estrutura ou metodologia você recomendaria para uma equipe de Data Science?
Respostas
Vale a pena diferenciar entre o que é Scrum (conforme definido pelo Guia do Scrum ) e o que é popularmente associado ao Scrum.
Por exemplo, pontos da história, histórias, estimativas, velocidade, etc. não fazem parte do Guia do Scrum.
A equipe não se comunica da mesma forma que os engenheiros. Eles precisam de muito tempo para discutir e formular hipóteses (ou seja, não é para isso que o Scrum foi criado), pelo menos esta é a minha experiência.
Novamente, não há nada no Guia do Scrum que diga que você não gasta muito tempo discutindo e formulando hipóteses. Você está falando sobre as convenções do Scrum ao invés do que o framework realmente diz.
Eu trabalhei com equipes de ciência de dados que usaram o framework Scrum e eles passaram muito tempo discutindo seu trabalho.
O planejamento de reuniões torna-se difícil devido à natureza desconhecida do trabalho.
Então, eu sugiro que você gaste mais tempo sincronizando e menos tempo planejando. O valor de um framework como o Scrum é ajudar uma equipe a trabalhar em conjunto de uma forma mais colaborativa, apoiando uns aos outros, se necessário.
Para responder à sua pergunta, Scrum e Kanban podem ser usados para trabalhar com equipes de ciência de dados. A escolha da estrutura geralmente se resume aos tipos de personalidade dos membros da equipe, à natureza da organização e ao tipo de domínio no qual você está trabalhando.
Estou especulando, mas suspeito que o problema aqui é que a equipe está tendo uma abordagem imposta a eles, em vez de ter controle sobre a maneira como trabalham. As retrospectivas e o ciclo de inspecionar e adaptar no Scrum têm como objetivo permitir que a equipe ajuste a maneira como trabalham até encontrar uma abordagem adequada.
Kanban, ou seja, fluxo gerenciado em vez de sprints com prazo definido, faz muito sentido para o trabalho de pesquisa e descoberta exatamente pelos motivos que você mencionou. Talvez você ainda possa produzir as métricas e relatórios de status para manter sua equipe responsável perante a gestão, mas a ideia é se concentrar na priorização e na entrega sustentável, em vez de estimativa e iteração. Deve ser possível fazer um bom caso para isso se você puder evidenciar o tipo de questões que mencionou.
Além disso, certifique-se de ter um pipeline de integração contínua eficiente em vigor. Desde que você possa liberar com a freqüência necessária, todos ganham se não tiverem que definir todas as suas expectativas em um incremento de uma ou duas semanas.
Se há muitas 'hipóteses' e reuniões sem prazos fixos - é mais porque o escopo dos trabalhos ainda não foi esclarecido claramente. Quando o escopo é cimentado e o cronograma é preparado, mas novos requisitos estão chegando ou mudando ou reuniões são atrasadas - nós apenas continuamos a trabalhar no escopo já acordado, destacando os atrasos para o Cliente com opções de compensação, se ele quiser desprioritizar um recurso em favor de outro.
Você pode tentar a estrutura SAFe (https://www.scaledagileframework.com/# e https://www.guru99.com/scaled-agile-framework.html) - Posso destacá-lo além do que outros respondentes mencionaram antes. De muitos palestrantes em conferências profissionais organizadas na Rússia, esta estrutura foi destacada muitas vezes como usada em 'laboratório' (este termo é usado para nomear uma equipe de médio ou grande porte, focada no desenvolvimento de produto em uma área ainda não muito conhecida como nós). Épico -> Recurso -> Fluxo da história do usuário. Como você mencionou, 'seu PO não é um especialista na área de assunto' e que existe um 'grande número de dependências entre as histórias. É mais como um fluxograma ou árvore de decisão do que um mapa da história. Achei o SAFe potencialmente adequado para uso, pois possui recursos e proprietários de recursos, que se tornam pessoalmente responsáveis pelo valor E2E, que os caras com quem eles confiam são especialistas no assunto área e pode fornecer valor comercial + código.
A decomposição no SAFe é: Épico -> Sub-épico de arquitetura (em seguida, divisão em um recurso (s), que são divididos em histórias, que são divididas em tarefas por sua vez) mais o sub-épico de negócios (em seguida, divisão em um recurso ( s), que são divididos em Histórias, que por sua vez são divididos em Tarefas).
Minha experiência pessoal (analista de negócios em um projeto de grande empresa, onde em uma de suas fases usamos a abordagem baseada em recursos do tipo SAFe para focar na entrega de valor de negócios para alguns, mas tópicos carregados de cenários). Recurso , é propriedade do analista de negócios, cujo componente do produto é o mais impactado (também conhecido como 'proprietário da empresa' - responsável pelo E2E e, especificamente, pelo valor do negócio) mais o líder de desenvolvimento (também conhecido como 'proprietário técnico' - orquestra o desenvolvimento de todas as histórias, ou seja, E2E dentro do recurso). Enquanto isso, 'proprietário da empresa' depende dos resultados de implementação pertencentes ao 'proprietário técnico', 'empresa' é de qualquer maneira o principal,conforme ele finalmente demonstra para o cliente (externamente ou interno geral Product Owner - como no seu caso) e coleta o feedback.Histórias de negócios sob o recurso , cada um é propriedade do analista de negócios (responsável por um determinado cenário, ou seja, funcionalidade de acordo com a decomposição do recurso). Uma vez que as histórias de negócios são descritas e há um E2E visível ou uma parte sólida dele - o pontapé inicial para o Proprietário / Equipe da História Técnica é organizado. Histórias técnicas sob o recurso, cada um é de propriedade do líder de desenvolvimento (responsável pelo cenário específico, ou seja, funcionalidade de acordo com a decomposição do recurso) - a fim de simplificar a geração de relatórios, Equipe DEV espelhou o Recurso Técnico-> Histórias Técnicas, mantendo os links para o ID da História de Negócios (falando sobre JIRA). Uma vez que as histórias técnicas são implementadas e há um E2E visível ou uma parte sólida dele, é organizado o DEMO para o proprietário / equipe do Business Story. Não destaquei Epics, pois nesta abordagem o 'Feature' era um termo mais relevante. Resumindo: PRÓS: envolvimento pessoal e responsabilidade pessoal. CONTRAS: sobrecarga para ficar de olho nas tarefas técnicas de um "proprietário de empresa" não técnico.