Scrum

Scrum Não Faz O Menor Sentido Para Cientistas De Dados

Eu sei, o título é polêmico, porém acredito que seja necessário para fomentar a discussão, além também de resumir bem a ideia central deste artigo. Que é justamente esta, Scrum não faz o menor sentido para cientistas de dados e você não deveria obrigá-los a usá-la.

“O Scrum é uma estrutura leve que ajuda pessoas, equipes e organizações a gerar valor por meio de soluções adaptáveis ​​para problemas complexos.”

Scrum é ruim ?

É uma boa pergunta, em minha opinião, baseada na minha experiência, acredito que não seja uma metodologia ágil ruim, mas também não acredito que seja perfeita, e a bala de prata para todos os problemas de organização e gestão em TI, como a sua comunidade a vende. Tenho também minhas ressalvas sobre sua eficiência em grandes projetos aonde algumas cerimônias acabam mais atrapalhando do que ajudando.

"Depois que o Manifesto se tornou popular, a palavra ágil se tornou um ímã para qualquer pessoa com pontos para defender, horas para faturar ou produtos para vender."

Abaixo vamos discutir sobre estas cerimônias e também sobre algumas coisas que simplesmente não fazem sentido para um projeto na área de dados.

Scrum foca em entregas incrementais, Sprints

O conceito de uma Sprint, aonde a cada pré-determinado intervalo de tempo (normalmente 2-4 semanas) uma entrega incremental (parcial) é realizada, não faz sentido para projetos de ciência de dados, devido justamente a natureza científica, e altamente especulativa de seu trabalho. Isso, no final do dia, só vai ser contra produtivo, aonde o time ira se sentir “forçado” a entregar algo que geralmente muda quase que completamente no decorrer das próximas Sprints ou é simplesmente descartado.

A entrega de um projeto de ciência de dados normalmente consiste em um ou vários modelos de ML, ou simplesmente um relatório (analise exploratória).

Raramente existem recursos intermediários que podem se sustentar por conta própria. O seu trabalho tem um valor e um fluxo que representam um padrão exponencial, e não linear. Para os Stakeholders (partes interessadas)  pode parecer que o projeto simplesmente não alcançou nada no decorrer da Sprint.

Forçar que um cientista de dados trabalhe dentro de um intervalo de tempo pré-determinado é uma péssima ideia. Não se pode simplesmente definir quais serão as tarefas que iram ser realizas a seguir e que será feita no decorar de duas semanas (uma Sprint). Simplesmente não funciona assim. A ciência de dados é um trabalho experimental que pode levar muito tempo para produzir qualquer resultado. Se produzir.

"Não importa quão grande seja o talento ou os esforços, algumas coisas levam tempo. Você não pode produzir um bebê em um mês engravidando nove mulheres."

Task, task, tasks....

Scrum tenta dividir tudo em pequenas tarefas (Tasks). Novamente, isso não se encaixa com a natureza do trabalho. A ciência de dados é um processo de constante experimentação e iteração.

Outra coisa super importante também é que tarefas que demandam muito tempo nem sempre são trabalhosas. No desenvolvimento tradicional de software, se uma tarefa precisa de 4 dias para ser concluída, na maioria das vezes, ela ocupará um desenvolvedor por 4 dias (ou 2 desenvolvedores por 2 dias, etc.).

Isso torna a velocidade de conclusão fácil de prever e o fluxo de desenvolvimento fácil de gerenciar. Porem, no entanto, nem sempre é o caso na ciência de dados. Por exemplo, se um cientista de dados precisar treinar um modelo que está desenvolvendo, o treinamento pode levar 4 dias (devido à quantidade de dados), mas o cientista de dados não estará ocupado com isso o tempo todo, ele apenas fara um monitoramento periódico para confirmar que o processo esta sendo executado corretamente.

Parabéns, você acabou de desperdiçar um cientista de dados por 4 dias, pois “não se pode atuar em duas tarefas simultaneamente”.

Os cientistas de dados nem sempre precisam de um PO

“O Product Owner representa as necessidades dos Stakeholders no Product Backlog. O Product Owner representa as partes interessadas para o time Scrum, o que inclui a representação de seus requisitos desejados no Product Backlog.”

Segundo o Scrum, é responsabilidade do PO (Product Owner, “dono do produto”) realizar a “tradução” dos complexos problemas dos stakeholders em uma lista de tarefas. Legal, mas, isso também não funciona para cientistas de dados.

Confiar em um PO para isso no lugar do cientista de dados é uma péssima ideia. Obter o contexto do problema com o PO simplesmente não é suficiente, nem é motivador, além de ser desnecessário. É mais eficaz para os cientistas de dados interagir diretamente com o cliente, entender o contexto do problema com o ele, mergulhar em discussões e após traçar um plano por conta própria.

Grande parte do trabalho que os cientistas de dados fazem é experimental (pesquisa) e não desenvolvimento de produtos ou funcionalidades. Dado o problema e seu contexto, ele desenha o próprio roteiro de como será realizado o projeto, analiticamente.

Como as tarefas necessárias ainda não estão claras para ninguém (PO e stakeholders), não faz sentido tirar essa responsabilidade do cientista de dados, cujo trabalho é exatamente esclarecê-las.

O que sempre acontece é que o cientista de dados frequentemente ira se tornar seu próprio PO, “dono” de seus projetos.

A definição de "Feito" ou "Pronto" é muito relativa

"Os Desenvolvedores devem estar em conformidade com a Definição de "Pronto". Se houver vários Times Scrum trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de Pronto. Compreender e aplicar o Scrum Framework permite que equipes e organizações entreguem de forma iterativa e incremental produtos valiosos de software liberável “Pronto” em 30 dias ou menos."

Projetos da área de dados são intrinsecamente diferentes entre si, é impossível usar a mesma definição de “pronto” para todos os projetos. Principalmente quando trabalhando em conjunto com um time de desenvolvimento de software tradicional.

Por exemplo, “pronto” para um projeto pode significar, que uma análise exploratória preliminar foi realizada, aonde nesta foi atestado que não é viável seguir com o projeto. Porem o time de desenvolvimento já tem a próxima Sprint planejada aonde eles iriam implementar uma funcionalidade X no produto que seria extraída a partir do projeto que estava sendo conduzido pelo time de dados. E agora?!  

Oque fazer então?

Ok, entendemos que Scrum não tem o melhor “fit” para projetos de Data Science, mas também não estou defendendo que os times de dados deveriam seguir a metodologia eXtreme Go Horse. Porem eles com certeza deveriam possuir mais liberdade para fluir horizontal e verticalmente dentro da empresa.

A área de dados é muito peculiar no mundo da tecnologia, pois, ao mesmo tempo que é uma área super técnica, mão na massa, é extremamente cientifica e experimental, também é a que mais esta próxima do “negócio”, é muito comum ver um cientista de dados, fluindo entre reuniões com time de desenvolvimento e com o time de diretoria da empresa, para falar do mesmo assunto, porem com um vocabulário e posicionamento totalmente diferente em cada reunião.

Por este motivo acredito que deveríamos tratar cientistas de dados mais como parceiros do negócio, do que um simples “Dev que mexe com dados”.

Mas por favor, me diga sua opinião abaixo!!!

O que acha de Scrum aplicado a ciência de dados? Já teve alguma experiência, como foi?

5 3 Votos
Relevância do artigo
Se inscrever
Notificar de
3 Comentários
Mais votados
Mais recentes Mais velhos
Inline Feedbacks
Ver todos
Rolar para cima