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. Это критерии, которые должен соблюсти заказчик, чтобы его задачу взяли в работу. Например, «к задаче должны быть написаны критерии приемки».
Словарик айтишника или Что? Где? Куда? Часть 2
Scrum-терминология
От англ. Definition of Done (дословно — критерии готовности) — список требований, по которым можно считать, что цель выполнена. Например, набор задач, которые должны быть завершены к определенной дате.
Майлстоун
От англ. milestone (дословно — веха) — запланированная дата окончания работ по выборочным задачам. Проставление таких «дат» позволяет не сбиваться с графика и отслеживать процесс работы и понимания выполнения целей.
Сторя
От англ. story (дословно — история) — корневая задача с описанием требований для разработки, она содержит в себе подзадачи, назначенные на разработчиков разных должностей. Это точка входа при разработке какого-либо функционала.
Фасилитатор
От англ. facilitator (дословно — координатор) — человек, берущий на себя обязанности ведущего. Он обеспечивает успешную коммуникацию внутри команды, пытается упростить общение и создает понимание между всеми участниками команды. Термин может использоваться и как существительное, и как прилагательное, и как глагол.
Разработка
Ассайнить
От англ. assign (дословно — поручать) — назначать задачу на человека в качестве исполнителя.
От англ. bug (дословно — жук) — ошибка в коде, проблема, недоработка. Слово уже давно в лексиконе разработчиков, но интересно то, как меняется форма термина. Калька «баг» превратилось в слово женского рода — «бага». В такой форме согласование в предложениях проще. А если ошибка или проблема совсем маленькая, то это багуля.
Грумить
От англ. groom (дословно — чистить) — приводить в порядок. Относится к коду, бэклогу, организации работы. В том же значении используется и русский аналог — «причесать».
Деплой
От англ. deploy (дословно — разворачивать) — процесс интеграции кода из разработческих веток в продуктовую (мастер) ветку. Термин также употребляется и как существительное, и как глагол, и как прилагательное.
Компилить
От англ. compile (дословно — составлять) — собирать написанный код воедино, конвертировать его из одного формата в другой, преобразовывать в требуемый вид для работы в браузере.
Костыль
Временная «подпорка» в коде, которая приводит к нужному результату, но само решение является идеологически неверным.
Лагать
От англ. lag (дословно — отставание) — плохая производительность, притормаживание, работа с ошибками.
Легаси
От англ. legacy (дословно — наследие) — код, написанный определенное время назад и считающийся морально устаревшим. Он всё ещё работает, но вызывает неприятие у разработчиков.
Мерджить
От англ. merge (дословно — слияние) — соединять свою часть работы с частями работы других разработчиков в рамках одной ветки. Сливать всё воедино.
Нативный
От англ. native (дословно — родной) — первоначально заложенное поведение или внешний вид элемента или кода.
Стоимость задачи
Пришедшее из скрама выражение, означающее суммарное количество затрат разработчика на задачу. Вопрос про стоимость задачи буквально означает оценку времени и усилий на неё. Соответственно дорого — долго и сложно, дешево — быстро и легко.
Фейлить
От англ. fail (дословно — неудача) — терпеть поражение, проваливать планы, заваливать что-либо. Чаще используется в разговорной, не технической речи.
От англ. fix (дословно — чинить) — решение проблемы, устранение бага. Термин употребляется и как существительное, и как глагол, и как прилагательное.
Должности
От англ. junior (дословно — новичок) — специалист любой должности, которая предусматривает градацию по уровню знаний. Джун находится на первой (нижней) ступеньке. Человек, знаний, которого хватает для выполнения рабочих обязанностей и разработки в целом, но не обладающий глубиной и широтой знаний.
От англ. lead, сокращенно от TeamLead (дословно — глава команды) — специалист высшей градации, обладающий широтой и глубиной знаний, является лидером команды. Он руководит процессами и помогает решать спорные технические вопросы.
Секопс
От англ. SecOps, сокращенно от Security Operations (дословно — интеграция безопасности) — специалист, занимающийся обеспечением безопасности при имплементации новых решений и безопасностью в целом.
Организационное
Апрув
От англ. approve (дословно — одобрять) — еще одна вариация для одобрения, утверждения или подтверждения чего-либо.
Валидный
От англ. valid (дословно — правильный) — в разговорной речи вариации слова означают согласие с оппонентом, одобрение его результата. Означает правильность решения. Часто заменяет слово «идет» в значении «подходит».
Инпут
От англ. input (дословно — вклад) — в разговорной речи используется в значении внимание, отклик.
Капиай
От англ. KPI, сокращенно от Key Performance Indicator (дословно — ключевой показатель результативности) — единица измерения, которая требуется для того, чтобы понять эффективность какой-либо деятельности.
Пинговать
От англ. ping (дословно — ударяться со стуком) — напоминать кому-либо о чем-либо, давать знать.
Эскалировать
От англ. escalate (дословно — обострять) — поднимать вопрос или проблему на обсуждение, привлекать внешние ресурсы, принимать меры.
И напоследок.
Райкер
От англ. wrike-er — человек, который работает в Wrike и является частью команды компании.
Как считаете, проще ли бы было новичкам, если при выходе на работу им давали расшифровку незнакомых терминов, которые обрушиваются уже в первый день работы? Дают ли ясность подобные расшифровки или только больше запутывают? Поделитесь своим мнением в комментариях.
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 не имеет.