Что такое definition of done

Модель Кано (Kano Model)

Модель позволяет классифицировать функциональные требования к продукту на основании их ценности для клиентов.
Модель разделяет все такие требования на пять категорий:

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

Источник

Продуктовый подход — польза и для бизнеса, и для разработчика

Я продуктовый разработчик, но так было не всегда. Лет 5 назад я впервые услышал фразу «продуктовая разработка», но я тогда не совсем понимал, что это значит. Мне говорят — вот у нас продукт, ну а я пишу код и пишу, чего такого-то. Есть ТЗ — и славно, нет ТЗ — как говорится, и результат будет ХЗ

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

Потом что-то поменялось в моей работе — ТЗ не стало. Это такой следующий шажок. Вот мы в продукте работаем, а теперь у нас еще и ТЗ нет. И что делать? Началось осознание того, что происходит.

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

Приходит к нам бизнес и говорит — давайте экономить. Конкретно на SMS и на платежной форме. Мы соглашаемся. У нас так вышло, что в тот момент наша команда знала продукт лучше, чем владелец продукта, так бывает. Мы знали особенные кейсы, мы знали, что мы где-то лишних SMS немного тратим. А значит, примерно знали, где можно что поделать.

Так что мы взяли спринт на анализ, и за этот спринт мы не написали ни строчки кода. Вообще.

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

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

Примеры задач

Например, вот задачка совсем простая. Есть пользователи, которые в настройках поставили галочку «логиниться только по паролю». А мы им зачем-то предлагаем логиниться по SMS. И они зачем-то эти SMS отправляют. Потом они вводят SMS, а потом они еще вводят пароль, хотя SMS можно было не вводить вообще. И пофиксить этот сценарий — это просто, что мы первым делом и сделали.

А вот посложнее задачка — перевести все SMS на пуши. Задачка достаточно грандиозная, у нас до сих пор идут работы, чтобы зафиналить этот перевод, потому что там много рефакторингов было, и мы написали много новых микросервисов и новые хранилки.

Вот мы написали роадмап, декомпозировали его, прикинули, составили план для каждой задачки, стали делать. Планомерно каждый спринт делали какую-то задачку, которая часть SMS срубала. И смотрели в реалтайме прямо на график, как меняется количество SMS. Мы видели, что продукт экономит. Прямо на глазах. Экономит — значит зарабатывает. Вот я смотрю на график и понимаю, что мы окупились в этот же спринт. Это очень круто по бизнес-эффекту. И понимаю, что мы как команда полезные. Мы окупаемся.

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

Плюсы подхода

У этого подхода (когда разработчика пускают на ранний этап) есть несколько плюсов и для бизнеса, и для самих разработчиков.

Я начну с плюса для бизнеса. Разработчик может предложить решение по принципу Парето. То есть за 20% времени можно сделать 80% бизнес-эффекта, и бизнесу это в большинстве случаев ОК. Можно на раннем этапе привлечь разработчика и ограничить какое-то количество функциональности, чтобы сделать ни больше и ни меньше.

Разработчик, допустим, такой вот грамотный парень, бизнес-ориентированный, который понимает, зачем, что, как внутри рефакторить, он может предложить такой рефакторинг, который откроет портал в инженерный рай и оттуда начнут сыпаться фичи. Сами.

То есть не просто там кодить какие-то технически упоротые вещи, а именно сделать рефакторинг ради бизнеса. Ну мы так открыли портал в инженерный рай и оттуда насыпалось на форму оплаты несколько новых фич. Среди них — новый способ оплаты, да еще и пару багов пофиксили одним рефакторингом.

А ещё разработчик может на раннем этапе оценить стоимость разработки задачи. Понятно, что если это какая-то нереальная вещь, у нее сомнительный бизнес-эффект, ее можно дальше не прорабатывать и не собирать для нее какие-то бизнес-требования, а просто отложить и пойти дальше, что-то более приоритетное взять.

Разработчик, у которого есть знание доменной области и знание SQL, может посчитать количество SMS, которые отправляются в месяц по какому-то сценарию. И исходя из этого количества SMS можно понять, сколько денег эта задача принесет. То есть бизнес-эффект тоже можно оценивать с помощью разработчика. Причём для этого не нужен какой-то отдельный аналитик. Понятно, что разработчик это сделает с какой-то погрешностью, но все-таки это возможно.

Обычно у фронтендеров такой майндсет и такая насмотренность, что они могут набросать макет. А если этот человек в офисе, то он может этот макет людям показывать и проводить коридорное тестирование. Тоже плюс.

Самый главный пункт, на мой взгляд, это когда мы в команде задачу сами придумали, когда мы ее сами декомпозировали, предоценили, потом мы ее взяли делать, потом мы ее довели до продакшена и еще собрали постоценку (в идеале). Тут есть ощущение, что вот это моя фича, это наша задача, она становится частичкой нас. И отсюда большая мотивация, чтобы задачу протащить через все этапы, чтобы везде ее сопроводить, и в конце концов понять — была ли твоя работа полезной.

Отсюда следует первый плюс для разработчика — это дополнительная мотивация. Как я и сказал, когда я задачу прорабатываю, я с ней сближаюсь и хочу ее делать. И другие задачи я тоже хочу делать. Это работает сильнее, чем зарплаты и прочее. Вот просто хотеть делать задачи, чтобы чувствовать себя полезным.

Следующее — это прокачка скиллов. И хард-скиллы типа SQL, и софт-скиллы. Некоторым разработчикам сложно выйти из команды, чтобы пойти куда-то там наружу с другой командой договариваться. И вот это очень хороший толчок к развитию этого навыка.

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

Следующий пункт — нетворкинг. Когда человек идет из команды с кем-то общаться — с инфобезопасниками, с юристами, еще кем-то внешним — он приходит к людям, знакомится с ними. И в следующий раз, когда он к ним приходит, они знают, зачем он пришел и что ему надо, и многие вопросы решаются гораздо легче.

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

И последний пункт. Просто нравится. Попробуйте, может, вам тоже понравится.

Но есть нюансы

Мы в команде начинаем с того, что придумываем, а заканчиваем тем, что выкатываем в прод. А это же новые зоны ответственности, мы их раньше не брали на себя, и надо сделать это более качественно.И я тут не только про отсутствие багов, а больше про качественную предоценку и подготовку задач. У нас для того, чтобы сделать качественно, есть инструменты.

По сути, это чеклисты. Я рекомендую эти инструменты, даже если у вас не скрам, не аджайл, если вы вот это все ненавидите. Инструменты скрамовские, но вы можете их применять, даже если у вас вотерфолл — они просто помогут. Это не какие-то ограничители, это шпаргалки.

Вот есть шпаргалка для проработки задачи. Definition of Ready for sprint. Этот чеклист мы писали сами.

Это шпаргалка, но это не барьер. Мы можем на него посмотреть и подумать, что по задачке можно еще поделать предварительно, чтобы ее успеть в спринте. Но если владелец продукта говорит — надо, мы соглашаемся, мы ее возьмем, но мы ни на что не коммитимся.

То есть с большой вероятностью там вскроется какая-то неизвестность в спринте, которая нас затормозит, и мы что-то не сможем. Увы, такое бывает. Но не барьер, это важно.

А вот Definition of done — это барьер. Что такое Definition of done?

Бывает же, что программист говорит: — Я сделал.
А у него спрашивают: — Что ты сделал?
Отвечает: — Я код написал.

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

DoD — чеклист, который позволяет договориться, когда говорить “Сделано” по задаче. Про DoD я сказал, что это барьер. Почему барьер? Потому что мы договорились с бизнесом, что мы продукт поддерживаем вот на таком уровне качества, не ниже. Этот чеклист — он про фиксацию уровня качества. Не Definition of Done команды, не Definition of Done компонента, а Definition of Done всего продукта.

И если мы что-то по Definition of Done, не успели за спринт сделать — печальная ситуация, но бывает. То мы берем эту несделанную работу и кладем ее в бэклог. И продакту нужно понимать, что есть некоторая несделанная работа, техдолг. Что ее придется потом когда-то сделать. А если ее не делать, она нас в будущем затормозит.

Мы все делаем сами. И чеклисты мы сами составляли, и процессы мы можем сами двигать как-то, если видим потребности, мы сами прорабатываем задачу, мы сами катим ее в продакшн, мы сами собираем постоценку.

Через это мы получаем некоторые профиты. Пять лет назад я не особо задумывался, пишу код и пишу. Это когда ты приходишь, в 9 утра начинаешь писать код, в 6 вечера можешь закончить и уйти домой.

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

На ментальное здоровье, на физическое здоровье, на отношение с близкими. Мы на работе проводим 80% времени. И очень важно то, как мы на работе кайфуем.

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

Если вам интересен взгляд на продуктовую разработку изнутри — подписывайтесь на мой TG-канал «Product Developer».

Источник

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 #24

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 не имеет.

Посмотрите на предлагаемое DoD — в нем нет ничего, что можно трактовать как ожидание бизнеса.

И это ожидаемо, потому что DoD вообще не является инструментом управления ожиданиями бизнеса. Это не более, чем внутренний чеклист команды, позволяющий убедиться, что принятный на проекте техпроцесс соблюдён.

А для ожиданий бизнеса есть совершенно другой, специально предназначенный для этого инструмент — критерии приёмки.

Но нет — теки знает, как на самом надо бизнесу, и поэтому должен диктовать DoD?

DoD — это вопрос из серии как надо делать, а не что нужно бизнесу. Поэтому да, предлагать его должны девелоперы, а бизнес уже решает, устраивает ли их такое соотношение цена/качество. Аналогия с кирпичами вполне уместна, как и аналогия с любым другим технологическим производством.

Источник