Data Science and Agile (What Works, and What Doesn't)
Юджин Ян разбирает, какие практики Agile (по сути Scrum) хорошо работают в data science, а какие — плохо. Хорошо ложатся три ритуала: планирование и приоритизация в начале спринта (выравнивает команду данных с потребностями организации и даёт стейкхолдерам понимание «бюджета»), чёткое определение задач с результатами и сроками (помогает не уходить в бесконечные исследования), а также ретроспективы и демо в конце спринта (рост команды, обратная связь, повышение bus factor). Плохо вписываются: data science задачи хуже определены и сложнее оцениваются, объём и требования могут резко меняться, ожидание готового «кода» в каждом спринте как в инженерии, а также риск стать «слишком хорошим» в Scrum — когда команда гонится за story points и срочными задачами, упуская важные, но не срочные возможности для инноваций уровня 10x–100x. Автор приводит примеры: расследование падения NPS и улучшение ранжирующего алгоритма e-commerce с целью +5% к конверсии. Это первая из двух частей; во второй обещаны конкретные фреймворки и корректировки процесса (статья от января 2019).
Data Science and Agile (What Works, and What Doesn't)
Data Science и Agile (что работает, а что — нет)
[ agile datascience productivity 🔥 ] · чтение на 13 мин
Since I last posted on moderating a panel on Data Science and Agile, some have reached out for my views on this. This topic is also discussed among the data science community, with questions on how agile can be incorporated into a data science team, and how to get the gains in productivity.
С тех пор как я в последний раз писал о том, что модерировал панель на тему Data Science и Agile, некоторые обращались ко мне за моими взглядами на это. Эта тема также обсуждается в сообществе data science, с вопросами о том, как внедрить agile в команду data science и как получить прирост производительности.
Can agile work well with data science? (Hint: If it can’t, this post, and the next, won’t exist.)
Может ли agile хорошо работать с data science? (Подсказка: если бы не мог, этого поста и следующего просто не существовало бы.)
Follow-up: Data Science and Agile (Frameworks for effectiveness)
Продолжение: Data Science и Agile (фреймворки для эффективности)
Follow-up: What I Love about Scrum for Data Science
Продолжение: За что я люблю Scrum в data science
In this post, we’ll discuss on the strengths and weaknesses of Agile in the context of Data Science. At risk of irritating agile practitioners, I may refer to Agile and Scrum interchangeably. Nonetheless, do note that Scrum is an agile process framework, and there are others such as Kanban, etc. In the next post, I’ll share some agile adjustments and practices that have proven to be useful—at least in the teams I’ve led. Stay tuned!
В этом посте мы обсудим сильные и слабые стороны Agile в контексте Data Science. Рискуя вызвать раздражение у практиков agile, я могу называть Agile и Scrum взаимозаменяемо. Тем не менее учтите, что Scrum — это один из agile-фреймворков процесса, и существуют другие, например Kanban и т. д. В следующем посте я поделюсь некоторыми agile-корректировками и практиками, которые доказали свою полезность — по крайней мере, в командах, которыми я руководил. Оставайтесь на связи!
Data science is part software engineering, part research and innovation, and fully about using data to create impact and value. Aspects of data science that work well with agile tend to be more of the engineering nature, while those closer related to research tends not to fit as well.
Data science — это отчасти разработка ПО, отчасти исследования и инновации и полностью про использование данных для создания эффекта и ценности. Те аспекты data science, которые хорошо работают с agile, обычно ближе к инженерной природе, тогда как те, что ближе к исследованиям, вписываются хуже.
What aspects of agile work well with data science?
Какие аспекты agile хорошо работают с data science?
TL; DR:
TL; DR:
Планирование и приоритизация в начале каждого спринта. Чёткое определение задач с результатами и сроками. Ретроспективы и демо в конце каждого спринта.
Planning and Prioritisation at the start of each Sprint
Планирование и приоритизация в начале каждого спринта
In most of my past teams, sprints are usually one or two weeks long, and we’ve found this to be a good length. Each sprint starts with a planning and prioritisation meeting which helps to align the data team with the needs of the organization.
В большинстве моих прошлых команд спринты обычно длятся одну или две недели, и мы выяснили, что это хорошая продолжительность. Каждый спринт начинается со встречи по планированию и приоритизации, которая помогает выровнять команду данных с потребностями организации.
Planning and prioritisation begins with engagement with stakeholders. Scrum provides for explicit prioritisation with stakeholders and provides the framework to have a good overview of the tasks planned (and delivered), as well as their associated complexity and effort needed. With Scrum, stakeholders have a view on their “budget” for each sprint, providing them with better context to decide on trade-offs in scope and participate in sprint planning.
Планирование и приоритизация начинаются с взаимодействия со стейкхолдерами. Scrum обеспечивает явную приоритизацию вместе со стейкхолдерами и даёт фреймворк, чтобы иметь хороший обзор запланированных (и выполненных) задач, а также связанной с ними сложности и необходимых усилий. Со Scrum у стейкхолдеров есть представление об их «бюджете» на каждый спринт, что даёт им лучший контекст для принятия решений о компромиссах в объёме работ и участия в планировании спринта.
Having regular planning and prioritisation meetings provide (internal and external) stakeholders a better understanding of the costs associated with each data science effort, and the overhead associated with frequently changing priorities and context switching. This ensures alignment between the data team and its stakeholders, with stakeholders being conscientious about their data effort budget, and the data team being aware of organizational needs and how they can effectively contribute.
Регулярные встречи по планированию и приоритизации дают (внутренним и внешним) стейкхолдерам лучшее понимание издержек, связанных с каждой data science инициативой, и накладных расходов, связанных с частой сменой приоритетов и переключением контекста. Это обеспечивает выравнивание между командой данных и её стейкхолдерами, при котором стейкхолдеры осознанно относятся к своему бюджету на работу с данными, а команда данных понимает потребности организации и то, как она может эффективно вносить вклад.
Such planning and prioritisation helps the data team to practice one of the seven habits of highly effective people—“First things first”.
Такое планирование и приоритизация помогают команде данных практиковать один из семи навыков высокоэффективных людей — «Сначала главное».
Clearly defining tasks with deliverables and timelines
Чёткое определение задач с результатами и сроками
One common issue faced by data science projects is a lack of focus, or getting derailed by investigations that go down the rabbit hole. This is partially due to the innate curiosity drives most data scientists, and partially due to the ill-defined nature of data science problems.
Одна из распространённых проблем data science проектов — недостаток фокуса или сход с пути из-за исследований, уходящих в кроличью нору. Отчасти это связано с врождённым любопытством, движущим большинством data scientist'ов, а отчасти — с нечёткой природой задач data science.
Defining tasks beforehand with clear timelines help to mitigate this issue. Having a clear, expected deliverable for each task aligns with one of the seven habits of highly effective people—“Begin with the end in mind”.
Заблаговременное определение задач с чёткими сроками помогает смягчить эту проблему. Наличие ясного, ожидаемого результата для каждой задачи соответствует одному из семи навыков высокоэффективных людей — «Начинай, представляя конечную цель».
When approached with a new request, it helps to have the data science lead, or someone with more experience, to help define the tasks and deliverables. For example, if trying to understand why net promoter score (NPS, a measure of customer experience) went down, the expected deliverables could include analysis on various aspects of customer experience, such as:
При поступлении нового запроса полезно, чтобы лид data science или кто-то более опытный помог определить задачи и результаты. Например, если мы пытаемся понять, почему упал net promoter score (NPS, мера клиентского опыта), ожидаемые результаты могут включать анализ различных аспектов клиентского опыта, таких как:
Доставка (например, своевременность, состояние посылки при получении). Продукт (например, рейтинги товаров, отзывы, цена). Клиентский сервис (например, время ожидания, число точек контакта, оценки клиентского сервиса). Метрики приложения (например, спамные уведомления, медленная загрузка, запутанный UI).
This would help narrow down the causes for the drop in NPS. Next, we can assess the impact of lower NPS on the business. Do customers with lower NPS spend less (i.e., cart size, purchase frequency, absolute spend)? Are they less active on the app or have they turned off notifications? Are they at risk of attrition?
Это помогло бы сузить причины падения NPS. Далее мы можем оценить влияние более низкого NPS на бизнес. Тратят ли меньше клиенты с более низким NPS (т. е. размер корзины, частота покупок, абсолютные траты)? Менее ли они активны в приложении или отключили уведомления? Есть ли риск их оттока?
Defining these questions and hypotheses upfront provide milestones for data scientists as they conduct their analysis. In addition, sharing these tasks with the stakeholders can elicit useful information and feedback based on their expertise.
Определение этих вопросов и гипотез заранее задаёт вехи для data scientist'ов по ходу их анализа. Кроме того, обсуждение этих задач со стейкхолдерами может дать полезную информацию и обратную связь, опирающуюся на их экспертизу.
The process is similar for building data products, where most projects have a similar flow:
Процесс схож при создании продуктов на данных, где у большинства проектов похожий поток:
Извлечение данных: минимальный набор денормализованных данных по всем источникам данных организации. Подготовка данных: единообразное форматирование, приведение строк к нижнему регистру, заполнение пропусков, обработка выбросов и редко встречающихся значений. Feature engineering: label/one-hot кодирование, нормализация/масштабирование непрерывных переменных, различная дополнительная инженерия признаков. Валидация: настройка фреймворка для валидации (т. е. случайная выборка, выборка по времени); определение правильных метрик машинного обучения и AB-тестирования. Машинное обучение: быстрая оценка нескольких моделей, выбор наиболее подходящих техник, тюнинг параметров, дополнительный feature engineering, ансамблирование. MVP и демонстрация результатов стейкхолдерам: ожидаемые улучшения текущих метрик, ожидаемые усилия и стоимость вывода в продакшен, дорожные карты. AB-тестирование: разделение трафика и выборка; учёт размера выборки и мощности, сбор результатов AB-тестирования и данных.
The above examples only list some of the tasks required at a very high level. A natural question from stakeholders will be—“how long will it take?”. Data scientists with a few years of experience can usually give a fairly accurate estimate of the effort required. Nonetheless, this may vary based on the environment (e.g, infra, security, bureaucracy), data quality, and skills of the data scientist(s).
Приведённые выше примеры перечисляют лишь некоторые из требуемых задач на очень высоком уровне. Естественный вопрос от стейкхолдеров будет таким: «сколько времени это займёт?». Data scientist'ы с несколькими годами опыта обычно могут дать достаточно точную оценку необходимых усилий. Тем не менее это может варьироваться в зависимости от среды (например, инфраструктура, безопасность, бюрократия), качества данных и навыков data scientist'а(ов).
Take for example, the development of a data product—should it take two years? If it’ll improve organizational outcomes by 10x, perhaps. If the improvement is 10%, maybe not, though it depends. Thus, setting clear timelines before the start of the project, based on the estimated value of the project, helps set the right context for the data science team. Depending on the timeline, whether it’s 6 weeks or 6 months to build an MVP, the data science team can allocate effort to each of the steps appropriately.
Возьмём, к примеру, разработку продукта на данных — должна ли она занять два года? Если она улучшит результаты организации в 10 раз, то, возможно. Если улучшение составляет 10%, то, может, и нет, хотя это зависит от обстоятельств. Поэтому установка чётких сроков до начала проекта, исходя из оценочной ценности проекта, помогает задать правильный контекст для команды data science. В зависимости от срока — будь то 6 недель или 6 месяцев на создание MVP — команда data science может распределить усилия по каждому из шагов соответствующим образом.
Retrospectives and Demos at the end of each sprint
Ретроспективы и демо в конце каждого спринта
Two rituals I especially enjoy are the retrospectives and demo sessions at the end of each sprint. Their aim is to help the team learn from each other, celebrate our achievements, and get feedback on how to do better for the next sprint. Considering that each takes about 30 - 60 minutes yet contribute so much to team growth, satisfaction, and well-being, they have very high return on investment (of time).
Два ритуала, которые мне особенно нравятся, — это ретроспективы и демо-сессии в конце каждого спринта. Их цель — помочь команде учиться друг у друга, отпраздновать наши достижения и получить обратную связь о том, как сделать лучше в следующем спринте. Учитывая, что каждый занимает около 30–60 минут, но при этом так сильно способствует росту команды, удовлетворённости и благополучию, они имеют очень высокую отдачу от инвестиций (времени).
At each retrospective, the team reflects on the past week’s sprint. There are many ways on how this can be done, but here’s an approach I’ve found to work. Everyone fills up the whiteboard with points on what they found:
На каждой ретроспективе команда осмысляет спринт прошедшей недели. Есть много способов это делать, но вот подход, который, как я обнаружил, работает. Каждый заполняет доску пунктами о том, что он обнаружил:
Приятное: какие аспекты спринта и задач им понравились? Какие достижения нам стоит отпраздновать? Раздражающее: какие аспекты работы были раздражающими? Были ли эти трудности скорее технической природы? Или бизнесовой? Или политической? Что мы можем сделать, чтобы стало лучше? Какие уроки из этого извлекли? Озадачивающее: что озадачило вас в течение недели? Сталкивался ли кто-то ещё в команде с этим раньше? Есть ли какие-нибудь идеи о следующих шагах?
If the retrospective is done weekly, it helps the team to grow and gain from each sprint. Given a 5% improvement from each weekly retrospective, after a year, the team will be 1.05 ^ 52 = 12x better!
Если ретроспектива проводится еженедельно, она помогает команде расти и извлекать пользу из каждого спринта. При улучшении на 5% от каждой еженедельной ретроспективы, через год команда станет в 1,05 ^ 52 = 12 раз лучше!
For the demo session, the team gets together to share significant milestones completed in the past sprint(s). It is not necessary for everyone to demo every week—usually, demos are done after a significant chunk of work, or a specific milestone, which can take anywhere between 2 - 8 weeks.
На демо-сессии команда собирается, чтобы поделиться значимыми вехами, завершёнными за прошедший(ие) спринт(ы). Необязательно, чтобы каждый делал демо каждую неделю — обычно демо проводят после значимого куска работы или конкретной вехи, что может занимать от 2 до 8 недель.
At the demo, the team can learn from each others’ experiences, as well as provide feedback. This greatly helps with team development, where a bunch of great people continuously develop and grow through learning and feedback from the people around them. This also helps to increase the bus factor, and helps more junior members of the team to level up on the more advanced methods, or gain context on the organization and data.
На демо команда может учиться на опыте друг друга, а также давать обратную связь. Это сильно помогает развитию команды, когда группа отличных людей непрерывно развивается и растёт благодаря обучению и обратной связи от окружающих. Это также помогает повысить bus factor и помогает более младшим членам команды подтянуться по более продвинутым методам или получить контекст об организации и данных.
In addition, demos promotes accountability within the data science team, where people strive to demo something periodically. Inviting the larger organization to the demo also promotes better understanding of data science efforts and ideas on how the data team can help with the organization’s goals.
Кроме того, демо способствуют ответственности внутри команды data science, где люди стремятся периодически что-то демонстрировать. Приглашение более широкой организации на демо также способствует лучшему пониманию усилий data science и идей о том, как команда данных может помочь в достижении целей организации.
What aspects of Agile make it hard to apply in Data Science
Какие аспекты Agile затрудняют его применение в Data Science
TL; DR:
TL; DR:
Усилия в Data Science хуже определены и потому их сложнее оценивать. Объём и требования могут меняться очень быстро. Ожидания, что спринты Data Science должны иметь результаты, как инженерные спринты. Быть слишком хорошим/дисциплинированным в Scrum.
Data Science efforts are more ill-defined and thus more difficult to estimate
Усилия в Data Science хуже определены и потому их сложнее оценивать
Data science problems are ill-defined relative to engineering problems—this makes estimation harder. For example, when a problem is provided, it is not always straightforward which data should be used. Once the dataset is decided upon, how much effort is needed in data exploration, cleaning and preparation, feature engineering, assessing multiple models, and then achieving the target metric? While the process can be properly defined, the amount of effort for each task may vary greatly across projects.
Задачи data science хуже определены по сравнению с инженерными задачами — это усложняет оценку. Например, когда поступает задача, не всегда очевидно, какие данные следует использовать. После того как датасет выбран, сколько усилий нужно на исследование данных, их очистку и подготовку, feature engineering, оценку нескольких моделей и затем достижение целевой метрики? Хотя процесс можно как следует определить, объём усилий на каждую задачу может сильно варьироваться от проекта к проекту.
Let’s assume you’re given the task of increasing conversion on an e-commerce website by improving its ranking algorithm, with a target of at least 5% increase (any less and it maybe difficult to detect through AB testing). This is a relatively large project to scope, with many uncertainties.
Предположим, вам дали задачу повысить конверсию на e-commerce сайте за счёт улучшения его алгоритма ранжирования, с целью прироста как минимум на 5% (при меньшем значении это, возможно, трудно будет обнаружить через AB-тестирование). Это относительно крупный проект для оценки объёма, со множеством неопределённостей.
Будут ли данные чистыми и соответствующими нашим предположениям, или в данных будут странные артефакты? Если в данных есть проблемы, почему? Трекер работает некорректно? Или это из-за необычного поведения пользователей? Как это влияет на анализ и на разрабатываемую систему? Как следует моделировать эту задачу? Должна ли это быть задача learning to rank, где товары ранжируются по каждой категории и поисковому запросу? Или это задача классификации на основе клика, или добавления в корзину, или оформления заказа? Или, может быть, это задача регрессии на основе кликов, добавлений в корзину, оформлений заказа или выручки? Какой должна быть метрика успеха? Клики? Покупки? Выручка? Должно ли это быть абсолютное значение (т. е. общее число покупок) или ставка (т. е. коэффициент конверсии)?
Based on the simple example above, the intent and desired outcomes are clear. However, there are multiple paths to arriving at the destination.
На основе простого примера выше, намерение и желаемые результаты ясны. Однако существует множество путей к достижению этой цели.
The search space is large and there are many things to try, which leads to difficulty in estimating the number of experiments needed and the effort of each experiment.
Пространство поиска велико, и есть много вещей, которые можно попробовать, что приводит к трудности в оценке числа необходимых экспериментов и усилий на каждый эксперимент.
Scope and requirements may change very quickly
Объём и требования могут меняться очень быстро
Due to the nature of the business, the scope and/or requirements from stakeholders may change rapidly. As the data is being explored for answers, the required analyses and solution may change as the work is being done. For example, stakeholders may have firm convictions on the cause of a problem and the required solution, but the data may suggest something else instead. As a result, the planned scope of work and tasks will have to pivot accordingly. This can be disruptive to the sprint if done too often.
В силу природы бизнеса объём и/или требования стейкхолдеров могут быстро меняться. По мере того как данные исследуются в поисках ответов, требуемые анализы и решение могут меняться прямо по ходу работы. Например, у стейкхолдеров могут быть твёрдые убеждения о причине проблемы и нужном решении, но данные могут указывать на нечто иное. В результате запланированный объём работ и задачи придётся развернуть соответствующим образом. Это может нарушать ход спринта, если делается слишком часто.
Relative to software engineering, data science as a discipline is relatively younger and less mature. (Yes, some may argue that data science is just statistics—which is mature—with a sexier packaging. Perhaps this is better addressed via another essay). Software engineering is a fairly mature discipline with relatively well-defined problems and design patterns, and thus tasks that are easier to scope. Data science is younger, with problems that are harder to define, and solutions that are not as straightforward. This difference makes breaking down projects into small, well-defined tasks, more difficult.
По сравнению с разработкой ПО, data science как дисциплина относительно моложе и менее зрелая. (Да, кто-то может возразить, что data science — это просто статистика, которая зрела, в более привлекательной обёртке. Возможно, это лучше разобрать в другом эссе.) Разработка ПО — довольно зрелая дисциплина с относительно хорошо определёнными задачами и паттернами проектирования, а потому с задачами, которые легче оценивать по объёму. Data science моложе, с задачами, которые сложнее определить, и решениями, которые не так очевидны. Это различие делает разбиение проектов на маленькие, хорошо определённые задачи более трудным.
Expectations that Data Science sprints should have deliverables like engineering sprints
Ожидания, что спринты Data Science должны иметь результаты, как инженерные спринты
Many people familiar with agile or scrum—likely from an engineering context—expect working code at the end of each sprint. When first applying scrum to data science, most project managers try to have a well defined outcome or deliverable. In the context of engineering, this might be setting up some infra, implementing a new feature, or developing a new front-end. In these cases, there is clearly a tangible result that they can “hold in their hands” (sort of) and report upwards, such as through demonstration of the new feature or front-end.
Многие люди, знакомые с agile или scrum — скорее всего, из инженерного контекста — ожидают рабочий код в конце каждого спринта. При первом применении scrum к data science большинство project-менеджеров пытаются иметь чётко определённый итог или результат. В контексте инженерии это может быть настройка какой-то инфраструктуры, реализация новой фичи или разработка нового фронтенда. В этих случаях явно есть осязаемый результат, который можно «подержать в руках» (вроде как) и отчитаться наверх, например через демонстрацию новой фичи или фронтенда.
However, in the case of data science, this gets a bit tricky. Sometimes, data science work involves analysis where someone expects an answer, or a machine learning model which contributes to measurable improvement in certain metrics. Such acceptance criteria are hard to define while scoping tasks and assigning PM tickets. Furthermore, given that data science is partly research, timeline-loving PMs may find the lack of clear deadlines disorientating. This leads to frustrated PMs where their expected outcomes are not met, and unduly stressed out data scientists who don’t have the time and space to innovate and find optimal solutions.
Однако в случае data science это становится немного хитрее. Иногда работа data science включает анализ, где кто-то ожидает ответа, или модель машинного обучения, которая вносит вклад в измеримое улучшение определённых метрик. Такие критерии приёмки трудно определить при оценке объёма задач и назначении PM-тикетов. Более того, учитывая, что data science отчасти исследование, любящие сроки PM могут находить отсутствие чётких дедлайнов дезориентирующим. Это приводит к расстроенным PM, чьи ожидаемые результаты не достигнуты, и к чрезмерно напряжённым data scientist'ам, у которых нет времени и пространства, чтобы творить и находить оптимальные решения.
Being too good/disciplined at Scrum
Быть слишком хорошим/дисциплинированным в Scrum
Is being too good at something ever a problem? Perhaps. Sometimes, when teams become very aligned with the business, and are very disciplined with meeting scrum-specific deadlines, a different kind of problem may occur.
Бывает ли когда-нибудь проблемой то, что ты слишком хорош в чём-то? Пожалуй, да. Иногда, когда команды становятся очень выровненными с бизнесом и очень дисциплинированными в соблюдении scrum-специфичных дедлайнов, может возникнуть проблема иного рода.
Business stakeholders understand best which projects can immediately make an impact on users and business outcomes. On the flip side, they are usually very focused on the day-to-day, and usually more on near term goals. Having priorities set solely by the business may lead to risks of being overly focused on the short-term, and missing out on opportunities for innovation that may lead to 10x or 100x improvements.
Бизнес-стейкхолдеры лучше всего понимают, какие проекты могут немедленно оказать влияние на пользователей и бизнес-результаты. С другой стороны, они обычно очень сосредоточены на повседневном и, как правило, больше на краткосрочных целях. Установка приоритетов исключительно бизнесом может привести к рискам чрезмерной сосредоточенности на краткосрочном и упущению возможностей для инноваций, которые могут привести к улучшениям в 10 или 100 раз.
Coupled with a data science team that is used to scrum and deadlines, this may lead to the (happy) problem of being overly focused on finishing their tasks before the sprint ends and accomplishing their story points. This appears to be productive (“Look at all the story points we completed! What a beautiful burn-down chart”) but may be deceptively ineffective—the urgent (and sometimes less important) is prioritised and executed efficiently over the important but not urgent.
В сочетании с командой data science, привыкшей к scrum и дедлайнам, это может привести к (приятной) проблеме чрезмерной сосредоточенности на завершении задач до конца спринта и выполнении своих story points. Это выглядит продуктивным («Посмотрите, сколько story points мы выполнили! Какая красивая burn-down диаграмма»), но может быть обманчиво неэффективным — срочное (и иногда менее важное) приоритизируется и выполняется эффективно в ущерб важному, но не срочному.
The data science team has strengths in “listening to the data” and research. Applying innovation to improve organisational outcomes should be part of their mandate.
Сильные стороны команды data science — в «прислушивании к данным» и исследованиях. Применение инноваций для улучшения результатов организации должно быть частью их мандата.
So can Data Science be Agile or not?
Так может ли Data Science быть Agile или нет?
“This post seems conflicting—first you tell me agile works well with data science, then you raise all the problems with it.”
«Этот пост кажется противоречивым — сначала ты говоришь мне, что agile хорошо работает с data science, а затем поднимаешь все проблемы с ним.»
Hopefully, after laying out some of the pros and cons, you’ll have a better idea of how to apply agile to data science, and the potential pitfalls. Despite some of the challenges, I believe agile and data science go well with each other—else I wouldn’t have adopted it in my past teams.
Надеюсь, изложив некоторые плюсы и минусы, вы получите лучшее представление о том, как применять agile к data science, и о потенциальных подводных камнях. Несмотря на некоторые трудности, я считаю, что agile и data science хорошо сочетаются друг с другом — иначе я не внедрял бы его в своих прошлых командах.
To address some of the issues raised, some simple adjustments can be made to the process and mindset—I’ll share about these in the next post. Stay tuned!
Чтобы разобраться с некоторыми из поднятых проблем, можно внести несколько простых корректировок в процесс и образ мышления — о них я расскажу в следующем посте. Оставайтесь на связи!
Update: This is the first post in a 2-part sharing on Data Science and Agile. In the next post, we discuss about some frameworks for effectively applying Agile to Data Science. You can find the next post here.
Обновление: это первый пост из двухчастного материала про Data Science и Agile. В следующем посте мы обсудим некоторые фреймворки для эффективного применения Agile к Data Science. Следующий пост вы можете найти здесь.
If you found this useful, please cite this write-up as:
Если вы нашли это полезным, пожалуйста, цитируйте эту статью как:
Yan, Ziyou. (Jan 2019). Data Science and Agile (What Works, and What Doesn't). eugeneyan.com. https://eugeneyan.com/writing/data-science-and-agile-what-works-and-what-doesnt/.
Yan, Ziyou. (Jan 2019). Data Science and Agile (What Works, and What Doesn't). eugeneyan.com. https://eugeneyan.com/writing/data-science-and-agile-what-works-and-what-doesnt/.
or
или
@article{yan2019agile2,
title = {Data Science and Agile (What Works, and What Doesn't)},
author = {Yan, Ziyou},
journal = {eugeneyan.com},
year = {2019},
month = {Jan},
url = {https://eugeneyan.com/writing/data-science-and-agile-what-works-and-what-doesnt/}
}
@article{yan2019agile2, title = {Data Science and Agile (What Works, and What Doesn't)}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2019}, month = {Jan}, url = {https://eugeneyan.com/writing/data-science-and-agile-what-works-and-what-doesnt/} }
Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.
Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.