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. Это трудно. Но если мы считаем себя профессионалами, подход должен быть профессиональным.

Наконец, все вышеизложенное — всего лишь личная субъективная точка зрения (других у меня нет). Надеюсь, вы сможете извлечь из этого материала что-то полезное.

Спасибо, буду крайне признателен за комментарии.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному4
LinkedIn



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 — это вопрос из серии как надо делать, а не что нужно бизнесу. Поэтому да, предлагать его должны девелоперы, а бизнес уже решает, устраивает ли их такое соотношение цена/качество. Аналогия с кирпичами вполне уместна, как и аналогия с любым другим технологическим производством.

DoD — это вопрос из серии как надо делать

Как надо кому?

Или, простите, есть «как надо» одно на всех годное?

есть «как надо» одно на всех годное?

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

Нет, вру — есть ещё один крайний случай — всякого рода life-critical системы.

Так что — есть всего, стало быть, три подхода —
— херак-херак и в продакшен
— сколько-нибудь долгую поддержку и развитие решения
— всякого рода life-critical системы

А чего ж методологий разработки в десять раз больше, если всего-то три типа проектов с понятными «как надо»?

А чего ж методологий разработки в десять раз больше, если всего-то три типа проектов с понятными «как надо»?

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

Простите, а с чего вдруг бизнес должен решать, нужны ли какие-то там юнит тесты или нет? Для большинства кейсов в индустрии разработки ПО уже давно выработаны best practice, которые и есть

«как надо» одно на всех годное

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

Да что это за мифические best practices выработанные для большинства кейсов? Которые еще и не требуют мнения заказчика? Ссылку? А то пацаны-то и не знают, бьются за что-то, новые подходы пробуют, экспериментируют зачем-то.

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

Ну, если нужна была еще одна иллюстрация про АГМ и как не делать customer collaboration — то вот она.

Да что это за мифические best practices выработанные для большинства кейсов?

Например, господин Capers Jones уже не первый год собирает статистику по индустрии по этому вопросу. Там всё с цифрами вплоть до ROI.

Например:
Exceeding 99% in Defect Removal Efficiency (DRE) for Software
Software defect origins and removal methods

мифические

OMG, я даже комментировать это не хочу.

новые подходы пробуют, экспериментируют зачем-то

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

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

Когда вы спрашиваете «Кто определяет Definition of Done?», от вас слышат «Кто принимает итоговое решение на проекте?», и отвечают правильно на незаданный вопрос: «Клиент».

Мы же должны сделать клиента счастливым, не?!

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

Так все же, этот самый «расширенный DoD» — должен быть в области видимости клиента, или нет? Если да, то зачем? Если нет, то о чем статья? :)

Думаю, да. Это показывает подход команды в области качества, борьба за которое начинается не с QA, а с разработчика. То есть, качество является встроенным, это не что-то второстепенное сбоку. Мы начинаем о нем думать с самого начала.

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

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

Имея видимый для клиента DoD это построение прозрачных отношений и не более. При возникновении узких мест или же снижении пропускной способности мы показываем клиенту, что у нас есть проблема и мы ее решаем, так как качество готового инкримента у команды стоит на первом месте. Таким образом клиент видит, что команда работает над решением проблемы, а не сидит и ничего не делает, и клиенту уже проще принять риск и как вариант предложить команде свою помощь по его решению, но и не более. А влезание с изменениями в установленные командой правила разработки может привести большим факапам на проекте. Если у команды есть свои прописанные уставом DoD, то стоит об этом сказать клиенту в самом начале разработки. А уже если клиент захочет вставить туда своих 5 копеек, то нужно с ним договориться и принять общее решение.

Зачем скрывать от заказчика свои преимущества? Наличие ДоД и следование бест практисам — это же ваше преимущество, зачем его скрывать? С другой стороны это помогает объяснить клиенту почему херак, херак и в продакшен, как правило, не вариант для вас, ведь такой эдхок подход противоречит ДоДу, а значит качеству, то есть ставит под сомнение достижение выгоды для клиента.

А кто говорит про скрывать? Если клиента не расстраивают, как Винни-Пуха, длинные слова, всегда лучше донести до него наш подход. И показать, что мы занимаемся качеством системно.

Ну это я, типо, с Вами как раз соглашался... :)

привіт. допоможіть, будь ласка, розібратися у кейсі конкретно для себе:

є скоуп задач, які ми віддаємо у одному релізі, це і фікс багів, виявлених кастомером, і делівері нових фіч, все типово. всі таски перед релізом потестовано і у джирі помарковано, власне, як fixed/ done/ resolved.
але є одна задача, яку вирішено не робити, це узгоджено девелоперами і бізнесом, сторона клієнта погодилася, що це мінорна зміна, на яку просто немає сенсу вбивати купу часу.
ми закриваємо її як resolved, в коментарях джири лишаються прикріплені імейл обговорення і вказано про no dev.

Питання: з вашого досвіду, чи етично переводити таску у статус resolved?

Привіт, у нас такі задачі переводять у статус ’Removed’ (в ТФС)

Справа, напевно, не у етичності, а в тому, як у подальшому відрізнити resolved/cancelled від resolved/done — для цілей support/performance analysis/accounting/whatever? І ще у питанні, чи не варто цю задачу de-prioritize щоби у подальшому зробити «безкоштовно», чи ще якось?

common practice на проекті — мільйон коментарів у джирі і атач всіх дотичних документів/ переписок.
себто, якщо приходить нова людина на моє місце і дивиться на тікет одним оком — бачить те, що він просто готовий, аби розібратися точніше — реально треба перевіряти коментарі. таким чином resolved/cancelled уточнюється лише при детальнішому аналізі

Мені здається, що термін «етично» (для кого?) не дуже коректний при оптимізації процесів. Тут інші фактори: а) чи визначили ви всі потенційні проблеми зараз/в майбутньому, пов’язані із існуючим процессом, б) наскільки ці проблеми для вас важливі(дорогі), в) наскільки дорого/дешево буде змінити процесс на більш оптимальний і (важливо! ) дотримуватись його. Іноді процес оцінки і обговорення всіх цих факторів обходиться дорожче, ніж просто використання усталених практик — про які вже всі написали, що використовують окремий статус

Ставьте статус won’t fix

Правильней ставить Rejected или Won’t Fix.

етично переводити таску у статус resolved?

10 раз «отче наш» и ваш грех прощен

Не думаю, что ставить resolve статус rejected функционалу — это хорошая идея. Уберите ее в беклог или поставьте статус, которые показывает именно отмену.

это набор критериев, которые позволяют понять, сделано ли то, что было целью разработки.

не „сделано”, а „готово”. Сделано или нет определяют acceptance criteria. Ибо в „готовность” вы включаете все полезные вам приемы — тестирование, ревью, разработка и т.п. Но „сделано” ли это — решит как раз клиент.

Подозреваю, что это — издержки перевода:

DoD is a checklist of valuable activities required to produce software. ©

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. ©

Полностью согласен. Только клиент решает сделан функционал или же нет. Ему в этом могут помочь acceptance criteria, что в свою очередь он должен подписать их кровью перед началом разработки. Я до этого никогда не слышал чтоб DoD был пропушен самим клиентом. Все правила DoD решает команда и на каждый этап разработки он может быть свой.

Я ничего не писал об Acceptance criteria. Это часть требований, которая, по сути, содержит ожидаемую бизнес-ценность функционала. И это как раз не технология, а чистый бизнес. То есть, это тоже ЧТО, а не КАК. К примеру, если у вас стори на разработку модуля оплаты (извините за совершенно заезженный кейс), то Acceptance criteria будет, скажем, успешная оплата картами Visa и Mastercard. Но там ничего нет о том, КАК вы собираетесь проверять этот модуль, какие тесты и другие активности для этого нужны.
Мой акцент был на технологии процесса, а не его бизнес-составляющей, в первую очередь потому, что на практике бизнес очень часто пытается вмешиваться в технологию.

Я и не говорил, что было что-то об acceptance criteria. Я говорил о том, что определение, использованное в статье, неверное — должно быть не «сделано», а «готово». Иначе — у вас определение аксептанс критериев для ДоД.

В русском языке между сделано и готово нет никакой разницы. Да, в Scrum принято дифференцировать done и ready, но меня интересовало общее понимание проблемы, а не терминология Scrum.

Я не понял, причем тут Scrum, если я говорил пока о common sense. Общее понимание логически неверно, только и всего. Но я не навязываюсь, что хотел, уже узнал.

Підписатись на коментарі