newsmode
search
Меню
arrow_back Назад

GovTech Conference - Data Science and Agile—Can or Not?

auto_awesomeКраткое саммари

Юджин Ян (Eugene Yan) выступил модератором панельной дискуссии на тему «Data Science и Agile — можно или нет?», прошедшей в рамках первой конференции STACK от GovTech в Сингапуре. В панели участвовали Steven Koh (GovTech), Adam Drake (бывший CDO Skyscanner и Redmart) и Ivan Zimine. Главный вывод: Agile — это прежде всего мышление и культура коротких итераций, постоянной обратной связи и корректировок, применимая и в data science, где результатом цикла могут быть анализы, проверка гипотез или визуализации. На примере с рекомендательным движком показано, как итеративный подход помогает избежать многолетней разработки не того продукта (поиск давал >90% кликов и покупок). Обсуждались также истинный Agile и принцип «Люди важнее процессов», а начинающим специалистам советовали собирать портфолио своих работ.

GovTech Conference - Data Science and Agile—Can or Not?

Конференция GovTech — Data Science и Agile: можно или нет?

[ agile datascience ] · 6 min read

[ agile datascience ] · чтение на 6 мин

Recently, I was invited to moderate a panel on the topic “Data Science and Agile–can or not?” It’s a Singlish way of asking if Agile can be applied in the domain of data science. The panel was held in conjunction with GovTech’s inaugural STACK conference for developers, programmers, and technologists from the private sector.

Недавно меня пригласили быть модератором панельной дискуссии на тему «Data Science и Agile — можно или нет?» Это синглишский способ спросить, применим ли Agile в области data science. Панель проходила в рамках первой конференции STACK от GovTech для разработчиков, программистов и технологов из частного сектора.

Check out the awesome venue we have

Взгляните, какая у нас была потрясающая площадка

Who was in the panel?

Кто участвовал в панели?

The panel involved the following guests, from left to right in the photo below:

В панели участвовали следующие гости (слева направо на фото ниже):

  • Eugene Yan (that’s me as moderator): VP of Data Science at Lazada (acquired by Alibaba), currently Senior Data Scientist at uCare.ai.
  • Steven Koh: Director of Government Digital Services at GovTech leading the Agile Consulting and Engineering team and evangelising agile development in the government.
  • Adam Drake: Formerly Chief Data Officer at Skyscanner and Redmart, with an exemplary record in the design, development, and delivery of cost-effective, high performance tech teams and systems.
  • Ivan Zimine: Physicist and neuroscientist who works on complex systems while applying open source and open practices.
  • Eugene Yan (это я, модератор): VP of Data Science в Lazada (приобретена Alibaba), в настоящее время Senior Data Scientist в uCare.ai. Steven Koh: директор Government Digital Services в GovTech, возглавляет команду Agile Consulting and Engineering и продвигает agile-разработку в государственном секторе. Adam Drake: бывший Chief Data Officer в Skyscanner и Redmart, с образцовым послужным списком в проектировании, разработке и внедрении экономичных, высокопроизводительных технических команд и систем. Ivan Zimine: физик и нейробиолог, работающий со сложными системами и применяющий open source и открытые практики.

    What were some of the notable questions and responses?

    Какие были самые примечательные вопросы и ответы?

    I don’t do anything related to technology–why should I care about agile or scrum?

    Я не занимаюсь ничем, связанным с технологиями, — почему меня должны волновать agile или scrum?

    The view from the panel was that Agile is a mindset and culture of having small iterations, continuous feedback, and course corrections and improvements. This is applicable not just in tech, but in other areas as well.

    Точка зрения панели была такова: Agile — это мышление и культура коротких итераций, постоянной обратной связи, корректировок курса и улучшений. Это применимо не только в технологиях, но и в других областях.

    One panelist gave a humorous (though not very accurate) example of adopting agile in budget planning, where the daily spending is adjusted based on each month’s cumulative spending, with estimates for total spending in the month. While these estimates are unlikely to be accurate down to the dollars and cents, they provide a ballpark figure for one to aim for.

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

    What does agile look like in the context of data science? How does the data science team fit into agile rituals? Do they follow daily stand-ups and planning?

    Как выглядит agile в контексте data science? Как команда data science вписывается в agile-ритуалы? Проводят ли они ежедневные стендапы и планирование?

    Some audience members had difficulty understanding how agile could be adopted in a data science team. Others are part of data science teams that tried practicing it, but with limited success.

    Некоторым слушателям было трудно понять, как agile можно внедрить в команде data science. Другие входят в команды data science, которые пытались его практиковать, но с ограниченным успехом.

    For the panelists (and myself), we felt that the mindset of agile could also be adopted in the context of data science, where projects are done in small iterative cycles. While the deliverables may not always be a working product, or additional features, there are measurable deliverables. This could come in the form of analyses that help understand possible causes of an issue, or the testing of multiple hypotheses to identify the key problem, or visualisations that provide better understanding of the context.

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

    Overall, the intent is iterative development, instead of adopting a traditional waterfall approach. In a waterfall approach, significant time would be spent developing a project plan and technical specs which are then “frozen” (i.e., minor changes are difficult, major changes are almost impossible).

    В целом замысел — итеративная разработка вместо традиционного водопадного подхода. При водопадном подходе много времени уходит на разработку плана проекта и технических спецификаций, которые затем «замораживаются» (то есть мелкие изменения вносить трудно, а крупные — почти невозможно).

    Next, the system is throughly designed based on the tech specs and developed over several months or years. Sometimes, the system delivered may be less or no longer relevant to the organization given that it was planned and designed years ago. Or worse, the project is found to be solving the wrong problem, or solving the right problem with the wrong approach, at the later stages of the waterfall cycle. Months/years of effort would have gone down the drain.

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

    For example, perhaps a decision was made to develop a recommendation engine for an e-commerce site. After significant planning, designing, and development, it was finally released after a year or two. However, there was no measurable lift to site metrics (e.g., conversion, revenue, daily average users).

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

    Eventually, a study on user purchasing behaviour and journey found that most of the sales funnel was generated by the search engine, with it accounting for > 90% of clicks and purchases. Very few users actually browsed based on the recommendation engine on the homepage, search, and product pages.

    В конце концов исследование покупательского поведения и пути пользователя показало, что бóльшая часть воронки продаж генерировалась поисковым движком, на который приходилось >90% кликов и покупок. Очень мало пользователей действительно просматривали товары на основе рекомендательного движка на главной странице, в поиске и на страницах товаров.

    In the example above, by adopting an agile approach, perhaps some quick analysis would have been done to determine which recommendation engine to develop first–search, product, or homepage? In this process, it would have been discovered that the potential gain from a recommendation engine would be significantly less than improving the search engine. The team can then course correct and redirect their efforts, saving precious resources and time and delivering measurable value.

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

    What does it mean to practice Agile? Is there such as thing as true Agile? A lot of companies claim they are Agile but in reality have projects crunched by unrealistic deadlines, unclear requirements, etc.

    Что значит практиковать Agile? Существует ли такое понятие, как настоящий Agile? Многие компании заявляют, что они Agile, но в реальности у них проекты зажаты нереалистичными дедлайнами, неясными требованиями и т. п.

    Currently, it seems there are different schools of thought around the concept of agile and a variety of ways that one can be certified for agile and scrum. Nonetheless, at its core, agile is a mindset and the fundamental principles are the same.

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

    The Agile Manifesto was raised, specifically, the first principle–“People over processes”. Imposing one school or practice of agile over another would be in violation of this principle. If a team finds practising the core principles of agile to be helpful in being more productive, that was good enough. There is no need to nitpick on whether they are adhering strictly to detailed agile methodology or techniques.

    Был упомянут Agile-манифест, в частности его первый принцип — «Люди важнее процессов». Навязывание одной школы или практики agile поверх другой нарушало бы этот принцип. Если команда находит, что следование основным принципам agile помогает работать продуктивнее, этого достаточно. Нет нужды придираться к тому, строго ли они придерживаются детальной agile-методологии или техник.

    In case you’ve not seen it before or need a refresher, here’s the Agile Manifesto.

    На случай, если вы не видели его раньше или нуждаетесь в напоминании, вот Agile-манифест.

    The Agile Manifesto: People over Process

    Agile-манифест: Люди важнее процессов

    I’m a recent technical graduate but have no experience with engineering in production, data science, etc. What can I do to get a technical role in either fields?

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

    The key advice panelists had was to develop a portfolio demonstrating one’s work. This could be in the form of small apps on a cloud server, or past analysis and write-ups, or simply blog posts.

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

    One apt example was shared by one of the panelists: He was out shopping for wedding photographers and assessing them based on their past portfolio. How many people would hiring a wedding photographer who did not have a portfolio? Similarly, as a technical candidate, having a portfolio helps to showcase your past work, giving potential hiring managers more confidence that you can deliver in the role.

    Один из участников поделился метким примером: он подбирал свадебных фотографов и оценивал их по прошлому портфолио. Многие ли наняли бы свадебного фотографа без портфолио? Аналогично, для технического кандидата наличие портфолио помогает показать ваши прошлые работы, давая потенциальным нанимающим менеджерам больше уверенности в том, что вы справитесь с ролью.

    Overall, it was an enjoyable discussion with the expert practitioners in the panel. I hoped the audience learnt and benefited a lot from their sharing–I certainty did!

    В целом это было приятное обсуждение с экспертами-практиками в панели. Надеюсь, аудитория многому научилась и извлекла большую пользу из их рассказов — я уж точно извлёк!

    As I moderate more and more panels, I find myself enjoying the discussion to a greater extent. In some of my past panels, I was nervous about keeping the conversation going and ensuring it was useful for the audience. Recently, the conversation is more casual, and I’m even able to joke around with the panelists. There were also natural follow-up questions that unearthed valuable experiences and anecdotes that the audience could take away. Looking forward to my next one!

    Чем больше панелей я модерирую, тем больше начинаю получать удовольствие от обсуждения. На некоторых прошлых панелях я нервничал из-за того, чтобы поддерживать разговор и обеспечивать его полезность для аудитории. В последнее время беседа стала более непринуждённой, и я даже могу пошутить с участниками. Возникали и естественные уточняющие вопросы, раскрывавшие ценный опыт и истории, которые аудитория могла унести с собой. С нетерпением жду следующей!

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

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

    Yan, Ziyou. (Oct 2018). GovTech Conference - Data Science and Agile—Can or Not?. eugeneyan.com. https://eugeneyan.com/speaking/data-science-and-agile-can-or-not-talk/.

    Yan, Ziyou. (Oct 2018). GovTech Conference - Data Science and Agile—Can or Not?. eugeneyan.com. https://eugeneyan.com/speaking/data-science-and-agile-can-or-not-talk/.

    or

    или

    @article{yan2018govtech, title = {GovTech Conference - Data Science and Agile—Can or Not?}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2018}, month = {Oct}, url = {https://eugeneyan.com/speaking/data-science-and-agile-can-or-not-talk/} }

    @article{yan2018govtech, title = {GovTech Conference - Data Science and Agile—Can or Not?}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2018}, month = {Oct}, url = {https://eugeneyan.com/speaking/data-science-and-agile-can-or-not-talk/} }



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

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