В предыдущей статье мы говорили о важности данных и проблемах с ними. Мы обсудили, что решение должно быть комбинацией i) инструментов, платформ и платформ, ii) настройки инженерного процесса, iii) корректировки организационной структуры. Сегодня поговорим об инженерных процессах.

Раньше разработка программного обеспечения в основном выполнялась с использованием водопадной модели с формальным утверждением и передачей на каждом этапе SDLC — требования, дизайн, разработка, контроль качества и производство с отдельными командами для управления этим. Выросла потребность в гораздо меньших циклах выпуска с быстрыми итерациями, и поэтому аспекты обеспечения качества и эксплуатации SDLC необходимо учитывать на ранних этапах, такие как сами требования и спецификации, или, другими словами, обеспечение качества и эксплуатацию необходимо сдвинуть влево, а затем практиковать DevOps. началось вместе с Agile и стало довольно популярным. Совсем недавно, когда общедоступное облако стало популярным, и частные данные компании начали передаваться через Интернет, проблемы безопасности усилились, и появилась новая тенденция — рассматривать безопасность на более ранней стадии цикла разработки, поэтому соображения безопасности были смещены влево, и мы получили DevSecOps. упражняться. Теперь, когда важность данных, особенно генерации данных, приобретает все большее значение, ее необходимо учитывать на раннем этапе SDLC, поэтому ее также следует сдвинуть влево. Следуя традиции, назовем его DevSecDataOps, пока не появится более подходящее имя.

Мы разработали шесть основных принципов данных под названием Приложение с шестью факторами, которые необходимо применять в цикле разработки программного обеспечения, чтобы максимально использовать преимущества данных. Название вдохновлено методологией Twelve-Factor App (12factor.net), первоначально представленной Адамом Уиггинсом. Хотя принципы Six Factor App могут применяться с любой методологией разработки программного обеспечения, которую мы обсудим в свете Agile. Вот шесть принципов:

Давайте обсудим их немного подробнее -

  1. В Scrum-команды должен входить инженер данных, аналитик данных и/или специалист по обработке данных. Эти роли открывают перспективу потенциальных вариантов использования данных, форматов данных и обработки данных. Существующие участники могут взять на себя эти роли. Один человек может выполнять эти роли в нескольких командах Scrum.
  2. Scrum-команды должны назначить владельца данных и владельца функции. Сегодня обычно владелец продукта управляет невыполненной работой по продукту, состоящей только из функций и не касающейся данных. Таким образом, владелец данных отстаивает варианты использования данных и ведет журнал невыполненных данных. Идея, лежащая в основе первых двух принципов, состоит в том, чтобы гарантировать, что правильный набор ролей (людей) является частью команды Scrum, которая будет отстаивать генерацию данных и потребление идей. Должны быть жадными в том, какие данные генерировать, даже если у нас сегодня нет вариантов их использования. Довольно легко подключиться к Kinesis Firehose и заархивировать его в S3 Glacier до тех пор, пока он нам не понадобится. Последующее внедрение кода генерации данных в рабочий модуль довольно сложно.
  3. В бэклоге разработчиков приоритет должен отдаваться информационным историям наряду с пользовательскими (особыми). Если не расставить приоритеты должным образом, у него очень высокие шансы закончиться техническим долгом. Мы все знаем, что при подготовке бэклога, если история перемещается на P4, ее вежливо удаляют. Я прочитал очень хорошую и забавную статью, объясняющую технический долг, сравнивая его с приготовлением еды на кухне. Проверьте это — https://www.scrum.org/resources/blog/technical-debt-product-owners.
  4. QA должен тщательно проверять сгенерированные данные на формат, качество и полноту.После того, как истории данных получат должное в журнале и разработке, QA будет относиться к ним так же, как к любой другой функции, которая проверяет данные на формат, качество и полнота.
  5. Сгенерированные данные должны быть отформатированы как схема БД или спецификация API.Сегодня чаще всего данные, если они генерируются, имеют произвольный формат или вообще не имеют формата. Мы предлагаем относиться к форматам данных так же, как мы относимся к схеме БД или спецификации API.
  6. Централизуйте доступ к данным, а не хранение данных. Цель состоит в том, чтобы максимально избежать репликации данных и объединить данные для доступа. Например, для доступа к API данные могут по-прежнему находиться в соответствующих хранилищах, а API GraphQL можно использовать для объединения доступа к данным из этих разрозненных баз данных. Для этого существует множество архитектур, но нам нравится архитектура сетки данных, предложенная Жамаком Дегани из Thoughtworks.

Давайте еще раз посмотрим, как эти принципы можно применить к agile-Scrum-процессу. На приведенной ниже диаграмме показаны различные шаги/действия, которые могут быть предприняты на каждом этапе типичной гибкой настройки.

На данный момент мы видим положительный эффект при их внедрении в SDLC. По мере того, как мы узнаем больше, мы будем настраивать его дальше. Было приятно, когда один из наших клиентов смог сократить усилия по обработке данных более чем на 50%, применив эти методы, не говоря уже об улучшении качества обучающих данных и точности прогнозов.

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

Часть I. Данные — это новое убийственное приложение.

Ссылка на часть III статьи. — скоро..