Технологии
Определение чего?
Знаете ли вы, почему вы следуете определенному процессу?
Меня осенила реальность. Я слепо следовал процессу, не задумываясь. Зачем я это делал?
Как команда, мы сворачиваем большое количество продуктов, чтобы заменить их коммерческими пакетами с полки (COTS). SaaS и цифровая трансформация и тому подобное.
В настоящее время я являюсь владельцем продукта, и моя основная роль заключается в обеспечении того, чтобы мы ограничивали наши функции тем, что соответствует стратегическому видению замены всех наших систем.
С точки зрения процесса, это позволяет мне довольно легко решать проблемы с Jira, поскольку наши изменения в основном небольшие и разовые.
В течение нескольких месяцев я создавал тикеты Jira, как мне казалось, довольно стандартным способом.
Я добавляю:
- сведения о заинтересованной стороне
- их первоначальный запрос
- история пользователя
- любой дополнительный контекст
- несколько скриншотов, если применимо
- определение сделанного
Вот он — прямо в конце маркированного списка. Определение Готово. Откуда я это взял и зачем я это туда помещаю?
Просто напомним некоторые термины:
Проблема
Главный термин для Истории, Особенности, Ошибки, Всплеска, Билета.
Определение готовности
Что должно быть в задаче, чтобы считать ее готовой к разработке?
Примеры:
- Будьте доработаны командой
- Содержать критерии приемлемости
- Подписаться
Определение готовности
Что нужно для того, чтобы задача считалась завершенной?
Примеры:
- Экспертная оценка двумя членами команды
- Заинтересованная сторона принимает изменения
- 85% покрытие юнит-тестами
- Критерии приемки выполнены
Критерии приемлемости
Вещи, которые добавляют ограничения, чтобы быть проблемой.
Примеры:
- Увеличение NPS на 2 % при покупке (прекрасный пример проверенного обучения)
- Номер телефона Поле ввода для использования маски ввода для конкретной страны
- Отчет можно скачать в формате CSV
- Кевин может получить доступ к экрану учета
Вернемся ко мне, когда я пишу определение готовности (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 минуту, но на самом деле я не вижу, чтобы эта конкретная разница вызывала слишком много проблем.
Вероятно, поэтому никто не смотрел на картину в целом и не пытался понять, как это органично выросло. Более тревожным аспектом является то, что люди привыкли к своим местным традициям и не задумывались о том, чтобы подвергать их сомнению в прошлом. Целесообразно регулярно пересматривать процесс, чтобы убедиться, что он все еще актуален, работает на команду и соответствует цели.
Если люди слепы к своим повседневным делам и практикам, под капотом могут быть более серьезные проблемы, о которых люди не подозревают.
Но в данном случае мы говорим только о второстепенном моменте. Определение определения готово… все будет хорошо…