Технологии

Определение чего?

Знаете ли вы, почему вы следуете определенному процессу?

Меня осенила реальность. Я слепо следовал процессу, не задумываясь. Зачем я это делал?

Как команда, мы сворачиваем большое количество продуктов, чтобы заменить их коммерческими пакетами с полки (COTS). SaaS и цифровая трансформация и тому подобное.

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

С точки зрения процесса, это позволяет мне довольно легко решать проблемы с Jira, поскольку наши изменения в основном небольшие и разовые.

В течение нескольких месяцев я создавал тикеты Jira, как мне казалось, довольно стандартным способом.

Я добавляю:

  • сведения о заинтересованной стороне
  • их первоначальный запрос
  • история пользователя
  • любой дополнительный контекст
  • несколько скриншотов, если применимо
  • определение сделанного

Вот он — прямо в конце маркированного списка. Определение Готово. Откуда я это взял и зачем я это туда помещаю?

Просто напомним некоторые термины:

Проблема

Главный термин для Истории, Особенности, Ошибки, Всплеска, Билета.

Определение готовности

Что должно быть в задаче, чтобы считать ее готовой к разработке?

Примеры:

  1. Будьте доработаны командой
  2. Содержать критерии приемлемости
  3. Подписаться

Определение готовности

Что нужно для того, чтобы задача считалась завершенной?

Примеры:

  1. Экспертная оценка двумя членами команды
  2. Заинтересованная сторона принимает изменения
  3. 85% покрытие юнит-тестами
  4. Критерии приемки выполнены

Критерии приемлемости

Вещи, которые добавляют ограничения, чтобы быть проблемой.

Примеры:

  1. Увеличение NPS на 2 % при покупке (прекрасный пример проверенного обучения)
  2. Номер телефона Поле ввода для использования маски ввода для конкретной страны
  3. Отчет можно скачать в формате CSV
  4. Кевин может получить доступ к экрану учета

Вернемся ко мне, когда я пишу определение готовности (DoD). Судя по резюме, я действительно писал критерии приемлемости (AC) для проблемы.

Когда я рылся в тикетах Jira, сделанных моим предшественником, я увидел, что они также использовали DoD вместо AC. Лид команды использует DoD. Итак, это кажется чем-то специфичным для нашей команды и проекта.

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

Несколько месяцев спустя...

Перенесемся на несколько месяцев вперед, и я с удовольствием использую AC — часть команды SRE придерживается DoD по своим проблемам, но это нормально. Для другой работы мне нужно прыгнуть в проект Jira другой команды и о чудо..

Там тоже используют DoD.

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

«Руководство по разработке — это центральный источник информации о том, как мы разрабатываем технологии в Omni Consumer Products. Это письменное руководство, описывающее процесс, политику, рекомендации и другую информацию, необходимую людям для создания программных и аппаратных систем «Универсальные потребительские продукты». Это руководство считается канонической позицией по любой теме».

Я заменил название организации на OCP. Если вы слишком молоды, чтобы знать об OCP, не стесняйтесь заменить его на SCP! Хотя реальная компания очень пушистая по сравнению с ней.

Справочник по разработке — замечательный ресурс, подробный, но он не охватывает что-то такое базовое, как написание тикета Jira.

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

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

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

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

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

Если люди слепы к своим повседневным делам и практикам, под капотом могут быть более серьезные проблемы, о которых люди не подозревают.

Но в данном случае мы говорим только о второстепенном моменте. Определение определения готово… все будет хорошо…