Data Science and Agile (Frameworks for Effectiveness)

Начните здесь Статьи Выступления Прототипирование О себе

Data Science and Agile (Frameworks for Effectiveness)

Data Science и Agile (фреймворки для эффективности)

[ mechanism agile datascience productivity ] · 14 min read

[ mechanism agile datascience productivity ] · чтение на 14 мин

This is the second post in a 2-part sharing on Data Science and Agile. In the last post, we discussed about the aspects of Agile that work, and don’t work, in the data science process. You can find the previous post here.

Это второй пост в материале из двух частей про Data Science и Agile. В прошлом посте мы обсудили те аспекты Agile, которые работают и не работают в процессе data science. Предыдущий пост можно найти здесь.

Follow-up: What I Love about Scrum for Data Science

Продолжение: За что я люблю Scrum в data science

A quick recap of what works well

Краткое напоминание о том, что работает хорошо

Periodic planning and prioritization: This ensures that sprints and tasks are aligned with organisational needs, allows stakeholders to contribute their perspectives and expertise, and enable quick iterations and feedback

Периодическое планирование и приоритизация: это гарантирует, что спринты и задачи соответствуют потребностям организации, позволяет стейкхолдерам вносить свои взгляды и экспертизу, а также обеспечивает быстрые итерации и обратную связь

Clearly defined tasks with timelines: This helps keep the data science team productive and on track, and being able to deliver on the given timelines — the market moves fast and doesn’t wait.

Чётко определённые задачи со сроками: это помогает команде data science оставаться продуктивной и идти по плану, а также укладываться в заданные сроки — рынок движется быстро и не ждёт.

Retrospectives and demos: Retrospectives help the team to improve with each sprint, and provide feedback and insight into pain points that should be improved on. Demos help the team to learn and get feedback from one another. If stakeholders are involved, demos also provide a view into what the data science team is working on.

Ретроспективы и демо: ретроспективы помогают команде улучшаться с каждым спринтом и дают обратную связь и понимание болевых точек, которые стоит исправить. Демо помогают команде учиться и получать обратную связь друг от друга. Если в них участвуют стейкхолдеры, демо также дают представление о том, над чем работает команда data science.

What about aspects that don’t work well?

А что насчёт аспектов, которые работают не очень?

Difficulty with estimations: Data science problems tend to be more ill-defined, with a larger search space for solutions. Thus, estimations tend to be tricker with a larger variance in error. One way around this is to have budgets for story-points / man days, and to time-box the experiments.

Сложность с оценками: задачи data science, как правило, хуже определены, с более широким пространством поиска решений. Поэтому оценки оказываются более рискованными, с большей дисперсией ошибки. Один из способов обойти это — выделять бюджеты на story-points / человеко-дни и ограничивать эксперименты по времени (таймбоксинг).

Rapidly changing scope and requirements: The rapidly evolving business environment may bring with it constantly changing organizational priorities. To mitigate this, have periodic prioritisations with stakeholders to ensure alignment. This also helps stakeholders better understand the overhead cost of frequent context switching.

Быстро меняющийся объём и требования: стремительно развивающаяся бизнес-среда может приносить с собой постоянно меняющиеся приоритеты организации. Чтобы смягчить это, проводите периодические приоритизации со стейкхолдерами для обеспечения согласованности. Это также помогает стейкхолдерам лучше понимать накладные издержки частого переключения контекста.

Expectations for engineering-like deliverables after each sprint: Project managers and senior executives with an engineering background might expect working software with each sprint. This may require some engagement and education to bring about mindset change. While the outcome from each sprint may not be working code, they are also valuable (e.g., experimental results, research findings, learnings, next steps).

Ожидание инженерных результатов после каждого спринта: проектные менеджеры и топ-менеджеры с инженерным бэкграундом могут ожидать работающее ПО после каждого спринта. Чтобы изменить такое мышление, может потребоваться некоторое вовлечение и просвещение. Хотя результатом каждого спринта может быть не работающий код, он тоже ценен (например, результаты экспериментов, выводы исследований, полученные знания, следующие шаги).

Being too disciplined with timelines: A happy problem is being too efficient and aligned with business priorities. Nonetheless, a data science team should be working on innovation. To take a leaf out of Google’s book, a team can build in 20% innovation time. Innovation is essential for 10x improvements.

Излишняя дисциплина со сроками: приятная проблема — быть слишком эффективными и согласованными с приоритетами бизнеса. Тем не менее команда data science должна заниматься инновациями. Если взять пример с Google, команда может закладывать 20% времени на инновации. Инновации необходимы для улучшений в 10 раз.

How to adapt Agile for Data Science

Как адаптировать Agile под Data Science

In light of the points discussed above, how can we more effectively apply agile/scrum to data science?

В свете обсуждённых выше моментов, как мы можем эффективнее применять agile/scrum к data science?

Here, I’ll share some frameworks/processes/ideas that worked well for my teams and I — hopefully, they’ll be useful for you too. Namely, they are:

Здесь я поделюсь некоторыми фреймворками/процессами/идеями, которые хорошо сработали для меня и моих команд — надеюсь, они будут полезны и вам. А именно:

Time-boxed iterations

Starting with Planning and Prioritisation, Ending with Demo and Retrospective

Writing up projects before starting

Updated mindset to include innovation

Итерации с таймбоксами Начинать с планирования и приоритизации, заканчивать демо и ретроспективой Письменно оформлять проекты до старта Обновлённое мышление, включающее инновации

Time-boxed Iterations

Итерации с таймбоксами

One framework I find helpful is “time-boxed iterations”. The focus is on having various iteration phases within each project, and within each iteration, ideas and outcomes are validated to a satisfactory level before moving to the next iteration.

Один фреймворк, который я считаю полезным, — «итерации с таймбоксами» (time-boxed iterations). Фокус в том, чтобы внутри каждого проекта было несколько фаз-итераций, и внутри каждой итерации идеи и результаты валидируются до удовлетворительного уровня прежде, чем переходить к следующей итерации.

This ensures consistent feedback at each stage of the project, especially at the early stages where things are most uncertain. The worst thing that can happen is spending significant time and resources on a project and finding that it is not what stakeholders really needed (because most people can’t articulate what they really need). Or that it will not be adopted/used. In addition, having time-boxed iterations prevents R&D endeavours from becoming a blackhole.

Это обеспечивает постоянную обратную связь на каждой стадии проекта, особенно на ранних этапах, где наибольшая неопределённость. Худшее, что может случиться, — потратить значительное время и ресурсы на проект и обнаружить, что это не то, что на самом деле было нужно стейкхолдерам (потому что большинство людей не могут сформулировать, что им действительно нужно). Или что им не будут пользоваться. Кроме того, итерации с таймбоксами не дают R&D-начинаниям превратиться в чёрную дыру.

Let’s go through each of the four stages listed above.

Давайте пройдёмся по каждой из четырёх перечисленных выше стадий.

Feasibility Assessment

Оценка осуществимости (Feasibility Assessment)

This is where we engage with stakeholders early on to clarify the problem statement, intent, deliverables, and constraints. Once there is sufficient clarity on the context, the data science team can then begin to assess if the problem can be solved by existing data.

Это этап, где мы заранее взаимодействуем со стейкхолдерами, чтобы прояснить формулировку проблемы, намерение, результаты и ограничения. Как только появляется достаточная ясность по контексту, команда data science может начать оценивать, можно ли решить проблему с помощью существующих данных.

If it can be solved by the existing data, what level of performance can we expect? For example, if the problem is product classification, is the ballpark estimate at 50% precision, or 90%? These initial metrics make a big difference to the usability of the product — 50% would make it hard to use, though still significantly better than a random guess, considering thousands of categories.

Если её можно решить на существующих данных, какого уровня производительности можно ожидать? Например, если задача — классификация товаров, грубая оценка точности (precision) — 50% или 90%? Эти начальные метрики сильно влияют на пригодность продукта: 50% сделали бы его трудным в использовании, хотя это всё равно значительно лучше случайного угадывания, учитывая тысячи категорий.

The main question in this stage is: Given the existing data, are we able to get a reasonable level of performance? Should we expend more resources on it?

Главный вопрос на этой стадии: учитывая имеющиеся данные, можем ли мы получить разумный уровень производительности? Стоит ли тратить на это больше ресурсов?

Let’s assume the desired accuracy level is 95%. If the ballpark estimate is 90%, with some time and effort, we might be able to achieve 95% accuracy. However, if the ballpark estimate is 70% (and a 25% gap is pretty big in data science), perhaps we should move the project to the backlog and work on steps to improve performance. This could involve additional data collection, transfer learning, research, etc.

Допустим, желаемый уровень точности — 95%. Если грубая оценка — 90%, то с некоторым временем и усилиями мы, возможно, сможем достичь 95% точности. Однако если грубая оценка — 70% (а разрыв в 25% довольно велик в data science), то, пожалуй, стоит отправить проект в бэклог и поработать над шагами по улучшению производительности. Это может включать дополнительный сбор данных, transfer learning, исследования и т. д.

Usually, this step can be done fairly quickly, in about 2–4 weeks, assuming it is an in-house project and familiarity with the data.

Обычно этот шаг можно выполнить довольно быстро, примерно за 2–4 недели, при условии, что это внутренний проект и есть знакомство с данными.

Proof of Concept (POC)

If the initial performance from the feasibility assessment was satisfactory, we move on to developing a POC. This involves building a minimum viable product (MVP) to demonstrate technical feasibility. The aim is to have working code and machine learning model(s) to validate the initial idea and implementation.

Если начальная производительность по итогам оценки осуществимости оказалась удовлетворительной, мы переходим к разработке POC. Это предполагает создание минимально жизнеспособного продукта (MVP) для демонстрации технической осуществимости. Цель — иметь работающий код и модель(и) машинного обучения, чтобы валидировать первоначальную идею и реализацию.

Validation can be done either via local validation, or AB testing, and the results shared with stakeholders to gather feedback on the level of performance.

Валидация может проводиться либо через локальную валидацию, либо через AB-тестирование, а результаты — делиться со стейкхолдерами для сбора обратной связи по уровню производительности.

The main question here: Is this good enough to expend additional resources to into production? Does it meet the performance requirements (e.g., model performance, latency, etc.)?

Главный вопрос здесь: достаточно ли это хорошо, чтобы тратить дополнительные ресурсы на вывод в продакшен? Соответствует ли это требованиям к производительности (например, качество модели, задержка и т. д.)?

Depending on the POC outcomes, we’ll decide whether or not to (i) deploy to production and iterate, or (ii) refine the POC further (because we’re so close), or (iii) revisit the project another time because the gap between a usable product and the existing MVP is too wide.

В зависимости от результатов POC мы решим, стоит ли (i) развернуть в продакшен и итерировать, или (ii) дорабатывать POC дальше (потому что мы так близко), или (iii) вернуться к проекту в другой раз, потому что разрыв между пригодным продуктом и существующим MVP слишком велик.

With an experienced team, the POC could be wrapped-up in about 4–8 weeks, depending on the complexity of the project.

С опытной командой POC можно завершить примерно за 4–8 недель, в зависимости от сложности проекта.

Deploy to Production

Вывод в продакшен

If everything has been going well so far, great! Next, we get to put our solution into production where it can make real impact. This usually involves working with data engineering (which may help with scheduling, scaling, monitoring, etc.) and the core engineering team for integration into the platform.

Если до сих пор всё шло хорошо — отлично! Дальше мы выводим наше решение в продакшен, где оно может приносить реальную пользу. Обычно это предполагает работу с дата-инженерией (которая может помочь с планированием задач, масштабированием, мониторингом и т. д.) и с основной инженерной командой для интеграции в платформу.

Code should be refactored to optimise for maintainability, performance, scalability, and robustness. Invest time to develop automated test cases and documentation, so others can easily learn about and understand the project, as well as contribute features and maintenance effort.

Код следует отрефакторить, оптимизируя его для поддерживаемости, производительности, масштабируемости и устойчивости. Инвестируйте время в разработку автоматических тестов и документации, чтобы другие могли легко изучить и понять проект, а также вносить вклад в виде фич и сопровождения.

Deployment to production can take anywhere from 3–9 months, depending on several factors include infrastructure (e.g., on premise or cloud), technical performance requirements, security, etc.

Вывод в продакшен может занять от 3 до 9 месяцев, в зависимости от нескольких факторов, включая инфраструктуру (например, on-premise или облако), требования к технической производительности, безопасность и т. д.

Some laymen, eager for results, might ask: “Don’t we have a working POC already? Why not just deploy that into production? Why do we need to spend more time?” Production-quality code focuses on resilience, maintainability, extensibility, scalability, etc. These aspects can be costly.

Некоторые непосвящённые, жаждущие результатов, могут спросить: «Разве у нас уже нет работающего POC? Почему бы просто не развернуть его в продакшен? Зачем тратить ещё время?» Код продакшен-качества фокусируется на устойчивости, поддерживаемости, расширяемости, масштабируемости и т. д. Эти аспекты могут обходиться дорого.

A software engineer, with experience at Google, Microsoft, Amazon, and Oracle, shared on Quora that a research prototype took 2 man-months, while a production-quality version required 117 man-months. That’s approximately 60x more time!

Один инженер-программист с опытом работы в Google, Microsoft, Amazon и Oracle поделился на Quora, что исследовательский прототип занял 2 человеко-месяца, тогда как версия продакшен-качества потребовала 117 человеко-месяцев. Это примерно в 60 раз больше времени!

Operational Maintenance

Операционная поддержка

Lastly, after deploying into production, the data product will require some effort maintaining it, as well as new features/models requested.

Наконец, после развёртывания в продакшен, дата-продукт потребует некоторых усилий на сопровождение, а также на запрашиваемые новые фичи/модели.

The size of this effort depends on the complexity of the product, as well as the amount of tech debt (which can come with hasty deployments, poor design, etc.).

Размер этих усилий зависит от сложности продукта, а также от объёма технического долга (который может возникнуть из-за поспешных развёртываний, плохого дизайна и т. д.).

Overall, the entire process from business request to production could take between 6–12 months.

В целом весь процесс от бизнес-запроса до продакшена может занять от 6 до 12 месяцев.

The framework emphasises on frequent check-ins with organisational stakeholders, ensuring that the data product developed is aligned with the organizational needs and allow for stakeholder feedback. There are also two major checkpoints, (i) feasibility assessment and (ii) POC outcomes, where the critical “go-ahead” decision is needed before the escalation of commitment and resources. Taken together, this helps ensure alignment with the organization.

Фреймворк делает акцент на частых сверках со стейкхолдерами организации, гарантируя, что разрабатываемый дата-продукт соответствует потребностям организации, и позволяя получать обратную связь от стейкхолдеров. Есть также две главные контрольные точки — (i) оценка осуществимости и (ii) результаты POC, — где требуется критическое решение «идём дальше» прежде, чем эскалировать обязательства и ресурсы. Вместе взятое, это помогает обеспечить согласованность с организацией.

Starting with Planning and Prioritisation, Ending with Demo and Retrospective

Начинать с планирования и приоритизации, заканчивать демо и ретроспективой

There are rituals I find very useful (and enjoy) at the start and end of each sprint. These are likely already part of your existing agile practices, though I thought it would be good to emphasise them.

Есть ритуалы, которые я считаю очень полезными (и которыми наслаждаюсь) в начале и в конце каждого спринта. Они, скорее всего, уже являются частью вашей существующей agile-практики, но я подумал, что будет хорошо их подчеркнуть.

At the start of each sprint, it is important to go through planning and prioritisation.

В начале каждого спринта важно пройти через планирование и приоритизацию.

Planning involves the data science team organising their tasks and effort based on the organization needs and priorities. Given the high level intent and deliverables, how can it be broken down into scoped tasks with estimates? Anything more than 2 days of effort should ideally be broken down further. I often plan for slightly more than achievable by the team for each sprint, before going to stakeholders for prioritization.

Планирование предполагает, что команда data science организует свои задачи и усилия исходя из потребностей и приоритетов организации. Учитывая высокоуровневое намерение и результаты, как их можно разбить на скоупированные задачи с оценками? Всё, что требует более 2 дней усилий, в идеале следует разбить дальше. Я часто планирую немного больше, чем команда может выполнить за спринт, прежде чем идти к стейкхолдерам за приоритизацией.

In prioritization, each task is assigned a level of importance/urgency. This is sometimes done with stakeholder involvement. When stakeholders are involved, it provides them with a clearer picture of the effort expended on their requests. In addition, they can provide their input and feedback, or suggest different ideas and approaches.

При приоритизации каждой задаче присваивается уровень важности/срочности. Иногда это делается с участием стейкхолдеров. Когда стейкхолдеры участвуют, это даёт им более ясную картину усилий, затраченных на их запросы. Кроме того, они могут вносить свой вклад и обратную связь или предлагать другие идеи и подходы.

Then at the end of each sprint, we have the demo and retrospective — this is especially enjoyable.

Затем в конце каждого спринта у нас есть демо и ретроспектива — это особенно приятно.

Demos allow the team to share checkpoints and achievements in their past sprint(s). This provides for learning across the whole team, increasing your bus factor. In addition, this provides an opportunity for the rest of the team to provide feedback on one another’s work, leading to improvements.

Демо позволяют команде делиться контрольными точками и достижениями прошедшего спринта (спринтов). Это обеспечивает обучение всей команды, повышая ваш bus factor. Кроме того, это даёт остальной части команды возможность дать обратную связь по работе друг друга, что ведёт к улучшениям.

Lastly, the team has a chance to “show off” their pride and joy from the past sprint(s), and have everyone celebrate team achievements, which is highly motivating.

Наконец, у команды есть шанс «похвастаться» своей гордостью и радостью за прошедший спринт (спринты), и все вместе отмечают командные достижения, что очень мотивирует.

After that, we also have a retrospective which provides a chance for everyone to take stock of current sprint. What went well? What didn’t? How can we improve? The team learns and gains from each demo and retrospective, making the next sprint slightly more effective and efficient.

После этого у нас также есть ретроспектива, которая даёт каждому шанс подвести итоги текущего спринта. Что прошло хорошо? Что нет? Как мы можем улучшиться? Команда учится и извлекает пользу из каждого демо и ретроспективы, делая следующий спринт чуть более результативным и эффективным.

Writing up projects before starting

Письменное оформление проектов до старта

I highly encourage team members to begin each project by spending some time planning the project and writing it up.

Я настоятельно рекомендую членам команды начинать каждый проект с того, чтобы потратить немного времени на планирование проекта и его письменное оформление.

Putting words into a document helps to clarify one’s thoughts, especially when the ideas and projects are nebulous.

Изложение мыслей в документе помогает прояснить собственные идеи, особенно когда идеи и проекты туманны.

The document also acts as a map that one can refer to at any time to ensure that the project is on track. Here’s a standard template that I find useful:

Документ также служит картой, к которой можно обратиться в любой момент, чтобы убедиться, что проект идёт по плану. Вот стандартный шаблон, который я считаю полезным:

What is the problem or opportunity?

What is the intent?

What is the desired outcome and/or success metric?

What is the deliverable?

What are the benefits?

What are the dependencies and constraints?

В чём проблема или возможность? В чём намерение? Какой желаемый результат и/или метрика успеха? Что является результатом (deliverable)? В чём выгоды? Какие есть зависимости и ограничения?

First, always start with the current situation — what is the problem or opportunity? Is there an existing approach to address it? What is the current performance level? Is the problem one where data and data science can help with? For example, it could be that an e-commerce website is currently classifying new products manually.

Во-первых, всегда начинайте с текущей ситуации — в чём проблема или возможность? Есть ли существующий подход к её решению? Каков текущий уровень производительности? Является ли это проблемой, в которой данные и data science могут помочь? Например, может быть так, что сайт электронной коммерции в настоящее время классифицирует новые товары вручную.

Assuming each person can classify 2,000 products daily, with a target of adding 1 billion new products in a year, this translates to 500 thousand man days (or 2,000 people assuming 250 working days a year). This is clearly a bottleneck to scaling.

Предположим, каждый человек может классифицировать 2 000 товаров в день, при цели добавить 1 миллиард новых товаров за год — это выливается в 500 тысяч человеко-дней (или 2 000 человек, если считать 250 рабочих дней в году). Это явно узкое место для масштабирования.

Next, from stakeholders, what is the high-level intent? With this intent, we can better understand the goal (i.e., the “what”), and the data science team can identify the best way (i.e., the “how”) to achieve it. In this case, the intent would be scale the number of products that can be added to the platform through automation.

Далее, от стейкхолдеров — каково высокоуровневое намерение? С этим намерением мы можем лучше понять цель (то есть «что»), и команда data science может определить наилучший способ (то есть «как») её достичь. В данном случае намерение состояло бы в том, чтобы масштабировать количество товаров, которое можно добавить на платформу, за счёт автоматизации.

Then, based on this intent, what is the direct desired outcome? Phrased differently, what is the success metric, if there is one pre-defined? This provides a target that guides the team through the time-boxed iteration process (see above). For example, if the intent is to automate product categorisation, some specific numbers could be 95% top-3 precision and recall with a latency of classifying 40 products per second. This latency would lead to classification of 1 billion products in 290 days. This may not be sufficient given the peaks and troughs of products being added — one way to get around this to scale horizontally (i.e., multiple APIs processing in parallel).

Затем, исходя из этого намерения, каков прямой желаемый результат? Иначе говоря, какова метрика успеха, если она предопределена? Это задаёт цель, которая ведёт команду через процесс итераций с таймбоксами (см. выше). Например, если намерение — автоматизировать категоризацию товаров, конкретными числами могли бы быть 95% top-3 precision и recall с задержкой классификации 40 товаров в секунду. Такая задержка привела бы к классификации 1 миллиарда товаров за 290 дней. Этого может быть недостаточно, учитывая пики и спады добавления товаров — один из способов обойти это — масштабироваться горизонтально (то есть несколько API, обрабатывающих параллельно).

Given the intent, desired outcome, and success metric, what is the deliverable? Here, the data science team will brainstorm various approaches to meet the intent. Perhaps it could be an API that is integrated into the platform where sellers can upload their products. Would having a batch mode be useful and adopted? What product fields are available to build our classifier (e.g., title, image, attributes, etc.)? In this case, the deliverable could be an API that takes in product fields and returns the top-three most likely categories. This API can be exposed to both internal and external users.

Учитывая намерение, желаемый результат и метрику успеха, что является результатом (deliverable)? Здесь команда data science проведёт мозговой штурм различных подходов для достижения намерения. Возможно, это мог бы быть API, интегрированный в платформу, куда продавцы могут загружать свои товары. Был бы полезен и востребован пакетный (batch) режим? Какие поля товара доступны для построения нашего классификатора (например, заголовок, изображение, атрибуты и т. д.)? В данном случае результатом мог бы быть API, который принимает поля товара и возвращает три наиболее вероятные категории. Этот API может быть доступен как внутренним, так и внешним пользователям.

With this deliverable, what are the downstream benefits to the business? This is essential for building the business case and helping the organization to see the value of the data product, and thus invest resources in it. In the case of an automated product classifier, one downstream benefit could be reduced manpower costs for product classification. You can get a good estimate based on the number of products each person can process per hour, and the hourly wage cost.

С этим результатом — каковы дальнейшие выгоды для бизнеса? Это существенно для построения бизнес-кейса и помощи организации увидеть ценность дата-продукта и, следовательно, вкладывать в него ресурсы. В случае автоматического классификатора товаров одной из выгод могло бы быть снижение затрат на рабочую силу для классификации товаров. Хорошую оценку можно получить исходя из числа товаров, которое каждый человек может обработать за час, и часовой стоимости труда.

Assuming that 90% of 1 billion products can be automatically classified, how much manpower is saved?

Предположим, что 90% из 1 миллиарда товаров можно классифицировать автоматически — сколько рабочей силы будет сэкономлено?

In addition, reducing the lead-time between product upload and going live on the site is a key metric for seller experience and making the seller platform more self-service.

Кроме того, сокращение времени между загрузкой товара и его публикацией на сайте — ключевая метрика для опыта продавца и для того, чтобы сделать платформу для продавцов более самообслуживаемой.

Next, are there any dependencies for this project? For example, are there specific integration points, such as the product database, or the interface where sellers update their products? Are there also certain requirements for the data and model refresh frequency in order for the model to stay up-to-date and maintain acceptable performance?

Далее, есть ли какие-либо зависимости у этого проекта? Например, есть ли конкретные точки интеграции, такие как база данных товаров или интерфейс, где продавцы обновляют свои товары? Есть ли также определённые требования к частоте обновления данных и модели, чтобы модель оставалась актуальной и сохраняла приемлемую производительность?

Lastly, what are the constraints for the data science effort? One possible constraint would be the language (e.g., Python, Java, Scala, Go). What languages are supported? What are the frameworks allowed for use? Is distributed computing available? What is the maximum latency tolerable of the API developed? How much compute and memory is available per API server? These are some of the key questions that would determine the architecture of the final solution developed.

Наконец, каковы ограничения для работы data science? Одним из возможных ограничений был бы язык (например, Python, Java, Scala, Go). Какие языки поддерживаются? Какие фреймворки разрешено использовать? Доступны ли распределённые вычисления? Какова максимально допустимая задержка разрабатываемого API? Сколько вычислительных ресурсов и памяти доступно на каждый сервер API? Это некоторые из ключевых вопросов, которые определят архитектуру итогового решения.

Having the above points thought through beforehand will provide clarity on the rest of the project. It doesn’t mean you need to have all the answers before starting on the project. What it means is that you should have thought through the process, end-to-end, and figured out the key questions before starting — at least then you know what are “known unknowns”. As suggested in the seven habits of highly effective people — “Begin with the end in mind”.

Продуманные заранее перечисленные выше пункты дадут ясность по остальной части проекта. Это не значит, что нужно иметь все ответы перед началом проекта. Это значит, что вам следует продумать процесс от начала до конца и разобраться с ключевыми вопросами перед стартом — по крайней мере, тогда вы знаете, что является «известными неизвестными». Как сказано в «Семи навыках высокоэффективных людей» — «Начинай, представляя конечную цель».

Updated Mindset to include Innovation

Обновлённое мышление, включающее инновации

There is no clear template or approach I can proposed for this.

Для этого нет ясного шаблона или подхода, который я мог бы предложить.

It could begin with a conversation with senior leadership on the mandate of the data science team, which should include innovation. Once the mandate is secured with a (manpower) budget for innovation, it is important to have a program with proper accountability.

Это могло бы начаться с разговора со старшим руководством о мандате команды data science, который должен включать инновации. Как только мандат закреплён с (кадровым) бюджетом на инновации, важно иметь программу с надлежащей подотчётностью.

For example, innovation projects could be allocated 2–3 weeks quarterly. They should be directly linked to a desired outcome, with downstream benefits to the organization. This helps with getting buy-in for the project as well.

Например, инновационным проектам можно было бы выделять 2–3 недели ежеквартально. Они должны быть напрямую связаны с желаемым результатом, с дальнейшими выгодами для организации. Это также помогает получить поддержку проекта.

Members involved should have a deliverable on sharing their learnings, outcomes, and proper code and documentation for these projects. This helps enforce accountability, and documentation helps others pick up the project easier, or when we have to revisit the project after a couple of months.

Участники должны иметь обязательство поделиться своими выводами, результатами, а также надлежащим кодом и документацией по этим проектам. Это помогает обеспечить подотчётность, а документация помогает другим легче подхватить проект или когда нам приходится вернуться к проекту через пару месяцев.

Key Takeaways

Ключевые выводы

Whew, that was a long post (and read). Thanks for staying with me so far.

Уф, это был длинный пост (и длинное чтение). Спасибо, что остались со мной до сих пор.

Overall, Agile is a good framework to apply in the context of data science, with benefits that we can directly gain from. Though there are some aspects that may not be suitable, there are some adaptations that can be made to make it more applicable for data science teams and projects.

В целом Agile — хороший фреймворк для применения в контексте data science, с выгодами, которые мы можем напрямую получить. Хотя есть некоторые аспекты, которые могут не подходить, есть и некоторые адаптации, которые можно сделать, чтобы он лучше подходил для команд и проектов data science.

The key thing to remember is that the most important thing is generating valuable work, be it working and accurate models, innovation and new approaches with 10x improvements, or learnings from failed experiments.

Ключевое, что стоит помнить, — самое важное — это создание ценной работы, будь то работающие и точные модели, инновации и новые подходы с улучшениями в 10 раз или выводы из неудавшихся экспериментов.

If adopting agile and making certain (other) adjustments help your team with achieving their goals, so be it. Don’t let it constrain the team from doing valuable work and fulfilling their potential.

Если внедрение agile и внесение определённых (других) корректировок помогает вашей команде достигать целей — так тому и быть. Не позволяйте этому ограничивать команду от выполнения ценной работы и реализации её потенциала.

With this, I end with the Agile Manifesto.

На этом я завершаю Agile-манифестом.

If you found this useful, please cite this write-up as:

Если вы нашли это полезным, пожалуйста, цитируйте эту работу так:

Yan, Ziyou. (Feb 2019). Data Science and Agile (Frameworks for Effectiveness). eugeneyan.com. https://eugeneyan.com/writing/data-science-and-agile-frameworks-for-effectiveness/.

or

или

@article{yan2019agile3, title = {Data Science and Agile (Frameworks for Effectiveness)}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2019}, month = {Feb}, url = {https://eugeneyan.com/writing/data-science-and-agile-frameworks-for-effectiveness/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.