Dod номер что это
Data Oriented Design на практике
Что такое DOD?
Данная статья была задумана как попытка сравнить разные подходы без попытки объяснить их суть. На Хабре есть несколько статей по теме, например эта. Стоит также посмотреть видео с конференции CppCon. Но в двух словах, DOD — это способ оперировать данными в cache friendly манере. Звучит непонятно, пример объяснит лучше.
Второй тест выполняется быстрее на 30% (в VS2017 и gcc7.0.1). Но почему?
Как дела обстоят на практике?
Чтобы понять реальность применения подхода я решил написать более-менее комплексный код, используя обе техники и сравнить результаты. Пускай это будет 2d симуляция твердых тел — мы создадим N выпуклых многоугольников, зададим параметры — массу, скорость и т.п. и посмотрим, сколько объектов мы сможем симулировать оставаясь на отметке 30 fps.
1. Array of Structures
1.1. Первая версия программы
Исходный код для первой версии программы можно взять из этого коммита. Сейчас мы кратко пробежимся по коду.
На моем стареньком ноутбуке эта программа рассчитывает 500 фигур максимум, перед тем, как fps начинает падать ниже 30. Фуууу, всего 500. Согласен, немного, но не забывайте, что каждый кадр мы повторяем расчеты 20 раз.
Думаю, что стоит разбавить статью скриншотами, поэтому вот:
1.2. Оптимизация номер 1. Spatial Grid
Коммит второй версии программы можно посмотреть здесь. Появился новый класс Grid и немного изменился метод ShapesApp::update() — теперь он вызывает методы сетки для проверки пересечений.
Эта версия держит уже 8000 фигур при 30 fps (не забываем про 20 итераций в каждом кадре)! Пришлось уменьшить фигуры в 10 раз, чтобы они поместились в окне.
1.3. Оптимизация номер 2. Multithreading.
Разделение основных задач добавило немного головной боли. Так например, если фигура пересекает границу ячейки в сетке, то она будет находится одновременно в нескольких ячейках:
Запустив эту версию я могу наблюдать 13000 фигур при 30 fps. Для такого количества объектов пришлось увеличить окно! И снова — в каждом кадре мы повторяем симуляцию 20 раз.
2. Structure of Arrays
2.1. Первая версия программы
То, что мы писали выше я называю традиционным подходом — я пишу такой код много лет и читаю, в основном, похожий код. Но теперь мы убьем структуру Shape и посмотрим — сможет ли эта небольшая модификация повлиять на производительность. Ко всеобщей радости рефакторинг оказался не сложным, даже тривиальным. Вместо Shape мы будем использовать структуру с векторами:
И передаем мы эту структуру так:
Т.е. вместо конкретных фигур передаются их индексы и в методе из нужных векторов берутся нужные данные.
Эта версия программы выдает 500 фигур при 30 fps, т.е. не отличается от самой первой версии. Связано это с тем, что измерения проводятся на малом количестве данных и к тому же самый тяжелый метод использует почти все поля структуры.
Далее без картинок, т.к. они точно такие же, как были ранее.
2.2. Оптимизация номер 1. Spatial Grid
Все как и раньше, меняем только AoS на SoA. Код здесь. Результат лучше, чем был ранее — 9500 фигур (было 8000), т.е. разница в производительности около 15%.
2.3. Оптимизация номер 2. Multithreading
Снова берем старый код, меняем структуры и получаем 15000 фигур при 30 fps. Т.е. прирост производительности около 15%. Исходный код финальной версии лежит здесь.
3. Заключение
Изначально код писался для себя с целью проверить различные подходы, их производительность и удобство. Как показали результаты, небольшое изменение в коде может дать довольно ощутимый прирост. А может и не дать, может быть даже наоборот — производительность будет хуже. Так например, если нам нужна всего один экземпляр, то используя стандартный подход мы прочитаем его из памяти только один раз и будем иметь доступ ко всем полям. Используя же структуру векторов, мы вынуждены будем запрашивать каждое поле индивидуально, имея cache-miss при каждом запросе. Плюс ко всему немного ухудшается читабельность и усложняется код.
Поэтому однозначно ответить — стоит ли переходить на новую парадигму всем и каждому — невозможно. Когда я работал в геймдеве над игровым движком, 10% прироста производительности — внушительная цифра. Когда я писал пользовательские утилиты типа лаунчера, то применение DOD подхода вызвало бы только недоумение коллег. В общем, профилируйте, измеряйте и делайте выводы сами :).
Dod номер что это
DID (Direct Inward Dialing) — возможность УАТС по маршрутизации входящих вызовов из телефонной сети общего пользования (ТФОП) напрямую на внутренний номер абонента, что позволяет использовать несколько городских линий для звонков значительно большему количеству внутренних абонентов. Сервис также может называться Direct Dial-In (DDI).
Этот сервис применяется для подстановки правильного внешнего номера при исходящих вызовах и для вызова пользователя обособленной телефонной сети организации без необходимости дополнительного донабора внутреннего номера.
Содержание
Описание технологии
В организациях обычно используются собственная АТС или услуга Centrex/Виртуальная АТС от оператора связи, у абонентов при этом применяются внутренние номера, доступные только в рамках этой организации. Обычно это подразумевает 3-х, 4-х или 5-значный план нумерации. Для соединения из ТФОП с абонентами организации используется внешний номер, предоставляемый оператором связи и назначаемый для телефонной линии соединяющей коммутатор и УАТС, обычно 7-10 значный. Звонок по данному внешнему номеру обычно передаётся конкретному абоненту с внутренним номером (секретарю или оператору) или обслуживаются специальным сервисом DISA, который позволяет выбрать внутреннего абонента или выполнить донабор внутреннего номера в тоновом режиме.
В США данная услуга была внедрена в 1960-х годах компанией AT&T, основываясь на более ранних разработках Deutsche Bundespost (сервис IKZ).
Использование
В учрежденческих АТС при необходимости адресовать вызовы на некоторые номера внутренним абонентам без посредников. [1]
Таким образом, определяются две различные модели поведения при прохождении телефонного звонка:
Direct outward dialing
Комплементарным к DID является Direct Outward Dialing (DOD) или Direct Dial Central Office (DDCO): УАТС подставляет в Caller ID конкретный публичный номер при исходящих звонках абонента УАТС в ТФОП.
Комбинация DOD/DDCO с DID позволяет сделать «прямой городской номер» наряду с внутренним (помимо прочего, это даёт адресату звонка возможность точного определения городского номера внутреннего абонента). УАТС подставляет в качестве CLI или Сaller ID тот же номер, который закреплён за внутренним номером абонента в DID.
Если не используется DOD/DDCO, обычно УАТС заполняет Caller ID номером, звонок на который попадает на секретаря или оператора центра обработки вызовов.
Синхронизация команды со SCRUM
Как мне кажется, одна их самых больших проблем в скраме — это полный рассинхрон между людьми в команде. Мне пока не удавалось увидеть ни одного стабильного решения этой проблемы. Конечно, есть стандартные инструменты, но далеко не всегда они дают ответы на все вопросы и закрывают все дыры.
Предлагаю зайти к нам в гости и посмотреть как с проблемой синхронизации внутри себя борется команда “Онлайн-ипотеки” компании “Альфа-Банк”.
Статья была подготовлена членами нашей команды: Марина, Дима, Настя, Вероника, Толя.
Не так давно (чуть более полугода назад) в Альфа-Банке стартовал новый проект — «Онлайн-Ипотека». Команда под проект собиралась с нуля. Люди на проект пришли разные и с разных мест работы. Все было прямо по гайду: DevTeam (JS, Java, QA, Аналитик), скрам-мастер и Product Owner. Никто из девтим до этого никогда не работал по скрам-фреймворку.
Первая точка синхронизации: DOR
Итак, мы все собрались, познакомились и почти сразу приступили к делу. Впереди нас ждало множество неочевидных (на первый взгляд) идей. Большинство из них впоследствии стали обыденными и логичными. Но вот что мы долгое время не могли побороть — это мнимая понятность задач. Часто бывает так, что берешь задачу в спринт, а она оказывается не так проста (а иногда и сложна), как казалось на первый взгляд.
Рассинхрон для нас заключался в следующем:
Опыт оказался крайне успешен. Мы стали действовать более слаженно и более продуктивно. На грумингах мы держали DOR перед глазами и использовали как чек-лист при разборе задачи. PO почти всегда узнавал заранее, чего не хватает задаче, и старался как можно скорее уточнить информацию. Иначе такая задача просто не попадала в следующий спринт.
Нам приходилось брать спайки (исследования) из верхних задач в общем бэклоге (backlog) в спринт, но это приносило колоссальный результат. Неопределенность снижалась, и мы начали корректно оценивать трудоемкость задачи.
Тут стоит отметить, что DOR у каждой команды должен быть свой. Дело в том, что он не должен представлять собой набор четких указаний от работодателя. Это скорее требования команды к минимальному описанию задачи и проработке подводных камней, которые должны быть выполнены для удобства и ускорения работы.
Критерии готовности user story к взятию в работу
Вторая точка синхронизации: DOD
Очень хорошо, когда вся команда понимает, какие задачи мы можем помещать в спринт, а какие лучше не стоит. После выполнения условий DOR мы столкнулись со следующим: мы берем задачу (user story) в работу, но как мы можем понять, что она точно готова?
Конечно, мы можем посмотреть на все саб-таски (sub task) и оценить готовность задач по ним. Но что, если мы не завели саб-таску по документации, тестированию или настройке доступов? Есть ли необходимость каждый раз заводить подобные саб-таски?
Ну хорошо. Допустим, мы идеально заводим саб-таски и идеально вовремя их закрываем. Тогда логично было бы закрыть задачу сразу после мерджа в мастер. Но ведь задача еще не на бою! Пользователь не увидит пользы от нашей работы, и все было зря.
Первое время мы спорили о факте закрытой задачи. После чего мы приняли какие-то не совсем формальные правила. Это сильно упростило работу, но время от времени все же конфликты возникали. Тогда мы пришли к следующему стандартному шагу синхронизации.
DOD (Definition Of Done) позволяет решить проблему приемки и общего понимания готовой задачи. DOD очень похож на DOR. Это такой же набор критериев, но на этот раз для готовой задачи. Взглянув на него, мы всегда можем сказать: готова задача или нет.
В результате мы выработали общее понимание того, что надо сделать, чтобы считать задачу закрытой. Только после выполнения всех пунктов задача переходит в DONE.
Подводим итоги первых двух шагов синхронизации
Отлично! Работать стало гораздо удобнее. Мы больше не тратим время на ненужные формальности о разговорах, какая задача готова, а какую стоит еще доработать. С другой стороны, мы больше не боимся брать задачи в спринт. Но что происходит между этими событиями? Раздор, разруха и хаос.
Аналитик не всегда может изначально проверить все задачи в спринте. Один из разработчиков может сделать изменения (без возможности откатиться), которые коснутся другого разработчика. В конце концов, PO тоже люди, и задачи могут меняться в ходе спринта, даже если это сильно не приветствуется в скраме.
На самом деле есть целая масса случаев, которые могут привести к конфликтам и непродуктивной работе между этапами взятия в работу и завершения задачи (для краткости — DOR и DOD). В любой команде почти всегда можно видеть одну и ту же проблему. Кто-то что-то куда-то залил, и второй разработчик теперь страдает. Это провоцирует конфликты и негатив. И, конечно, эта проблема почти всегда возникает, когда одной задачей занимаются несколько разработчиков.
Вначале мы пытались найти что-то из уже существующего вроде DOR и DOD. К сожалению, ничего подобного и подходящего к нам мы не нашли (может быть, плохо искали). Пробовали 1 work in progress, но опыт не удался. Каждая задача состоит из разнородных частей. Наш опыт показал, что при таком подходе кто-то из разработчиков всегда скучает, а кто-то вынужден задерживаться на работе и доделывать свою “половинку”. Не так давно мы собрались и подумали над еще одним промежуточный этапом:
Третья точка синхронизации — наша собственная задумка: DOT
DOT (Definition Of Test) представляет собой набор критериев тестирования задачи и сборки ее в единое целое на тестовом стенде. Также мы устанавливаем правила о том, что девтим не может приступать к дальнейшим действиям (pull requests и тд), пока DOT не будет выполнен полностью.
Взглянем на рисунок и попробуем разобрать идею более подробно. Для начала представим, что у нас имеется только один разработчик на одну задачу:
Сразу отметим здесь ключевую особенность. У нас есть то, что должно быть сделано, и то, что делать нельзя до выхода из зоны тестирования. Сюда можно отнести прохождение pull request, мердж в мастер, выкатку и прочее.
Сразу стоит отметить отличие от DOR и DOD. Когда мы говорим про DOR, мы говорим о том, что нужно для решения задачи. При разговоре о DOD, мы говорим какую задачу можно считать сделанной. В DOT на нас влияют сразу несколько видов обстоятельств. С одной стороны, разработка задачи должна быть завершена. С другой, многие действия для доведения задачи в полностью готовый вид делать не стоит.
По-настоящему раскрывает себя идея в случае нескольких разработчиков с одной задачей. Посмотрим на такой случай. В нашем примере у нас будут фронт и бэк:
Схема очень примерная. Понятно, что у нас один специалист может помогать (или мешать) другому. Необходимость доработать задачу может всплыть раньше. А выкаткой на бой может заниматься другой человек. Главное тут другое. У нас есть некая область с четко оговоренными ДО и ПОСЛЕ. Более того, ПОСЛЕ не может наступить, пока не будут выполнены все условия DOT. И только после этого можно получить ОК от тестирования.
Что еще тут важно? Как видно из картинки, разработка может начинаться в разное время. Самое главное тут то, что в область тестирования входят несколько разработчиков в разное время, но выйти из нее они могут только вместе. Чем они будут заняты в это время — можно договориться.
После того как задача полностью протестирована, все разработчики получают волшебный ОК от тестирования, и теперь уже стартуют из одной точки. Интересно, что здесь крайне мала вероятность каких-то недочетов в синхронизации. Оставшиеся действия занимают примерно одинаковое время.
Потребностью DOT является необходимость жесткой синхронизации разработчиков между собой. В одну область входят несколько разработчиков в разное время, но выходят всегда в единой точке.
Минусом такого подхода является дополнительное время на продумывание организации задач на этапе формирования. Но на самом деле такие затраты легко окупаются. При этом, задачи становятся более структурированными и прогнозируемыми.
Definition of Ready — то, о чем нам забыли рассказать
Введение
Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.
Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.
На Definition of Ready далее по тексту — DoR я наткнулся случайно, в профильном чате, который посвящен Agile. Попытавшись найти информацию, не нашёл ни одного упоминания в рунете на эту тему. Поэтому отправился читать и переводить англоязычные статьи. Теперь делюсь с вами результатом, надеюсь это поможет сделать вашу команду, еще круче и продуктивнее.
Что такое DoR
И так, что же такое DoR? Google переводчик подскажет, что это «определение готовности». Если DoD включает в себя критерии завершенности задачи, то DoR — критерии готовности задачи к взятию в работу. То есть, если задача, отвечает критериям из DoR, команда может взять её на планировании в работу. Вроде бы просто, вы уже наверняка начали придумывать как наконец то вместе с командой составите целый список требований для вашего PO, чтобы тот стал писать тонну документации, а остальные члены команды спокойно смогли сидеть за своим компьютером, и молча писать код. Это только начало, и DoR не то, чем кажется на первый взгляд.
Зачем нужен DoR
Сначала ответим на вопрос: зачем нужен этот артефакт? Какую пользу он принесет команде? DoR поможет команде:
Давайте взглянем на список проблем, которые косвенно, или напрямую вытекают из-за отсутствия DoR:
В конце концов, это приводит к выпуску продукта, который не рабочий, бесполезный, не решает первоочередной проблемы. А это в пустую потраченное время, которое каждый желает тратить на важные вещи. В одной из статей, я встретил отличное высказывание: «Мусор вошёл, мусор вышел».
Где применять DoR
DoR используют на Product Backlog Refinement далее по тексту PBR или более привычное название артефакта: Grooming. Во время этой активности, User Story становятся готовыми — Ready. Это означает что результатом мероприятия, в Бэклоге продукта, будут Ready US. DoR нужен чтобы описать состояние, при котором US, можно обсуждать на планировании. Это называется Takin in — принятые US.
Чтобы пойти дальше, обращаю внимание, как Джефф Сазерленд, один из основателей Scrum и Agile манифеста, рассказывает о DoR и DoD в своих видео. Сазерленд вводит понятия Done-Done, и Ready-Ready. Когда член команды говорит что задача готова или выполнена, подразумевается, что она соответствует тем критериям, которые команда определила в DoD и DoR соответственно. Это важный аспект, каждый член команды должен понимать его, и не забывать. Иначе возникают смешные ситуации, когда на Daily Петя будет рассказывать что задача уже выполнена, а потом выяснится, что там ещё тесты дописать надо, и было бы неплохо выполнить рефакторинг кода, да и Code Review ещё не проходили.
Таким образом, пока US не достигнет состояния Ready-Ready, она не существует, и не обсуждается на планировании. Верхняя часть бэклога должна состоять только из US, с состоянием Ready-Ready. Лучший способ добиться этого, прорабатывать US вместе с командой. Это позволит взглянуть на задачу с разных сторон, вовлечь в процесс каждого члена команды, и впоследствии развить коллективную ответственность за выпускаемый функционал. Разработчики буду сами отвечать за результат и качество, если осознают, что это плод «их» совместной работы.
Когда применять DoR
Когда команда понимает во время PBR, что задача не соответствует DoR, и несет с собой слишком много неопределенности, составляйте список вопросов, выбирайте исследователя, и откладывайте задачу до следующего PBR. В моей команде, это называлось Research, но впоследствии мы перешли на Spike из XP, так как посчитали что это приносит больше результата и ясности по итогу исследования. Обязательно ограничивайте исследование по времени, и обозначьте результат, который хотите получить по итогу. Во время Spike исследователь может привлечь любую помощь со стороны, например участников других команд, методологов, PO, архитекторов… в общем любого, кого посчитает нужным. Результат — ответы на вопросы, новые данные, прототип. Если таких User Story много, в каждый спринт можно брать по 1-2 Spike, на следующие итерации, таким образом обеспечите постоянный поток Ready задач.
Как уже упоминалось выше, DoR — набор критериев. Команда может попробовать сама составить эти критерии. Проработайте те “сигналы”, которые прослеживаются в итерациях. Обсудите на ретроспективах эти моменты, найдите глубинную причину. Если нет желания тратить следующую ретроспективу на это, воспользуйтесь готовыми решениями.
Во многих статьях описывается модель INVEST, которая похожа на SMART, но более подходит для User Story. Помимо статей, данную модель так же рекомендуют и в Agile литературе. Например Роман Пихлер в книге “Управление продуктом в Scrum” или Майк Кон — “Пользовательские истории. Гибкая разработка программного обеспечения”.
INVEST модель
Заключение
В заключение: используя DoR, вы не избавитесь от пробелов, которые будут просачиваться в спринт. Так же это не означает, что во время спринта отпадает необходимость постоянного контакта PO с разработчиками. Постоянно фиксируйте результаты обсуждений в виде приемочных тестов, так никто из команды, не потеряет понимание статуса задачи. Проанализируйте и обсудите с командой текущие проблемы, возможно они связаны с отсутствием DoR.
DoR — артефакт, который позволит команде лучше продумывать US, что в конечном итоге снизит риски, и позволит побудить каждого члена команды к постоянному обсуждению задач. Много развернутой информации о INVEST, и User Story, вы найдете в книге «Пользовательские истории». Рекомендую дать прочитать эту книгу каждому члену команды, или хотя бы прочитайте сами и поделитесь с ними информацией.
Напишите в комментариях какие DoD и DoR используются у вас в команде.
DoD |Definition of Done| Критерии готовности
Definition Of Done (DoD) — критерии, определяющие степень готовности задачи.
Часто у членов команды нет общего понимания о том, что такое «готово». Это может приводить к постоянным конфликтам внутри команды и багам на продуктивной среде. Также довольно распространена ситуация, когда Владелец Продукта просит команду закончить работу быстрее. Например, ему нужно раньше конкурентов вывести продукт на рынок. Часто в такой ситуации урезается скоуп тестирования или функционал реализуется путем приделывания костылей. Такой подход ведет к накоплению технического долга.
DoD — это чек-лист, c помощью которого можно понять, что задача готова. Каждая команда имеет свои критерии готовности. Они определяются в зависимости от контекста и состава команды. Очень важно, чтобы каждый член команды полностью понимал и принимал каждый пункт в этом списке. Другими словами DoD это разновидность командного соглашения по конкретному вопросу.
Критерии готовности, которые выбрала команда, это открытая информация, доступная всем заинтересованным лицам. Их наличие обеспечивает прозрачность, как внутри команды, так и во вне по отношению ко всей организации. Со временем команда улучшает критерии готовности путем ретроспективных изменений. Уровень DoD является показателем зрелости команды.
DoD в LeSS
Если продукт развивают несколько команд, использующих LeSS-фреймворк, то критерии готовности должны быть общими. Другими словами, нужен единый Definition of Done.
Пример DoD Scrum команды
Пример DoD Kanban команды
Аналитика
Разработка
Тестирование
Definition of Ready
Кроме критериев готовности хорошей практикой считается использовать Definition of Ready или DoR. Это критерии, которые должен соблюсти заказчик, чтобы его задачу взяли в работу. Например, «к задаче должны быть написаны критерии приемки».