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 |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. Это критерии, которые должен соблюсти заказчик, чтобы его задачу взяли в работу. Например, «к задаче должны быть написаны критерии приемки».
Definition of Done, или кто за что отвечает
Нет ничего проще, чем ответить на вопрос: «Вы это сделали или нет?». Но гораздо сложнее добиться одинакового понимания ответа обеими сторонами: бизнесом, который ставит задачи, и самой разработкой, которая их решает.
Думаю, ни один проект не будет успешен, если не привести бизнес и технологию к общему знаменателю, и в этой связи Definition of Done выглядит одним из критически важных инструментов такого приведения.
Эта статья посвящена самому, как мне кажется, распространенному и опасному заблуждению, связанному с этим инструментом. Подавляющее большинство людей, которым я задавал вопрос «Кто определяет Definition of Done?», отвечали на первых секундах: «Клиент».
Минутка матчасти
Definition of Done — это набор критериев, которые позволяют понять, сделано ли то, что было целью разработки. Формат Definition of Done может быть любым, но чаще всего это простой список с перечнем активностей, которые должны быть успешно завершены, чтобы функционал мог считаться готовым.
Чем больше и объемнее Definition of Done, тем более строгим оно считается. И тем больше нужно времени и усилий, чтобы наш функционал добрался до желаемого состояния «сделано». И тем выше вероятность, что функционал будет работать в соответствии с ожиданиями бизнеса.
Баланс между потерями на первое и вероятностью второго — это беспощадное поле брани, на котором было сломано много копий, команд, проектов, продуктов и сервисов.
Кому это нужно
Практически ни одно событие, где общаются менеджеры проектов, скрам-мастеры и члены команд разработки не обходится без жалоб из серии «нам не дают достаточного количества времени на полноценное тестирование». При этом в качестве сил зла обычно выступает сам клиент, его представитель или владелец продукта, а в качестве причины фигурируют, главным образом, замедление процесса разработки и отсутствие заметной невооруженным глазом бизнес-ценности для продукта или сервиса.
Конкретный способ управления разработкой, будь то эволюционировавший до некоего итеративного гибрида Waterfall или же чистый, как слеза, Scrum, при этом никакой роли не играет. Как, впрочем, и бизнес-модель компании-разработчика. Хоть внутренний продукт, хоть наружный, хоть мы продали клиенту дюжину тушек — конечная цель разработки одна и та же: производство программного обеспечения, которое работает и кому-то для чего-то нужно.
Сферический конь в вакууме
Возьмем простой сценарий, где у нас есть условный Клиент, который знает, какой именно Продукт нужно произвести и запустить, и Команда, которая знает, как он, Продукт, создается.
Для начала, чтобы предвосхитить возможные упреки со стороны разработки, то есть от Команды к Клиенту, напомню, что единственное, в чем обязан разбираться Клиент — это предметная область, то есть бизнес. Да, было бы неплохо, чтобы Клиент понимал, что код не растет на дереве, а тестирование — это не хаотичная активность приматов на этом же дереве, но, строго говоря, это не обязательно.
С другой стороны, единственное, в чем должна разбираться Команда — это разработка программного обеспечения. Опять же, было бы неплохо, чтобы Команда видела бизнес-цель за набором смешных цветных объектов в трекинговой системе, но ремарка та же, что и в предыдущем абзаце.
В сухом остатке у нас есть человек, который знает или думает, что знает, ЧТО делать, и не обязан знать КАК, и есть группа людей с горящими глазами, которая знает КАК, но пока не знает, ЧТО именно.
Ближе к делу
С учетом вышеизложенного, весь процесс коммуникаций по ходу разработки представляет собой, с одной стороны, трансляцию Клиентом Команде бизнес-требований, а с другой — трансляцию Командой Клиенту необходимых для реализации сроков и текущего статуса разработки этих самых требований.
Обратите внимание, Клиент не ориентируется в 50 оттенках серого от «уже сделал локально» и «залил в dev, но еще не проверили» до «прошли все тесты на stage». Не ориентируется совсем и воспринимает фразу «Функционал готов» самым буквальным образом — готов быть залитым в живой production.
Соответственно, все остальные типы «готовности» для него с точки зрения бизнеса никакого смысла не имеют. Он мог, опираясь на оценки Команды, сжечь на костре маркетинга несколько десятков или сот тысяч долларов в процессе подготовки к запуску на определенную дату. И Falcon Heavy, который собран и красиво возвышается на платформе, но не может взлететь, Клиента, скорее всего, не устроит.
Поэтому Команде, мне кажется, было бы логично, давая определенные оценки по времени, иметь в виду именно этот тип готовности функционала. А для этого набор действий Команды по производству Продукта (или его инкремента), должен включать все виды активностей, необходимых для того, чтобы быть уверенными в качестве и работоспособности функционала.
Необходимых с чьей точки зрения?
Вот мы и подобрались к главному вопросу, на который значительная часть Команд отвечает неправильно. Прямо или косвенно спрашивает разрешения на включение в оценку по времени, к примеру, код ревью или юнит-тестов. Или другими словами, просит Клиента участвовать в формировании содержания Definition of Done.
Клиента! Но ведь Клиент — единственное причастное к разработке Продукта лицо, которое не знает, как разрабатывается программное обеспечение! Зачем у него спрашивать, и уж тем более, зачем у него спрашивать разрешения правильно делать работу Команды? В этом нет никакого бизнеса, это технология!
Естественно, не менее абсурдно выглядят и попытки Клиента ускорить разработку за счет «выставки народной резни» по качеству вообще и Definition of Done в частности: «А без юнит-тестов?», «А зачем мы тратим время на ревью?», «Зачем документация по API?», «Не рассказывайте сказки, я сам в 1812 году работал с перфокартами» и так далее.
Представьте, что к каменщику, которого наняли строить и который между рядами кирпичей кладет или ложит раствор, подходит Заказчик и говорит: «Слушай, мужик, зачем ты тратишь свое время и мои деньги на это месиво? Нельзя просто положить кирпич на кирпич, а раствора туда иногда для запаха между каждым десятым и каждым одиннадцатым рядом?!»
Представили? Выглядит просто сказочно. Конечно, все аналогии лживы по своей природе, но в чем принципиальная разница между этим примером и нашим случаем? И там, и там, Человек-ЧТО влазил и рассказывал Человеку-КАК — как тому делать его работу. Каменщик ведь не пытался построить оперный театр вместо дельфинария, он просто соблюдал технологию процесса. Не более того.
Кто виноват и что делать
Во-первых, Definition of Done должно быть. Причем даже если Команда не одна, а N, оно должно быть одно на всех.
Потому что если ваш цех по производству Kotlin-пасочек станет хронически обгонять цех RxSwift-пасочек по причине отсутствующего или гораздо менее строгого Definition of Done, мобильная разработка рискует превратиться в храм боли. Боли при общении с Клиентом.
При этом, естественно, усилия QA команды получат ярко выраженный Android-вектор, и это направление будет тормозить запуск всего Продукта в целом.
Позволю себе привести формулу для расчета количества Definition of Done в зависимости от количества команд:
NDoD = 1 NT
где NDoD — количество Definition of Done,
NT — количество Команд
Во-вторых, Definition of Done должно быть четко сформулировано и понятно всем причастным, включая Клиента. Но его источником должна быть технология, а не бизнес. Соответственно, если Команда хочет увидеть силы, которые не выделяют достаточного количества времени на тестирование, ей нужно посмотреть в зеркало.
После титров
И в завершение позволю себе пару небольших ремарок.
Да, есть определенная (и крайне незначительная) часть проектов, где единственное, что имеет значение — это время, даже в ущерб качеству. Но это исключение, которое подтверждает правило.
И нет, я не считаю, что это легко — не позволять Клиенту диктовать Definition of Done. Это трудно. Но если мы считаем себя профессионалами, подход должен быть профессиональным.
Наконец, все вышеизложенное — всего лишь личная субъективная точка зрения (других у меня нет). Надеюсь, вы сможете извлечь из этого материала что-то полезное.
Спасибо, буду крайне признателен за комментарии.
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.
В избранное В избранном 2
Похожие статьи
ІТ платить мало податків? Подкаст DOU #23
50 комментариев
Я всегда был за то, чтобы проговаривать ожидания. Много лечит. Хорошая дифференциация. Есть шанс свести к единому мнению бизнес и разработку.
Представим себе на минутку обычную компанию, в которой нет дихотомии клиент/исполнитель. Компания сама себе заказчик, нет никакого аутсорсингового сетапа, АГМ не генерирует релевантных решений. Даже в такой ситуации DoD наверное имеет смысл. Но почему?
Посмотрим на выводы, только уберем из них АГМ:
Потому что если ваш отдел андроид-разрабортки станет хронически обгонять отдел ios-разработки по причине отсутствующего или гораздо менее строгого Definition of Done, мобильная разработка рискует превратиться в храм боли. Боли при общении внутри компании.
Что ж, действительно, если есть два отдела, которые работают «наперегонки» — будет крайне сложно удерживать их версии и релизы синхронными, однако DoD тут вообще не при чем, причин — миллион. И в качестве регулятора скорости разработки DoD тоже так себе. Куда как проще синхронизировать планивания или количество условных человеколюдей.
Ну а если в коммуникациях у вас боль — то в продукте, согласно закону Конвея, конечно отразится и в продукте. Но только можно ли поправить плохие коммуникации с помощью DoD?
Но его источником должна быть технология, а не бизнес. Соответственно, если Команда хочет увидеть силы, которые не выделяют достаточного количества времени на тестирование, ей нужно посмотреть в зеркало.
Почему бы это, интересно, именно теки должен бы это делать? Если убрать на секунду АГМ, и тот факт, что автор — теки, что же останется?
Представьте, что к программисту, которого наняли программировать и который после всякой строки кода пишет комментарии, подходит менеджер и говорит: «Слушай, мужик, зачем ты тратишь свое время и мои деньги на это месиво? Нельзя просто писать строку за строкой кода, а каментить уже целые методы или функции? Зачем рассусоливать, нам это через полгода переписывать»
Выглядит сказочно, но на всяк товар свой купец, и есть разные бизнес-ситуации, требующие разного подхода. Но нет — теки знает, как на самом надо бизнесу, и поэтому должен диктовать DoD?
Вот это деление на Человека-Что и Человека-Как — оно же течет прямо из АГМ, в нем все слезы аутсорсинга — и ущемленная самооценка, и неумение договариваться, и неравноправие в партнерстве. А убери отношения клиент/исполнитель — и зачем тебе DoD?
Что есть АГМ? Быстрый гуглёж не выдаёт ничего релевантного
Рискну предположить, что это Annual General Meeting (AGM)
Начал подозревать, что на самом деле это значит «аутсорс головного мозга» 🙂
Кто знает. Автор поста видимо решил сохранить интригу.
Не согласен. Правда, я поддержал Dmytro Lapshyn в вопросе о АГМ. На даже не зная, что имелось ввиду, деление на Человека КАК и ЧТО — оно не искусственное, это физика процесса. Есть человек из бизнеса, и есть команда, которая в бизнесе не разбирается. Она разбирается в производстве программного обеспечения.
Зачем мне DoD? Затем, что мы должны договориться до одинакового понимания одинаковых вещей. Какая разница, с какой стороны Продакт овнер? Конечно, бизнес-ситуации разные и продукты разные, но как это влияет на то, что технология должна быть ясна и ее надо придерживаться?
Есть человек из бизнеса, и есть команда, которая в бизнесе не разбирается.
Это чудесный мир картонных чучелок, где ты или туда или обратно и все (относительно) просто.
Давай предположим, что человек из бизнеса строит не первый бизнес. В каждом из них он занимался именно бизнес-частью, но успел столкнуться с: несколькими неудачными СТО, многократно невыдержанными сроками разработки, лекциями о сложности и непредсказуемости мира ИТ и нечеткой природы оценок, сорванными контрактами и поставками, перегруженным колл-центром после релиза недотестированой версии. Один его бизнес был энтерпрайзным, би-ту-би-шным, с тяжелыми многолетними контраткми с неустойками, другой — стартапом в другой области, с быстрыми итерациями и тестированием на живых пользователях.
Можно ли сказать, что он совсем уж не разбирается в производстве программного обеспечения?
Ты готов встать между ними с плакатом «Источником DoD должна быть технология, а не бизнес» и выдать им нарукавные повязки «ЧТО» и «КАК»? Или, возможно, двум интеллигентным людям с разносторонним опытом есть о чем поговорить на равных и прийти к понятному и прозрачному взаимному соглашению?
Затем, что мы должны договориться до одинакового понимания одинаковых вещей.
Золотые слова! Но почему же одинаковое понимание вещей всенепременно должно проистекать от технокоманды?
Забавно. Я о вашем первом посте. Вы корректируете цитаты из статьи, добавляете туда свои выводы (нужен DoD кому-то или нет), но подаете все еще как цитату из статьи. И потом это комментируете и выводите «автора» на чистую воду. Не уверен, что вам вообще нужен оппонент для дискуссии, вы пока справляетесь и сами.
1. Я так понимаю, ваш условный человек из бизнеса так много сталкивался с айти-проектами, попадал на неустойки и сталкивался с сорванными поставками, что технологию разработки знает лучше, чем профессиональная команда, которую он сам для разработки своего продукта нанял. Верно?
2. А условный программист писал так много непокрытого тестами кода и так мало рефакторил, что начал разбираться в бизнесе? И видел так много смертей от регрессии, что не удосужился объяснить, зачем нужно соблюдать технологию. Причем сам он тестов он не писал, получается, из-за рукожопости менеджмента. Все так?
3. Я не готов стать плакатом. Но этого и не требуется. Я готов работать в рамках своей зоны ответственности, НЕ определять бизнес-цели, но и НЕ позволять деформировать технологию человеку, который в ней НЕ разбирается. А еще я готов объяснять клиенту свой подход в области качества, а не жаловаться, как все ничего не понимают, не говорят по-английски, меняют требования и так далее.
4. Снова подмена понятий. Я не писал, что понимание ВСЕХ вещей должно исходить от Команды. Только той части, которая касается чистой технологии. И статья посвящена именно этому.
Тем не менее, хотел бы поблагодарить вас за вышеприведенные гипотетические примеры, потому что, боюсь, проблемы, которые вы в них озвучили, вполне типичны для всей сферы. И случись оба примера в одной реальной компании, это стало бы настоящей находкой для человека, который бы решился перестроить ее внутренние процессы.
Там много всего: и проблемы в работе с клиентом и его ожиданиями, и управление скоупом и его изменениями, и работа с оценками, и качество менеджемента. В общем, на эти темы можно написать еще не один десяток статей.
Я считаю DoD отличным инструментом и значимым артефактом agile разработки. Той самой agile разработки, четверть манифеста которой заключается в принципе:
Customer collaboration over contract negotiation
И DoD, что характерно, является именно что разновидностью contract. И хотя коллаборация с клиентом намного важнее этого контракта — он все же есть в методологии, и польза его не вызывает сомнений. Мне кажется, это именно потому, что соглашение по поводу базовых терминов является основой здоровой customer collaboration. Чтобы фраза «it’s done» не вызывала в будущем боли несоответствия ожиданиям, а вызывала приятную улыбку взаимопонимания. И мне кажется, что это важный момент в понимании смысла и назначения DoD. Потому что тут может случайно произойти подмена. И, кажется, происходит.
Есть такая штука — профессиональные деформации. Психологические паттерны, связанные с определенной работой. Работа в аутсорсинге тоже обладает своими характерными особенностями, с которыми приходится сталкиваться. И у тех, кто достаточно долго работал в аутсорсинге (а то и вообще всегда) может сложиться впечатление, что вся разработка софта — она вот такая, как в аутсорсинге, ну плюс-минус. Когда такие люди рассуждают о разработке вообще, не в контексте аутсорсинга — это хорошо слышно, потому что они проецируют свой аутсорсинговый опыт на видение разработки в целом. Я называю это Аутсорсинг Головного Мозга.
И вот перед нами такая статья — о разработке вообще, о Definition Of Done — концепции, никак не связанной с аутсорсингом, не имеющей никаких аутсорсинговых коннотаций. Тем не менее, из стати хорошо слышно, что автор вовсе не практикует и не собирается практиковать customer collaboration! Более того, старается его минимизировать, и как раз считает, что DoD — это путь к минимизации коммуникаций (еще бы, она названа Болью в статье!).
Так вот, мне кажется, что статья практически полностью про АГМ на примере DoD.
Какие маркеры говорят от этом? Это, конечно, «Клиент» и «Заказчик», красной линией проходящие через статью. В разработке софта вообще есть, конечно, разные стейкхолдеры, и налаживание отношений между ними — сложное и важное дело, но именно в аутсорсинге (и другой сервисной разработке) эти роли так сильно акцентированы: ведь две компании пытаются работать вместе при совершенно разной парадигме бизнесов. Тут и продажи, и формирование ожиданий и контракт и приемка и все остальное — целое ремесло по работе с клиентом, которого. совсем нет в компании, которая сама себе разрабатывает. И Боль вокруг Клиента — это следствие аутсорсинга в куда большей степени, чем необходимости четкой работы стейкхолдеров в разработке вообще.
Но самое ужасное, что по многим фразам становится ясно, что никто не умеет в customer collaboration!
Например:
— код написан;
— юнит-тесты написаны и успешно выполнены;
— код прошел ревью;
— документация обновлена;
— функциональное тестирование успешно завершено;
— регрессионное тестирование успешно завершено.
Чем больше и объемнее Definition of Done, тем более строгим оно считается. И тем больше нужно времени и усилий, чтобы наш функционал добрался до желаемого состояния «сделано». И тем выше вероятность, что функционал будет работать в соответствии с ожиданиями бизнеса.
Это же ужасно. Посмотрите на предлагаемое DoD — в нем нет ничего, что можно трактовать как ожидание бизнеса. Разве бизнес хоть капельку волнует, был ли код ревью? Тут все меры — про минимизацию багов (и это тоже характерная фиксация аутсорсинга, кстати). При этом то, что бизнес могло бы волновать — тут начисто отсутствует: где «можно пощупать на стейджинге» или «выкачено на продакшн»? Покажите мне бизнес, который не волнуют эти вещи в критерии «готовности»?
Почему так? Да потому что АГМ, и никто не хочет думать и говорить о проблемах кастомера. Почему я так думаю? А вот:
В сухом остатке у нас есть человек, который знает или думает, что знает, ЧТО делать, и не обязан знать КАК, и есть группа людей с горящими глазами, которая знает КАК, но пока не знает, ЧТО именно.
Разве это выглядит как призыв к customer collaboration? Да это прямо противоположная движуха — мы к тебе не лезем и ты к нам не приставай. Может, показалось?
С учетом вышеизложенного, весь процесс коммуникаций по ходу разработки представляет собой, с одной стороны, трансляцию Клиентом Команде бизнес-требований, а с другой — трансляцию Командой Клиенту необходимых для реализации сроков и текущего статуса разработки этих самых требований.
В этом месте каждый уважающий себя адепт аджайла должен встать, махом перевернуть стол и крикнуть «bullshit!» — потому что это прямо противоположно принципу customer collaboration over contract negotiations.
Вот примерно из этих соображений я пытаюсь аккуратно намекнуть — а что, если бы уберем аутсорсинг из этой статьи — что мы получим? Каков будет ответ на заглавный вопрос? Зачем нужен DoD если нет Клиента/Заказчика, а работа идет внутри одного коллектива? И окажется, что единственная фраза в статье, начинающаяся с «потому что. » это
Потому что если ваш цех по производству Kotlin-пасочек станет хронически обгонять цех RxSwift-пасочек по причине отсутствующего или гораздо менее строгого Definition of Done, мобильная разработка рискует превратиться в храм боли. Боли при общении с Клиентом.
И это слабенькое понимание роли DoD — зато сильный знак огромной проблемы в общении с Клиентом. Ну и попытка решить ее с помощью всех доступных средств, годных или нет.
Знаете, какой еще характерный маркер АГМ?
В сухом остатке у нас есть человек, который знает или думает, что знает, ЧТО делать, и не обязан знать КАК, и есть группа людей с горящими глазами, которая знает КАК, но пока не знает, ЧТО именно.
Аутсорсинг так яростно продает «экспертизу, комплиментарную вашему пониманию бизнеса», что и сам в это верит — что мир устроен по принципу чистых функций и должностных инструкций, и их можно докупать и совмещать как ликвидные универсальные ресурсы. А это только защитный механизм в аутсорсинге, и ничего общего с customer collaboration не имеет.